World volume reverts to "previous" solid during run?

[mkelsey]

Following @evc 's suggestion in my other forum post, I am still seeing some very weird behaviour with our geometry.

We have a world volume with a non-centered origin (now built using G4ExtrudedSolid), done in such a way that our detector apparatus is at (0,0,0) in the world, but the surrounding laboratory is structured as in the real world. Here’s a top view, with the world volume outlined in magenta:

The “2 m” notations correspond to /vis/scene/add/axes, and are nicely centered on the cylindrical detector apparatus.

This is all fine, and everything aligns properly (we also use the “checkGeom” flag and there are no overlap problems reported anywhere in the geometry).

However, if we run test events with geantinos (for instance), we get errors on many events about track “starting point has moved” errors, and “stuck track” errors, because particles have seemingly left the world volume but are still being tracked. I ran this job interactively, with the visualization set to draw tracks on each event.

A screen capture from OpenGL shows that the world volume has somehow changed! Notice below that the magenta outline is now shifted away from our geometry, and is centered on the coordinate axes:

If I do a new visualization output, e.g., with /vis/ogl/printEPS, the geometry gets redrawn correctly, with the world volume as normal (first drawing). That’s why I did a screenshot.

I’ve turned on verbose output, I’ve set breakpoints in the debugger. I do not see anywhere that our “BuildWorld()” function ever gets called after /run/beamOn. I don’t understand why the worker threads would change the geometry in any way.

As a final note, this only happens when we use an MT build (even with just a single worker thread). If we build with old-style “sequential” G4, this doesn’t happen.

[mkelsey]

I think I have found the source of this weird shifting. In our geometry framework, I have a base class BuildWorld() function that creates the unshifted volume shape and wraps it in the LV for placement as the world. For the particular layout above, with the cavern hall and side drifts, I wrote an override of BuildWorld() which calls into the base class, gets the LV, then creates its own different shape (with the coordinate offset), and pushes the new shape in via LV->SetSolid().

Somehow, it seems that during the event loop (i.e., within a /run/beamOn cycle), the original old shape was being used for the world, instead of the replacement.

To fix this properly, I refactored the BeginWorld() function to instead call a virtual MakeWorldShape(), which the subclasses can now override directly, and just create a single solid that gets wrapped in the LV. This fixed the situation I pictured above.

But I am still curious about whether I was using SetSolid() correctly, and whether I was supposed to do something else in addition (remove the original from the G4SolidStore? Delete it? Something else).