... | ... | @@ -37,10 +37,14 @@ This is an as detailed as possible outline of the requirement list for physics p |
|
|
|
|
|
1. in particular thinking about point 6.4.1/2 we have to either further break down the interface, or we define a way to let "SecondariesProcesses" act only in specific cases. Consider a ```thinning``` SecondariesProcess, which should act on the output of ```collisons``` but *not* on the output of ```decays``` etc. Thus, logically we would like to distinguish ```interaction << decay << thinning``` from ```(interaction << thinning) << decay```
|
|
|
|
|
|
## Further discussions here (to be resolved and merged in the requirements list above):
|
|
|
## Further discussions (to be resolved and merged in the requirements list above):
|
|
|
|
|
|
Notes from HD:
|
|
|
- ProcessSequences should not be created with `operator<<`, but just like `std::tuple`, by passing the elements to ctor. `ProcessSequence(process1, process2, ...)`. The `operator<<` is not good for initialization.
|
|
|
|
|
|
### ProcessSequences should not be created with `operator<<`, but just like `std::tuple`, by passing the elements to ctor. `ProcessSequence(process1, process2, ...)`. The `operator<<` is not good for initialization.
|
|
|
|
|
|
|
|
|
|
|
|
- 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.
|
... | ... | @@ -64,6 +68,6 @@ Notes from HD: |
|
|
|
|
|
- HD to RU: The Stack should hold on to allocated memory and not give it back, to minimize the very costly allocations and deallocations. Ideally, the Stack would be placed on the stack (I am talking about what people normally call stack in C++, the non-dynamically allocated memory used by a program), by implementing it based on std::array or similar. The particles placed on the Stack should be trivially constructible types, so that copying a particle is a matter of copying bits around. Under these conditions, using the Stack could be fast enough. If the photons have to be stored somewhere anyway, they should be put 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))
|
|
|
- DB: Cherenkov photons are in physics terms a ```ContinuousProcess``` 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))
|
|
|
|
|
|
- RU: try to resolve this here: Cherenkov process is a ContinuousProcess. Cherenkov photons need to be stored, and this should happen on "a" stack. This Stack does not need to be the identical one used for real particles, but this could be arranged with a "stack decorator". |
|
|
\ No newline at end of file |