Skip to content

GitLab

Open
Opened by olesen@olesenDeveloper

cleanup the openfoam reader

There are many parts of the OpenFOAM reader that need attention to avoid further bit-rot. Here's a short-list of things to be addressed.

  • relocate to its own dedicated directory (as per Exodus, Ensight etc). This will make it somewhat easier to breakup some small bits during refactoring and to introduce some privately used classes. Previously discussed part of this with @demarle. In principal, this is initially just a git mv, but my CMake level of knowledge means that I can't easily figure out which cmake files I'd need to adjust. I mentioned this to @tcoulange as a potentially trivial thing for kitware to handle.

  • remove support for some really old bits. The OpenFOAM "cells" file is old (>10years). OpenFOAM itself only supports for extreme backwards compatibility, but hasn't written it in the last decade. We could/should drop this clutter from the reader. It is only 80 lines, but IMO fairly pointless. (done)

  • make the 32/64-bit handling less clunky. After discussions with @demarle, I have a dual-sized list for label/scalar using vtkNew that eliminates loads of casting. Fairly ready to go, but so many other messy places that it is not easy to add this encapsulation. (consistency is now there, a reasonable amount of cleanup, final is less urgent)

  • the internal parser needs a good clean and restructuring so that it becomes more clear what is actually being called. The OpenFOAM mesh should get its own class for handling the OpenFOAM to VTK translation. I've done something similar with our own libraries and think most of it could be done similarly in the vtk version.

  • in the OpenFOAM plugin update for OpenFOAM-1706, I think I've found a much more elegant means of caching the mesh. Instead of caching the OpenFOAM stuff read from disk, we should be translating it directly to a vtk unstructured-grid and cache that with smart pointers. Field updates are added to a shallow copy of the data (previously worked out with @acbauer ). This should really help reduce overhead and improve speed.

  • add display of patch names as a bunch of text actors. This is useful for figuring out your geometry and currently one of the features of our plugin that I use the most.

There are more things, but this is just the short-list and issue to start. I guess that @jpouderoux should also be involved.

Edited by olesen