to avoid clash with the set type, e.g. in topoSetDict
actions
(
{
action new;
type cellZoneSet;
name c0;
source shapeToCell;
shape hex;
}
);
the entry "shape hex" selects the hex cell shape.
The editor must be specified by configuring the EDITOR environment
variable. For example to use the 'gedit' editor, the following entry
could be added to the user's .bashrc file:
export EDITOR=gedit
corresponding to a give order, another case or another region.
Description
Utility to reorder the patches of a case
The new patch order may be specified directly as a list of patch names
following the -patchOrder option or from the boundary file of a reference
case specified using the -referenceCase option with or without the
-referenceRegion option.
This utility run either serial or parallel but either way the reference
case boundary file is read from the constant directory.
Usage
\b reorderPatches
Options:
- \par -patchOrder \<patch names\>
Specify the list of patch names in the new order.
- \par -referenceCase \<case path\>
Specify the reference case path
- \par -referenceRegion \<name\>
Specify an alternative mesh region for the reference case.
If -referenceCase is not specified the current case is used.
- \par -overwrite \n
Replace the old mesh with the new one, rather than writing the new one
into a separate time directory
- \par -region \<name\>
Specify an alternative mesh region.
functionObjects layerAverage, nearWallFields, wallHeatFlux, wallHeatTransferCoeff,
wallShearStress and forcesBase now support both the 'patches' option for which a
list of regular expressions to select the patches is specified and the new simple
'patch' option for which a single patch name is specified.
These files are now searched for starting at the current time and back in time
to constant but stopping at the most recent polyMesh directory containing faces,
i.e. the most recent topological specification of the mesh. Zones which cannot
be found are set empty rather than requiring zone files to be present containing
an empty list.
This allows a remote location to be synchronised. In this case, it is
synchronised to the first valid process. This choice is abitrary. A
lastProcOp could be implemented similarly, or a more complex criteria
could be used.
