STMGeometryUpdate2023

Wiki page to collect information and instructions for the STM geometry update campaign in 2023. We are taking the geometry in the standalone simulation (defined here: https://github.com/jijunc/Geant4-Simulation/blob/main/src/B4cDetectorConstruction.cc) and putting it into the main Offline (https://github.com/Mu2e/Offline/)

The following is copied from an e-mail I sent around with some additional comments in (). It will be updated as we go

Visualizing Geometry

The geometry browsing tutorial is here: https://mu2ewiki.fnal.gov/wiki/GeometryBrowserTutorial2019. The basic idea is that you run:

mu2e -c Offline/Mu2eG4/fcl/gdmldump.fcl

to get a mu2e.gdml file. You then have a ROOT .C macro (which calls code in a corresponding .cc and .hh file) to then draw the geometry to the screen. You should be able to write the code so that it draws just the downstream STM infrastructure to the screen, which can save a lot of moving the camera around. (This will be easier once the mother volume is in)

Summary of Mu2e Geometry System

Here’s a summary of how the Mu2e geometry code is structured:

• The classes defined in STMGeom/ each represent a part of the STM geometry (e.g. GeDetector, TopShieldingWall). These classes will hold the dimension values.
• The code in GeometryService/src/STMMaker.cc takes the dimension values defined in SimpleConfig files (e.g. Mu2eG4/geom/STM_v05.txt) and creates the classes
• The code in Mu2eG4/src/constructSTM.cc takes the classes created in STMMaker, and creates the G4 volumes, logical volumes, and places them in the world

Git

Setting Up

From your terminal:

git clone git@github.com:AndrewEdmonds11/Offline
cd Offline
git checkout stm-geom-update-2023
git pull

After this your "remote" will be the branch stm-geom-update-2023 in the "fork" AndrewEdmonds11/Offline

Note, every time you start work, you may want to do the "git pull" command in case someone else has made changes

See GitHubWorkflow page for more tips and tricks

Committing and Pushing Changes

After you have made a change to a file (e.g. Mu2eG4/src/constructSTM.cc) you can check the changes you are adding with:

git diff Mu2eG4/src/constructSTM.cc

Then you can add and commit it to your local version of the branch

git add Mu2eG4/src/constructSTM.cc
git commit -m "A useful commit message e.g. added TopShielding to downstream STM geometry"

Finally, you will want to push it to the remote branch so that others can pull it in with

git push

Making Changes

For volumes that exist and already have configurable parameters

For volumes that already exist in the current Offline, you can (mostly) update dimensions in the .txt files. On your branch, create a new file called Mu2eG4/geom/STM_v06.txt and on the first line put:

#include “Offline/Mu2eG4/geom/STM_v05.txt”

to save us from having to re-enter variables that we aren’t changing.

Then to e.g. change the length of the HPGe crystal, you can add this line to the text file:

stm.det1.halfLength = 1; // units are in mm

You can check which dimensions can be changed in the .txt file by looking in GeometryService/src/STMMaker.cc. I found the example above on line 419. To follow this number around the code, we then go down to line 249, where we are creating a GeDetector class (which is defined in STMGeom/inc/GeDetector.hh).

The GeDetector class we create is then used in Mu2eG4/src/constructSTM.cc. We grab the parameter values on line 76, get the half length back out at line 1222, use it to create a TubParams (which I’ll get to later) on line 1236, which is then used on line 1247 to create a VolumeInfo class. The nestTubs() function we see on line 1261 deals with all the G4Tubs, G4LogicalVoluem, G4PVPlacement etc.

For volumes that exist but do not have configurable parameters

For volumes that already exist in Offline but have a parameter that can’t be changed in the .txt file, you will need to make some code changes. Using the HPGe’s rotation as an example, we need to:

• Add the config parameter to GeometryService/src/STMMaker.cc
  • e.g. after line 420, you can add this line

_detector1Rotation = _config.getDouble("stm.det1.rotation");

(and add a double _detector1Rotation; line to the STMMaker.hh file)

• and then on line 241, you should change CLHEP::HepRotation::IDENTITY to something sensible
• Add the parameter and value to Mu2eG4/geom/STM_v06.txt

That should all work for this example. Luckily GeDetector already had a _rotation variable so we didn’t need to change anything there.

For volumes that do not exist

For volumes that do not exist in Offline, there will be a lot to do. Here is what I think needs to be done using TopShielding as an example:

• Create a new TopShielding.hh file in STMGeom/inc/ (you can copy GeDetector and change things appropriately)
  • Keep the build, originInMu2e and rotation variables
  • Add the dimensions you need to keep track of:
    • e.g length, width, layer1Material, layer1Thickness, layer2Material, layer2Thickness etc.
  • And also add to STMGeom/inc/STM.hh a lines like this:
    • TopShielding const * getSTMTopShieldingPtr() const { return _pSTMTopShieldingParams.get(); } (at e.g. line 35)
    • std::unique_ptr<TopShielding> _pSTMTopShieldingParams; (e.g. at line 58)
    • and #include the TopShielding.hh file at the top
• Then in the GeometryService/src/STMMaker.cc, you will want to add in the parseConfig() function (e.g. at line 463)
  • _topShieldingBuild = _config.getBool( "stm.shield.top.build");
  • _topShieldLength = _config.getDouble(“stm.shield.top.length”);
  • _topShieldLayer1Material = _config.getString(“stm.shield.top.layer1.material”);
  • etc. and add the variables to the STMMaker.hh file too
• Then in Mu2eG4/src/constructSTM.cc, we will need:
  • TopShielding const & pSTMTopShieldingParams = *stmgh.getSTMTopShieldingPtr(); (at line 79)
• Then this is the complicated bit. Still in constructSTM.cc and although this could go anywhere in the constructSTM() function, I think line 1213 is an appropriate place, we will need:
  • A block of code like lines 1216 to 1226 that extracts all the parameter values from pSTMTopShieldingParams
    • for materials use the findMaterialOrThrow() function
  • A block of code like lines 1235 to 1239 that organizes the parameters into shapes
    • These are all defined in Offline/GeomPrimitives/inc
    • e.g. for TopShielding you can use Box instead of TubsParams
  • A block of code like lines 1241 to 1244 that defines the positions of everything in this part of the geometry
  • Finally, a block of code like lines 1246 to 1259 that then creates and places the volume in the simulation
    • The nestTubs() function is defined Mu2eG4/inc/nestTubs.hh
    • It looks like all the G4 volumes types have a nest function defined here e.g. for the TopShielding example you might want to use nestBox
    • These nest*() function have a bunch of arguments, hopefully it’s obvious what they all should be
• Finally, you can then add the configuration parameters you defined earlier to Mu2eG4/geom/STM_v06.txt

Checking for overlaps

These are described here: https://mu2ewiki.fnal.gov/wiki/Validation#Overlaps. We should do both the root and geant4 methods periodically