Reduce the number of phaseSystems libraries:
- phaseSystems previously had a number of smaller libraries to provide
interface and model properties, etc. This potential flexibility was
never actually used anywhere, but causes cyclic dependencies between
phaseSystem and the models (and turbulence) that causes extreme
difficulty for mingw linking (issue #1238).
- libincompressibleMultiphaseSystems
- removed: libmassTransferModels
- libmultiphaseSystem
- removed: libcompressibleMultiphaseEulerianInterfacialModels
- libreactingMultiphaseSystem
- removed: libreactingPhaseSystem
- removed: libreactingEulerianFvPatchFields
- removed: libreactingEulerianInterfacialCompositionModels
- removed: libreactingEulerianInterfacialModels
- removed: libmultiphaseReactingTurbulenceModels
- libreactingTwoPhaseSystem
- removed: libreactingPhaseSystem
- removed: libreactingEulerianFvPatchFields
- removed: libreactingEulerianInterfacialCompositionModels
- removed: libreactingEulerianInterfacialModels
Avoid duplicate symbol for phaseCompressibleTurbulenceModels
Common turbulence models are defined in libreactingMultiphaseSystem,
and libmultiphaseReactingTurbulenceModels is now redundant.
The libtwoPhaseReactingTurbulenceModels extends the common models
for reactingTwoPhaseSystem.
1) Implementation of the compressibleIsoInterFOam solver
2) Implementation of a new PLIC interpolation scheme.
3) New tutorials associated with the solvers
This implementation was carried out by Henning Scheufler (DLR) and Johan
Roenby (DHI), following :
\verbatim
Henning Scheufler, Johan Roenby,
Accurate and efficient surface reconstruction from volume fraction data
on general meshes, Journal of Computational Physics, 2019, doi
10.1016/j.jcp.2019.01.009
\endverbatim
The integration of the code was carried out by Andy Heather and Sergio
Ferraris from OpenCFD Ltd.
- previously introduced `getOrDefault` as a dictionary _get_ method,
now complete the transition and use it everywhere instead of
`lookupOrDefault`. This avoids mixed usage of the two methods that
are identical in behaviour, makes for shorter names, and promotes
the distinction between "lookup" access (ie, return a token stream,
locate and return an entry) and "get" access (ie, the above with
conversion to concrete types such as scalar, label etc).
1) Add interfaceHeatResistance model to icoReactingMultiphaseInterFoam
This model uses a spread source for the continuity Eq.
It is recommended for cases with good mesh resolution.
2) Adding iso-surface type of calculation for the interface for
the kineticGasEvaporation model
3) Add switch for option to take into account volume change
4) Add poolEvaporation tutorial
1) Adding interfaceHeight FO
2) Adding interfaceHeatResistance mass transfer model to
interCondensatingEvaporatingFoam with spread source approach
3) Reworking framework for icoReactingMultiphaseInterFoam
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.
Modified revert of commit 6c6f777bd5.
- The "alphaContactAngleFvPatchScalarField" occurs in several
places in the code base:
- as abstract class for two-phase properties
- in various multiphase solvers
To resolve potential linking conflicts, renamed the abstract class
as "alphaContactAngleTwoPhaseFvPatchScalarField" instead.
This permits potential linking of two-phase and multi-phase
libraries without symbol conflicts and has no effect on concrete
uses of two-phase alphaContactAngle boudary conditions.
ENH: Several modifycations to avoid erroneuos rays to be shot
from wrong faces.
ENH: Updating tutorials and avoiding registration of the
coarse singleCellFvMesh
Adding solarLoad tutorial case simpleCarSolarPanel
ENH: Changes needed for the merge
- 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)
- Can result in inadvertent conversions where the user should really
know or check if the pointer is valid prior to using.
- Still have several places to fix that are using the deprecated copy
construct and copy assignment
- accidentally introduced by 27c62303ad
STYLE: trial use of brace-initialized dimensionSet
- instead of writing
dimensionedScalar(dimensionSet(1, -2, -2, 0, 0, 0), Zero);
we can use C++11 brace-initialization to bundle the parameters
for the dimensionSet construction and simply write
dimensionedScalar({1, -2, -2, 0, 0, 0}, Zero);
Note the following is incorrect syntax (extra brackets):
dimensionedScalar(({1, -2, -2, 0, 0, 0}), Zero);
- provide a lookupOrDefault constructor form, since this is a fairly
commonly used requirement and simplifies the calling sequence.
Before
dimensionedScalar rhoMax
(
dimensionedScalar::lookupOrDefault
(
"rhoMax",
pimple.dict(),
dimDensity,
GREAT
)
);
After
dimensionedScalar rhoMax("rhoMax", dimDensity, GREAT, pimple.dict());
- read, readIfPresent methods with alternative lookup names.
- Mark the Istream related constructors with compile-time deprecated
warnings.
BUG: read, readIfPresent methods not handling optional dimensions (#1148)
- makes the intent clearer and avoids the need for additional
constructor casting. Eg,
labelList(10, Zero) vs. labelList(10, 0)
scalarField(10, Zero) vs. scalarField(10, scalar(0))
vectorField(10, Zero) vs. vectorField(10, vector::zero)
- for some special cases we wish to mark command-line arguments as
being optional, in order to do our own treatment. For example,
when an arbitrary number of arguments should be allowed.
Now tag this situation with argList::noMandatoryArgs().
The argList::argsMandatory() query can then be used in any further
logic, including the standard default argument checking.
- with the new default check, can consolidate the special-purpose
"setRootCaseNonMandatoryArgs.H"
into the regular
"setRootCase.H"
- revert to a simple "setRootCase.H" and move all the listing related
bits to a "setRootCaseLists.H" file. This leaves the information
available for solvers, or whoever else wishes, without being
introduced everywhere.
- add include guards and scoping to the listing files and rename to
something less generic.
listOptions.H -> setRootCaseListOptions.H
listOutput.H -> setRootCaseListOutput.H