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;
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.
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.
- exception calcType.H since it'll most likely be used for building
applications anyhow
- use quailified names in more of the lagrangian code
- killed some tab indents in various places.
- objectRegistry gets a rename() that also adjusts the dbDir
- cloud reworked to use static variables subInstance and defaultName.
This avoids writing "lagrangian" everywhere
string fixes
- avoid masking of std::string::replace in string.H
- avoid old strstream in PV3FoamReader
- can use 'XX.empty()' instead of 'XX.size() == 0', 'XX.size() < 1' or
'XX.size() <= 0' or for simpler coding.
It also has the same number of characters as '!XX.size()' and /might/ be
more readable
- many size checking had 'XX.size() > 0', 'XX.size() != 0', or 'XX.size() >= 1'
when a simple 'XX.size()' suffices
