mirror of
https://github.com/OpenFOAM/OpenFOAM-6.git
synced 2025-12-08 06:57:46 +00:00
41304deafb
When restarting form a previous calculation, the averaging is continuous or
may be restarted using the \c restartOnRestart option.
The averaging process may be restarted after each calculation output time
using the \c restartOnOutput option or restarted periodically using the \c
periodicRestart option and setting \c restartPeriod to the required
averaging period.
Example of function object specification:
\verbatim
fieldAverage1
{
type fieldAverage;
functionObjectLibs ("libfieldFunctionObjects.so");
...
restartOnRestart false;
restartOnOutput false;
periodicRestart false;
restartPeriod 0.002;
fields
(
U
{
mean on;
prime2Mean on;
base time;
window 10.0;
windowName w1;
}
p
{
mean on;
prime2Mean on;
base time;
}
);
}
\endverbatim
\heading Function object usage
\table
Property | Description | Required | Default value
type | type name: fieldAverage | yes |
restartOnRestart | Restart the averaging on restart | no | no
restartOnOutput | Restart the averaging on output | no | no
periodicRestart | Periodically restart the averaging | no | no
restartPeriod | Periodic restart period | conditional |
fields | list of fields and averaging options | yes |
\endtable
Fields are used by dsmcFoam in several ways, some of which are different to
their use elsewhere in OpenFOAM. None of these fields are solved by partial
differential equations, they are used either to record simulation data, or to
supply boundary data.
In each case there are 11 fields:
boundaryT, boundaryU:
The wall and free stream conditions at the boundary are specified for
velocity and temperature with these fields - only the data on the
patches is used, the cell data is not. These are the only two fields
which supply data to the case.
dsmcRhoN:
The population of dsmc particles in cells is recorded to visualise how
well the cell population conditions required for dsmc are met. The
boundary conditions are zeroGradient because only cell data is
meaningful.
fD, q:
The wall heat flux (q) and force density (fD, i.e. stress vector) is
recorded with these fields - only the data on wall patches is relevant,
the cell data is not.
iDof, internalE, linearKE, momentum, rhoM, rhoN:
These fields are the densities of extensive quantities in the
simulation, i.e. of number, mass, momentum, energy. Cell data is
recorded in the internal field and the boundaryField is used to record
the data of particles that strike wall patches. The properties of
particles striking wall faces are weighted by 1/(Un*fA), where Un is the
normal component of the particle's velocity and fA is the face area.
This is done so that when intensive quantities, such as velocity or
temperature, are evaluated on the wall the values are correct this
allows velocity slip and temperature jump to be evaluated.
Therefore, the data in these fields on wall patches is of a different
type to the volume data. This may cause problems when post-processing,
as any interpolation of these fields will have a artifacts in the near
wall cells because the values on the faces are radically different.
This can be overcome by visualising the data uninterpolated, or by
copying the fields and setting zeroGradient boundary conditions on
walls. Calculated intensive fields do not have this issue.
Further fields are produced by dsmcFoam, i.e. dsmcSigmaTcRMax (used in the
selection of collision partners) and by the fieldAverage (averaging the
extensive quantity densities) and dsmcFields (calculating intensive quantities,
i.e. velocity and temperature, from extensive quantities) function objects in
each case as it runs.