GitLab

I wanted to kick off a general discussion and get ideas and input from the kitware guys (eg, @charles.gueunet @mwestphal @utkarsh.ayachit). There are a few independent/intertwined items that I'd like to hash out.

Currently, the openfoam readers have a flat selector for all regions (eg, fluid, solid, etc) as well as all mesh parts (eg, internal mesh, various boundary patches etc). In the near future I would like to add selection of individual mesh zones as well. This is useful feature for people with a large external aero mesh with an inner cellzone closer to the vehicle. All of the internal plumbing is already in place in the reader, but it is not yet possible to select individual zones.

If we add in selection of individual zones, it will definitely cause cognitive overload for the users. In the classic motorBike case, this would give us an extra few entries in addition to the already 60+ individual patches.

Even if the newer composite data format that @utkarsh.ayachit has been working on isn't rolled out, I think it would be reasonable to replace the openfoam region selection with a tree structure with the hope that this could make the selections easier for a user to navigate. Will need to discuss which parts need to be adjusted, any caveats, may be desirable to bang together a qt widget for the reader too.

Another big topic is the addition of support for openfoam "collated" format, which is essentially a single file version of the respective processor<digit> format. So instead of having separate files like "processor{0,1,2,..127}/10/rho", we can instead have "processors128/10/rho" of block decomposed data comprising information for all processors. It is also possible to have segregated files such as "processors128_0-63/10/rho" and "processors128_64-127/10/rho".

Without concerning ourselves directly with the internals, suffice it to say that would we definitely prefer to read the collated file once for the respective procs.

The composite/multi-block structure:

Case
|-- processor0
|   |-- internal
|   |-- boundary
|   |   |-- patch0
|   |   |-- ...
|   |   \-- patchN
|-- processor1
|   |-- internal
|   |-- boundary
|   |   |-- patch0
|   |   |-- ...
|   |   \-- patchN
...

I think we need to turn this side-ways and have pieces (or equivalent) instead:

Case
|-- internal
|   |-- processor0
|   |-- ...
|   \-- processorN
|-- boundary
    |-- patch0
    |   |-- processor0
    |   |-- ...
    |   \-- processorN
    |-- ...
    \-- patchN
        |-- processor0
        |-- ...
        \-- processorN

If we do this, the vtkOpenFOAMReader (aka serial reader) would have to know which pieces it should be populating. It would also mean that the private class in vtkOpenFOAMReader would also need a piece-equivalent for its raw input data (Points, Faces, Owner, Neighbour, NumCell).

I might be overly complicating things, but it looks like that is what would need to change.