MDTs Conversion

[dimitra97]

-Conversion of the bounding boxes and putting the surfaces inside

Next steps:

• Matching function implementation
• Check memory consumption with/without converting and caching the surfaces
• As a future step I had the idea of the following: Instead of converting also the bounding box for the MDTs in geomodel-acts code what about converting always just surfaces and configure for example the builder I have developed in the past that also comes with the navigation model: https://github.com/acts-project/acts/blob/main/Core/include/Acts/Detector/MultiWireStructureBuilder.hpp This is supposed to construct a bounding box out of the surfaces we configure. Because also I think in the following technologies (e.g rpcs, tgcs, nsw) we will just need the layers to be converted as surfaces. And in the end we can group the surfaces in bounding boxes without actually converting them. I think this would simplify also the code that does the conversions.

[Berggren-Jonas]

I have implemented a recursive function that goes through the tree of each specified FPV and calls the matching function on each element. There the matching function checks if the name (e.g "Tube") and material (e.g. "Aluminium) matches the querry. I add a flag where the user can specify if the FPV should be converted to a bounding box.

python3 geomodel_vol.py -i ATLAS-R3-MUONTEST_v3.db -q Muon --convert-boundingboxes --output-obj -o muons -ml Aluminium -n Tube BML1_MDT03_1_3_1

[Berggren-Jonas]

converting all MDTs with cached sensitive surfaces to obj uses at most 3.9GB skipping the conversion to obj uses at most 688MB

Because of the seg fault issue I can't test the obj conversion without caching the surfaces, but without caching and without obj conversion I get 688GB of peak memory consumption. So I guess caching isn't that expensive.

[Berggren-Jonas]

I can't see if the total detector is converted correctly since my laptop can't handle the resulting 1.9GB obj