- additional coefficients:
- Side force coefficient: direction in curl(lift,drag),
- Yaw moment coefficient: rotation axis in dir(lift)
- Roll moment coefficient: rotation axis in dir(drag)
Order of output
- forces(drag,side,lift)
- moments(roll,pitch,yaw)
Note
- For force coeffs, front and rear axles' contributions are computed
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'.
