flsimulate warnings when using new gveto and wall vertex generators

[willquinn]

In flsimulate using the new vertex generators detailed in pull request 182 I got the following warnings: -------- WWWW ------- G4Exception-START -------- WWWW ------- *** G4Exception : GeomNav1002 issued by : G4Navigator::ComputeStep() Track stuck or not moving. Track stuck, not moving for 10 steps in volume -calo.PMT_HAMAMATSU_R5912.model.log_PV- at point (781.62,1683.88,258.336) direction: (0.894453,-0.186827,0.406263). Potential geometry or navigation problem ! Trying pushing it of 1e-07 mm ...Potential overlap in geometry!

This is just a warning message. -------- WWWW -------- G4Exception-END --------- WWWW -------

-------- WWWW ------- G4Exception-START -------- WWWW ------- *** G4Exception : GeomNav1002 issued by : G4Navigator::ComputeStep() Track stuck or not moving. Track stuck, not moving for 10 steps in volume -calo.PMT_HAMAMATSU_R5912.model.log_PV- at point (781.558,-646.909,-520.447) direction: (0.514698,-0.193035,0.835358). Potential geometry or navigation problem ! Trying pushing it of 1e-07 mm ...Potential overlap in geometry!

This is just a warning message. -------- WWWW -------- G4Exception-END --------- WWWW -------`

I believe this is what @emchauve was asking about. This did not cause a crash however.

[drbenmorgan]

I think this is almost certain to be an issue with overlapping volumes - the PMTs are defined in terms of a geomtools::simple_shaped_model of a geomtools::polycone, as defined in the .geom files under:

https://github.com/SuperNEMO-DBD/Falaise/tree/develop/resources/snemo/demonstrator/geometry/GeometryModels/calorimeter_modules

with polycone data taken from:

https://github.com/SuperNEMO-DBD/Falaise/tree/develop/resources/geometry/PMT

The first thing to do would be to check if there are any obvious typos or bad data in those. The underlying Geant4 definition of polygon is here in case that's useful.

There's a guide on how to check overlaps in Geant4 here:

http://geant4-userdoc.web.cern.ch/geant4-userdoc/UsersGuides/ForApplicationDeveloper/html/Detector/Geometry/geomOverlap.html

but that's mostly runnable through UI commands. The simulation does have the facility to run like this, but has never been enabled. I'll have a look at how best to add that in so we can see if those facilities can help. NB: we're still running a pretty old Geant4, latest Bayeux (and upcoming tag) provide provisional support for 10.5, so might need those to get "best" overlap checking.

I've assigned to us for now, but add any others you want!

[lemiere]

bxgeomtools_inspector probably could be used to track overlap....

[lemiere]

Position : (781.558,-646.909,-520.447) is related to the back of a 8 inch PMT glass. (base side)

If overlap exist that's between 8 inch PMT shape and its envelop....

My point of view, that's not an issue... to confirm with @fmauger (single rq is dynode and base are not implemented into the 8inch module)

[lemiere]

Your feeling ? @fmauger , @drbenmorgan

[fmauger]

I have no immediate good idea right now but I believe we should search for a bad positioning of the PMT within some mother envelop or with a very close volume (extruded scintillator block, support, back PMT base...). Visual inspection with proper zooming could help to find a "visible" odd skip. That could also come because of some rounding error when 2 volumes are touching. In that case, we should add a tiny safety margin (~1um) in the geom file. I think there is some option for that in the geomtools::stacked_model class but I need to check.

[drbenmorgan]

Discussed in SI meeting this morning - will postpone until after next release, which should be in the next couple of weeks. We'll then revisit and find people to look at this in detail.

[fmauger]

I've inspected the region where Will got some G4 tracking issue. It occured at the end of PMT bulb envelop. This is probably due to the exact matching of the glass bulb with its mother envelop which uses exactly the same shape profile (profile data from a file). So I guess G4 faces a pb here when a particle in the glass needs to step out to the air behind the bulb. The G4 driver wants to make it crossing two flattened boundaries at the same time and so misses the child->parent->grandparent sequence properly... so the tracking driver is somewhat lost in the hierarchy. It is my interpretation but maybe wrong. Anyway I have to think to a fix (bayeux/falaise ?). I have some hints but needs tests.