- deprecate dimensionedType constructors using an Istream in favour of
versions accepting a keyword and a dictionary.
Dictionary entries are almost the exclusive means of read
constructing a dimensionedType. By construct from the dictionary
entry instead of doing a lookup() first, we can detect possible
input errors such as too many tokens as a result of a input syntax
error.
Constructing a dimensionedType from a dictionary entry now has
two forms.
1. dimensionedType(key, dims, dict);
This is the constructor that will normally be used.
It accepts entries with optional leading names and/or
dimensions. If the entry contains dimensions, they are
verified against the expected dimensions and an IOError is
raised if they do not correspond. On conclusion, checks the
token stream for any trailing rubbish.
2. dimensionedType(key, dict);
This constructor is used less frequently.
Similar to the previous description, except that it is initially
dimensionless. If entry contains dimensions, they are used
without further verification. The constructor also includes a
token stream check.
This constructor is useful when the dimensions are entirely
defined from the dictionary input, but also when handling
transition code where the input dimensions are not obvious from
the source.
This constructor can also be handy when obtaining values from
a dictionary without needing to worry about the input dimensions.
For example,
Info<< "rho: " << dimensionedScalar("rho", dict).value() << nl;
This will accept a large range of inputs without hassle.
ENH: consistent handling of dimensionedType for inputs (#1083)
BUG: incorrect Omega dimensions (fixes#2084)
- 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.
- writes positions and a single field (eg, diameter) in plain ASCII files,
suitable for importing in a spreadsheet or manipulation with
scripting tools.
- code integrated from
https://develop.openfoam.com/Community/OpenFOAM-addOns
New name: findObject(), cfindObject()
Old name: lookupObjectPtr()
Return a const pointer or nullptr on failure.
New name: findObject()
Old name: --
Return a non-const pointer or nullptr on failure.
New name: getObjectPtr()
Old name: lookupObjectRefPtr()
Return a non-const pointer or nullptr on failure.
Can be called on a const object and it will perform a
const_cast.
- use these updated names and functionality in more places
NB: The older methods names are deprecated, but continue to be defined.
Description
Calculates the spatial minimum and maximum extents of a field
The extents are derived from the bound box limits after identifying
the locations where field values exceed the user-supplied threshold
value.
Usage
Example of function object specification:
fieldExtents1
{
type fieldExtents;
libs ("libfieldFunctionObjects.so");
...
writeToFile yes;
log yes;
fields (alpha);
threshold 0.5;
patches ();
}
Where the entries comprise:
Property | Description | Required | Default
type | type name: fieldExtents | yes |
writeToFile | write extents data to file | no | yes
log | write extents data to standard output | no | yes
internalField | Process the internal field | no | yes
threshold | Field value to identify extents boundary | yes |
referencePosition | Reference position | no | (0 0 0)
fields | list of fields to process | yes |
patches | list of patches to process | no | <all>
Output data is written to the file \<timeDir\>/fieldExtents.dat
Note
For non-scalar fields, the magnitude of the field is employed and
compared to the threshold value.
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.
- 'signed' input parameter only mandatory for distance > 0.
A distance <= 0 is always signed and the input parameter is ignored.
- Use normal distance when distance == 0. This has no effect when
the surface has no open edges, but improves on rounding issues
around the zero crossing when the surface has open edges.
This may still need future revisiting.
- the original intention was to avoid vtp output when the clouds are
empty anyhow. However, it is useful for post-processing to have
clouds with zero parcels (eg, before the start of injection).
Pruning of empty clouds is now an option in the vtkCloud dictionary
controls, with the default being false (no pruning). This represents
a non-breaking change in behaviour since it generates more output
than previously.
Example,
{
type vtkCloud;
//- Suppress writing of empty clouds (default: false)
prune true;
}
- functionObjectLibs -> libs
- redirectType -> name
- change deprecated writeCompression flags types to Switch.
- cleanup some trailing ';;' from some dictionaries
- for larger problems with a smaller region of interest, can apply a
bounding to limit the size of the ensight geometry and fields created.
Since the implementation uses a fvMeshSubset, there is an additional
per-process memory overhead.
A high output frequency should be avoided with moving meshes, since
this indirectly forces a frequent update of the submesh.
- takes a direct approach of determining which cells are cut and walks
the cell faces directly to build the resulting surface.
- better handling of corner cases.
* Avoids redundant points when the cut passes exactly through a
mesh point.
* Supresses generation of duplicates faces when the plane cut
coincides exactly with a mesh face.
- for severely concave cells where the plane cuts a face multiple times
there is currently no remedial action taken, except to note the
failure and unwind the insertion of the corresponding points and
faces.
- signedDistance() method is like distance() but retains
the positive/negative sign for the side of the plane.
- the sign() method returns the sign as -1,0,+1 integer for
classification purposes where it is important to distinguish between
a zero value and a positive value (eg, for cutting). Optional
tolerance can be supplied to round for zero.
- refactor and inlined simple and frequently used methods.
- add boundBox faceCentre() method, which can be useful for creating
clipping planes from a bounding box.
Relocated treeBoundBox faceNormals to boundBox since they apply
equally there - the meaning of the faces (x-min, x-max, etc)
is the same, even if the point addressing for the faces differs.
- some paraview versions (eg, on windows) don't support float, only double.
This mostly affected the vtkSurfaceWriter.
The foamToVTK is also affected, but since it also supports the XML
output formats (vtp, vtu) these can be used instead.
- improve doxygen entries for searchable surfaces.
- support selection of searchable surfaces with shorter names.
Eg,
type box | cylinder | ...;
vs type searchableBox | searchableCylinder | ...;
- relocate some standard functionality to TimePaths to allow a lighter
means of managing time directories without using the entire Time
mechanism.
- optional enableLibs for Time construction (default is on)
and a corresponding argList::noLibs() and "-no-libs" option
STYLE:
- mark Time::outputTime() as deprecated MAY-2016
- use pre-increment for runTime, although there is no difference in
behaviour or performance.
Correcting thermoSingleLayer.C mask field alpha to avoid heat sources where there is no film.
Tunning fvSolution for alpha for twoPhasePachuka tutorial
- list all regions from constant/regionProperties:
* foamListRegions
- list specific region type from constant/regionProperties:
* foamListRegions fluid
* foamListRegions solid
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.
- the dictionary-driven variant of stitchMesh allows sequential
application of 'stitch' operation with requiring intermediate
writing to disk.
- Without arguments:
* stitchMesh uses a system/stitchMeshDict or -dict dict
- With arguments:
* master/slave patches specified on the command-line as in previous
versions.
- 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.
Basic directional refinement:
- only for coordinate aligned meshes
- only for refinementRegions
See the mesh/snappyHexMesh/aerofoilNACA0012_directionalRefinement
tutorial.
- input or output scaling of values to manage dissimilar unit systems
in the structures model
- logging of communicated force, moments and updated positions.
This allows tracking of the information exchange throughout the
duration of the simulation and may assist in post-simulation diagnosis.
- the problem arises since the various surface writers are stateless.
The collated output format hacks around this limitation by adding in
its own fieldDict caching (to disk).
Now include an updateMesh() method to hook into geometry changes.
This is considered a stop-gap measure until the surface output
handling is improved.
- improvement documentation for surface sampling.
- can now specify alternative sampling scheme for obtaining the
face values instead of just using the "cell" value. For example,
sampleScheme cellPoint;
This can be useful for cases when the surface is close to a boundary
cell and there are large gradients in the sampled field.
- distanceSurface now handles non-closed surfaces more robustly.
Unknown regions (not inside or outside) are marked internally and
excluded from consideration. This allows use of 'signed' surfaces
where not previously possible.
Improvements to existing functionality
--------------------------------------
- MPI is initialised without thread support if it is not needed e.g. uncollated
- Use native c++11 threading; avoids problem with static destruction order.
- etc/cellModels now only read if needed.
- etc/controlDict can now be read from the environment variable FOAM_CONTROLDICT
- Uniform files (e.g. '0/uniform/time') are now read only once on the master only
(with the masterUncollated or collated file handlers)
- collated format writes to 'processorsNNN' instead of 'processors'. The file
format is unchanged.
- Thread buffer and file buffer size are no longer limited to 2Gb.
The global controlDict file contains parameters for file handling. Under some
circumstances, e.g. running in parallel on a system without NFS, the user may
need to set some parameters, e.g. fileHandler, before the global controlDict
file is read from file. To support this, OpenFOAM now allows the global
controlDict to be read as a string set to the FOAM_CONTROLDICT environment
variable.
The FOAM_CONTROLDICT environment variable can be set to the content the global
controlDict file, e.g. from a sh/bash shell:
export FOAM_CONTROLDICT=$(foamDictionary $FOAM_ETC/controlDict)
FOAM_CONTROLDICT can then be passed to mpirun using the -x option, e.g.:
mpirun -np 2 -x FOAM_CONTROLDICT simpleFoam -parallel
Note that while this avoids the need for NFS to read the OpenFOAM configuration
the executable still needs to load shared libraries which must either be copied
locally or available via NFS or equivalent.
New: Multiple IO ranks
----------------------
The masterUncollated and collated fileHandlers can now use multiple ranks for
writing e.g.:
mpirun -np 6 simpleFoam -parallel -ioRanks '(0 3)'
In this example ranks 0 ('processor0') and 3 ('processor3') now handle all the
I/O. Rank 0 handles 0,1,2 and rank 3 handles 3,4,5. The set of IO ranks should always
include 0 as first element and be sorted in increasing order.
The collated fileHandler uses the directory naming processorsNNN_XXX-YYY where
NNN is the total number of processors and XXX and YYY are first and last
processor in the rank, e.g. in above example the directories would be
processors6_0-2
processors6_3-5
and each of the collated files in these contains data of the local ranks
only. The same naming also applies when e.g. running decomposePar:
decomposePar -fileHandler collated -ioRanks '(0 3)'
New: Distributed data
---------------------
The individual root directories can be placed on different hosts with different
paths if necessary. In the current framework it is necessary to specify the
root per slave process but this has been simplified with the option of specifying
the root per host with the -hostRoots command line option:
mpirun -np 6 simpleFoam -parallel -ioRanks '(0 3)' \
-hostRoots '("machineA" "/tmp/" "machineB" "/tmp")'
The hostRoots option is followed by a list of machine name + root directory, the
machine name can contain regular expressions.
New: hostCollated
-----------------
The new hostCollated fileHandler automatically sets the 'ioRanks' according to
the host name with the lowest rank e.g. to run simpleFoam on 6 processors with
ranks 0-2 on machineA and ranks 3-5 on machineB with the machines specified in
the hostfile:
mpirun -np 6 --hostfile hostfile simpleFoam -parallel -fileHandler hostCollated
This is equivalent to
mpirun -np 6 --hostfile hostfile simpleFoam -parallel -fileHandler collated -ioRanks '(0 3)'
This example will write directories:
processors6_0-2/
processors6_3-5/
A typical example would use distributed data e.g. no two nodes, machineA and
machineB, each with three processes:
decomposePar -fileHandler collated -case cavity
# Copy case (constant/*, system/*, processors6/) to master:
rsync -a cavity machineA:/tmp/
# Create root on slave:
ssh machineB mkdir -p /tmp/cavity
# Run
mpirun --hostfile hostfile icoFoam \
-case /tmp/cavity -parallel -fileHandler hostCollated \
-hostRoots '("machineA" "/tmp" "machineB" "/tmp")'
Contributed by Mattijs Janssens
- controlled by the the 'printExecutionFormat' InfoSwitch in
etc/controlDict
// Style for "ExecutionTime = " output
// - 0 = seconds (with trailing 's')
// - 1 = day-hh:mm:ss
ExecutionTime = 112135.2 s ClockTime = 113017 s
ExecutionTime = 1-07:08:55.20 ClockTime = 1-07:23:37
- Callable via the new Time::printExecutionTime() method,
which also helps to reduce clutter in the applications.
Eg,
runTime.printExecutionTime(Info);
vs
Info<< "ExecutionTime = " << runTime.elapsedCpuTime() << " s"
<< " ClockTime = " << runTime.elapsedClockTime() << " s"
<< nl << endl;
--
ENH: return elapsedClockTime() and clockTimeIncrement as double
- previously returned as time_t, which is less portable.
- 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"
keeping chocked conditions of Mach number.
This BC can work in two modes, chocked or non-chocked. In the
chocked mode the Ma is an input. In the non-chocked mode
the Ma is calculated from model inputs.
The tutorial demonstrates generation of a C-grid mesh using blockMesh
The geometry is provided by a surface mesh (OBJ file) of the NACA0012 aerofoil
The case is setup with a freestream flow speed of Ma=0.72
Thanks to Kai Bastos at Duke University for the geometry and helpful input.
These BCs blend between typical inflow and outflow conditions based on the
velocity orientation.
airFoil2D tutorial updated to demonstrate these new BCs.
- use succincter method names that more closely resemble dictionary
and HashTable method names. This improves method name consistency
between classes and also requires less typing effort:
args.found(optName) vs. args.optionFound(optName)
args.readIfPresent(..) vs. args.optionReadIfPresent(..)
...
args.opt<scalar>(optName) vs. args.optionRead<scalar>(optName)
args.read<scalar>(index) vs. args.argRead<scalar>(index)
- the older method names forms have been retained for code compatibility,
but are now deprecated
chtMultiRegionFoam now supports reaction/combustion modelling in fluid
regions in the same way as reactingFoam.
TUT: chtMultiRegionFoam: Added reverseBurner tutorial
This tutorial demonstrates chtMultiRegionFoam's combustion capability
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
and replaced rhoPimpleDyMFoam with a script which reports this change.
The rhoPimpleDyMFoam tutorials have been moved into the rhoPimpleFoam directory.
This change is the first 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.
rhoReactingFoam: Updated for changes to rhoPimpleFoam files
Now pimpleDyMFoam is exactly equivalent to pimpleFoam when running on a
staticFvMesh. Also when the constant/dynamicMeshDict is not present a
staticFvMesh is automatically constructed so that the pimpleDyMFoam solver can
run any pimpleFoam case without change.
pimpleDyMFoam: Store Uf as an autoPtr for better error handling
pimpleFoam: Set initial deltaT from the Courant number
for improved stability on start-up and compatibility with pimpleDyMFoam
ENH: pimpleFoam: Merged dynamic mesh functionality of pimpleDyMFoam into pimpleFoam
and replaced pimpleDyMFoam with a script which reports this change.
The pimpleDyMFoam tutorials have been moved into the pimpleFoam directory.
This change is the first 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.
tutorials/incompressible/pimpleFoam: Updated pimpleDyMFoam tutorials to run pimpleFoam
Renamed tutorials/incompressible/pimpleFoam/RAS/wingMotion/wingMotion2D_pimpleDyMFoam
-> tutorials/incompressible/pimpleFoam/RAS/wingMotion/wingMotion2D_pimpleFoam
XiEngineFoam is a premixed/partially-premixed combustion engine solver which
exclusively uses the Xi flamelet combustion model.
engineFoam is a general engine solver for inhomogeneous combustion with or
without spray supporting run-time selection of the chemistry-based combustion
model.
Standard crank-connecting rod and the new free-piston kinematics motion options
are provides, others can easily be added.
Contributed by Francesco Contino and Nicolas Bourgeois, BURN Research Group.
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.
- Instead of relying on #inputMode to effect a global change it is now
possible (and recommended) to a temporary change in the inputMode
for the following entry.
#default : provide default value if entry is not already defined
#overwrite : silently remove a previously existing entry
#warn : warn about duplicate entries
#error : error if any duplicate entries occur
#merge : merge sub-dictionaries when possible (the default mode)
This is generally less cumbersome than the switching the global
inputMode. For example to provide a set of fallback values.
#includeIfPresent "user-files"
...
#default value uniform 10;
vs.
#includeIfPresent "user-files"
#inputMode protect
...
value uniform 10;
#inputMode merge // _Assuming_ we actually had this before
These directives can also be used to suppress the normal dictionary
merge semantics:
#overwrite dict { entry val; ... }
Note: performs its own tracking and does not rely on the base
particle::trackXXX functions, and uses a local particle position.
Look to update to barycentric tracking in the future.
The combined solver includes the most advanced and general functionality from
each solver including:
Continuous phase
Lagrangian multiphase parcels
Optional film
Continuous and Lagrangian phase reactions
Radiation
Strong buoyancy force support by solving for p_rgh
The reactingParcelFoam and reactingParcelFilmFoam tutorials have been combined
and updated.
