Points now always get decomposed or reconstructed for the initial face
instance. This means that they are available in the constant directory
even if decomposition/reconstruction begins at a later time which has
its own moved points field.
The cellProc field is the field of cell-processor labels.
The names "distribution" and "dist" have been removed as these are
ambiguous in relation to other forms of distribution and to distance.
The reconstructPar utility now reconstructs the mesh if and when it is
necessary to do so. The reconstructParMesh utility is therefore no
longer necessary and has been removed.
It was necessary/advantagous to consolidate these utilities into one
because in the case of mesh changes it becomes increasingly less clear
which of the separate utilities is responsible for reconstructing data
that is neither clearly physical field nor mesh topology; e.g., moving
points, sets, refinement data, and so on.
This is so that when an executable is removed and replaced by a
placeholder script, a pull, re-build and run now launches the script
rather than an out-of-date executable.
When this option is enabled, non-conformal boundary conditions will be
added to all the fields. It enables exactly the same behaviour as the
"fields" entry that is available when using this utility with a settings
dictionary (system/createNonConformalCouplesDict).
If files of the same name exist in different sub-directories of the main
directory, e.g. 'inletPatch/0/patch.vtk' and 'outletPatch/0/patch.vtk', a
further index is appended to the name in the generated links, e.g.
'patch0.0000.vtk' and 'patch1.0000.vtk'
The schemesField option:
- To employ the same numerical schemes as another field set
the \c schemesField entry,
works to set discretisation schemes and a standard linear solver and settings
but not MULES for which an entry in fvSolution under the actual field name is
required.
When two phases interact, neither of which can become continuous, only a
general model is appropriate. A warning should not be issued regarding a
general model's use for this configuration.
Many functionObjects operate on fvMesh objects, in particular vol and surface
fields and they cannot be updated in polyMesh as they depend on fvMesh data
which is updated after polyMesh.
If the sequence of meshes are decomposed independently the number, order and
potentially type of processor patches is likely to change. Thus the processor
patches and patch fields must be replaced with those of the new mesh.
