Re: [fluka-discuss]: Secondary production after primary absorption and other

From: Paola Sala <paola.sala_at_mi.infn.it>
Date: Sat, 2 May 2020 18:53:42 +0200

Hello
Answers below.
You can also have a look to the lecture
https://agenda.infn.it/event/20624/contributions/105895/attachments/68619/85014/AdvancedScoring2019.pdf
 given at the last advanced course, look at slides 42 and onwards

> Dear Fluka expert,
>
> I would like to ask you for help with some FLUKA issues.
>
> Everything is concerning a very simple setup: a carbon beam is
> irradiating a cylindrical PMMA and two silicon detectors are in its
> surroundings to detect outcoming particles.
>
> I want to score three things:
>
> 1. Kinetic energy of all produced particles during inelastic
> interaction - not necessarily an interaction of primaries (it will
> be probably filtered out in further analysis but not within the
> simulation)
> 2. Vertex of primary inelastic scattering for detected particles
> 3. Information about parent
>
> My approach is to use the routines mgdraw.f, stuprf.f and mdstck.f (this
> one just for an investigation) with the main stack FLKSTK and other
> stacks for secondaries (GENSTK, FHEAVY, EMFSTK).
>
> 1st:
>
> Within the mgdraw.f routine, I use the USDRAW to find out if inelastic
> scattering happened. What I thought that could work just in these cases
> within USDRAW is to call above stacks for secondaries and score the
> wanted information from them but ...
>
> Firstly, for the FHEAVY and secondaries with JTRACK <-6  it is
> recommended to score kinetic energy with TRACKR (info from the FLUKA
> manual) but into TRACKR only transported particle is copied from the
> FLKSTK. Is this correct?
Could you please point me to the section in the manual please, because
maybe there is come cnfusion?
TRACKR (and JTRACK) contain as you say only the currently transported
particle (i.e. the primary of the interaction).

For secondaries in FHEAVY, the kinetic energy is in FHEAVY, in the
variable TKHEAV(ip)


>
> Secondly, I was not able to find in the stacks (GENSTK, FHEAVY, EMFSTK)
> some particles which were newly added to the FLKSTK after this inelastic
> interaction. It looks like some heavy ions are missing there and it is
> interesting that if I call mdstck.f within this inelastic int. it is
> also there...I was thinking that this could be some residual nucleus and
> that I am using a wrong stack - is this possible? (in the attachment
> there is a file with an example of "missing particle in the secondary
> stacks" - this is output of *.log file during the simulation from USDRAW
> - ICODE 101 then mdstack.f and at the end when new particle is
> propagated the current state/content is printed which is with those new
> particles.)
>

In USDRAW you should consider also the RESNUC common to find the residual
nucleus (as you suspected).


> So, my approach right now is to use FLKSTK and see which particles are
> newly added there after an inelastic collision of primary and score
> their kinetic energy. This can be easily checked (if it is new) with
> Numpar of the previously propagated particle - every new particle has to
> posses bigger Numpar than this previous one.
>
> 2nd and 3rd:
>
> For this purpose, I use the stuprf.f and user variables within the
> TRACKR and the FLKSTK (nice explanation how to do that is in the FLUKA
> manual) and for the PV I just use a condition that the generation of the
> parent has to be 1 if the information about parent should be changed...
>
> One of my problems is that sometimes there is an inelastic interaction
> which produce the same particle as the incomming one which disturbs the
> information stored in user variables about the parent -> for example the
> primary vertex is right now the position of this interaction which is
> not the original one. I think that I found a solution but I am not
> perfectly sure that it is correct -  within stuprf there is NPPRMR which
> I hope serves those purposes and tells whether the particle is the same
> as the incoming one. So within this case (NPPRMR = 1) I do not modify
> this information about a parent. Is this the correct solution?

Yes

>
> If it would be more clear/helpful I can send you the code itself...
>
> Sorry that the email is so long :)
>
> Best Regards
>
> Lukáš Marek
>


Paola Sala
INFN Milano
tel. Milano +39-0250317374
tel. CERN +41-227679148

__________________________________________________________________________
You can manage unsubscription from this mailing list at https://www.fluka.org/fluka.php?id=acc_info
Received on Sat May 02 2020 - 20:37:41 CEST

This archive was generated by hypermail 2.3.0 : Sat May 02 2020 - 20:48:15 CEST