Debugging MCNP import into Cubit

[rmchurch]

I can use the import of MCNP .i file into Cubit for some files, but there is one that is causing a segfault. I have looked for ELL, WED, ARB flags, but it doesn't have them. Are there additional ways to debug? I started to build from scratch mcnp2cad, but figured I would first see if there are additional steps recommended to find root cause.

[MicahGale]

This isn't a way to debug the problem inside of the Cubit plugin, but may still be helpful. I am wondering: are you sure your input file is valid? A quick plug for another utility: MontePy (I am the lead developer) can do quite a few sanity checks that your input file is valid for MCNP 6.2+, and in my experience sometimes more aggressive than MCNP.

• Documentation on checking
• Steps:

pip install montepy
montepy -c <foo.i>

[rmchurch]

Thanks, thats useful. I was told this ran successfully on MCNP 6.2. I tried out montepy but got an error for a line:

530   35  -2.334 -60066.2 -60077.3 -60088.1 60077.1 -61 201 vol=3.53E+07 imp:n,p=1

where it doesn't like the floating point:

ValueError: invalid literal for int() with base 10: '-60066.2'

[makeclean]

That looks like it doesn't like the macrobody facets On Wed, 2024-06-05 at 10:51 -0700, Michael Churchill wrote: valid literal for int() with base 10: '-60066.2'

[makeclean]

Can you share your input? One thing I would try is remove half the cell definitions inthe input deck, if it still fails remove a further half, and keep bisecting until you find the problem surface.

[rmchurch]

Attached. I'll start trying the bisection method.

Base2.i.txt

[MicahGale]

@makeclean you are correct that this is an issue that MontePy can't handle macrobodies. Can this plugin handle Macrobody facets?

[makeclean]

If memory serves, then yes I'm fairly sure it does

[makeclean]

Looks like its the 2nd cell which is the first problem... - intersection of three tori

[makeclean]

I think our implementation doesn't actually have the correct logic for this case; we missed the case where the major radius -s less than 0, we have the case for major radius < minor radius, but not the third case - I'll raise a bug