1. 11 Jun, 2020 1 commit
  2. 09 Dec, 2019 1 commit
  3. 31 Oct, 2019 1 commit
  4. 02 Aug, 2019 1 commit
  5. 30 Jul, 2019 1 commit
  6. 06 Feb, 2019 1 commit
  7. 13 Sep, 2017 1 commit
    • Andrew Heather's avatar
      ENH: Lagrangian - provided backwards compatibility for cases using the · 2defba00
      Andrew Heather authored
      old "positions" file form
      The change to barycentric-based tracking changed the contents of the
      cloud "positions" file to a new format comprising the barycentric
      co-ordinates and other cell position-based info.  This broke
      backwards compatibility, providing no option to restart old cases
      (v1706 and earlier), and caused difficulties for dependent code, e.g.
      for post-processing utilities that could only infer the contents only
      after reading.
      The barycentric position info is now written to a file called
      "coordinates" with provision to restart old cases for which only the
      "positions" file is available. Related utilities, e.g. for parallel
      running and data conversion have been updated to be able to support both
      file types.
      To write the "positions" file by default, use set the following option
      in the InfoSwitches section of the controlDict:
          writeLagrangianPositions 1;
  8. 29 Aug, 2017 1 commit
  9. 23 Aug, 2017 1 commit
  10. 22 Aug, 2017 1 commit
    • Will Bainbridge's avatar
      lagrangian: Un-templated the tracking data · 87c15bf1
      Will Bainbridge authored
      Tracking data classes are no longer templated on the derived cloud type.
      The advantage of this is that they can now be passed to sub models. This
      should allow continuous phase data to be removed from the parcel
      classes. The disadvantage is that every function which once took a
      templated TrackData argument now needs an additional TrackCloudType
      argument in order to perform the necessary down-casting.
  11. 28 Apr, 2017 1 commit
    • Will Bainbridge's avatar
      Lagrangian: Rewrite of the particle tracking algorithm to function in · 743dea87
      Will Bainbridge authored
      terms of the local barycentric coordinates of the current tetrahedron,
      rather than the global coordinate system.
      Barycentric tracking works on any mesh, irrespective of mesh quality.
      Particles do not get "lost", and tracking does not require ad-hoc
      "corrections" or "rescues" to function robustly, because the calculation
      of particle-face intersections is unambiguous and reproducible, even at
      small angles of incidence.
      Each particle position is defined by topology (i.e. the decomposed tet
      cell it is in) and geometry (i.e. where it is in the cell). No search
      operations are needed on restart or reconstruct, unlike when particle
      positions are stored in the global coordinate system.
      The particle positions file now contains particles' local coordinates
      and topology, rather than the global coordinates and cell. This change
      to the output format is not backwards compatible. Existing cases with
      Lagrangian data will not restart, but they will still run from time
      zero without any modification. This change was necessary in order to
      guarantee that the loaded particle is valid, and therefore
      fundamentally prevent "loss" and "search-failure" type bugs (e.g.,
      2517, 2442, 2286, 1836, 1461, 1341, 1097).
      The tracking functions have also been converted to function in terms
      of displacement, rather than end position. This helps remove floating
      point error issues, particularly towards the end of a tracking step.
      Wall bounded streamlines have been removed. The implementation proved
      incompatible with the new tracking algorithm. ParaView has a surface
      LIC plugin which provides equivalent, or better, functionality.
      Additionally, bug report <https://bugs.openfoam.org/view.php?id=2517>
      is resolved by this change.
  12. 30 Nov, 2016 2 commits
  13. 16 Aug, 2016 1 commit
  14. 17 Jun, 2016 1 commit
  15. 02 Jun, 2016 1 commit
    • Mark Olesen's avatar
      ENH: group info about particle output with "{}" etc · 526ecfec
      Mark Olesen authored
      - The only reasonable means of mirroring the data layout.
        The '{}' delimiters mark the extent of the binary writes.
        The primitives 'label' and 'scalar' are directly supported and correspond
        to known byte widths.
        Using "List<scalar>" was a bad choice, since this triggers unpleasant
        tokenizing behaviour. Instead use 'scalars' as a provisional placeholder
        to indicates a list of scalar values. However, there is currently no
        support for actually handling lists of scalars, for several reasons:
         * The information is not available at compile-time.
           The cloud or parcel must be queried. And it must be guaranteed
           that this value is consistent for the entire cloud.
         * Binary output of lists is currently not great for determining the
           the encoded width:
              - A zero-size list is a single '0'.
              - The leading size is a non-constant number of digits.
              - There are prefix/suffix newlines need to be tagged and
        The special '*' (glob) token indicates that the remaining content
        has a dynamic variable length and nothing reasonable can be known
        about their sizes. This is exemplified by the collision records.
  16. 25 Apr, 2016 2 commits
  17. 21 Apr, 2016 1 commit
    • Mark Olesen's avatar
      ENH: add parcel property types (fixes #109) · b6ca9887
      Mark Olesen authored
      - assists in decoding what the binary IO content means
      ENH: use label instead of bool for the KinematicParcel active state (fixes #111)
      - avoids internal padding of the data structure and simplifies
        downstream use.
      ENH: make particle sizeofFields public (fixes #110)
      Also fixes #108 (missing faceI and stepFraction entries) which had
      also been fixed in the upstream as well.
  18. 10 Jan, 2016 1 commit
  19. 22 Feb, 2015 1 commit
  20. 18 Dec, 2014 1 commit
  21. 07 Nov, 2013 1 commit
  22. 05 Nov, 2013 2 commits
  23. 13 Aug, 2013 1 commit
  24. 12 Aug, 2013 1 commit
  25. 06 Aug, 2013 1 commit
  26. 03 May, 2013 1 commit
  27. 21 Aug, 2012 1 commit
  28. 07 Jun, 2012 1 commit
  29. 13 Dec, 2011 1 commit
  30. 14 Aug, 2011 1 commit
  31. 27 May, 2011 1 commit
  32. 24 May, 2011 1 commit
  33. 24 Feb, 2011 1 commit
  34. 15 Feb, 2011 1 commit
  35. 25 Jan, 2011 1 commit
  36. 19 Jan, 2011 1 commit
  37. 14 Jan, 2011 1 commit