... | ... | @@ -6,21 +6,21 @@ This is an as detailed as possible outline of the requirement list for physics p |
|
|
|
|
|
1. The collection of all processes defines the air shower physics
|
|
|
|
|
|
1. All processes can (or even must) be collected in one single C++ container, this we call ```ProcessList```
|
|
|
1. All processes can (or even must) be collected in one single C++ container, this we call ```ProcessList```, however, ProcessList is a templated type and we would typically replace it with ```auto```, and two different ProcessLists will not be simply type-compatible.
|
|
|
|
|
|
1. The ```ProcessList``` is one argument to the air shower machine of CORSIKA, i.e. ```ProcessList list=...; Cascade EAS(list,...);```
|
|
|
|
|
|
1. We want ```ProcessList```s to be mergeable, combineable to create more complicated sequences starting from simpler ones
|
|
|
1. We want ```ProcessList```s to be mergeable, combineable to create more complicated sequences starting from simpler ones, thus logically: ```auto list1 = /*ProcessList*/; auto list2= /*ProcessList*/; auto list3 = list1 + list2;```
|
|
|
|
|
|
1. Internally, we must distinguish different types of contained ```Processes``` which is driven by the fact that particle can be modified in very different ways:
|
|
|
1. Internally, we must distinguish different types of contained ```Processes``` which is driven by the fact that particles need to be modified in different ways:
|
|
|
|
|
|
1. continuous processes modify the properties of one particle
|
|
|
1. continuous processes modify properties of one particle, they need access to the current trajectory-step of the particle
|
|
|
|
|
|
1. stochastic processes produce new particles, AND remove the current beam particle. This is typical for collisions, or decays.
|
|
|
1. stochastic processes produce new particles, AND remove the current beam particle. This is typical for collisions, or decays. They do not need trajectory data.
|
|
|
|
|
|
1. (we also need continuous processes that can _also_ produce extra secondaries, e.g. Bremsstrahlung, maybe Cherenkov photons, etc. - but this is maybe beyond what we need to define here)
|
|
|
|
|
|
1. processes that act on new secondaries produced (SecondariesProcess), typical applications are:
|
|
|
1. processes that act on new secondaries (SecondariesProcess), typical applications are:
|
|
|
|
|
|
1. thinning, re-weighting
|
|
|
1. low-energy cuts etc.
|
... | ... | @@ -31,12 +31,14 @@ This is an as detailed as possible outline of the requirement list for physics p |
|
|
|
|
|
1. The detailed interface to all the above processes is slightly different and driven by the underlying physics.
|
|
|
|
|
|
1. In addition we need a machinery to switch between two "branches" in the sequence based on phase-space regions, the most simple use-case is switching fro hadrons between low- and high- energy interaction model. But this can include small process-sequences by itself (switching between (sub-) process lists)
|
|
|
1. In addition we need a machinery to switch between two "branches" in the sequence based on phase-space regions, the most simple use-case is switching for hadrons between low- and high- energy interaction model. But this can include small process-sequences by itself (switching between sub-process lists)
|
|
|
|
|
|
1. processes lists are ordered. They are executed in the order of appearance in the code.
|
|
|
|
|
|
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):
|
|
|
|
|
|
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.
|
|
|
- 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.
|
... | ... | @@ -54,10 +56,14 @@ Notes from HD: |
|
|
|
|
|
- HD to RU: Ok, `DiscreteProcess` then. The common ancestor would have `GetStepLength` and `MakeSecondaries` or something similar. That `GetStepLength` means something different for an InteractionProcess and a DecayProcess can be explained in the comments/docs.
|
|
|
|
|
|
|
|
|
|
|
|
- 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...
|
|
|
- RU: Cherenkov is a very good candidate for ```ContinuousProcess```. In fact, Cherenkov radiation IS part of the continuous energy loss calculations a la Bethe-Bloch. Radio emission, 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 processed 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...
|
|
|
|
|
|
- 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)) |
|
|
\ No newline at end of file |
|
|
- 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))
|
|
|
|
|
|
- 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 |