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.
- changed the sectorCoeffs keyword to 'point' from 'axisPt'
for more similarity with other dictionaries.
Continue to accept 'axisPt' for compatibility.
- helps reduce clutter in the topoSetDict files.
Caveats when using this.
The older specification styles using "name" will conflict with the
set name. Eg,
{
name f0
type faceSet;
action add;
source patchToFace;
sourceInfo
{
name inlet;
}
}
would flattened to the following
{
name f0
type faceSet;
action add;
source patchToFace;
name inlet;
}
which overwrites the "name" used for the faceSet.
The solution is to use the updated syntax:
{
name f0
type faceSet;
action add;
source patchToFace;
patch inlet;
}
- old 'DELETE' enum was easily confused with 'REMOVE', which removes
the set, not the elements from the set.
- provide corresponding subtractSet() method
STYLE: HashSet set/unset instead of insert/erase methods in topoSetSource
- simplifies switching to/from bitSet storage
Update of overRhoPimpleDyMFoam and overInterDyMFoam solvers.
Adding corresponding tutorials with best possible settings
The main effort was put on reducing pressure spikes as the
stencil change with hole cells on the background mesh.
Previously the coordinate system functionality was split between
coordinateSystem and coordinateRotation. The coordinateRotation stored
the rotation tensor and handled all tensor transformations.
The functionality has now been revised and consolidated into the
coordinateSystem classes. The sole purpose of coordinateRotation
is now just to provide a selectable mechanism of how to define the
rotation tensor (eg, axis-angle, euler angles, local axes) for user
input, but after providing the appropriate rotation tensor it has
no further influence on the transformations.
--
The coordinateSystem class now contains an origin and a base rotation
tensor directly and various transformation methods.
- The origin represents the "shift" for a local coordinate system.
- The base rotation tensor represents the "tilt" or orientation
of the local coordinate system in general (eg, for mapping
positions), but may require position-dependent tensors when
transforming vectors and tensors.
For some coordinate systems (currently the cylindrical coordinate system),
the rotation tensor required for rotating a vector or tensor is
position-dependent.
The new coordinateSystem and its derivates (cartesian, cylindrical,
indirect) now provide a uniform() method to define if the rotation
tensor is position dependent/independent.
The coordinateSystem transform and invTransform methods are now
available in two-parameter forms for obtaining position-dependent
rotation tensors. Eg,
... = cs.transform(globalPt, someVector);
In some cases it can be useful to use query uniform() to avoid
storage of redundant values.
if (cs.uniform())
{
vector xx = cs.transform(someVector);
}
else
{
List<vector> xx = cs.transform(manyPoints, someVector);
}
Support transform/invTransform for common data types:
(scalar, vector, sphericalTensor, symmTensor, tensor).
====================
Breaking Changes
====================
- These changes to coordinate systems and rotations may represent
a breaking change for existing user coding.
- Relocating the rotation tensor into coordinateSystem itself means
that the coordinate system 'R()' method now returns the rotation
directly instead of the coordinateRotation. The method name 'R()'
was chosen for consistency with other low-level entities (eg,
quaternion).
The following changes will be needed in coding:
Old: tensor rot = cs.R().R();
New: tensor rot = cs.R();
Old: cs.R().transform(...);
New: cs.transform(...);
Accessing the runTime selectable coordinateRotation
has moved to the rotation() method:
Old: Info<< "Rotation input: " << cs.R() << nl;
New: Info<< "Rotation input: " << cs.rotation() << nl;
- Naming consistency changes may also cause code to break.
Old: transformVector()
New: transformPrincipal()
The old method name transformTensor() now simply becomes transform().
====================
New methods
====================
For operations requiring caching of the coordinate rotations, the
'R()' method can be used with multiple input points:
tensorField rots(cs.R(somePoints));
and later
Foam::transformList(rots, someVectors);
The rotation() method can also be used to change the rotation tensor
via a new coordinateRotation definition (issue #879).
The new methods transformPoint/invTransformPoint provide
transformations with an origin offset using Cartesian for both local
and global points. These can be used to determine the local position
based on the origin/rotation without interpreting it as a r-theta-z
value, for example.
================
Input format
================
- Streamline dictionary input requirements
* The default type is cartesian.
* The default rotation type is the commonly used axes rotation
specification (with e1/e2/3), which is assumed if the 'rotation'
sub-dictionary does not exist.
Example,
Compact specification:
coordinateSystem
{
origin (0 0 0);
e2 (0 1 0);
e3 (0.5 0 0.866025);
}
Full specification (also accepts the longer 'coordinateRotation'
sub-dictionary name):
coordinateSystem
{
type cartesian;
origin (0 0 0);
rotation
{
type axes;
e2 (0 1 0);
e3 (0.5 0 0.866025);
}
}
This simplifies the input for many cases.
- Additional rotation specification 'none' (an identity rotation):
coordinateSystem
{
origin (0 0 0);
rotation { type none; }
}
- Additional rotation specification 'axisAngle', which is similar
to the -rotate-angle option for transforming points (issue #660).
For some cases this can be more intuitive.
For example,
rotation
{
type axisAngle;
axis (0 1 0);
angle 30;
}
vs.
rotation
{
type axes;
e2 (0 1 0);
e3 (0.5 0 0.866025);
}
- shorter names (or older longer names) for the coordinate rotation
specification.
euler EulerRotation
starcd STARCDRotation
axes axesRotation
================
Coding Style
================
- use Foam::coordSystem namespace for categories of coordinate systems
(cartesian, cylindrical, indirect). This reduces potential name
clashes and makes a clearer declaration. Eg,
coordSystem::cartesian csys_;
The older names (eg, cartesianCS, etc) remain available via typedefs.
- added coordinateRotations namespace for better organization and
reduce potential name clashes.
- improve doxygen entries for searchable surfaces.
- support selection of searchable surfaces with shorter names.
Eg,
type box | cylinder | ...;
vs type searchableBox | searchableCylinder | ...;
- functionObjectLibs -> libs
- redirectType -> name
- change deprecated writeCompression flags types to Switch.
- cleanup some trailing ';;' from some dictionaries
- Updated tutorial headers
- Added copyright note to isoAdvector src
- Removed outcommented code lines in interIsoFoam solver
- Removed all LTS from interIsoFoam since this is not currently supported
- Confirmed that discInConstantFlow gives identical results with N subCylces and time step N*dt
- Confirmed that this also holds when nOuterCorrectors > 1.
- the expansions were previously required as slash to follow, but
now either are possible.
"<case>", "<case>/" both yield the same as "$FOAM_CASE" and
will not have a trailing slash in the result. The expansion of
"$FOAM_CASE/" will however have a trailing slash.
- adjust additional files using these expansions
Support the following expansions when they occur at the start of a
string:
Short-form Equivalent
========= ===========
<etc>/ ~OpenFOAM/ (as per foamEtcFile)
<case>/ $FOAM_CASE/
<constant>/ $FOAM_CASE/constant/
<system>/ $FOAM_CASE/system/
These can be used in fileName expansions to improve clarity and reduce
some typing
"<constant>/reactions" vs "$FOAM_CASE/constant/reactions"
The combustion and chemistry models no longer select and own the
thermodynamic model; they hold a reference instead. The construction of
the combustion and chemistry models has been changed to require a
reference to the thermodyanmics, rather than the mesh and a phase name.
At the solver-level the thermo, turbulence and combustion models are now
selected in sequence. The cyclic dependency between the three models has
been resolved, and the raw-pointer based post-construction step for the
combustion model has been removed.
The old solver-level construction sequence (typically in createFields.H)
was as follows:
autoPtr<combustionModels::psiCombustionModel> combustion
(
combustionModels::psiCombustionModel::New(mesh)
);
psiReactionThermo& thermo = combustion->thermo();
// Create rho, U, phi, etc...
autoPtr<compressible::turbulenceModel> turbulence
(
compressible::turbulenceModel::New(rho, U, phi, thermo)
);
combustion->setTurbulence(*turbulence);
The new sequence is:
autoPtr<psiReactionThermo> thermo(psiReactionThermo::New(mesh));
// Create rho, U, phi, etc...
autoPtr<compressible::turbulenceModel> turbulence
(
compressible::turbulenceModel::New(rho, U, phi, *thermo)
);
autoPtr<combustionModels::psiCombustionModel> combustion
(
combustionModels::psiCombustionModel::New(*thermo, *turbulence)
);
ENH: combustionModel, chemistryModel: Simplified model selection
The combustion and chemistry model selection has been simplified so
that the user does not have to specify the form of the thermodynamics.
Examples of new combustion and chemistry entries are as follows:
In constant/combustionProperties:
combustionModel PaSR;
combustionModel FSD;
In constant/chemistryProperties:
chemistryType
{
solver ode;
method TDAC;
}
All the angle bracket parts of the model names (e.g.,
<psiThermoCombustion,gasHThermoPhysics>) have been removed as well as
the chemistryThermo entry.
The changes are mostly backward compatible. Only support for the
angle bracket form of chemistry solver names has been removed. Warnings
will print if some of the old entries are used, as the parts relating to
thermodynamics are now ignored.
ENH: combustionModel, chemistryModel: Simplified model selection
Updated all tutorials to the new format
STYLE: combustionModel: Namespace changes
Wrapped combustion model make macros in the Foam namespace and removed
combustion model namespace from the base classes. This fixes a namespace
specialisation bug in gcc 4.8. It is also somewhat less verbose in the
solvers.
This resolves bug report https://bugs.openfoam.org/view.php?id=2787
ENH: combustionModels: Default to the "none" model
When the constant/combustionProperties dictionary is missing, the solver
will now default to the "none" model. This is consistent with how
radiation models are selected.
and replaced interDyMFoam with a script which reports this change.
The interDyMFoam tutorials have been moved into the interFoam directory.
This change is one of a set of developments to merge dynamic mesh functionality
into the standard solvers to improve consistency, usability, flexibility and
maintainability of these solvers.
Henry G. Weller
CFD Direct Ltd.
interMixingFoam, multiphaseInterFoam: Updated for changes to interFoam
Within decomposeParDict, it is now possible to specify a different
decomposition method, methods coefficients or number of subdomains
for each region individually.
The top-level numberOfSubdomains remains mandatory, since this
specifies the number of domains for the entire simulation.
The individual regions may use the same number or fewer domains.
Any optional method coefficients can be specified in a general
"coeffs" entry or a method-specific one, eg "metisCoeffs".
For multiLevel, only the method-specific "multiLevelCoeffs" dictionary
is used, and is also mandatory.
----
ENH: shortcut specification for multiLevel.
In addition to the longer dictionary form, it is also possible to
use a shorter notation for multiLevel decomposition when the same
decomposition method applies to each level.
Correcting thermoSingleLayer.C mask field alpha to avoid heat sources where there is no film.
Tunning fvSolution for alpha for twoPhasePachuka tutorial
Resolves bug-report https://bugs.openfoam.org/view.php?id=2785
ENH: compressibleInterFoam family: merged two-phase momentum stress modelling from compressibleInterPhaseTransportFoam
The new momentum stress model selector class
compressibleInterPhaseTransportModel is now used to select between the options:
Description
Transport model selection class for the compressibleInterFoam family of
solvers.
By default the standard mixture transport modelling approach is used in
which a single momentum stress model (laminar, non-Newtonian, LES or RAS) is
constructed for the mixture. However if the \c simulationType in
constant/turbulenceProperties is set to \c twoPhaseTransport the alternative
Euler-Euler two-phase transport modelling approach is used in which separate
stress models (laminar, non-Newtonian, LES or RAS) are instantiated for each
of the two phases allowing for different modeling for the phases.
Mixture and two-phase momentum stress modelling is now supported in
compressibleInterFoam, compressibleInterDyMFoam and compressibleInterFilmFoam.
The prototype compressibleInterPhaseTransportFoam solver is no longer needed and
has been removed.
- Arrhenius viscocity model for incompressible viscocity.
- energyTransport FO for incompressible single and multiple phase
flows and viscousDissipation fvOption source.
- Tutorial to show the use of energyTransport:
multiphase/multiphaseInterFoam/laminar/mixerVessel2D
- Tutorial to show viscousDissipation:
compressible/rhoPimpleFoam/RAS/TJunction
In this version of compressibleInterFoam separate stress models (laminar,
non-Newtonian, LES or RAS) are instantiated for each of the two phases allowing
for completely different modeling for the phases.
e.g. in the climbingRod tutorial case provided a Newtonian laminar model is
instantiated for the air and a Maxwell non-Newtonian model is instantiated for
the viscoelastic liquid. To stabilize the Maxwell model in regions where the
liquid phase-fraction is 0 the new symmTensorPhaseLimitStabilization fvOption is
applied.
Other phase stress modeling combinations are also possible, e.g. the air may be
turbulent but the liquid laminar and an RAS or LES model applied to the air
only. However, to stabilize this combination a suitable fvOption would need to
be applied to the turbulence properties where the air phase-fraction is 0.
Henry G. Weller, Chris Greenshields
CFD Direct Ltd.
- although this has been supported for many years, the tutorials
continued to use "convertToMeters" entry, which is specific to blockMesh.
The "scale" is more consistent with other dictionaries.
ENH:
- ignore "scale 0;" (treat as no scaling) for blockMeshDict,
consistent with use elsewhere.
- allows configuration without an environment variable.
For compatibility still respect FOAM_SIGFPE and FOAM_SETNAN
env-variables
- The env-variables are now treated as true/false switch values.
Previously there was just a check for env exists or not, but this
can be fairly fragile for a user's environment.
Community contribution from Johan Roenby, DHI
IsoAdvector is a geometric Volume-of-Fluid method for advection of a
sharp interface between two incompressible fluids. It works on both
structured and unstructured meshes with no requirements on cell shapes.
IsoAdvector is as an alternative choice for the interface compression
treatment with the MULES limiter implemented in the interFoam family
of solvers.
The isoAdvector concept and code was developed at DHI and was funded
by a Sapere Aude postdoc grant to Johan Roenby from The Danish Council
for Independent Research | Technology and Production Sciences (Grant-ID:
DFF - 1337-00118B - FTP).
Co-funding is also provided by the GTS grant to DHI from the Danish
Agency for Science, Technology and Innovation.
The ideas behind and performance of the isoAdvector scheme is
documented in:
Roenby J, Bredmose H, Jasak H. 2016 A computational method for sharp
interface advection. R. Soc. open sci. 3: 160405.
[http://dx.doi.org/10.1098/rsos.160405](http://dx.doi.org/10.1098/rsos.160405)
Videos showing isoAdvector's performance with a number of standard
test cases can be found in this youtube channel:
https://www.youtube.com/channel/UCt6Idpv4C8TTgz1iUX0prAA
Project contributors:
* Johan Roenby <jro@dhigroup.com> (Inventor and main developer)
* Hrvoje Jasak <hrvoje.jasak@fsb.hr> (Consistent treatment of
boundary faces including processor boundaries, parallelisation,
code clean up
* Henrik Bredmose <hbre@dtu.dk> (Assisted in the conceptual
development)
* Vuko Vukcevic <vuko.vukcevic@fsb.hr> (Code review, profiling,
porting to foam-extend, bug fixing, testing)
* Tomislav Maric <tomislav@sourceflux.de> (Source file
rearrangement)
* Andy Heather <a.heather@opencfd.co.uk> (Integration into OpenFOAM
for v1706 release)
See the integration repository below to see the full set of changes
implemented for release into OpenFOAM v1706
https://develop.openfoam.com/Community/Integration-isoAdvector
Adding special alphaCourantNo for overlaping
Adding bounded term to UEq.H for overInterDyMFoam
Changing to NO_WRITE for the cellMask field
Changing twoSimpleRotors tutorial to open domain
Adds overset discretisation to selected physics:
- diffusion : overLaplacianDyMFoam
- incompressible steady : overSimpleFoam
- incompressible transient : overPimpleDyMFoam
- compressible transient: overRhoPimpleDyMFoam
- two-phase VOF: overInterDyMFoam
The overset method chosen is a parallel, fully implicit implementation
whereby the interpolation (from donor to acceptor) is inserted as an
adapted discretisation on the donor cells, such that the resulting matrix
can be solved using the standard linear solvers.
Above solvers come with a set of tutorials, showing how to create and set-up
simple simulations from scratch.
