Add distance to surface tests

[EricMEsch]

Generates a dummy gdml volume consisting of 4 detectors (one of each type) and simulates 1 eV electrons sampled within those volumes. Then checks if the distance output from Geant4 agrees with the calculation from legendhpges. Currently the tolerance is implemented as default 1 nm. Additionally produces a plot that shows the hit profile for each detector.

Regarding the runtime: the 3 tests added here take combined ~ 10 secs to run on my machine, with all of the now 48 tests (excluding the vis tests) taking ~ 80 secs

Related #223

Edit: Maybe someone have a look over my python code. I copied a lot of stuff from Tobys implementation, but i also changed a lot. I am not that familiar with python so i might have done something in an overcomplicated way

[tdixon97]

lar can be removed from this GDML, but then change the mother volume for HPGe to be the world not lar.

[tdixon97]

these lines are not needed in this case. They only create a macro to simulate in the LAr cylinders.

[EricMEsch]

I do kinda need both lines. The list of detectors is so i can just loop through all 4 types (although i can omit the detectors variable by just directly inserting the list into the enumerator).

And i need the n to keep track of the unique detector IDs to also create the detectors-fake.mac to register the detectors.

[tdixon97]

Sorry I selected the wrong lines. I meant 70-77 where we create the LAr cylinder information (lines)

[EricMEsch]

Ah yes, you are right. I dont know how i deleted the write statements below but not that^^

[tdixon97]

This looks a great test.
I think the threshold could be a bit smaller but also 1nm sounds fine.
Some lines of python code can be removed I added comments.

[tdixon97]

The test fails in CI:

AttributeError: module 'legendhpges' has no attribute 'draw

I have found this before, I think you have to import directly the hpges.draw submodule.`

[EricMEsch]

The test failed because the pre-commit hooks (namely ruff apparently) removed the from legendhpges import draw import due to "unused import" 🤦. I just changed the line to directly use that submodule now.

[tdixon97]

One other idea.
When I was writing the distance calculations in legendhpges I was a bit concerned we might have numerical issues if the global coordinates are large.
What about having a second test where we rerun the simulation but with the largest global offset we might have in eg. L-1000, eg. 5 m (is it reasonable?) and check everything still agrees?

[EricMEsch]

I just did some tests:

I think the threshold could be a bit smaller but also 1nm sounds fine.

I could reduce it. The distance in the output file is saved as a double in meters. For double we expect an accuracy of approximately 16 decimals, so we could even go to fm accuracy (although i am not sure of the accuracy in legendhpges, but my tests confirmed that they agree on 1e-15 meters tolerance).

The offset of possibly 5 meters should not be relevant.

[tdixon97]

Yeah I'm worried about the global offset more for the distances from legendhpges, which is based on the global positions. These distances are also validated by this test.
If we find there is an issue with this we might want to switch to storing the position as a local position in the remage output. What do you think @gipert ? Maybe local positions will be smaller and you can always reconstruct the global one from the GDML.

[EricMEsch]

Ah, i just realized that of course in geant4 we do encounter the same issue. As we do as well use the global coordinates first to then transform them into the local coordinates. And if we lost accuracy, we can not get it magically back using the transform. So forget my previous example^^

In Geant4 doubles are used, so the accuracy would roughly be (largest offset) * 1e-16 which should be fine for our setup

[gipert]

Awesome, thanks Eric.