- handling multiple regions require multiple readers
- a region is currently recognized by the file name, anything after the
'=' delimiter (eg, "case=region.OpenFOAM") is used to determine the
mesh region, but might be changed in the future
eg, 'case%region', 'case^region', 'case~region', 'case{region}' ...
Note:
- Having a separate reader for each region instead attempting to handle
all the mesh regions in a single reader is the better solution.
It is not only simpler, but allows distinct field selections for
each region
Todo:
- Haven't a test for Lagrangian and multi-regions.
- only create (and remove) case.OpenFOAM file if it doesn't already exist
- new -touch option just generates case.OpenFOAM file and exits
- new -region option to create case=regionName.OpenFOAM file
(the delimiter may change in the future)
- usage, explicit -fast option for rebuilding new -mpi, -python, -mesa
options for specifying alternative modules to include without editing
the file
- the build options can also be grabbed from the script name itself.
eg, the soft-link buildParaView3.3-cvs-python specifies that the python
module should be included
- misc. cleanup in tools/buildParaViewFunctions: give the user some
feedback about the python version, set all variables at the bottom
of the file rather between initialise and build.
- be more careful when changing the hard-links to avoid the find
'-execdir' option (fails when the user has '.' in the path), and
do separate find/loop/grep/sed on the files to avoid touching too many
files and ruining a later rebuild stage.
Notes:
- the cmake uses -DCMAKE_INSTALL_PREFIX=$PARAVIEW_APP_DIR, but this
variable isn't defined anywhere.
- handle new cloud locations, got missed before the release
- handle multiple clouds
- more efficient checking of fields etc.
- write case file at the end, thus we can potentially
do something more intelligent about the time set handling
- streamlined code somewhat, minor attempt to reclaim some memory
- now use "mesh parts" for patches/zones/sets/etc throughout to avoid
ambiguity with mesh regions
- collect superCells and addPointCellLabels in a class. The old version
actually seemed to have overwritten the addPointCellLabels with each
cellSet/cellZone. This means that part of the pointFields would be trashed
in the combination of polyhedral cells, cellSets/cellZones and internalMesh
- polyDecomp information for muitiple mesh regions, but not yet exploited
- pointFields now working for cellZones/cellSets
- extroplating fields onto walls also works as expected for interpolated
pointFields
- added tooltips to reader GUI
TODO:
- pointFields (real and interpolated) for faceSets/faceZones
