Possible problem when the (0,0,0) element of a lattice is defined by a RPP macrobody

[valeriogiusti]

Hi @paulromano,
I have been playing a bit with this tool and probably I hit a possible issue.
The problem seems to come up when in the MCNP input file there is a lattice where the (0,0,0) element is defined by an RPP macrobody.

For example in the case of the file 17x17.txt, where the lattice is defined as "lat=0:16 0:16 0:0", the lower_left is correctly set to [ -0.62992 -0.62992 -12.]. On the other hand in the case of the file 17x17_rpp.txt, where the lattice is the same but the (0,0,0) element is now defined by a macrobody, the lower_left of the lattice is set to [-20.78736 -20.78736 -12.].

I tried to dive a little into the code but I'm less than a newbie in python. As far as I understood it seems that when the (0,0,0) element is defined by a macrobody its region is created without preserving the MCNP's convention mentioned in lines 487-489. I found that a simple workaround (but I'm not sure if that will work in all the possible cases) is to swap v1 with v0 at lines 491 and 493.

Replacing lines 490-493 with the following ones makes the job.
`

            if sides['x'][0] < sides['x'][1]:
                if sides['z']:
                    v0, v1 = np.array([sides['x'], sides['y'], sides['z']]).T
                else:
                    v0, v1 = np.array([sides['x'], sides['y']]).T
            else: 
                if sides['z']:
                    v1, v0 = np.array([sides['x'], sides['y'], sides['z']]).T
                else:
                    v1, v0 = np.array([sides['x'], sides['y']]).T

`
However, I'm sure that a more elegant way exists.

In the case of a symmetric lattice with respect to the (0,0,0) element still defined by a macrobody, the lower_left is correctly set but the x and y axes are inverted. Given the files 17x17_sym.txt and 17x17_sym_rpp.txt, where the lattice is now defined as "lat=-8:8 -8:8 0:0", for MCNP the geometry is obviously the same and it looks as shown here below

Converting the two files in OpenMC inputs, we get the following geometry plots:

• with the (0,0,0) element defined by surfaces
  
• with the (0,0,0) element defined by an RPP macrobody
  
  The first one is the same as MCNP while for the second the x and y axes are inverted.
  The above change allows the get the proper geometry also in this case.

Thanks again for this tool.
Valerio

[paulromano]

@valeriogiusti Thanks for reporting this issue! Your proposed fix would resolve the issue with rpp but it would cause problems for others because it would effectively change the order that the x surfaces are listed (e.g., try converting your 17x17_sym.txt case with the proposed fix). A better fix is to change the RectangularParallelepiped class in OpenMC to always give surfaces in the same order that MCNP gives them. I just submitted a pull request to OpenMC to make this change (openmc-dev/openmc#2146).