Implement utility to benchmark navigation performance

[gipert]

It would be nice to have a tool that lets the user know whether the implementation of a certain solid is efficient or not. Example: comparing tessellated vs CSG solids.

• Does it make sense to loop over all volumes in the physical store?
• Does it make sense to shoot geantinos? Starting from where and with which direction?
• How to "isolate" the solid of interest from the rest?

[tdixon97]

I think we should increase the priority for this item since its important to have in place before developing geometry. What would we like to do? I can try to have a look.

It would be nice to have a tool that lets the user know whether the implementation of a certain solid is efficient or not. Example: comparing tessellated vs CSG solids.

* Does it make sense to loop over all volumes in the physical store?

I am not sure what you mean here ? We can maybe just use a single volume at a time to make this faster, rather than checks on the full array.

* Does it make sense to shoot geantinos? Starting from where and with which direction?

Geantinos or a real simulation, eg. some gammas or betas?

* How to "isolate" the solid of interest from the rest?

What about just starting with a basic geometry with just the "complicated" volume we are concerned about?

[EricMEsch]

Does it make sense to loop over all volumes in the physical store?

I just had an idea, but then realized the issue with tesselated solids. How are tesselated solids treated? Because at that point iterating through each single triangle is not really useful. I tried looking at the GDML, i am not entirely sure i correctly understand, but i think the entire tesselated volume is treated as one physical volume? Then i think looping over all volumes makes sense.

[EricMEsch]

Something that i remembered from the call last wednesday, Jason mentioned that his sampler was very good at spotting overlapps in geometry. He said it could even spot overlapps that geant4 was not able to find. I did not get the time to look in depth at what you introduced with #226, @tdixon97 but do you think something like that could then also be used to benchmark the navigation performance? As overlapps are tightly connected to navigation issues.

[tdixon97]

I am not sure, what I wrote treats one G4VSolid at a time so there cannot be overlaps. @jasondet what did you have in mind?

[ManuelHu]

Finding overlaps is certainly important, but here we are more interested in comparing the overhead of different implementations. Example: to find the best option to implement a single part; either as a lot of (nested) boolean solids, or as tesselated solids, ...

This already assumes that the geometry is well-defined (i.e. all meshes are closed, no overlaps). I do not think that toby's code helps a lot to benchmark this (i.e. it could be used to benchmark DistanceToIn/DistanceToOut, but not so much more)...

Otherwise benchmarking also does not really make sense, as the simulation being slow is probably the least problem when having overlaps...

[ManuelHu]

a very simple thing I did a while ago with different PEN plate meshes:

Notes_Optical_Mesh_performance.pdf

[tdixon97]

Yeah I was thinking of something similar, but do we also need to compare the results of the simulation?

[EricMEsch]

"Geantino runtime tomography" sounds like a great approach (and name 😄). Although i am not 100% sure why you need the gridded CSG source? Couldnt you just specify a planar square with the GPS? (or in order to also get all directions specify a sphere?) I think the GPS planar source sampling should be time uniform, as it is just randomly specifying x and y with a given z.

[gipert]

@nikolay327 also worked on this in the past, did you document it anywhere Niko?

[jasondet]

the geantino check is simple: a geantino must exit every volume it enters, so the number of surface intersections must be even. That one check found many problems in the early MJD geometries (usually people nesting and putting surfaces within kCarTolerance of each other) that were not found by other methods.

I think one can also implement a check that a geantino must exit a daughter volume before it exits a parent. I can't remember if that crosscheck is already in G4, if not then it should be. But it should be easy to add to the geantino checks.

[nikolay327]

@gipert In the past, I've worked on a way to find duplicated vertices of a tessellated solid from a GDML file. You can find it here. It is currently implemented with simple bash commands. I've also worked on a way to find a daughter volume within arbitrarily nested volumes without having to loop over all (daughter) volumes multiple times. But, it is only available on my local pc. I believe I sent them to @ManuelHu in the past. Not sure if these are what you need.