Geometry issues with nested torii

User Support
1

Hi everyone,

I’m trying to build a simple “tokamak” out of nested openmc.ZTorus surfaces/cells. Here is the relevant surface and cell definitions:

R = 138

# Surfaces

vacuum_s = openmc.ZTorus(0,0,0,R,30,30)
first_wall_s = openmc.ZTorus(0,0,0,R,35,35)
vacuum_vessel_s = openmc.ZTorus(0,0,0,R,40,40,boundary_type=“vacuum”)

# Cells

vacuum_c = openmc.Cell(fill=None,region=-vacuum_s)
first_wall_c = openmc.Cell(fill=tungsten,region=+vacuum_s&-first_wall_s)
vacuum_vessel_c = openmc.Cell(fill=ss316,region=+first_wall_s&-vacuum_vessel_s)

When the major radius R = 138, the code runs perfectly. When R = 139 the code crashes, either segfaulting or reporting the following geometry overlap error (when running “openmc -g” geometry debug mode):

ERROR: Overlapping cells detected: 3, 2 on universe 1
Segmentation fault (core dumped)

I know that the implentation of nested torii in MC is difficult because of the high order surface equations, often leading to difficult tracking. I recall a similar problem in MCNP, where the solution was to “allow” higher numbers of lost particles to deal with the numerical “holes/overlaps” in the geometry.

Has anyone encountered a similar issue? Is there a potential fix or workaround? Am I possibly doing something wrong (as a first-time OpenMC user)?

I’m running OpenMC 0.13.1.

Thanks!

2

@hartwig I just ran into this recently as well and I’m pretty sure it’s a bug. I ran my case with gdb and got the following error messages, although turning logging on in gdb seems to change the error that I get which I was not expecting…

Here is the error with logging turned on:

Starting program: /usr/local/bin/openmc 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff7116700 (LWP 16211)]
[New Thread 0x7ffff6915700 (LWP 16212)]
[New Thread 0x7ffff6114700 (LWP 16213)]
[New Thread 0x7ffff5913700 (LWP 16214)]
[New Thread 0x7ffff5112700 (LWP 16215)]
[New Thread 0x7ffff4911700 (LWP 16216)]
[New Thread 0x7ffff4110700 (LWP 16217)]

Thread 2 "openmc" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7116700 (LWP 16211)]
openmc::Particle::cross_surface (this=0x7ffff7115b20) at /home/peterson/pkgs/openmc/src/particle.cpp:394
394	  const auto& surf {model::surfaces[i_surface - 1].get()};

And here is without logging turned on

Thread 8 "openmc" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff4110700 (LWP 17110)]
0x00007ffff7e1249e in std::_Hashtable<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, int>, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, int> >, std::__detail::_Select1st, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<true, false, true> >::_M_find_before_node (this=this@entry=0x7ffff7fc5980 <openmc::REACTION_TYPE_MAP[abi:cxx11]>, __n=__n@entry=15, __k=..., 
    __code=__code@entry=9415719926073928134) at /usr/include/c++/9/bits/hashtable.h:1567
1567	    _Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal,

@pshriwise mentioned that he was able to trace the error to openmc::initialize_maps in reaction.cpp which seems to match with the second error above as openmc::REACTION_TYPE_MAP is used within that function.

3

Ethan,

Well, of course, it’s us tokamak fusion energy people finding all the bugs in nested torii. Oh to have a simple repeating square lattice geometry :grinning: Let’s see what some of the other developers think and whether there’s either a bug fix forthcoming or some sort of workaround.

~ZSH

4

Thanks for reporting this @hartwig! Torii are very new in OpenMC and it appears we still have some corner-case bugs to work out. I was able to reproduce the segfault and will dig into it a bit further next week.

5

Quick update – I just submitted a pull request that should fix the problem described here.