Plans for python objects from MCNP output files? [short answer: no]

[SterlingButters]

Sorry, I'm not following the feature request template since I'm thinking this project's scope is intentionally limited to input files but thought I would ask the question.

[MicahGale]

Yes as it now stands there is no plan to support output files. The main reasons for this are:

1. There is no public documentation on the output files, so we are treating the file format as export controlled.
2. From my experience: output files are not fun to robustly parse.
3. The best workflow is to enable the MCTAL file, and to use: mcnptools to parse the mctal file.

If one day MCNP implements H5 files, or really any standardized format really, for tallies, I'd be open to revisit this.

[SterlingButters]

There is no public documentation on the output files, so we are treating the file format as export controlled.

Yes, the export-controlled aspect is clearly the main hurdle. The question becomes: is source code designed to parse output files abstracted enough from the output file itself to not be considered export-controlled?

If one day MCNP implements H5 files, or really any standardized format really, for tallies, I'd be open to revisit this.

Based on the last symposium, it sounds like they are headed that way but I guess the best workflow might still be the mcnptools path.

I guess support for output files would be pretty duplicative - makes sense to ignore

[MicahGale]

We can bug the MCNP devs if output code is export controlled, but being with a National Lab I have taken the most conservative approach.

The other aspect is: I suspect they don't document the output because they can break backwards compatibility at any time they want with outputs, which working with just sounds awful.

[SterlingButters]

So believe it or not, I'm coming back to this thinking we should maybe reconsider. To be honest I had never actually tried to use mcnptools. It turns out that it is unbelievably slow (at least tests with a few imsht/meshtal's I had lying around). Natively reading the output file in python for some 4 different meshtallies (from a 160MB meshtal file) takes about 6 seconds while mcnptools takes 10x that (and the results are conceivably worse on a 1+GB file I have). Admittedly, the mcnptools code looks cleaner but it is very slow.

LANL may be moving strictly to H5 files in which case MontePy could just offer some simple wrapper methods to extract data from the H5 files. Also, because I suspect they will move to HDF5, I wouldn't suggest any sort of parsing of regular output files near-term. However, I think the story is different for meshtals - near-term support could be of benefit.

[MicahGale]

I'm surprised it's so much slower since it has a C++ backend. If we had guidance from LANL on the output files' export control status I could make a decision on allowing a merge.

[SterlingButters]

I was surprised too. I wouldn't expect that I could attribute it to the compilation although it did fail 3 tests related to PTRAC (which I didn't plan to utilize so I ignored).

Anyway, as far as export control goes, I'd expect the requirements to be less restrictive on meshtal's since the output format is pretty simplistic - but would certainly need to confirm. I have contacts at LANL none that could provide guidance wrt export control - might be up to ORNL now that I think about it.

[MicahGale]

It probably would be LANL. RSICC only really gets involved AFAIK I think the idea outcome is that they publish a manual on the output formats. If you're going to PHYSOR we should probably bug some of the MCNP developers about that.

[tjlaboss]

This discussion should be briefly summarized on https://idaholab.github.io/MontePy/faq.html

[MicahGale]

It is for the scope, which isn't the FAQ. https://github.com/idaholab/MontePy/pull/380/files#diff-fda687ac736f7caab288058b149b58e3e4be6096e90dfbff9324641110e04578R76