Integration of VOF MULES new interfaces. Update of VOF solvers and all instances
of MULES in the code.
Integration of reactingTwoPhaseEuler and reactingMultiphaseEuler solvers and sub-models
Updating reactingEuler tutorials accordingly (most of them tested)
New eRefConst thermo used in tutorials. Some modifications at thermo specie level
affecting mostly eThermo. hThermo mostly unaffected
New chtMultiRegionTwoPhaseEulerFoam solver for quenching and tutorial.
Phases sub-models for reactingTwoPhaseEuler and reactingMultiphaseEuler were moved
to src/phaseSystemModels/reactingEulerFoam in order to be used by BC for
chtMultiRegionTwoPhaseEulerFoam.
Update of interCondensatingEvaporatingFoam solver.
- If applied:
This commit allows the user to compute:
- the Lamb vector (https://en.wikipedia.org/wiki/Lamb_vector),
- on-the-fly or via postProcess utility
- for a given volVectorField (one per functionObject entry)
- Why:
The motivation is the literature-reported quantitative connection
between the Lamb vector (divergence) and the spatially localised
instantaneous fluid motions, e.g. high- and low-momentum fluid
parcels, which possess considerable level of capacity to affect
the rate of change of momentum, and to generate forces such as drag.
- Verification:
- Smooth-wall plane channel flow case (Moser et al. 1999) by
# Curtis et al. (2008) On the Lamb vector divergence
in Navier–Stokes flows, doi:10.1017/S0022112008002760
- What's next:
- The verification-show case
- Extended code guide entry titled "Lamb vector"
Calculates and outputs the pressure fields p_rgh and ph_rgh based on the
option that was previously hard-coded in the fireFoam solver
Usage
Example of function object specification to calculate hydrostatic pressure:
\verbatim
hydrostaticPressure1
{
type hydrostaticPressure;
libs ("libinitialisationFunctionObjects.so");
...
}
\endverbatim
Where the entries comprise:
\table
Property | Description | Required | Default value
log | Log to standard output | no | yes
p_rgh | Name of p_rgh field | no | p_rgh
ph_rgh | Name of ph_rgh field | no | ph_rgh
pRef | Name of pressure ref field | no | pRef
rho | Name of density field | no | rho
U | Name of velocity field | no | U
gh | Name of gravity*height volume field | no | gh
ghf | Name of gravity*height surface field | no | ghf
nCorrectors | Number of correctors when solving ph_rgh | no | 5
\endtable
Note
Calculates the hydrostatic pressure on construction/re-initialisation;
the execute and write functions are not used.
- for codedFunctionObject and CodedSource the main code snippets
were not included in the SHA1 calculation, which meant that many
changes would not be noticed and no new library would be compiled.
As a workaround, a dummy 'code' entry could be used solely for the
purposes of generating a SHA1, but this is easily forgotten.
We now allow tracking of the dynamicCodeContext for the coded
objects and append to the SHA1 hasher with specific entries.
This should solve the previous misbehaviour.
We additionally add information about the ordering of the code
sections. Suppose we have a coded function object (all code
segments are optional) with the following:
codeExecute "";
codeWrite #{ Info<< "Called\n"; #};
which we subsequently change to this:
codeExecute #{ Info<< "Called\n"; #};
codeWrite "";
If the code strings are simply concatenated together, the SHA1 hashes
will be identical. We thus 'salt' with their semantic locations,
choosing tags that are unlikely to occur within the code strings
themselves.
- simplify the coded templates with constexpr for the SHA1sum
information.
- Correct the CodedSource to use 'codeConstrain' instead of
'codeSetValue' for consistency with the underlying functions.
- Eg, with surface writers now in surfMesh, there are fewer libraries
depending on conversion and sampling.
COMP: regularize linkage ordering and avoid some implicit linkage (#1238)
- prior to sampledSurface supporting different interpolation schemes a
workaround means was used to simulate cellPoint -> face
interpolation, with averaging of vertex interpolation.
We instead now use cellPoint interpolation directly for the face
values when 'interpolate=true'.
- Extended runTimePostProcessing to include access to "live"
simulation objects such a geometry patches and sampled surfaces
stored on the "functionObjectObjects" registry.
- Add 'live' runTimePostProcessing of cloud data.
Extracts position and fields from the cloud via its objectRegistry writer
- For the "live" simulation objects, there are two new volume filters
that work directly with the OpenFOAM volume fields:
* iso-surface
* cutting planes
Both use the VTK algorithms directly and support multiple values.
Eg, can make multiple iso-levels or multiple planes parallel to each
other.
- When VTK has been compiled with MPI-support, parallel rendering will
be used.
- Additional title text properties (shadow, italic etc)
- Simplified handling of scalar-bar and visibility switches
- Support multiple text positions. Eg, for adding watermark text.
- fits better into the general sampling framework, improves flexibilty
and allows code reduction.
ENH: include surface fields on sampledSurfaces that support it
- The writers have changed from being a generic state-less set of
routines to more properly conforming to the normal notion of a writer.
These changes allow us to combine output fields (eg, in a single
VTK/vtp file for each timestep).
Parallel data reduction and any associated bookkeeping is now part
of the surface writers.
This improves their re-usability and avoids unnecessary
and premature data reduction at the sampling stage.
It is now possible to have different output formats on a per-surface
basis.
- A new feature of the surface sampling is the ability to "store" the
sampled surfaces and fields onto a registry for reuse by other
function objects.
Additionally, the "store" can be triggered at the execution phase
as well
- similar to what erase() does, but as a mutable operation (#1180)
- replace basicThermo lookupAndCheckout (commit 880c98757d) with
the new objectRegistry::checkOut() method.
