STMGeometryUpdate2023: Difference between revisions
(Created page with "= STMGeometryUpdate2023 = Wiki page to collect information and instructions for the STM geometry update campaign in 2023. We are taking the geometry in the standalone simulat...") |
No edit summary |
||
Line 83: | Line 83: | ||
*** These nest*() function have a bunch of arguments, hopefully it’s obvious what they all should be | *** 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 | * 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 |
Revision as of 16:55, 11 July 2023
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
Setting up Git
(I'll add instructions here when I create the branch in a minute)
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
- A block of code like lines 1216 to 1226 that extracts all the parameter values from pSTMTopShieldingParams
- 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