APT Recommendations for Improving Plotting Tools For SNAP Visualization

[NRCgg]

I added some background files to the repository:

APT recommendations for plotting tool improvements - 2019

[NRCgg]

Chester Gingrich's ( @NRCgg ) comments back to APT, Inc. (at the time and now to ISL, Inc and others):

Regarding ParaView:

1. With regard to writing JNI libraries for each platform to support ParaView/Code Parsers; can the APTplot custom TRACE, RELAP5, etc. file parsers be rewritten in C++ so that ParaView (or other applications) can make use of them?
2. I liked the observation: " It would be possible to use ParaView as a server to drive plot generation, but this would require the development of a custom user interface. " - I am thinking that a "simple" and easily customizable GUI could be designed and implemented to do something like this - not just for ParaView but including many existing visualization tools.
3. Regarding a SNAP Job-Stream ParaView Job-step: This was developed and is in SNAP now!

General:

1. APT made a number of references to "No Job Stream Support" for many of the applications. I commented that SNAP does already provide a "Black Box" job step which is essentially just a custom script that anyone can write and use in a Job-Stream. Black-Box job-steps is not the same as job-stream support - BUT, it could accomplish MUCH of what most users need, I think.
2. APT mentioned that the APTplot GUI could be updated to be more user friendly and add some of these features - for extra funding. My observation is that APT, Inc (and now ISL, Inc) technically own the APTplot application. The NRC can't fund commercially owned application development! Maybe we could fund a new GUI like APTplot, maybe a "SNAPplot", that would fulfill our requirements?

[murpup]

I am not sure what you mean when you say that NRC cannot fund commercially-owned application development. NRC can fund pretty much anything it wants so long as it meets a legitimate and lawful need and the terms can be negotiated to both parties satisfaction. Any software development we fund would give NRC certain rights with regard to use/modification/redistribution, but the contractor is under no obligation to agree to the terms.

[NRCgg]

@murpup You hit it on the head though in your statement "as long as terms can be negotiated... ". For instance, you can't fund development changes to MS Word and then claim to have the rights to redistribute MS Word without MS having its say! The issue I had (and maybe no longer have depending on ISL, Inc's position on APTPlot) was that the APTPlot owner did NOT want us funding APTPlot changes - they wanted full ownership of APTPlot. This may not be true of ISL, Inc. or they may be willing to fork APTPlot into a "SNAPplot" package that the NRC owns? Any comment? @NRC-Research/snap

[WDunsford]

This is definitely an area were we (ISL) need to brainstorm some solutions, and present them informally to @NRCgg. I would like to see AptPlot grow to what it could be. The UI has been trapped in the 1980's, but the existing scripting language and capability for parsing plot files should not just be discarded out of hand.

[murpup]

You should take a look at Veusz

[NRCgg]

Ian Porter's ( @porteri NRC FAST code project manager at the time; he has since left the agency) comments:

• What about a change in the thought process behind "the 2D and 3D mesh generation" section?

  What if all of our codes (TRACE, PARCS, FAST, MELCOR, SCALE) moved to using a standardized output format (i.e., HDF5, VTK, Exodus, etc) rather than trying to find a tool or develop something specifically to interface with each of our different existing formats (improving flexibility). This would obviously be more work on the code groups but opens up doors for new tools & modernizing our capabilities – redacted

• For FAST, we should consider that we are moving from only supporting 2-D (r,z) meshes to both structured 3-D meshes (plate, sphere & cylinder geometries) as well as unstructured grid meshes. What’s currently in our plot file won’t suffice for these changes (which is why we support VTK and are developing HFD5 and Exodus output file support)

• VERAView is another piece of open-source (DOE - ORNL) python-based software that should be considered (it was designed to visualize full reactor cores in 3D as well as provide 2D plots). redacted (I’m currently working on HFD5 support into FAST to do work with this tool).

• I’m surprised MatPlotLib (I assume this is MatPlot in the document - ) didn’t get more consideration. I feel like this can very easily do what APTPlot can do (in my opinion easier to use / graphs look better) and would be a nice plug-in step in lieu of APT Plot when we have pre-defined graphs that we want created after a run.

As we discussed yesterday, we should also consider the front-end mesh-generation in this discussion as well. We need to be able to generate meshes that are beyond a “pipe” or slab for all of our non-LWR (and potentially some of the new LWR fuel concepts) analyses. Right now we have to use CUBIT from Sandia to generate an unstructured Exodus mesh. We’re also looking into supporting the open-source mesh generator Gmsh as well. Ideally there will be some link (or just one interface) between our input file generator and our input mesh generator.

[NRCgg]

Chris Murray's ( @murpup NRC TRACE code project manager) comments:

Regarding Survey of Software Packages:

• I see some pros and cons for each reviewed software package, but I see no further cost-benefit analysis that conclusively demonstrates/concludes that modifying APTplot with the needed capabilities is the cheapest/quickest/best way to go.
• Where is TecPlot? That is considered the industry standard and should be reviewed and features copied to the maximum extent allowable and that it makes sense.

Regarding 2D and 3D Mesh Generation:

• You need another example in which the 3D plotting capability will allow the user to identify a slice in the Z direction, and will map multiple HTSTR components to the Y axis, and the X axis is the radial node. I think this will require some changes to TRACE to locate HTSTR’s in 3D space. This info is available for PARCS mappings, but it needs to be generalized I think.
• The user should have the ability to flip which axis the fields apply to. For the HTSTR, the Y is really the Z axis (height). A user might want their plot to be such that the x axis applies to the radial direction, the z axis applies to the z directions, and the fuel temperature would be plotted on the Y axis.

Regarding Recommendations:

• ( about the UI refactoring for APTplot ) This should be priority # 1. Then 3D plot capabilities, then the other stuff
• ( about standalone application development that builds 3D mesh data ) I recommend against this approach. Instead, build a solid API for required 3D mesh info and let the codes worry about generating the information necessary to exploit the API. Otherwise, we end up with multiple maintenance points for each code with regard to parsing the code input.
• ( about updates to APTplot requiring additional funding ) redacted
• ( about Java Beans User Interface) This section requires significant expansion. They should be discussing what specific improvements they intend to make to the APTPlot User Interface to make it easier for engineers to use, how the look and feel of plots will be improved, and how it will speed up analysis. We want the user to be able to open up multiple plot tabs at a time, the ability to select and drag and drop plot items around without having to go through a separate dialog box to do so, the ability to quickly manipulate data channels by doing math on them, etc.
• ( about keyboard commands converted into toolbar toggles ) Without giving up the capability to use keyboard commands, right?
• ( about 3D plotting Feature in APTplot) Will there be a movie option?