functionEntry expansion is enabled for dictionary expansion with the -expand
option. The disableFunctionEntries option is no longer needed and has been removed.
This part of the name is unnecessary, as it is clear from context that
the name refers to a reaction. The selector has been made backwards
compatible so that old names will still read successfuly.
Function1 has been generalised in order to provide functionality
previously provided by some near-duplicate pieces of code.
The interpolationTable and tableReader classes have been removed and
their usage cases replaced by Function1. The interfaces to Function1,
Table and TableFile has been improved for the purpose of using it
internally; i.e., without user input.
Some boundary conditions, fvOptions and function objects which
previously used interpolationTable or other low-level interpolation
classes directly have been changed to use Function1 instead. These
changes may not be backwards compatible. See header documentation for
details.
In addition, the timeVaryingUniformFixedValue boundary condition has
been removed as its functionality is duplicated entirely by
uniformFixedValuePointPatchField.
Now for the wall in the simpleFoam pitzDaily tutorial case the following
patchField types are printed
group : wall
scalar v2 v2WallFunction
scalar nut nutkWallFunction
scalar k kqRWallFunction
scalar nuTilda zeroGradient
scalar p zeroGradient
scalar omega omegaWallFunction
scalar f fWallFunction
scalar epsilon epsilonWallFunction
vector U noSlip
instead of
group : wall
scalar v2 generic
scalar nut generic
scalar k generic
scalar nuTilda zeroGradient
scalar p zeroGradient
scalar omega generic
scalar f generic
scalar epsilon generic
vector U noSlip
by introducing a new specialised type, variable, derived from word with
additional valid characters. This avoids some complex type-juggling in the
parser and keyType in which string was used to represent either a string or a
variable.
When running in parallel the decomposed dictionary files are read from the
case directory in either un-collated or collated format and changed dictionaries
written in the form specified by the selected fileHandler.
The instance directory of the dictionary file is obtained from the file path
argument, e.g.
mpirun -np 4 foamDictionary 0.5/U \
-entry boundaryField.movingWall.value \
-set "uniform (2 0 0)" -parallel
If the -case option is specified time is created from the case
system/controlDict enabling support for parallel operation, e.g.
mpirun -np 4 \
foamDictionary -case . 0/U -entry boundaryField.movingWall.value \
-set "uniform (2 0 0)" \
-parallel
This will read and modify the 0/U field file from the processor directories even
if it is collated. To also write the 0/U file in collated format the collated
fileHandler can be specified, e.g.
mpirun -np 4 \
foamDictionary -case . 0/U -entry boundaryField.movingWall.value \
-set "uniform (2 0 0)" \
-fileHandler collated -parallel
This provides functionality for field manipulation equivalent to that provided
by the deprecated changeDictionary utility but in a more flexible and efficient
manner and with the support of fileHandlers for collated parallel operation.
which are now read directly from the thermophysicalProperties dictionary for
consistency with non-reacting mixture thermodynamics. The species thermo and
reactions lists can still be in separate files if convenient and included into
the thermophysicalProperties file using the standard dictionary #include.
This formalises the flexible and extensible OpenFOAM thermodynamics and reaction
format as the direct input to OpenFOAM solvers. The CHEMKIN format is still
supported by first converting to the OpenFOAM format using the chemkinToFoam
utility.
This is useful to visualise sources which are created as
volScalarField::Internal, e.g. the turbulence generation term for models like
kEpsilon in which it is named kEpsilon:G.
To avoid additional clutter in the interface volFields, surfaceFields and
pointFields are now selected from a single fields selection box consistent with
the single directory with guaranteed unique names in which they are stored.
Note that when visualising the "phi" flux fields that these are extensive, the
value depends directly on the face area, so unless the mesh is uniform
interpolated continuous colour plots are not physical or informative.
Based on proposal contributed by Mattijs Janssens
and copy assignment operator for classes with a copy constructor
This is often described as the rule of 3 (or rule of 5 in C++11 if move
constructors and assignment operators are also defined) and makes good sense in
ensuring consistency. For classes in which the default bitwise copy constructor
or assignment operator are appropriate these are now specified explicitly using
the "= default" keyword if the other is explicitly defined fulfilling the rule
of 3 without the need to define the body of the function.
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.
Replaced all uses of complex Xfer class with C++11 "move" constructors and
assignment operators. Removed the now redundant Xfer class.
This substantial changes improves consistency between OpenFOAM and the C++11 STL
containers and algorithms, reduces memory allocation and copy overhead when
returning containers from functions and simplifies maintenance of the core
libraries significantly.
Using the new field mapper framework it is now possible to create specialised
mappers rather than creating a fatter and fatter interface in the base mapper.
This approach is far more extensible, comprehensible and maintainable.
This clarifies the purpose which is to indicate that the object should be read
or written on this particular processor rather than it is or is not valid.
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.