-closedDomain domain does not contain inlets or outlets
-minDimCells <int> number of cells in the shortest direction, e.g. 10
-region <name> specify alternative mesh region
This update allows Zoltan to be used by snappyHexMesh to redistribute the mesh
after refinement and sub-setting even if some processors loose all their cells
in the process.
The majority of input parameters now support automatic unit conversion.
Units are specified within square brackets, either before or after the
value. Primitive parameters (e.g., scalars, vectors, tensors, ...),
dimensioned types, fields, Function1-s and Function2-s all support unit
conversion in this way.
Unit conversion occurs on input only. OpenFOAM writes out all fields and
parameters in standard units. It is recommended to use '.orig' files in
the 0 directory to preserve user-readable input if those files are being
modified by pre-processing applications (e.g., setFields).
For example, to specify a volumetric flow rate inlet boundary in litres
per second [l/s], rather than metres-cubed per second [m^3/s], in 0/U:
boundaryField
{
inlet
{
type flowRateInletVelocity;
volumetricFlowRate 0.1 [l/s];
value $internalField;
}
...
}
Or, to specify the pressure field in bar, in 0/p:
internalField uniform 1 [bar];
Or, to convert the parameters of an Arrhenius reaction rate from a
cm-mol-kcal unit system, in constant/chemistryProperties:
reactions
{
methaneReaction
{
type irreversibleArrhenius;
reaction "CH4^0.2 + 2O2^1.3 = CO2 + 2H2O";
A 6.7e12 [(mol/cm^3)^-0.5/s];
beta 0;
Ea 48.4 [kcal/mol];
}
}
Or, to define a time-varying outlet pressure using a CSV file in which
the pressure column is in mega-pascals [MPa], in 0/p:
boundaryField
{
outlet
{
type uniformFixedValue;
value
{
type table;
format csv;
nHeaderLine 1;
units ([s] [MPa]); // <-- new units entry
columns (0 1);
mergeSeparators no;
file "data/pressure.csv";
outOfBounds clamp;
interpolationScheme linear;
}
}
...
}
(Note also that a new 'columns' entry replaces the old 'refColumn' and
'componentColumns'. This is is considered to be more intuitive, and has
a consistent syntax with the new 'units' entry. 'columns' and
'componentColumns' have been retained for backwards compatibility and
will continue to work for the time being.)
Unit definitions can be added in the global or case controlDict files.
See UnitConversions in $WM_PROJECT_DIR/etc/controlDict for examples.
Currently available units include:
Standard: kg m s K kmol A Cd
Derived: Hz N Pa J W g um mm cm km l ml us ms min hr mol
rpm bar atm kPa MPa cal kcal cSt cP % rad rot deg
A user-time unit is also provided if user-time is in operation. This
allows it to be specified locally whether a parameter relates to
real-time or to user-time. For example, to define a mass source that
ramps up from a given engine-time (in crank-angle-degrees [CAD]) over a
duration in real-time, in constant/fvModels:
massSource1
{
type massSource;
points ((1 2 3));
massFlowRate
{
type scale;
scale linearRamp;
start 20 [CAD];
duration 50 [ms];
value 0.1 [g/s];
}
}
Specified units will be checked against the parameter's dimensions where
possible, and an error generated if they are not consistent. For the
dimensions to be available for this check, the code requires
modification, and work propagating this change across OpenFOAM is
ongoing. Unit conversions are still possible without these changes, but
the validity of such conversions will not be checked.
Units are no longer permitted in 'dimensions' entries in field files.
These 'dimensions' entries can now, instead, take the names of
dimensions. The names of the available dimensions are:
Standard: mass length time temperature
moles current luminousIntensity
Derived: area volume rate velocity momentum acceleration density
force energy power pressure kinematicPressure
compressibility gasConstant specificHeatCapacity
kinematicViscosity dynamicViscosity thermalConductivity
volumetricFlux massFlux
So, for example, a 0/epsilon file might specify the dimensions as
follows:
dimensions [energy/mass/time];
And a 0/alphat file might have:
dimensions [thermalConductivity/specificHeatCapacity];
*** Development Notes ***
A unit conversion can construct trivially from a dimension set,
resulting in a "standard" unit with a conversion factor of one. This
means the functions which perform unit conversion on read can be
provided dimension sets or unit conversion objects interchangeably.
A basic `dict.lookup<vector>("Umean")` call will do unit conversion, but
it does not know the parameter's dimensions, so it cannot check the
validity of the supplied units. A corresponding lookup function has been
added in which the dimensions or units can be provided; in this case the
corresponding call would be `dict.lookup<vector>("Umean", dimVelocity)`.
This function enables additional checking and should be used wherever
possible.
Function1-s and Function2-s have had their constructors and selectors
changed so that dimensions/units must be specified by calling code. In
the case of Function1, two unit arguments must be given; one for the
x-axis and one for the value-axis. For Function2-s, three must be
provided.
In some cases, it is desirable (or at least established practice), that
a given non-standard unit be used in the absence of specific
user-defined units. Commonly this includes reading angles in degrees
(rather than radians) and reading times in user-time (rather than
real-time). The primitive lookup functions and Function1 and Function2
selectors both support specifying a non-standard default unit. For
example, `theta_ = dict.lookup<scalar>("theta", unitDegrees)` will read
an angle in degrees by default. If this is done within a model which
also supports writing then the write call must be modified accordingly
so that the data is also written out in degrees. Overloads of writeEntry
have been created for this purpose. In this case, the angle theta should
be written out with `writeEntry(os, "theta", unitDegrees, theta_)`.
Function1-s and Function2-s behave similarly, but with greater numbers
of dimensions/units arguments as before.
The non-standard user-time unit can be accessed by a `userUnits()`
method that has been added to Time. Use of this user-time unit in the
construction of Function1-s should prevent the need for explicit
user-time conversion in boundary conditions and sub-models and similar.
Some models might contain non-typed stream-based lookups of the form
`dict.lookup("p0") >> p0_` (e.g., in a re-read method), or
`Umean_(dict.lookup("Umean"))` (e.g., in an initialiser list). These
calls cannot facilitate unit conversion and are therefore discouraged.
They should be replaced with
`p0_ = dict.lookup<scalar>("p0", dimPressure)` and
`Umean_(dict.lookup<vector>("Umean", dimVelocity))` and similar whenever
they are found.
and make '-explicitFeatures' the option to use explicitFeatures. When implicitFeatures
is used, a surfaceFeaturesDict file is not written out to the system directory
including blockMeshDict, surfaceFeaturesDict and snappyHexMeshDict, based on the
case surface geometry.
Description
Preconfigures blockMeshDict, surfaceFeaturesDict and snappyHexMeshDict
files based on the case surface geometry files.
Starting from a standard OpenFOAM case, this utility locates surface
geometry files, e.g. OBJ, STL format, in the constant/geometry directory.
It writes out the configuration files for mesh generation with
snappyHexMesh based on assumptions which can be overridden by options on
the command line.
The utility processes the surface geometry files, attempting to anticipate
their intended purpose, trying in particular to recognise whether the
domain represents an external or internal flow. If there is a surface
which is closed, and is either single or surrounds all other surfaces,
then it is assumed that it forms the external boundary of an internal
flow. This assumption is overridden if the bounds of the background mesh
are specified using the '-bounds' option and they are more than 50% larger
than the surface bounds.
Surfaces which form boundaries of the domain may contain named regions
that are intended to become patches in the final mesh. Any surface region
whose name begins with 'inlet' or 'outlet' will become a patch of the same
name in the final mesh. On an external surface (for an internal flow),
regions can be identified as inlets and outlets using the '-inletRegions'
and '-outletRegions' options, respectively. When either option specifies a
single region, the resulting patch name will be specifically 'inlet' or
'outlet', respectively. Surfaces which are contained within the domain,
which do not surround or intersect other surfaces, are assumed by default
to be wall patches. Any closed surface which surrounds another (but not an
external surface) is used to form a cellZone within the mesh. Any surface
can be specifically identified as a cellZone with the '-cellZones' option,
with the additional '-baffles' and '-rotatingZones' options available to
assign a surface to a more specific use.
The background mesh for snappyHexMesh is a single block generated by
blockMesh, configured using a blockMeshDict file. The block bounds are
automatically calculated, but can be overridden by the '-bounds'
option. The number of cells is calculated to produce a fairly small
prototype mesh. The cell density can be overridden by the '-nCells' option
or can be scaled up by an integer factor using the '-refineBackground'
option. When the background mesh is required to form patches in the final
mesh, e.g. for an external flow, the user can specify the names and types
of the patches corresponding to the six block faces using options such as
'-xMinPatch', '-xMaxPatch', etc. The name and type of the default patch,
formed from block faces which are not configured, can also be specified
with the '-defaultPatch' option. The utility provides placeholder entries
for all block faces unless the '-clearBoundary' option is used. A special
'-cylindricalBackground' option generates a cylindrical background mesh,
oriented along the z-axis along x = y = 0.
The snappyHexMesh configuration is generated automatically, applying a set
of defaults to the main configuration parameters. By default, explicit
feature capturing is configured, for which a surfaceFeaturesDict file is
written for the user to generate the features files with the
surfaceFeatures utility. Implicit feature capturing can alternatively be
selected with the '-implicitFeatures' option. Refinement levels can be
controlled with a range of options including: '-refinementLevel' for the
baseline refinement level; '-refinementSurfaces' for levels on specific
surfaces; '-refinementRegions' for levels inside specific surfaces;
'-refinementBoxes' for quick, box-shaped refinement regions specified by
min and max bounds; '-refinementDists' for distance-based refinement; and
'-nCellsBetweenLevels' to control the transition between refinement
levels. A '-layers' option specifies additional layers of cells at wall
boundaries. The insidePoint parameter is set to '(0 0 0)' by default but
can be overridden using the '-insidePoint' option.
