use target composition from environment in sibyll interface

so far the target material is hard coded in the sibyll interface (oxygen, bad habit).

If I am not mistaken this requires an extension to the ProcessSequence and/or DiscreteProcess. Currently only references to the stack and the particle are passed in the DoDiscrete/DoInteraction call.

There are two options:

1. easy solution: Sibyll gets a reference to the environment as an argument of the constructor. Then you can write sth. like fEnvironment.GetContainingNode(particle.GetPosition()).GetNuclearComposition(). In a situation with multiple physics modules this will be less efficient than the second solution because the correct volume has to be looked up by each individual process.
2. bit more laborious solution: Change the GetInteractionLength() interface to accept a VolumeTreeNode& parameter referencing the current volume. Here the lookup happens only once.

I think for quick progress option 1 would be sufficient.

Done. I pass the target information from the sampling of the interaction length in GetInteractionLength to DoINteraction by making kTarget a data member of the sibyll process . This assumes that the two always follow in sequence, which may be not always the case. This is very much Fortran style :), and not very transparent.

Also, sampling the composition should not be part of the sibyll interface but rather part of NuclearComposition or the Environment.

Also the sampling as is assumes elemental fractions are in decreasing order.

Some things:

• instead of fEnvironment.GetContainingNode(particle.GetPosition()).GetNuclearComposition() we should also have fEnvironment.GetContainingNode(particle.GetPosition()).GetTarget() as Felix now implemented inside Sibyll. This is easy to do.

• in the GetInteractionLength I doubt we need a target at all. This is a general feature of propagation: during propagation the target is irrelevant, it is the mixture that matters. We have to, in fact, average over the nuclear composition here. The same is true for "density" and any other physical property of matter. Basically: in GetInteractionLength the target (in air) is always "air" (O+N+Ar+C+...) but in DoInteraction you chose one particular nucleus. This we have to generalize.

• we need a caching mechanism on Environment level. Not only one trajectory/track, but a whole shower (or part of a shower) will be contained in one single volume. We don't want to do volume lookups that are not needed all the time. This is related to #82 (closed).

I agree with Ralf's second point. What needs to be done for the interaction length is to accumulate the cross sections for each component, weighted by their number fraction. The random sampling happens in DoInteraction().

The GetTarget() as part of the NuclearComposition is only possible as sth. like GetTarget(crossSectionVector). You cannot sample a target without knowing the cross sections for each component.

And btw, there is no need to reinvent the wheel for the sampling here. Just use std::discrete_distribution.

thanks for the std reference. I figured something like that existed already.

I agree on the GetTarget(crossSectionVector), which means we need the cross section in GetInteractionLength and in DoInteraction. In order to avoid calculating it twice, we would have to store it somewhere. I wonder does that belong to the Process or the Particle?

First and second point are solved.

Issues are:

• no random numbers in environment yet. so far i use the sibyll stream
• we need another conversion routine for the target particles, or make GetNucleusA( Proton ) evaluate to 1, so far it is 0. However then we would have to catch neutrons or accept a little charge violation. Negligible in air showers since it is on the target side, but maybe not in general.
• the cross section for each component is read twice, in GetInteractionLength and in DoInteraction.

created branch 117-use-target-composition-from-environment-in-sibyll-interface-2

mentioned in merge request !51 (closed)

added Critical label

mentioned in merge request !55 (merged)

closed via merge request !55 (merged)

mentioned in commit f2b83d2f