... | ... | @@ -41,9 +41,11 @@ Notes from HD: |
|
|
- There are two kinds of thinning, which are distinctly different. There is the thinning that drops low-energy secondaries. This should be handled by a process, not by the sequence. A ThinnedInteractionProcess would derive from the generic InteractionProcess and apply thinning to its output. For the ProcessSequence this is transparent. The second kind of thinning happens after the shower has been fully simulated. To safe disk space, the shower core is either removed completely or further thinned as a function of lateral distance to the shower axis. This should be done by the particle writer, it is also not a responsibility of the ProcessSequence.
|
|
|
- RU: indeed, there a physics-driven thinning that must happen inside the cascade - and it is up to the user to decide what and how exactly he wants to do that. There is *not* one thinning algorithm, there are many options with different applicability. In addition there is output-thinning just to save disk space. This is not physics-driven.
|
|
|
- RU: there is one aspect we should keep in mind: thinning will be applied to a longish list of processes in the cascade, e.g. high-energy hadronic model, low-energy hadronic model, nuclear hadronic model, eventually decays, e.m. pair production, e.m. bremsstrahlung, and maybe others that we don't think about right now. So changing the algorithm should be safe against making simple mistakes of inconsistency. I think ```ThinnedInteractionProcess<ThinAlgo, InteractionAlgo>``` might be good, but also ```ProcessSequence sub_list = (interactionAlog << thinAlgo);```. In the former case they are applied to a particular Process in the latter case to a corresponding piece of ProcessSequence. I think this is completely analogous and just a matter of taste.
|
|
|
- DB: I am in favour of some kind of Wrapper to apply different thinning algorithms to a Process. This would reduce code duplication quite a bit and is still easy enough to understand. The difficulty here is that the interaction process needs to forward the information which particle was created to the thinning algorithm.
|
|
|
|
|
|
- Interactions and Decays are very similar and called by the ProcessSequence in essentially the same way. This common aspect of the two classes should be factored into a base class. InteractionProcess and DecayProcess remain distinct, but have a common ancestor, perhaps called InteractionOrDecayProcess.
|
|
|
- RU: if we want a common anchestor, it probably should be ```DiscreteProcess```. However, what exactly should it do? The decay has "GetLifetime(projectile)" "DoDecay(projectile)" while the interaction has "GetInteractionLength(projectile)", "DoInteraction(projectile, target)". Note: the "target" in the last call is still missing but should be added for physics reasons.
|
|
|
- CherenkovProcess also shares functionality with DecayProcess and InteractionProcess. This could also possibility factored into a common base class (but I don't know enough about Cherenkov production to see whether this makes sense). Regarding thinning, there should be a gain a ThinnedCherenkovProcess which inherits from the common CherenkovProcess. The thinning algorithm for Cherenkov photons is likely different from the one applied to interactions, so these two should not be forced together.
|
|
|
|
|
|
- RU: Cherenkov is a very good candidate for ```ContinousProcess```. In fact, Cherenkov radiation IS part of the continuous energy loss calculations a la Bethe-Bloch. Radio emmission, Cherenkov, dEdX are all ```ContinuousProcess```es. At least currently Cherenkov photons (as well as radio photons/waves) are not put on the particle stack in C7, they are directly processes and written to file. But is is up to discussion to eventually change this in C8 and also pipe it through the stack (?). This might be highly inefficient since we would all the time create a large number of very short-lived object dynamically on the stack... |
|
|
\ No newline at end of file |
|
|
- RU: Cherenkov is a very good candidate for ```ContinousProcess```. In fact, Cherenkov radiation IS part of the continuous energy loss calculations a la Bethe-Bloch. Radio emmission, Cherenkov, dEdX are all ```ContinuousProcess```es. At least currently Cherenkov photons (as well as radio photons/waves) are not put on the particle stack in C7, they are directly processes and written to file. But is is up to discussion to eventually change this in C8 and also pipe it through the stack (?). This might be highly inefficient since we would all the time create a large number of very short-lived object dynamically on the stack...
|
|
|
- DB: Cherenkov photons are in physics terms a ```ContinousProcess``` even if they there contribution is rather small. For most implementations the exact track must be known (similar to Radio). Cherenkov Photons do require some sort of storage/stack... (see [Requirement DynamicStack](Requirement-list-for-the-Dynamic-Stack)) |
|
|
\ No newline at end of file |