terrapower / armi

An open-source nuclear reactor analysis automation framework that helps design teams increase efficiency and quality
https://terrapower.github.io/armi/
Apache License 2.0
214 stars 83 forks source link

Allow plugins to define their own VTK-shapes for visualization #1254

Open drewj-usnctech opened 1 year ago

drewj-usnctech commented 1 year ago

It would be great if there was a plugin hook for converting block-types to ParaView geometry objects. This would allow new geometry exposed through the defineBlockTypes and defineAssemblyTypes hooks to be rendered in ParaView.

The logic for converting blocks to VTK meshes is defined here

https://github.com/terrapower/armi/blob/a4bca36231b8b74c39633f0ad86b6719910cc7a4/armi/bookkeeping/visualization/utils.py#L145-L161

And looks pretty well suited for plugin manipulation.

albeanth commented 1 year ago

@drewj-usnctech, just curious, can you provide an example of what new geometry you'd like to see supported? Before coming to TP I exclusively used Paraview and Visit for visualization and am always curious to see how we can improve ARMI Apps for use in these programs. Note, my knowledge of this corner of ARMI ends with what's written in the docs....

drewj-usnctech commented 1 year ago

@albeanth unfortunately I'm not able to say. Only that we're using the hooks mentioned above to add new geometry into the ARMI data model, and we'd like to use similar hooks for vtk viz. Without copying / subclassing / overriding the existing vis-file entry point to make a small change

albeanth commented 1 year ago

@drewj-usnctech got it, cool. Thanks!

jakehader commented 1 year ago

@drewj-usnctech, I think that it makes sense in this case for you to just write a separate module in your application and subclass or pull in what is needed. I'm not sure the threshold for more plugin hooks, but this seems like a specific implementation need for visualization and it might be better to implement a function that can take your special blocks/assemblies and make the VTK mesh you desire.

If you were able to share the geometry/mesh types in VTK that you'd like to be exposed in the framework without saying too much about the geometry/ feature you are modeling then maybe there is a way to implement some better functionality that can interact with VTK types better? Not sure.

drewj-usnctech commented 1 year ago

@jakehader

it might be better to implement a function that can take your special blocks/assemblies and make the VTK mesh you desire.

yeah this is what we were planning on doing already. Writing and exposing a function like

def newShapeToVTK(b: Block) -> VTKMesh:
   # mesh the snazzy shape

that feels very much in line w/ the new block and assembly type hooks. Or, similar to how new blocks / assemblies are defined with hooks as a map-like thing

    @staticmethod
    @HOOKIMPL
    def defineNewVTKMeshTypes():
        return [(MyNewBlock, newShapeToVTK)]

There's a non-zero amount of work to subclass the entry point and vtk dumper to make these minor changes, but there's also a non-zero amount of work needed to make the hooks usable by the entry point and dumpers. A new hook would be more useful for people who already have written hooks for new block and assembly geometries. It makes for a nice symmetry too

jakehader commented 1 year ago

I see what you mean @drewj-usnctech. I think that we need to discuss more generally what the plugin hooks should expose. Your solution seems reasonable but I also want to make it super clear in the plugin hook system what types of things should be exposed in the API.

@john-science want to help think about this?

drewj-usnctech commented 1 year ago

@john-science @jakehader we had a user reach out about this feature being useful with our custom Block and Assembly shapes. Thoughts?