- 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;
}
- improve doxygen entries for searchable surfaces.
- support selection of searchable surfaces with shorter names.
Eg,
type box | cylinder | ...;
vs type searchableBox | searchableCylinder | ...;
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.
- although this has been supported for many years, the tutorials
continued to use "convertToMeters" entry, which is specific to blockMesh.
The "scale" is more consistent with other dictionaries.
ENH:
- ignore "scale 0;" (treat as no scaling) for blockMeshDict,
consistent with use elsewhere.
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
}
}
The modes of operation are set by the dimensions of the pressure field
to which this boundary condition is applied, the \c psi entry and the value
of \c gamma:
\table
Mode | dimensions | psi | gamma
incompressible subsonic | p/rho | |
compressible subsonic | p | none |
compressible transonic | p | psi | 1
compressible supersonic | p | psi | > 1
\endtable
For most applications the totalPressure boundary condition now only
requires p0 to be specified e.g.
outlet
{
type totalPressure;
p0 uniform 1e5;
}
In most boundary conditions, fvOptions etc. required and optional fields
to be looked-up from the objectRegistry are selected by setting the
keyword corresponding to the standard field name in the BC etc. to the
appropriate name in the objectRegistry. Usually a default is provided
with sets the field name to the keyword name, e.g. in the
totalPressureFvPatchScalarField the velocity is selected by setting the
keyword 'U' to the appropriate name which defaults to 'U':
Property | Description | Required | Default value
U | velocity field name | no | U
phi | flux field name | no | phi
.
.
.
However, in some BCs and functionObjects and many fvOptions another
convention is used in which the field name keyword is appended by 'Name'
e.g.
Property | Description | Required | Default value
pName | pressure field name | no | p
UName | velocity field name | no | U
This difference in convention is unnecessary and confusing, hinders code
and dictionary reuse and complicates code maintenance. In this commit
the appended 'Name' is removed from the field selection keywords
standardizing OpenFOAM on the first convention above.
See http://www.openfoam.org/mantisbt/view.php?id=2076
- .org is the file extension for emacs org-mode as well
- .orig is more to the point (.org isn't always recognized as "original")
- .original is too long, although more consistent with the convention
of source code file naming
Update script contributed by Bruno Santos
