- 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
- various GUI properties are now animateable="0"
(meaning they no longer show up on the time-line)
- move reader switches to the bottom of the GUI
- move Lagrangian fields above pointFields for better visibility
- basic support for multiple clouds
- filter fields based on selection before looping over all the geometry bits
- mesh conversion functions now return VTK mesh types for easier handling
- faceZones mesh conversion had points/faces allocation reversed
- updateInfo with every call to setTime() that changes the timeIndex
This seems to be the only way to notice Lagrangian fields
- restore displaying patchnames that got forgotten in the last commit
- misc reorganization
- normal mesh data on port0
- Lagrangian data on port1
- no fixed block numbers for dividing internalMesh, patches, zones etc.
This helps avoid ugly gaps in the multiblock output
- avoid segfault if Lagrangian fields are converted without positions
TODO:
- can we label the output ports?
- the selection of Lagrangian data and fields is wonky.
- added printMemory() method to aid debugging memory used
- call UpdateInformation() if the mesh has changed
- automatic activation of "internalMesh", "p", "U"
is suppressed if a fvMesh is cached. Otherwise,
appearing/disappearing volFields can cause a crash
Note:
The message "had to make up a selection value" that sometimes occurs
seems to be paraview related (see paraview mailing list),
