Currently these deleted function declarations are still in the private section
of the class declarations but will be moved by hand to the public section over
time as this is too complex to automate reliably.
The base dynamicFvMesh now reads and stores the dynamicMeshDict and motion
solver receive it as a constructor argument.
Also rationalised the motionSolver diffusivity classes in which storing the
faceDiffusivity field provided no advantage; now it is created and returned on
demand.
The writeEntry form is now defined and used consistently throughout OpenFOAM
making it easier to use and extend, particularly to support binary IO of complex
dictionary entries.
The motion solvers are executed in order and the resulting displacements
accumulated into an overall displacement and the displaced point positions
returned.
This functionality replaces the dynamicMotionSolverListFvMesh class with the
equivalent specification of a "solvers" list rather than a "solver" entry in
dynamicMeshDict e.g.
dynamicFvMesh dynamicMotionSolverFvMesh;
solvers
(
Rotor
{
solver solidBody;
solidBodyCoeffs
{
cellZone region1;
solidBodyMotionFunction rotatingMotion;
rotatingMotionCoeffs
{
origin (0 0 0);
axis (0 0 1);
omega 100; // rad/s
}
}
}
Piston
{
solver velocityComponentLaplacian;
motionSolverLibs ("libfvMotionSolvers.so");
velocityComponentLaplacianCoeffs
{
component z;
diffusivity inverseDistance 1(wall1);
}
}
);
Registration occurs when the temporary field is transferred to a non-temporary
field via a constructor or if explicitly transferred to the database via the
regIOobject "store" methods.
Class
Foam::dynamicInterpolatedFvMesh
Description
Interpolates pre-specified motion specified as a set of pointVectorFields.
The motion can be provided either as a set of displacement or position
fields and the entry \c displacement specified accordingly.
Usage
Example:
\verbatim
dynamicFvMesh dynamicInterpolatedFvMesh;
displacementLaplacianCoeffs
{
field wantedDisplacement;
displacement yes;
interpolationScheme linear;
}
\endverbatim
This will scan the case for \c wantedDisplacement \c pointVectorFields in
the time directories and interpolate those in time (using \c linear
interpolation) to obtain the current displacement. The advantage of
specifying displacement in this way is that it automatically works in
parallel using \c decomposePar to decompose the set of \c pointVectorFields
provided.
Description
Solid-body motion of the mesh specified by a run-time selectable motion
function. Applies SLERP interpolation of movement as function of
distance to the object surface to move the mesh points.
Mesh motion solver simple linear expansion and contraction of a mesh
region defined by a motion axis and the extents of the motion.
Example:
\verbatim
dynamicFvMesh dynamicMotionSolverFvMesh;
motionSolver displacementLinearMotion;
axis (0 1 0);
xFixed 0.8;
xMoving 0;
displacement table
(
(0 0)
(4 0.7)
);
\endverbatim
This mesh is compressed between \c xFixed and \c xMoving in the direction
\c axis between time 0 and 4 with a maximum displacement of 0.7.
The mesh beyond \c xFixed is fixed and beyond \c xMoving moves with maximum
displacement.
In early versions of OpenFOAM the scalar limits were simple macro replacements and the
names were capitalized to indicate this. The scalar limits are now static
constants which is a huge improvement on the use of macros and for consistency
the names have been changed to camel-case to indicate this and improve
readability of the code:
GREAT -> great
ROOTGREAT -> rootGreat
VGREAT -> vGreat
ROOTVGREAT -> rootVGreat
SMALL -> small
ROOTSMALL -> rootSmall
VSMALL -> vSmall
ROOTVSMALL -> rootVSmall
The original capitalized are still currently supported but their use is
deprecated.
When an OpenFOAM simulation runs in parallel, the data for decomposed fields and
mesh(es) has historically been stored in multiple files within separate
directories for each processor. Processor directories are named 'processorN',
where N is the processor number.
This commit introduces an alternative "collated" file format where the data for
each decomposed field (and mesh) is collated into a single file, which is
written and read on the master processor. The files are stored in a single
directory named 'processors'.
The new format produces significantly fewer files - one per field, instead of N
per field. For large parallel cases, this avoids the restriction on the number
of open files imposed by the operating system limits.
The file writing can be threaded allowing the simulation to continue running
while the data is being written to file. NFS (Network File System) is not
needed when using the the collated format and additionally, there is an option
to run without NFS with the original uncollated approach, known as
"masterUncollated".
The controls for the file handling are in the OptimisationSwitches of
etc/controlDict:
OptimisationSwitches
{
...
//- Parallel IO file handler
// uncollated (default), collated or masterUncollated
fileHandler uncollated;
//- collated: thread buffer size for queued file writes.
// If set to 0 or not sufficient for the file size threading is not used.
// Default: 2e9
maxThreadFileBufferSize 2e9;
//- masterUncollated: non-blocking buffer size.
// If the file exceeds this buffer size scheduled transfer is used.
// Default: 2e9
maxMasterFileBufferSize 2e9;
}
When using the collated file handling, memory is allocated for the data in the
thread. maxThreadFileBufferSize sets the maximum size of memory in bytes that
is allocated. If the data exceeds this size, the write does not use threading.
When using the masterUncollated file handling, non-blocking MPI communication
requires a sufficiently large memory buffer on the master node.
maxMasterFileBufferSize sets the maximum size in bytes of the buffer. If the
data exceeds this size, the system uses scheduled communication.
The installation defaults for the fileHandler choice, maxThreadFileBufferSize
and maxMasterFileBufferSize (set in etc/controlDict) can be over-ridden within
the case controlDict file, like other parameters. Additionally the fileHandler
can be set by:
- the "-fileHandler" command line argument;
- a FOAM_FILEHANDLER environment variable.
A foamFormatConvert utility allows users to convert files between the collated
and uncollated formats, e.g.
mpirun -np 2 foamFormatConvert -parallel -fileHandler uncollated
An example case demonstrating the file handling methods is provided in:
$FOAM_TUTORIALS/IO/fileHandling
The work was undertaken by Mattijs Janssens, in collaboration with Henry Weller.
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;
}
}
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
}
}
