The splash kinetic energy has been changed to depend upon the velocity
of the parcel normal to the wall, rather than the absolute velocity, in
accordance with the original reference.
This patch was contributed by Stefan Hildenbrand at Pfinder
Resolves bug report https://bugs.openfoam.org/view.php?id=2682
Interpolated continuous phase data is only needed during a track and
therefore shouldn't be stored on the parcel. The continuous velocity,
density and viscosity have been moved from the kinematic parcel to the
kinematic parcel tracking data. This reduces the memory usage of the
kinematic layer by about one third. The thermo and reacting layers still
require the same treatment.
A lot of methods were taking argument data which could be referenced or
generated from the parcel class at little or no additional cost. This
was confusing and generated the possibility of inconsistent data states.
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.
The combined solver includes the most advanced and general functionality from
each solver including:
Continuous phase
Lagrangian multiphase parcels
Optional film
Continuous and Lagrangian phase reactions
Radiation
Strong buoyancy force support by solving for p_rgh
The reactingParcelFoam and reactingParcelFilmFoam tutorials have been combined
and updated.
and the continuous-phase simulation type
For LTS and steady-state simulations the transient option does not need to be
provided as only steady-state tracking is appropriate. For transient running
the Lagrangian tracking may be steady or transient.
The evolution of a KinematicParcel happens in three stages; (1) tracking
across the cell, (2) interaction with the face or patch that has been
hit, and (3) clculation and and update of parcel and cell properties.
The KinematicParcel used to evolve in this order, as steps 1 and 2 were
part of the same lower level method. This meant that the update stage
was done after interacting with the face, meaning the parcel was not in
the cell that had just been tracked through, or, by means of a patch
interaction, had been modified such that it was no longer representative
of the track through the cell.
With the separation of stages 1 and 2 in the base class, it is now
possible to do the update stage before interacting with the face (i.e.,
proceeding in the order 1, 3, 2). This makes the state consistent for
the updates, and avoids the issues described.
Patch contributed by Timo Niemi, VTT.
This resolves bug report https://bugs.openfoam.org/view.php?id=2282
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.
The TrackData::switchProcessor flag was not being set for some of the
tracking steps made by the more complicated parcels. In the case that a
parcel starts the step already on a processor boundary, this sometimes
lead to the particle being transferred back and forth indefinitely. The
flag is now explicitly set in all cases.
