Description
fvMeshTopoChanger which maps the fields to a new mesh or sequence of meshes
which can optionally be mapped to repeatedly for example in multi-cycle
engine cases or cycled through for symmetric forward and reverse motion.
Usage
\table
Property | Description | Required | Default value
libs | Libraries to load | no |
times | List of times for the meshes | yes |
repeat | Repetition period | no |
cycle | Cycle period | no |
begin | Begin time for the meshes | no | Time::beginTime()
timeDelta | Time tolerance used for time -> index | yes |
\endtable
Examples of the mesh-to-mesh mapping for the multi-cycle
tutorials/incompressibleFluid/movingCone case:
\verbatim
topoChanger
{
type meshToMesh;
libs ("libmeshToMeshTopoChanger.so");
times (0.0015 0.003);
cycle #calc "1.0/300.0";
begin 0;
timeDelta 1e-6;
}
\endverbatim
This can be useful when reusing thermo configurations across multiple
setups. In one simulation, the fluid might be entirely air, and in
another there might be additional pollutant or fuel species. This could
be defined without changing the species' thermo enties as follows:
"(mixture|air)"
{
specie
{
molWeight 28.9;
}
thermodynamics
{
Hf 0;
Cv 724.8;
}
transport
{
mu 1.84e-05;
Pr 0.7;
}
}
This was semi-supported before, but it lead to the wrong name (i.e., the
wildcard string) being stored in the base specie class. Now the name is
passed through the thermo constructors, so it is always correct.
Class
Foam::functionObjects::checkMesh
Description
Executes primitiveMesh::checkMesh(true) every execute time for which the
mesh changed, i.e. moved or changed topology.
Useful to check the correctness of changing and morphing meshes.
Example of checkMesh specification:
\verbatim
checkMesh
{
type checkMesh;
libs ("libutilityFunctionObjects.so");
executeControl timeStep;
executeInterval 10;
}
\endverbatim
or using the standard configuration file:
\verbatim
#includeFunc checkMesh(executeInterval=10)
\endverbatim
Can be used with any solver supporting mesh-motion, in particular the movingMesh
solver module, to check the mesh quality following morphing and/or topology
change.
to avoid the need to call predict() in the constructor and ensure they are
available when required between mesh change and predict().
Also instantiated Fickian and MaxwellStefan multicomponent diffusion models for
multiphaseEuler.
e.g. the simple exact match search
foamToC -allLibs -search VoFTurbulenceDamping
generates:
VoFTurbulenceDamping is in table
fvModel libVoFTurbulenceDamping.so
but the regular expression search
foamToC -allLibs -search "VoF.*"
generates the results for all names in all tables containing the sub-string "VoF":
VoFCavitation is in table
fvModel libVoFCavitation.so
VoFSolidificationMeltingSource is in table
fvModel libVoFSolidificationMeltingSource.so
VoFClouds is in table
fvModel libVoFClouds.so
VoFFilmTransfer is in table
fvModel libfilmVoFTransfer.so
VoFTurbulenceDamping is in table
fvModel libVoFTurbulenceDamping.so
If the libs entry is not provided and the name of the library containing the
functionObject, fvModel or fvConstraint corresponds to the type specified the
corresponding library is automatically loaded, e.g. to apply the
VoFTurbulenceDamping fvModel to an incompressibleVoF simulation the following
will load the libVoFTurbulenceDamping.so library automatically and instantiate
the fvModel:
turbulenceDamping
{
type VoFTurbulenceDamping;
delta 1e-4;
}
The velocity boundary conditions are corrected before the construction of the
face velocity or momentum but for multi-region cases with interacting velocity
boundary conditions this is only possible after all the region solver modules
have been constructed so it is better to delay the optional construction of the
face velocity/momentum until preSolve().
This avoids potential hidden run-time errors caused by solvers running with
boundary conditions which are not fully specified. Note that "null-constructor"
here means the constructor from patch and internal field only, no data is
provided.
Constraint and simple BCs such as 'calculated', 'zeroGradient' and others which
do not require user input to fully specify their operation remain on the
null-constructor table for the construction of fields with for example all
'calculated' or all 'zeroGradient' BCs.
Following this improvement the null-constructors have been removed from all
pointPatchFields not added to the null-constructor table thus reducing the
amount of code and maintenance overhead and making easier and more obvious to
write new pointPatchField types.
This avoids potential hidden run-time errors caused by solvers running with
boundary conditions which are not fully specified. Note that "null-constructor"
here means the constructor from patch and internal field only, no data is
provided.
Constraint and simple BCs such as 'calculated', 'zeroGradient' and others which
do not require user input to fully specify their operation remain on the
null-constructor table for the construction of fields with for example all
'calculated' or all 'zeroGradient' BCs.
A special version of the 'inletOutlet' fvPatchField named 'zeroInletOutlet' has
been added in which the inlet value is hard-coded to zero which allows this BC
to be included on the null-constructor table. This is useful for the 'age'
functionObject to avoid the need to provide the 'age' volScalarField at time 0
unless special inlet or outlet BCs are required. Also for isothermalFilm in
which the 'alpha' field is created automatically from the 'delta' field if it is
not present and can inherit 'zeroInletOutlet' from 'delta' if appropriate. If a
specific 'inletValue' is require or other more complex BCs then the 'alpha'
field file must be provided to specify these BCs as before.
Following this improvement it will now be possible to remove the
null-constructors from all fvPatchFields not added to the null-constructor
table, which is most of them, thus reducing the amount of code and maintenance
overhead and making easier and more obvious to write new fvPatchField types.
which allows lambda to set higher in the cells adjacent to the boundary which is
particularly useful when solving for waves in a domain with no mean-flow and
wave BCs to avoid numerical stability problems where the specified wave flow
reverses into the domain. The alternative is to use symmetry rather than wave
BCs on the side patches which is stable without using lambdaBoundary but there
is modest distortion of the wave profile adjacent to the side patches which does
not propagate into the domain due to the wave forcing.
to demonstrate motion of a floating object due to waves without any mean flow,
generated by the waveForcing fvModel using the waves specification in
constant/waveProperties which is also used for the side boundary conditions.
