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.
- Use on/off vs longer compressed/uncompressed.
For consistency, replaced yes/no with on/off.
- Avoid the combination of binary/compressed,
which is disallowed and provokes a warning anyhow
except turbulence and lagrangian which will also be updated shortly.
For example in the nonNewtonianIcoFoam offsetCylinder tutorial the viscosity
model coefficients may be specified in the corresponding "<type>Coeffs"
sub-dictionary:
transportModel CrossPowerLaw;
CrossPowerLawCoeffs
{
nu0 [0 2 -1 0 0 0 0] 0.01;
nuInf [0 2 -1 0 0 0 0] 10;
m [0 0 1 0 0 0 0] 0.4;
n [0 0 0 0 0 0 0] 3;
}
BirdCarreauCoeffs
{
nu0 [0 2 -1 0 0 0 0] 1e-06;
nuInf [0 2 -1 0 0 0 0] 1e-06;
k [0 0 1 0 0 0 0] 0;
n [0 0 0 0 0 0 0] 1;
}
which allows a quick change between models, or using the simpler
transportModel CrossPowerLaw;
nu0 [0 2 -1 0 0 0 0] 0.01;
nuInf [0 2 -1 0 0 0 0] 10;
m [0 0 1 0 0 0 0] 0.4;
n [0 0 0 0 0 0 0] 3;
if quick switching between models is not required.
To support this more convenient parameter specification the inconsistent
specification of seedSampleSet in the streamLine and wallBoundedStreamLine
functionObjects had to be corrected from
// Seeding method.
seedSampleSet uniform; //cloud; //triSurfaceMeshPointSet;
uniformCoeffs
{
type uniform;
axis x; //distance;
// Note: tracks slightly offset so as not to be on a face
start (-1.001 -0.05 0.0011);
end (-1.001 -0.05 1.0011);
nPoints 20;
}
to the simpler
// Seeding method.
seedSampleSet
{
type uniform;
axis x; //distance;
// Note: tracks slightly offset so as not to be on a face
start (-1.001 -0.05 0.0011);
end (-1.001 -0.05 1.0011);
nPoints 20;
}
which also support the "<type>Coeffs" form
// Seeding method.
seedSampleSet
{
type uniform;
uniformCoeffs
{
axis x; //distance;
// Note: tracks slightly offset so as not to be on a face
start (-1.001 -0.05 0.0011);
end (-1.001 -0.05 1.0011);
nPoints 20;
}
}
For example the actuationDiskSource fvOption may now be specified
disk1
{
type actuationDiskSource;
fields (U);
selectionMode cellSet;
cellSet actuationDisk1;
diskDir (1 0 0); // Orientation of the disk
Cp 0.386;
Ct 0.58;
diskArea 40;
upstreamPoint (581849 4785810 1065);
}
rather than
disk1
{
type actuationDiskSource;
active on;
actuationDiskSourceCoeffs
{
fields (U);
selectionMode cellSet;
cellSet actuationDisk1;
diskDir (1 0 0); // Orientation of the disk
Cp 0.386;
Ct 0.58;
diskArea 40;
upstreamPoint (581849 4785810 1065);
}
}
but this form is supported for backward compatibility.
Main changes in the tutorial:
- General cleanup of the phaseProperties of unnecessary entries
- sensibleEnthalpy is used for both phases
- setTimeStep functionObject is used to set a sharp reduction in time step near the start of the injection
- Monitoring of pressure minimum and maximum
Patch contributed by Juho Peltola, VTT.
Description
Temperature-dependent surface tension model in which the surface tension
function provided by the phase Foam::liquidProperties class is used.
Usage
\table
Property | Description | Required | Default value
phase | Phase name | yes |
\endtable
Example of the surface tension specification:
\verbatim
sigma
{
type liquidProperties;
phase water;
}
\endverbatim
for use with e.g. compressibleInterFoam, see
tutorials/multiphase/compressibleInterFoam/laminar/depthCharge2D
These models have been particularly designed for use in the VoF solvers, both
incompressible and compressible. Currently constant and temperature dependent
surface tension models are provided but it easy to write models in which the
surface tension is evaluated from any fields held by the mesh database.
Demonstrates meshing a cylinder with hemispehrical ends using snappyHexMesh with
a polar background mesh that uses the point and edge projection feature of blockMesh.
The case prescribes a multiMotion on the cylinder, combining an oscillatingLinearMotion
and transverse rotatingMotion.
This allows single, multi-phase and VoF compressible simulations to be performed
with the accurate thermophysical property functions for liquids provided by the
liquidProperty classes. e.g. in the
multiphase/compressibleInterFoam/laminar/depthCharge2D tutorial water can now be
specified by
thermoType
{
type heRhoThermo;
mixture pureMixture;
properties liquid;
energy sensibleInternalEnergy;
}
mixture
{
H2O;
}
as an alternative to the previous less accurate representation defined by
thermoType
{
type heRhoThermo;
mixture pureMixture;
transport const;
thermo hConst;
equationOfState perfectFluid;
specie specie;
energy sensibleInternalEnergy;
}
mixture
{
specie
{
molWeight 18.0;
}
equationOfState
{
R 3000;
rho0 1027;
}
thermodynamics
{
Cp 4195;
Hf 0;
}
transport
{
mu 3.645e-4;
Pr 2.289;
}
}
However the increase in accuracy of the new simpler and more convenient
specification and representation comes at a cost: the NSRDS functions used by
the liquidProperties classes are relatively expensive to evaluate and the
depthCharge2D case takes ~14% longer to run.
The fundamental properties provided by the specie class hierarchy were
mole-based, i.e. provide the properties per mole whereas the fundamental
properties provided by the liquidProperties and solidProperties classes are
mass-based, i.e. per unit mass. This inconsistency made it impossible to
instantiate the thermodynamics packages (rhoThermo, psiThermo) used by the FV
transport solvers on liquidProperties. In order to combine VoF with film and/or
Lagrangian models it is essential that the physical propertied of the three
representations of the liquid are consistent which means that it is necessary to
instantiate the thermodynamics packages on liquidProperties. This requires
either liquidProperties to be rewritten mole-based or the specie classes to be
rewritten mass-based. Given that most of OpenFOAM solvers operate
mass-based (solve for mass-fractions and provide mass-fractions to sub-models it
is more consistent and efficient if the low-level thermodynamics is also
mass-based.
This commit includes all of the changes necessary for all of the thermodynamics
in OpenFOAM to operate mass-based and supports the instantiation of
thermodynamics packages on liquidProperties.
Note that most users, developers and contributors to OpenFOAM will not notice
any difference in the operation of the code except that the confusing
nMoles 1;
entries in the thermophysicalProperties files are no longer needed or used and
have been removed in this commet. The only substantial change to the internals
is that species thermodynamics are now "mixed" with mass rather than mole
fractions. This is more convenient except for defining reaction equilibrium
thermodynamics for which the molar rather than mass composition is usually know.
The consequence of this can be seen in the adiabaticFlameT, equilibriumCO and
equilibriumFlameT utilities in which the species thermodynamics are
pre-multiplied by their molecular mass to effectively convert them to mole-basis
to simplify the definition of the reaction equilibrium thermodynamics, e.g. in
equilibriumCO
// Reactants (mole-based)
thermo FUEL(thermoData.subDict(fuelName)); FUEL *= FUEL.W();
// Oxidant (mole-based)
thermo O2(thermoData.subDict("O2")); O2 *= O2.W();
thermo N2(thermoData.subDict("N2")); N2 *= N2.W();
// Intermediates (mole-based)
thermo H2(thermoData.subDict("H2")); H2 *= H2.W();
// Products (mole-based)
thermo CO2(thermoData.subDict("CO2")); CO2 *= CO2.W();
thermo H2O(thermoData.subDict("H2O")); H2O *= H2O.W();
thermo CO(thermoData.subDict("CO")); CO *= CO.W();
// Product dissociation reactions
thermo CO2BreakUp
(
CO2 == CO + 0.5*O2
);
thermo H2OBreakUp
(
H2O == H2 + 0.5*O2
);
Please report any problems with this substantial but necessary rewrite of the
thermodynamic at https://bugs.openfoam.org
Henry G. Weller
CFD Direct Ltd.
boundaryRadiationProperties: updating to new format
dynamicMeshDict and snappyHexMeshDict in utorials/multiphase/interDyMFoam/RAS/motorBike to follow Mattijs Git lab id 381
Now the interFoam and compressibleInterFoam families of solvers use the same
alphaEqn formulation and supporting all of the MULES options without
code-duplication.
The semi-implicit MULES support allows running with significantly larger
time-steps but this does reduce the interface sharpness.
Avoids slight phase-fraction unboundedness at entertainment BCs and improved
robustness.
Additionally the phase-fractions in the multi-phase (rather than two-phase)
solvers are adjusted to avoid the slow growth of inconsistency ("drift") caused
by solving for all of the phase-fractions rather than deriving one from the
others.
Bounding thermo.rho in rhoPorousSimpleFoam.
Changing initial time step in externalSolarLoad tutorial.
Commenting out momemtun source term in steamInjection which causes problems
Integration of ihcantabria wave models
Integration of functionality produced by The Environmental Hydraulics Institute "IHCantabria" (http://www.ihcantabria.com/en/)
- Original code introduced in commit 95e9467e
- Restructured and updated by OpenCFD into a new `waveModels` library available to the interFoam family of solvers
Main source:
`$FOAM_SRC/waveModels`
Tutorials:
`$FOAM_TUTORIALS/multiphase/interFoam/waveExample*`
Capabilities include:
- Wave generation
- Solitary wave using Boussinesq theory
- Cnoidal wave theory
- StokesI, StokesII, StokesV wave theory
- Active wave absorption at the inflow/outflow boundaries based on shallow water theory
IHCantabria Authors:
- Javier Lopez Lara (jav.lopez@unican.es)
- Gabriel Barajas (barajasg@unican.es)
- Inigo Losada (losadai@unican.es)
See merge request !88
e.g. the motion of two counter-rotating AMI regions could be defined:
dynamicFvMesh dynamicMotionSolverListFvMesh;
solvers
(
rotor1
{
solver solidBody;
cellZone rotor1;
solidBodyMotionFunction rotatingMotion;
rotatingMotionCoeffs
{
origin (0 0 0);
axis (0 0 1);
omega 6.2832; // rad/s
}
}
rotor2
{
solver solidBody;
cellZone rotor2;
solidBodyMotionFunction rotatingMotion;
rotatingMotionCoeffs
{
origin (0 0 0);
axis (0 0 1);
omega -6.2832; // rad/s
}
}
);
Any combination of motion solvers may be selected but there is no special
handling of motion interaction; the motions are applied sequentially and
potentially cumulatively.
To support this new general framework the solidBodyMotionFvMesh and
multiSolidBodyMotionFvMesh dynamicFvMeshes have been converted into the
corresponding motionSolvers solidBody and multiSolidBody and the tutorials
updated to reflect this change e.g. the motion in the mixerVesselAMI2D tutorial
is now defined thus:
dynamicFvMesh dynamicMotionSolverFvMesh;
solver solidBody;
solidBodyCoeffs
{
cellZone rotor;
solidBodyMotionFunction rotatingMotion;
rotatingMotionCoeffs
{
origin (0 0 0);
axis (0 0 1);
omega 6.2832; // rad/s
}
}
to handle the size of bubbles created by boiling. To be used in
conjunction with the alphatWallBoilingWallFunction boundary condition.
The IATE variant of the wallBoiling tutorial case is provided to
demonstrate the functionality:
tutorials/multiphase/reactingTwoPhaseEulerFoam/RAS/wallBoilingIATE
Contributed by Juho Peltola, VTT
Notable changes:
1. The same wall function is now used for both phases, but user must
specify phaseType ‘liquid’ or ‘vapor’
2. Runtime selectable submodels for:
- wall heat flux partitioning between the phases
- nucleation site density
- bubble departure frequency
- bubble departure diameter
3. An additional iteration loop for the wall boiling model in case
the initial guess for the wall temperature proves to be poor.
The wallBoiling tutorial has been updated to demonstrate this new functionality.
using a run-time selectable preconditioner
References:
Van der Vorst, H. A. (1992).
Bi-CGSTAB: A fast and smoothly converging variant of Bi-CG
for the solution of nonsymmetric linear systems.
SIAM Journal on scientific and Statistical Computing, 13(2), 631-644.
Barrett, R., Berry, M. W., Chan, T. F., Demmel, J., Donato, J.,
Dongarra, J., Eijkhout, V., Pozo, R., Romine, C. & Van der Vorst, H.
(1994).
Templates for the solution of linear systems:
building blocks for iterative methods
(Vol. 43). Siam.
See also: https://en.wikipedia.org/wiki/Biconjugate_gradient_stabilized_method
Tests have shown that PBiCGStab with the DILU preconditioner is more
robust, reliable and shows faster convergence (~2x) than PBiCG with
DILU, in particular in parallel where PBiCG occasionally diverges.
This remarkable improvement over PBiCG prompted the update of all
tutorial cases currently using PBiCG to use PBiCGStab instead. If any
issues arise with this update please report on Mantis: http://bugs.openfoam.org
The modes of operation are set by the dimensions of the pressure field
to which this boundary condition is applied, the \c psi entry and the value
of \c gamma:
\table
Mode | dimensions | psi | gamma
incompressible subsonic | p/rho | |
compressible subsonic | p | none |
compressible transonic | p | psi | 1
compressible supersonic | p | psi | > 1
\endtable
For most applications the totalPressure boundary condition now only
requires p0 to be specified e.g.
outlet
{
type totalPressure;
p0 uniform 1e5;
}
Added the option '-subDict' to specify a sub-dictionary if multiple
replacement sets are present in the same file. This also provides
backward compatibility by setting '-subDict dictionaryReplacement'
The use of the term 'source' in the context of post-processing is
confusing and does not properly describe the process of region
selection. The new names 'surfaceRegion' and 'volRegion' better
describe the purpose of the functionObjects which is to provide field
processing functionality limited to a specified region of space, either
a surface or volume.
The keyword 'source' is renamed 'regionType' which better describes the
purpose which is to specify the method by which the surface or volume
region is selected.
The keyword to select the name of the surface or volume region is
renamed from 'sourceName' to 'name' consistent with the other
name-changes above.
with the more general and flexible 'postProcess' utility and '-postProcess' solver option
Rationale
---------
Both the 'postProcess' utility and '-postProcess' solver option use the
same extensive set of functionObjects available for data-processing
during the run avoiding the substantial code duplication necessary for
the 'foamCalc' and 'postCalc' utilities and simplifying maintenance.
Additionally consistency is guaranteed between solver data processing
and post-processing.
The functionObjects have been substantially re-written and generalized
to simplify development and encourage contribution.
Configuration
-------------
An extensive set of simple functionObject configuration files are
provided in
OpenFOAM-dev/etc/caseDicts/postProcessing
and more will be added in the future. These can either be copied into
'<case>/system' directory and included into the 'controlDict.functions'
sub-dictionary or included directly from 'etc/caseDicts/postProcessing'
using the '#includeEtc' directive or the new and more convenient
'#includeFunc' directive which searches the
'<etc>/caseDicts/postProcessing' directories for the selected
functionObject, e.g.
functions
{
#includeFunc Q
#includeFunc Lambda2
}
'#includeFunc' first searches the '<case>/system' directory in case
there is a local configuration.
Description of #includeFunc
---------------------------
Specify a functionObject dictionary file to include, expects the
functionObject name to follow (without quotes).
Search for functionObject dictionary file in
user/group/shipped directories.
The search scheme allows for version-specific and
version-independent files using the following hierarchy:
- \b user settings:
- ~/.OpenFOAM/\<VERSION\>/caseDicts/postProcessing
- ~/.OpenFOAM/caseDicts/postProcessing
- \b group (site) settings (when $WM_PROJECT_SITE is set):
- $WM_PROJECT_SITE/\<VERSION\>/caseDicts/postProcessing
- $WM_PROJECT_SITE/caseDicts/postProcessing
- \b group (site) settings (when $WM_PROJECT_SITE is not set):
- $WM_PROJECT_INST_DIR/site/\<VERSION\>/caseDicts/postProcessing
- $WM_PROJECT_INST_DIR/site/caseDicts/postProcessing
- \b other (shipped) settings:
- $WM_PROJECT_DIR/etc/caseDicts/postProcessing
An example of the \c \#includeFunc directive:
\verbatim
#includeFunc <funcName>
\endverbatim
postProcess
-----------
The 'postProcess' utility and '-postProcess' solver option provide the
same set of controls to execute functionObjects after the run either by
reading a specified set of fields to process in the case of
'postProcess' or by reading all fields and models required to start the
run in the case of '-postProcess' for each selected time:
postProcess -help
Usage: postProcess [OPTIONS]
options:
-case <dir> specify alternate case directory, default is the cwd
-constant include the 'constant/' dir in the times list
-dict <file> read control dictionary from specified location
-field <name> specify the name of the field to be processed, e.g. U
-fields <list> specify a list of fields to be processed, e.g. '(U T p)' -
regular expressions not currently supported
-func <name> specify the name of the functionObject to execute, e.g. Q
-funcs <list> specify the names of the functionObjects to execute, e.g.
'(Q div(U))'
-latestTime select the latest time
-newTimes select the new times
-noFunctionObjects
do not execute functionObjects
-noZero exclude the '0/' dir from the times list, has precedence
over the -withZero option
-parallel run in parallel
-region <name> specify alternative mesh region
-roots <(dir1 .. dirN)>
slave root directories for distributed running
-time <ranges> comma-separated time ranges - eg, ':10,20,40:70,1000:'
-srcDoc display source code in browser
-doc display application documentation in browser
-help print the usage
pimpleFoam -postProcess -help
Usage: pimpleFoam [OPTIONS]
options:
-case <dir> specify alternate case directory, default is the cwd
-constant include the 'constant/' dir in the times list
-dict <file> read control dictionary from specified location
-field <name> specify the name of the field to be processed, e.g. U
-fields <list> specify a list of fields to be processed, e.g. '(U T p)' -
regular expressions not currently supported
-func <name> specify the name of the functionObject to execute, e.g. Q
-funcs <list> specify the names of the functionObjects to execute, e.g.
'(Q div(U))'
-latestTime select the latest time
-newTimes select the new times
-noFunctionObjects
do not execute functionObjects
-noZero exclude the '0/' dir from the times list, has precedence
over the -withZero option
-parallel run in parallel
-postProcess Execute functionObjects only
-region <name> specify alternative mesh region
-roots <(dir1 .. dirN)>
slave root directories for distributed running
-time <ranges> comma-separated time ranges - eg, ':10,20,40:70,1000:'
-srcDoc display source code in browser
-doc display application documentation in browser
-help print the usage
The functionObjects to execute may be specified on the command-line
using the '-func' option for a single functionObject or '-funcs' for a
list, e.g.
postProcess -func Q
postProcess -funcs '(div(U) div(phi))'
In the case of 'Q' the default field to process is 'U' which is
specified in and read from the configuration file but this may be
overridden thus:
postProcess -func 'Q(Ua)'
as is done in the example above to calculate the two forms of the divergence of
the velocity field. Additional fields which the functionObjects may depend on
can be specified using the '-field' or '-fields' options.
The 'postProcess' utility can only be used to execute functionObjects which
process fields present in the time directories. However, functionObjects which
depend on fields obtained from models, e.g. properties derived from turbulence
models can be executed using the '-postProcess' of the appropriate solver, e.g.
pisoFoam -postProcess -func PecletNo
or
sonicFoam -postProcess -func MachNo
In this case all required fields will have already been read so the '-field' or
'-fields' options are not be needed.
Henry G. Weller
CFD Direct Ltd.
In most boundary conditions, fvOptions etc. required and optional fields
to be looked-up from the objectRegistry are selected by setting the
keyword corresponding to the standard field name in the BC etc. to the
appropriate name in the objectRegistry. Usually a default is provided
with sets the field name to the keyword name, e.g. in the
totalPressureFvPatchScalarField the velocity is selected by setting the
keyword 'U' to the appropriate name which defaults to 'U':
Property | Description | Required | Default value
U | velocity field name | no | U
phi | flux field name | no | phi
.
.
.
However, in some BCs and functionObjects and many fvOptions another
convention is used in which the field name keyword is appended by 'Name'
e.g.
Property | Description | Required | Default value
pName | pressure field name | no | p
UName | velocity field name | no | U
This difference in convention is unnecessary and confusing, hinders code
and dictionary reuse and complicates code maintenance. In this commit
the appended 'Name' is removed from the field selection keywords
standardizing OpenFOAM on the first convention above.
This changes simplifies the specification of functionObjects in
controlDict and is consistent with the 'libs' option in controlDict to
load special solver libraries.
Support for the old 'functionObjectLibs' name is supported for backward compatibility.
to have the prefix 'write' rather than 'output'
So outputTime() -> writeTime()
but 'outputTime()' is still supported for backward-compatibility.
Also removed the redundant secondary-writing functionality from Time
which has been superseded by the 'writeRegisteredObject' functionObject.
for consistency with the time controls in controlDict and to avoid
unnecessary confusion. All code and tutorials have been updated.
The old names 'outputControl' and 'outputInterval' are but supported for
backward compatibility but deprecated.
See http://www.openfoam.org/mantisbt/view.php?id=2076
- .org is the file extension for emacs org-mode as well
- .orig is more to the point (.org isn't always recognized as "original")
- .original is too long, although more consistent with the convention
of source code file naming
Update script contributed by Bruno Santos
Patch contributed by Juho Peltola, VTT
The new JohnsonJacksonSchaefferFrictionalStress model is included and
the LBend tutorial case to demonstrate the need for the changes to the
frictional stress models.
Resolves bug-report http://www.openfoam.org/mantisbt/view.php?id=2058
Feature mppic inter foam
New MPPICInterFoam solver. Add MPPIC cloud to a VOF approach. Particles volume are considered into transport Eq fluxes.
Solves for 2 incompressible, isothermal immiscible fluids using a VOF
(volume of fluid) phase-fraction based interface capturing approach.
The momentum and other fluid properties are of the "mixture" and a single
momentum equation is solved.
Solver:
/applications/solvers/multiphase/MPPICInterFoam
Tutorial:
/tutorials/multiphase/MPPICInterFoam/twoPhasePachuka
See merge request !41
RunFunctions: Added "isTest()" argument parsing function
tutorials: Updated Allrun scripts to propagate the "-test" option
tutorials: Removed the lower Alltest scripts and updated the Allrun to
use the "isTest()" function to handle test-specific operation
in decomposeParDict.
This default number of processors may be overridden by the new "-np"
option to runParallel which must be specified before the application
name e.g.:
runParallel -np 4 pisoFoam
The built-in explicit symplectic integrator has been replaced by a
general framework supporting run-time selectable integrators. Currently
the explicit symplectic, implicit Crank-Nicolson and implicit Newmark
methods are provided, all of which are 2nd-order in time:
Symplectic 2nd-order explicit time-integrator for 6DoF solid-body motion:
Reference:
Dullweber, A., Leimkuhler, B., & McLachlan, R. (1997).
Symplectic splitting methods for rigid body molecular dynamics.
The Journal of chemical physics, 107(15), 5840-5851.
Can only be used for explicit integration of the motion of the body,
i.e. may only be called once per time-step, no outer-correctors may be
applied. For implicit integration with outer-correctors choose either
CrankNicolson or Newmark schemes.
Example specification in dynamicMeshDict:
solver
{
type symplectic;
}
Newmark 2nd-order time-integrator for 6DoF solid-body motion:
Reference:
Newmark, N. M. (1959).
A method of computation for structural dynamics.
Journal of the Engineering Mechanics Division, 85(3), 67-94.
Example specification in dynamicMeshDict:
solver
{
type Newmark;
gamma 0.5; // Velocity integration coefficient
beta 0.25; // Position integration coefficient
}
Crank-Nicolson 2nd-order time-integrator for 6DoF solid-body motion:
The off-centering coefficients for acceleration (velocity integration) and
velocity (position/orientation integration) may be specified but default
values of 0.5 for each are used if they are not specified. With the default
off-centering this scheme is equivalent to the Newmark scheme with default
coefficients.
Example specification in dynamicMeshDict:
solver
{
type CrankNicolson;
aoc 0.5; // Acceleration off-centering coefficient
voc 0.5; // Velocity off-centering coefficient
}
Both the Newmark and Crank-Nicolson are proving more robust and reliable
than the symplectic method for solving complex coupled problems and the
tutorial cases have been updated to utilize this.
In this new framework it would be straight forward to add other methods
should the need arise.
Henry G. Weller
CFD Direct
so that the specification of the name and dimensions are optional in property dictionaries.
Update tutorials so that the name of the dimensionedScalar property is
no longer duplicated but optional dimensions are still provided and are
checked on read.
LTS is selected by the ddt scheme e.g. in the
tutorials/multiphase/interFoam/ras/DTCHull case:
ddtSchemes
{
default localEuler rDeltaT;
}
LTSInterFoam is no longer needed now that interFoam includes LTS
support.
Multi-species, mass-transfer and reaction support and multi-phase
structure provided by William Bainbridge.
Integration of the latest p-U and face-p_U algorithms with William's
multi-phase structure is not quite complete due to design
incompatibilities which needs further development. However the
integration of the functionality is complete.
The results of the tutorials are not exactly the same for the
twoPhaseEulerFoam and reactingTwoPhaseEulerFoam solvers but are very
similar. Further analysis in needed to ensure these differences are
physical or to resolve them; in the meantime the twoPhaseEulerFoam
solver will be maintained.
by introducing rational base-classes rather than using the hideous
'switch' statement. Further rationalization of the cell-selection
mechanism will be implemented via an appropriate class hierarchy to
replace the remaining 'switch' statement.
Mesh-motion is currently handled very inefficiently for cellSets and not
at all for inter-region coupling. The former will be improved when the
cell-selection classes are written and the latter by making the
meshToMesh class a MeshObject after it has been corrected for mapFields.
fvOptions does not have the appropriate structure to support MRF as it
is based on option selection by user-specified fields whereas MRF MUST
be applied to all velocity fields in the particular solver. A
consequence of the particular design choices in fvOptions made it
difficult to support MRF for multiphase and it is easier to support
frame-related and field related options separately.
Currently the MRF functionality provided supports only rotations but
the structure will be generalized to support other frame motions
including linear acceleration, SRF rotation and 6DoF which will be
run-time selectable.
Existing case did not properly converge and suffered slow convergence
with the water level failing to reach an equilibrium. A slight rise in
the channel appears to help the water level reach an equlibrium when the flow
rate over the rise matches the inlet flow rate.
nLimiterIter: Number of iterations during limiter construction
3 (default) is sufficient for 3D simulations with a Courant number 0.5 or so
For larger Courant numbers larger values may be needed but this is
only relevant for IMULES and CMULES
smoothLimiter: Coefficient to smooth the limiter to avoid "diamond"
staggering patters seen in regions of low particle phase-fraction in
fluidised-bed simulations.
The default is 0 as it is not needed for all simulations.
A value of 0.1 is appropriate for fluidised-bed simulations.
The useful range is 0 -> 0.5.
Values larger than 0.5 may cause excessive smearing of the solution.
Previous behavior which may be useful for moving-mesh cases can be
selected using the optional entry:
writeTotalArea yes;
The initial total area is written in the log and data file header e.g.:
# Source : faceZone f0
# Faces : 8
# Area : 1.063860e-02
Description
Specify an etc file to include when reading dictionaries, expects a
single string to follow.
Searches for files from user/group/shipped directories.
The search scheme allows for version-specific and
version-independent files using the following hierarchy:
- \b user settings:
- ~/.OpenFOAM/\<VERSION\>
- ~/.OpenFOAM/
- \b group (site) settings (when $WM_PROJECT_SITE is set):
- $WM_PROJECT_SITE/\<VERSION\>
- $WM_PROJECT_SITE
- \b group (site) settings (when $WM_PROJECT_SITE is not set):
- $WM_PROJECT_INST_DIR/site/\<VERSION\>
- $WM_PROJECT_INST_DIR/site/
- \b other (shipped) settings:
- $WM_PROJECT_DIR/etc/
An example of the \c \#includeEtc directive:
\verbatim
#includeEtc "etcFile"
\endverbatim
The usual expansion of environment variables and other constructs is
retained.
For multi-region cases the default location of blockMeshDict is now system/<region name>
If the blockMeshDict is not found in system then the constant directory
is also checked providing backward-compatibility
