Production of multigroup cross sections with NJOY

[shimwell]

Description

Following up with a slack conversation with @bohmt @MicahGale and @lewisgross1296

Currently the njoy.py file is able to create cards for ACER, PURR, GASPR, HEATR, HEATR_LOCAL, BROADR, RECONR and is useful for processing nuclear data. We also have lots of nice inbuilt energy group structures and NJOY input file writting and output file reading.

I was wondering if we could add GROUPR to the supported NJOY cards and another method called something like a classmethod MGXS.from_njoy()?

This would give use the ability to generate multigroup cross sections directly from ENDF data (without particle transport).

I have tried to match the existing openmc NJOY templates by using njoy inp examples from IAEA and groupr examples from T2 and page 230 of the njoy manual but I don't really know NJOY well enough to understand all the numbers.

_TEMPLATE_GROUPR = """
groupr / %%%%%%%%%%%%%%%% Multigroup data %%%%%%%%%%%%%%%%
{nendf} {npendf} 0 {ndir} /
{mat} 1 1 11 6 1 1 1/  <---- arbitrary structure for ign, arbitrary structure for igg, 11 for iwt number, 6 for mfd number, not sure about the last 3 numbers
'{library} GROUPR for {zsymam} processed by NJOY'/
{temperature}
1.E+10
 {num_energy_bins}
{energy_bins}
 {num_energy_bins}
{energy_bins}
3/
6/
16/
0/
0/
"""

Tagging @gonuke who is also interested in have a method of making multigroup cross sections

Alternatives

Run NJOY outside of openmc and get the GROUPR cross sections

Compatibility

This would add a method without disturbing existing code

[makeclean]

I thought one had to do it through transport, else you are missing the various group weighting factors from where the flux is in a given group and for self shielding?

[lewisgross1296]

Typically, you need some multi-group neutron spectrum, yes. I guess if you use a "typical" spectrum, you don't need to run transport, but that probably would not be recommended unless you were confident in the flux. But if you just want quick and dirty MGXS, you could use equal group weighting or some contrived flux weighting.

[shimwell]

NJOY does offer a couple of models to estimate self shielding (Bondarenko model and the flux calculator). I guess they are not as good as transporting but perhaps better than nothing.

[MicahGale]

Yes with GROUPR inputs ( I refuse to say card) you use a fine-group structure. I would say anything less than 50 groups with GROUPR is getting risky.

So the one thing is I have actually written a script to do exactly this before with openmc. The hardest part is that it produces a group-wise ENDF GENDF (little sad they did create a GANDALF backronym). It uses a few more advanced features of ENDF-6 that breaks the ENDF reader in Openmc. I think this should be done but with a lot of infrastructure rework for reading ENDFs to make it more robust.

On Transport for multigroup cross sections

This is just me rambling, for better documentation see GROUPR in the NJOY manual.

So with multigroup cross sections you assume that the flux can be represented by something like

$$\sigma = \frac{\sum_{n=1}^N \phi_n \sigman}{\sum{n=1}^N \phi_n}$$

Where $$\phi_n$$ is the flux , and $$\sigma_n$$ is the multi-group cross-section. This essentially assumes that the flux can be represented as:

$$\phi = \sum_{n=1}^N a_n \psi_n$$

Where $a_n$ is the group flux multiplier and $$\psi_n$$ is the "shape". So this assumes that inside of the energy group the flux shape is constant and is just varied by a multiplier. This is only valid for very fine groups.

In GROUPR you typically do a combo of a maxwell-boltzmann flux, a $$\frac{1}{E}$$, and a watts fission spectrum in thermal, epithermal, fast spectra. So this typical fast spectrum isn't valid for use in fusion, which is the biggest danger I see.

[shimwell]

I had a go at getting NJOY to run GROUPR but couldn't quite get it working.

 njoy 2016.74  12Jan24                                       04/11/24 23:05:58
 *****************************************************************************

 reconr...                                                                0.0s

 ---message from rdf2bw---calculation of angular distribution not installed.

 ---message from emerge---nonpositive elastic cross sections found.

 broadr...                                                                2.1s

 heatr...                                                                 3.9s

 heatr...                                                                 7.3s

 gaspr...                                                                26.7s

 purr...                                                                 27.5s

 mat = 2631                                                              27.5s

 ---message from purr---mat 2631 has no unresolved parameters
                          copy as is to nout

 groupr...                                                               27.7s

 ***error in groupr***unable to find mat=2631 t=  2.9360E+02

STOP 77
Traceback (most recent call last):
  File "/home/j/group_data_with_njoy/openmc_script.py", line 15, in <module>
    make_ace(
  File "/home/j/openmc/openmc/data/njoy.py", line 422, in make_ace
    run(commands, tapein, tapeout, **kwargs)
  File "/home/j/openmc/openmc/data/njoy.py", line 227, in run
    raise CalledProcessError(njoy.returncode, njoy_exec,
subprocess.CalledProcessError: Command 'njoy' returned non-zero exit status 77.

I'm building on this branch and running this test script

import openmc
from openmc.data.njoy import make_ace

kwargs = {
    "output_dir": ".",
    "acer": "./acer",
    "pendf": "./pendf",
    "heatr": "./heatr",
    "broadr": "./broadr",
    "gaspr": "./gaspr",
    "purr": "./purr",
    "groupr": "./groupr",
    "evaluation": None,
}
make_ace(
    filename="n-026_Fe_056.endf",
    temperatures=[293.6],
    stdout=True,
    **kwargs
)

[MicahGale]

I'll crack open the NJOY manual again and take a look at your template. This error is weird, because the mat number should be the same throughout the whole run.

[paulromano]

It uses a few more advanced features of ENDF-6 that breaks the ENDF reader in Openmc

@MicahGale can you elaborate on this?

[MicahGale]

@paulromano, it's been awhile and misremembered. I didn't have to change anything with endf.py base implementation; I just had to create a new class to handle the peculiarities of reading a GENDF.

Rereading the code though; there are so many magic numbers with ENDF files. I personally don't think there is much value in OpenMC creating a much more extensive ENDF parser. I think if we really want to go down this road for GROUPR I think we should use ENDFtk instead of implementing a GENDF reader. If we did this, I think the path forward would be:

1. Make PRs to ACEtk and ENDFtk to make it build wheels, be pip installable and deployed to pypi.
2. Add these libraries as optional(?) python dependencies
3. Deprecate openmc.data.endf, and switch the machinery to ENDFtk

[MicahGale]

But the more I think about this: is there enough use of openmc multi-group data to justify this being placed in openmc? I feel like multi-group is pretty rare and really should be left to the user to do.