I have been familiar with VTK for some time and use it extensively in ParaView plugins/VTK modules I write for post-processing of FEA data, but my use of VTK has been limited to post-processing. What I am not keen to is the efficiency of the data structures, since we are happy to take inefficiencies in a trade off for versatile tools when it comes to post-processing (most of the time).
With that context, what are your thoughts about using a vtkUnstructuredGrid to store mesh within a FEA software? Has this been done before and are the trade offs known? One issue I can see is extending the vtkCell class. It doesn’t look feasible to inherit since specialized cell types inherit from vtkCell. It could be done via composition with new class inheriting from vtkCell that provides a finite element interface as an extension and holds/wraps an instance of a specialized class, such as vtkHexahedron.
Another issue that I well aware of from post-processing is that the data cannot really fit into a vtkUnstructuredGrid since we deal with XFEM in a distributed computing environment. Typically, we use a multiblock structure (each block holds a component) with each block being a multipiece structure (each piece holds a part of the component that a rank is responsible for) and each piece is a vtkUnstructuredGrid that includes ghost cells. VTK’s core and general filters seems to usually play nicely with this structure.
These are a few concerns I see, but I am sure I am missing many more. We develop many algorithms for XFEM that might be useful to others if developed within VTK, and we would benefit from what VTK offers. I am just trying to get some grasp about what it would take and what challenges might lie ahead.
There is a question of design challenges of fitting VTK into an FEA code (I found the InsituDataSets article that is very useful)
In-situ data structure support is fairly hit or miss at the moment. There’s been a recent push to fix-up more filters to be compatible with them, but you may run into trouble if you use filters that are off the common path. That said, there have been projects using them successfully for a while now, so the basic functionality should be there.
There is a question of how much overhead is there for VTK data structures (I am still uncertain about this part)
Things are improving on this front, especially for in-situ arrays. The methods described in this blog post have been optimized to get the same performance for (non-virtual) in-situ arrays that we see for native arrays.
The vtkCellArray container (which may or may not come in handy for an in-situ dataset) was recent rewritten to support more in-situ usecases, such as runtime support for 32 or 64 bit ids and split offsets/connectivity arrays.
As for the overall question of whether VTK’s data structures would be suitable for use as a native mesh in an FEA, it’s hard to say without doing quite a bit of investigation and benchmarking.
In-situ data structure support is fairly hit or miss at the moment. There’s been a recent push to fix-up more filters to be compatible with them, but you may run into trouble if you use filters that are off the common path. That said, there have been projects using them successfully for a while now, so the basic functionality should be there.
Ah, this is very useful to know. I would say that the CommonFilters would be suitable for most in-situ visualization, but it sounds like things might need to be repacked into the VTK structures for post-processing, which requires some filters from other modules.
Things are improving on this front, especially for in-situ arrays. The methods described in this blog post have been optimized to get the same performance for (non-virtual) in-situ arrays that we see for native arrays.
The vtkCellArray container (which may or may not come in handy for an in-situ dataset) was recent rewritten to support more in-situ usecases, such as runtime support for 32 or 64 bit ids and split offsets/connectivity arrays.
I had read that blog about data arrays this morning and it was helpful. It sounds encouraging that there a movement towards VTK being suitable for in-situ visualization.
As for the overall question of whether VTK’s data structures would be suitable for use as a native mesh in an FEA, it’s hard to say without doing quite a bit of investigation and benchmarking.
I came to the same conclusion, so I was wondering if anyone had done the investigation or implementation.
Thank you very much for these thoughts. They were quite helpful.
No, I apologize for my ambiguity. I am considering the viability of using VTK as the mesh data structures within an FEA code. I have a lot of uncertainty regarding the performance and design challenges, so I thought I would reach out to the community and see if others had explored this.