GitLab

- additional rcEdge(), rcEdges() methods for reverse order walk

- accept generic edge() method as alternative to faceEdge() for
  single edge retrieval.

- edge() method with points -> returns the vector

- reduce the number of operations in edgeDirection methods

DEFEATURE: remove longestEdge global function

- deprecated and replaced by face::longestEdge() method (2017-04)

- eliminates a potentially invalid code branch.
  Since it essentially had the same internals as std::swap anyhow,
  make that more evident.

ENH: use std::swap for basic types

- makes it clearer that they do not rely on any special semantics

1) Small modification to the tracking logic for detA zero.
2) Adding small vector displacement to locate function to avoid error where
particle is inserted at the cell centre.

Was checking the old celli instead of the result of
re-finding the position. See also Foundation commit 50a965f8866683a81d79cbc7811af7333baf9d10.

Sergio Ferraris authored Aug 28, 2020 and Andrew Heather committed Dec 17, 2020

- Dealing with detA < 0 tracking issues
- Modified locate function

- a top-level cloud::nParcels() virtual, which is overloaded by the
  first level of Cloud inheritance. This permits quick determination of
  cloud sizes, even when retrieved from registry with the base level.
  Eg,
      cloud* cldPtr = mesh.cfindObject<cloud>("myCloud");
      label nParcels = (cldPtr ? cldPtr->nParcels() : 0);

- make writeLagrangianPositions on by default unless explicitly
  disabled in the InfoSwitches.

  Flag output errors (where neither coordinates nor positions are
  written) with Fatal.

- additional IOField helper functions in cloud

STYLE: simplify iterator inheritance

- remove writeLagrangianCoordinates as InfoSwitch, since this is
  something that a regular user should not be able to disable.

- change "\%" -> "%" in plain string

Will Bainbridge authored Mar 13, 2018 and Andrew Heather committed Mar 13, 2018

Resolves bug report https://bugs.openfoam.org/view.php?id=2871

Will Bainbridge authored Sep 12, 2017 and Andrew Heather committed Sep 12, 2017

The 4.x tracking enforces reduced dimensionality on the parcels by
moving them to the centre of the mesh at the start of each track,
without considering the topology. This can leave the parcel outside it's
associated tetrahedron.

The barycentric algorithm isn't tolerant to incorrect topology, so
instead of changing position, it was written to track to the mesh
centre. This worked, but effectively doubled the number of tracking
calls. This additional cost has now been removed by absorbing the
constraint displacement into the existing motion track, so that the same
number of tracking steps are performed as before.

Partially resolves bug report https://bugs.openfoam.org/view.php?id=2688

Note: performs its own tracking and does not rely on the base
particle::trackXXX functions, and uses a local particle position.

Look to update to barycentric tracking in the future.

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;

Will Bainbridge authored Aug 09, 2017 and Andrew Heather committed Aug 09, 2017

Particle collisions with ACMI patches are now handled. The hit detects
whether the location is within the overlap or the coupled region and
recurses, calling the hit routine appropriate for the region.

The low level tracking methods are now more consistently named. There is
now a distinction between tracking to a face and hitting it. Function
object side effects have been moved out of the base layer and into the
parcels on which they are meaningful.

Will Bainbridge authored Jul 18, 2017 and Andrew Heather committed Jul 18, 2017

Tracking through an inverted region of the mesh happens in a reversed
direction relative to a non-inverted region. Usually, this allows the
tracking to propagate normally, regardless of the sign of the space.
However, in rare cases, it is possible for a straight trajectory to form
a closed loop through both positive and negative regions. This causes
the tracking to loop indefinitely.

To fix this, the displacement through inverted regions has been
artifically increased by a small amount (1% at the moment). This has the
effect that the change in track fraction over the negative part of the
loop no longer exactly cancels the change over the positive part, and
the track therefore terminates.

Will Bainbridge authored Jul 13, 2017 and Andrew Heather committed Jul 13, 2017

The KinematicCloud::patchData method has been made consistent on moving
meshes and/or when the time-step is being sub-cycled.

It has also been altered to calculate the normal component of a moving
patch's velocity directly from the point motions. This prevents an
infinite loop occuring due to inconsistency between the velocity used to
calculate a rebound and that used when tracking.

Some minor style improvements to the particle class have also been made.

Will Bainbridge authored Jun 01, 2017 and Andrew Heather committed Jun 01, 2017

The logic for generating tetrahedra from a face base point and an offset
was duplicated in a few places. It is now confined to the tetIndices
class.

Will Bainbridge authored Apr 28, 2017 and Andrew Heather committed Apr 28, 2017

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.