I have an interesting use-case for in-situ and I have been looking to become Catalyst user for while. I read the blog about the new API, have gone through some examples in ParaView source tree, basic Conduit examples and so encouraged… dived into OpenFOAM.
I am aware of the legacy API based function object but before trying out my application I decided to adapt it to the new API. I did not have any particular reason other than wanting to learn more about the internals, but also future proofing the code as the team I am in tends to use the latest ESI OpenFOAM and the latest ParaView and VTK.
Unfortunately I underestimated the difficulty. I think I understand the overall structure and I am very impressed with the progress that has been made on incorporating different sources of information that OpenFOAM produces. But, I am finding it hard to understand what is happening at the lower-levels. I am happy and would like to do some of the programming work over a the next 2-3 months, but would use some supervisory support. This is all in preparation for a bigger project where I expect that flexibility will be important.
My current and still fairly early stumbling block is passing the mesh information. I can see that the current function object uses
vtuSizing classes from the main source code. Do I understand correctly that translation from OpenFOAM internals to VTK happens through this instances of these classes? Is it advisable, under the new API, to make a translation into
vtkUnstructuredGrid and pass it through Conduit or should I rather translate the full OpenFOAM mesh into Conduit mesh format.