implement a StageParticle generator which is aware of heterogenous materials #1290
Conversation
…aterials: - define base classes for sampling elements from a composite material and coordinates of (pre)stopped particles - implement the above in the form of sampling elements via their atomic volume, and coordinates via randomly choosing one negative muon - add in approximate DIO spectra for carbon and hydrogen by scaling the energy coordinate of the calculated aluminum spectrum
|
Hi @edcallaghan,
which require these tests: build. @Mu2e/fnalbuild-users, @Mu2e/write have access to CI actions on main. ⌛ The following tests have been triggered for 830cbc7: build (Build queue has 1 jobs) |
edcallaghan
changed the title
|
☀️ The build tests passed at 830cbc7.
N.B. These results were obtained from a build of this Pull Request at 830cbc7 after being merged into the base branch at 684bac4. For more information, please check the job page here. |
There was a problem hiding this comment.
This PR adds important new capability for capture on heterogenous materials, directly relevant for several applications. A presentation on the physics inputs underlying this is needed, for instance the assumptions behind using the Heeck spectrum outside of aluminum, and why atomic radius is the right scaling for relative capture rates. I have a few minor technical questions as well, but basically this looks really good.
| #include <vector> | ||
|
|
||
| // art | ||
| #include <art/Framework/Principal/Event.h> |
There was a problem hiding this comment.
Same comment about < vs " as in the other PR.
EventGenerator/src/SConscript
Outdated
| @@ -13,6 +13,8 @@ helper=mu2e_helper(env); | |||
|
|
|||
| cryinc = os.environ['CRYHOME'] + '/src' | |||
| crylib = os.environ['CRY_LIB'] | |||
| g4inc = os.environ['G4INCLUDE'] | |||
There was a problem hiding this comment.
I would like to keep all references to G4 within Mu2eG4. The motivation is to be able to make G4-free builds which are required by the trigger. We eventually want to get to MC-free builds but we are not there yet.
One generator module is already in G4 for this reason:
Mu2eG4/src/GammaConvGenerator_module.cc
Please look into what that would require for this PR.
Maybe it's time to make a new top level directory for event generators that depend on G4.?
There was a problem hiding this comment.
The fundamental "problem" is that materials are defined via hard-codes in Mu2e/src/ConstructMaterials.cc, so that interfacing with G4 is the only way to query what they are comprised of. If there were a Mu2e-owned Service/interface which maintained a table of configurable materials and their compositions, which G4 queried when constructing G4Materials, then that would provide the functionality I'm looking for and simplify that construction routine (and also, presumably, obviate the delayed-initialization tricks I've had to use here).
But I imagine that there is a reason that things are done the way they are (and, if not, implementing the kind of ting I'm imagining is a separate project). In that case, I don't particularly care whether the generator lives under EventGenerator/, Mu2eG4/, or somewhere new. Unless there is some subtly in crossing project boundaries that I'm not aware of, just moving it into Mu2eG4 would probably satisfy the separation you'd like.
There was a problem hiding this comment.
Please move it into Mu2eG4 and revert the changes to EventGenerator/src/SConscript.
Implementing a complete parallel materials system seemed like far too much work for something that would never be used except to feed G4. And we did not have a use case to drive making a simplified materials system. It's only been in the past year or so that we have had a use case.
There was a problem hiding this comment.
Ok --- CompositeMaterialGenerator, ElementSamplerTool, and AtomicVolumeSamplerTool, which depend directly or indirectly on G4, now live under Mu2eG4, and the uses of G4 libraries or Mu2eG4 in EventGenerator/src/SConscript have been removed. PositionSamplerTool and MuStopPositionSamplerTool, which do not depend on G4, still live under EventGenerator.
|
FYI, a recent commit resolves a lingering deficiency in which, e.g. static CLHEP random sampling methods were called which used a global random number engine. All the random sampling introduced in this PR now relies on an |
|
The recent set of pushes address two points. The first is to update the The second is to remedy a deficiency in the implemented element-sampling functionality for the intended use case of IPA Michels --- namely that what matters for choosing which element the Michel came from is not just which atom the muon captured on, but also the different decay fractions for the different elements available (this is fairly small correction for the IPA, at ~1%). To accommodate this, some of the actual sampling functionality from |
|
@FNALbuild run build test |
|
⌛ The following tests have been triggered for 5cf58c0: build (Build queue has 2 jobs) |
|
☀️ The build tests passed at 5cf58c0.
N.B. These results were obtained from a build of this Pull Request at 5cf58c0 after being merged into the base branch at 53e76f7. For more information, please check the job page here. |
|
📝 The HEAD of |
|
@FNALbuild run build test |
|
⌛ The following tests have been triggered for 5cf58c0: build (Build queue has 1 jobs) |
|
☀️ The build tests passed at 5cf58c0.
N.B. These results were obtained from a build of this Pull Request at 5cf58c0 after being merged into the base branch at 2d7b0cb. For more information, please check the job page here. |
This PR implements an event generator which is aware that materials may be composed of multiple elements, and defers the actual generation of daughters to different routines each associated with a different element. This involves the definition of both base classes defining a somewhat generic interface and concrete implementations of samplers for both i) which element is relevant for a given generator call, and ii) the spacetime coordinates of the generated daughter. To enable the use of these routines for simulating Michel electrons originating in the inner proton absorber, updates are made to the global constants listing, and approximate (read: very approximate) DIO spectra are added to the repository.
Changes to existing build rules:
-
EventGenerator/src/SConscript: compilation now includes from/links againstGEANT4. This is to enforce a "one definition rule" connecting materials as relevant in simulation and in event the new event generators. This is described in more detail below.Updates to existing functionality:
-
PhysicsParams: This interface can now be used to query the atomic radius of various elements.New modules:
-
CompositeMaterialGenerator: This is the generator described above. The module contains both anart-tool which samples elements from an existingG4Material, and a map from atomic labels toart-tools which sample starting positions/times and PDG/momenta of the generated particle, respectively. At each call, an element is sampled according the configured routine, and the chosen element's tools are then called to actually define the generated particle, which is expressed as aStageParticle. That the elements for which sampling tools are defined and the elements which comprise the chosenG4Materialmatch is verified, but this must be deferred until "runtime" to accommodate out-of-order construction, wherein theG4Materialsare not actually defined when the module is initialized. The use ofart-tools allows for a very flexible configuration interface --- I was really glad to discover this!New functionality:
-
ElementSamplerTool: This base class defines an interface for sampling an element from aG4Material. This is another place with a deferred-initialization pattern, in which the actual access of aG4Materialis deferred until the tool is actually called, to ensure that theG4Materialhas been defined.-
AtomicVolumeSamplerTool: A concrete implementation of the above, in which elements are sampled according to their relative volumes. This is relevant to the choice of which element a muon will be atomically captured by; the volumes are computed from the estimated atomic radii, which are supplied by theGlobalConstantsService/PhysicsParamsinterface.-
PositionSamplerTool: This base class defines an interface for sampling spacetime coordinates, given a preexisting collection ofSimParticles. A more generic interface would require passing the fullart::Eventinto this class's sampling method, which can cause subtle data corruption involving unresolved pointers into data product collections which may present in downstream modules. Access to the data products should stay at the module-level, so the tool interface can only cover up to collections of particles. This limits its use to the generation ofStageParticles, and thus the sampling call returns the chosenSimParticleto be referenced by the generatedStageParticle.-
MuStopDecayPositionSamplerTool: A concrete implementation of the above. A single muon is chosen from the collection ofSimParticles, and its position is used as the starting position of the generatedStageParticle. The time coordinate is sampled exponentially according to the bound muon lifetime in the relevant atom.New auxiliary data:
-
globalConstants_01.txt: The atomic numbers and radii of carbon and hydrogen, as well the lifetimes and fractions for muons bound therein, have been added. FYI, some of the earlier numbers here are referenced from 2013, and may want to be revisited. There are preexisting entries labeledIPAwhich are just copies of the values for carbon --- AFAIK these aren't actively used for anything, but I've left them in place nonetheless. AczarneckiCoefficiententry for carbon already existed. A value for hydrogen is ~required to cleanly make use of the existing interface, but a value for hydrogen has not been calculated (to my knowledge). There is currently no intent to make use of the associated functionality, so I've entered a value of zero, but this is admittedly not great.-
ConditionsService/data/heeck_finer_binning_2016_szafron-scaled-to-{6C,1H}.tbl: Two new pretabulated spectra have been added, which are duplicates ofheeck_finer_binning_2016_szafron.tblwith the abscissa (first column) scaled such that the endpoint value is that of the relevant isotope. This is a crude approximation, but allows us to simulate "a tail" for standard model decays of carbon- or hydrogen-bound muons as a first pass; they can be replaced with improved tabulations as they become needed and available.One open question I have is this: in a few places, I found it convenient to call a
GEANT4-supplied rng, e.g.G4Uniform(), as opposed to sorting through theartinterface for that. I'm not expecting a yes, but is that alright?