Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • VTK VTK
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 877
    • Issues 877
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 234
    • Merge requests 234
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Terraform modules
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • VTKVTK
  • VTKVTK
  • Issues
  • #18157
Closed
Open
Issue created Mar 23, 2021 by olesen@olesenDeveloper

restructure openfoam region selection etc

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.

Edited Mar 23, 2021 by olesen
Assignee
Assign to
Time tracking