- 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)

  - how did the old versions actually even work?

  - remove inappropriate fields from the regions
    (only important or useful for post-processing)
  - Allclean script had missed some files

  - 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.

 - routines taken from triSurface but are not restricted to triangles

  - remove TimeRange property from XML. Not needed for discrete time data
  - represent Lagrangian data as VTK_VERTEX for simple visualization

  - 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.