Add muon EM processes to Celeritas physics list and muon brems/ioni Process classes
#1411
Conversation
…on and brems process classes
amandalund
added
enhancement
| return options.mu_pair_production || options.mu_ionization | ||
| || options.mu_bremsstrahlung || options.mu_coulomb | ||
| || options.mu_msc; | ||
| } |
There was a problem hiding this comment.
Perhaps, like optical physics, we should have a muon physics sub-block?
There was a problem hiding this comment.
Sounds good--wasn't sure whether to do that or put them next to the other standard EM processes, but having the operator bool is nicer for this.
|
|
||
| if (options_.mu_coulomb) | ||
| { | ||
| // TODO: update the Celeritas Coulomb scattering model to support muons |
There was a problem hiding this comment.
If these aren't todos that aren't next on the list to be updated, could you annotate them as doxygen so that they automatically show up on the todo list?
| // TODO: update the Celeritas Coulomb scattering model to support muons | |
| //! \todo Update the Celeritas Coulomb scattering model to support muons |
There was a problem hiding this comment.
Oh nice, didn't realize they got put in a list.
| // TODO: possibly use Urban MSC until Wentzel VI is implemented and | ||
| // update the Celeritas Urban model to support muons |
There was a problem hiding this comment.
| // TODO: possibly use Urban MSC until Wentzel VI is implemented and | |
| // update the Celeritas Urban model to support muons | |
| /*! | |
| * \todo Possibly use Urban MSC until Wentzel VI is implemented and | |
| * update the Celeritas Urban model to support muons | |
| */ |
| @@ -202,7 +202,7 @@ TEST_F(RootJsonDumperTest, all) | |||
| "name" : "G4_STAINLESS-STEEL", | |||
| "state" : 1, | |||
| "temperature" : 293.15, | |||
| "number_density" : 86993489258991547580416, | |||
| "number_density" : 86993489258991530803200, | |||
There was a problem hiding this comment.
I just noticed this is showing up as an integer... @pcanal is this a bug in the ROOT JSON exporter? It looks like "integer floating point" values are being represented as integers... see the change in energy below from 1.02... to 1000.
|
|
||
| if (options_.mu_bremsstrahlung) | ||
| { | ||
| physics_list->RegisterProcess(new G4MuBremsstrahlung(), p); |
There was a problem hiding this comment.
I don't know if this is the right time to address this, but it is worth mentioning: The applicable energy ranges for muon bremsstrahlung are a bit tricky in G4.
- The
G4EmStandardPhysicsonly enables muon brems if theG4EmParameters::MaxKinEnergy() > G4HadronicParamaters::EnergyThresholdForHeavyHadrons()(which is 1.1 GeV by default) - The
G4MuBremsstrahlungModelalso has its own applicability that we may double check.
So should we register the process no matter what and its use is defined downstream, or should we make CelerEmStandardPhysics more similar to G4EmStandardPhysics (i.e. adding thresholds from the get go)?
There was a problem hiding this comment.
Interesting... I don't think we account for that MaxKinEnergy being anything other than the default in our code currently (e.g. we just hardcode all our model upper limits to the dafault 100 TeV) so maybe it's fine not worrying about it for now, but I'm also happy to add it. Out of curiosity, do you know in what circumstances MaxKinEnergy mght be set to something lower? Looks like EnergyThresholdForHeavyHadrons has a maximum possible value of 5 GeV, and its description says:
if max kinetic energy is below this limit EM and hadronic physics is not instantiated for hyperons, anti-hyperons, anti light ions, b-, c- particles
For the model applicability, since it's an energy loss process we should be ok letting the limits be defined implicitly by the bounds of the energy loss/cross section tables (which will be determined by the prodution cuts and G4MuBremsstrahlungModel::MinEnergyCut()).
There was a problem hiding this comment.
Yep. I also assumed it being ok since the XS tables would limit it, and I tend to prefer registering here and applying limits downstream. At least to me, this seems like a more logical approach: the physics list sets the processes on or off. If there are constraints, these are applied later. Regarding your question about the MaxKinEnergy(), that I don't know for sure. I would guess that some detectors saturate above a certain energy, so you just make the simulation faster by reducing that for a set of models? Maybe @whokion knows...
There was a problem hiding this comment.
Well, the brem cross section of muons is relatively small compared to ionization at the low energy and the radiative effect becomes meaningful (%level) as a part of the total energy loss only at the high energy (order of GeV or higher, but depending on materials).
This adds the muon bremsstrahlung and ionization
Processclasses, adds options to enable muon EM processes (currently all false, but brems and ioni can be enabled for testing/validation), and adds the standard EM muon processes to our physics list.