Duplicate Nuclides in Material definition will lose information

[MicahGale]

Describe the bug

Recent discussions with @tjlaboss and @gonuke has brought to my attention that anecdotally material definitions might (and have good reason) repeat nuclides in the material definitions. For now I will say this is ambiguous.

MontePy was built with the assumption that this wasn't the case, and so cannot handle it properly. Material composition data are stored in a dictionary so the last instance of a nuclide will overwrite previous ones. Here a unique nuclide is a unique ZAID and a unique library.

m1 1001.80c 0.5 1001.80c 0.5

Would export as:

m1 1001.80c 0.5

Whereas:

m1 1001.80c 0.5 1001.00c 0.5

Would be exported properly.

Use Cases

So there are two cases to cover:

1. Repeated nuclides with different libraries
2. Repeated nuclides with the same libraries

Repeats with identical libraries

This case is helpful for defining a mixed material where the two components contain the same nuclide. This would make the material definition more readable (by MCNP standards). For example boric acid, B(OH)_3, dissolved in water.

Repeats with different libraries

This case can be used to mix two libraries with different temperatures as a means for temperature interpolation.

Research into the Manual

The MCNP manual is vague on this topic. It says:

Each material must be defined as a set of components with their corresponding material fraction.

This implies that nuclides can't be repeated; however not everyone is a mathematician so sets shouldn't be interpreted too strictly. Reading all of 3.3.2.1 (6.2 manual) there is no explicit guidance one way or another on this issue. So for now this should be treated as being ambiguous.

Work around

For the time being if a user has problems with this they can avoid it by ensuring their model has no duplicate nuclides with identical libraries by manually summing these repeats and replacing it with one entry.

Next Steps

1. Ask for clarification on this ambiguity in the documentation.

This came about from my work to imagine an improved interface for material_components on the branch mat_redesign, and discussing it in #475.

If we do need to support repeated nuclides I cannot think of a good non-backwards-compatibility-breaking fix that would preserve the interface of Material.material_components.

I think it might be time for a major release to fix this.

DIscussion of what that new interface will be go to #475.

To Reproduce

This would show up any time a file is read and then written:

import montepy
montepy.read_input("foo").write_problem("bar")

Version

• All version <= 0.4.0

[MicahGale]

This was discussed some in #475

[MicahGale]

I finally was able to find a clear confirmation of this in the MCNP 6.3 manual.

Section 5.6.2.4

Some MCNP input files make use of an old, traditional method for dealing with material temperatures called “stochastic mixing.” When a material is used in a cell that has a temperature in-between the temperatures used by NJOY in producing the ACE files, users can approximate the temperature effects on cross-section data by including both a “hot” version and a “cold” version of the ACE data used for each isotope in the material. For example, if there are ACE files available at 293.6K and 600K, and a cell has a temperature of 446.8K (halfway between the available ACE files), then an approximate way to model the material is to include each isotope twice - once using the ZAID at the lower ACE file temperature and once using the ZAID for the ACE file at the higher temperature, with 50% of the atom or weight fractions used for each of the bounding ZAIDs. During transport, the MCNP code will select the “hot” ZAID half the time and the “cold” ZAID the other half, stochastically, so that the average for the mixture matches the cell temperature. This approach is approximate, because it is not interpolation based on physics, just a stochastic mixing of the bounding data.

Given this: duplicate nuclide entries a material must be allowed.

[MicahGale]

Upon further testing this bug is not as catastrophic as first thought, but mostly by accident.

material_components use Isotope objects as keys. Isotope has implemented __hash__ naively thinking this was all that was needed for two instances of this class to be the same key. You also need to implement __eq__ though.

So due to this oversight repeated nuclides can still be present because they will have different instances of seemingly the same Isotope. This is still a bad interface, so we should still go forward with a 1.0 release IMO though.

To test this:

I ran

import montepy
problem = montepy.read_input("test.imcnp")
print(problem.materials[3])

With a modified tests/input/test.imcnp:

MESSAGE: this is a message$
it should show up at the beginning$
foo
$
MCNP Test Model for MOAA
C cells$
c # hidden vertical Do not touch 
c
1 1 20
         -1000  $ dollar comment
...

C water
C foo
m3        1001.80c           2
           8016.80c           1
           8016.80c           1
MT3 lwtr.23t h-zr.20t h/zr.28t$
...

This printed:

MATERIAL: 3 fractions: atom
 H-1     (80c) 2.0
 O-16    (80c) 1.0
 O-16    (80c) 1.0
Thermal Scattering: THERMAL SCATTER: ['lwtr.23t', 'h-zr.20t', 'h/zr.28t']