Re: [fluka-discuss]: Dumping information with mgdraw

From: Paola Sala <paola.sala_at_mi.infn.it>
Date: Fri, 29 Jan 2021 08:54:45 +0100

Dear Giovanni,

The information is not dumped fully for one particle before passing to the
next one.
Conversely, at each interaction, including delta-ray production, all
exiting particles are loaded in a buffer (the "stack" ), in decreasing
energy order (with exceptions, not relevant here). Tracking re-starts from
the last loaded particle. The reason is to avoid the accumulation in the
buffer of a huge quantity of interaction products from consecutive
interactions of high energy particles.

There is a variable that can help you in reconstructing the track:
In ISPUSR(MKBMX2) (common (TRACKR) ) you find the "track number" of the
currently tracked particle.
This value is automatically incremented for secondary particles at
interactions and decays. In case of delta-ray production, elastic
scattering, compton, bremsstrahlung, the incident particle keeps its track
number unchanged.
In case you wish to check, the variable is set in the strupre.f and
stuprf.f use routines.

For what concerns the loop in mgdraw: in your case, NTRACK is equal to 1
because you do not have any magnetic field in the simulation. In case of
magnetic field, the curved step is approximated with a series of NTRACK
substeps.

If you are calculating energy depositions, do not forget the ENDRAW entry
in mgdraw. You'll find there energy depositions from "point" events, like
particles going below transport threshold, or recoil nuclei (depending on
transport requests).

You can have a look at the "Advanced Scoring" lecture
(https://agenda.infn.it/event/20624/contributions/105895/attachments/68619/85014/AdvancedScoring2019.pdf)
and exercise in the last advanced Fluka Course. Keep in mind that some
information there will need to be updated to the fluka2020 release, in
particular for what concerns ion transport.

Hope this helps

Paola
> Dear fluka expert,
> thank you for your reply. You are right, my previous email was a little
> confusing.
> After dumping I convert the txt file in a rootTree with the same
> information dumped by mgdraw. In the screenshot I scanned the tree just
> with the event number, pdg code (translated from the Fluka code to Geant4
> code), track_id and position of the energy deposition. I omitted the other
> information of line 112 (i.e. STPNAME, Ekin, atrack and momenta), just
> because I thought it was less confusing, but I was wrong.
> Nevertheless the lines that you see in the rootTree are exactly in the
> same
> order as in the txt file produced by mygdraw. My concern was about the
> order, because my colleague said that it could be a problem if the
> information step by step are not dumped entirely for one particle before
> passing to the next one.
>
> For what concerns track_id I defined it with "ISPUSR(MKBMX2)" (which is
> the
> last dumped information in line 112). I did not implement any personal
> stuprf or stupre subroutine. I am not an expert in Fluka and maybe this is
> not the proper way to define it.
>
> For what concerns DE, you are right as well, I wanted to dump the energy
> deposited in the current track segment. The loop is irrelevant and I
> should
> have deleted it, that was a mistake by my side. But it should be correct
> nevertheless, doesn't it? In my simulations, NTRACK is always equal to 1
> and that loop is not really a loop.
>
> I hope to have been more clear and thank you in advance,
>
> Giovanni
>
> Il giorno mer 20 gen 2021 alle ore 15:08 Stefan E. Mueller <
> stefan.mueller_at_hzdr.de> ha scritto:
>
>> Dear Giovanni -
>>
>> I am not sure if I fully understand your problem. The screenshot you
>> attached shows the output of a RootTTree, which gives different
>> information to what your "mymgdraw.f"-file gives in output.
>>
>> If your question is why in your RootTTree the variable "track_id" is not
>> consecutive within an event then it would be good to understand how you
>> define "track_id" in your application, the attached mymgdraw.f-file
>> doesn't contain this information.
>>
>> Another thing I noted is that when in line 93 of mymgdraw.f, you define
>> DE = DTRACK (NTRACK), I'd think DE will contain always the energy
>> deposit
>> of the last track segment, regardless of the value of the iterator
>> variable "I" - is this really the intention?
>>
>> Stefan
>>
>> --
>> Stefan E. Mueller
>> Department of Information Services and Computing - Computational Science
>> and Institute of Radiation Physics
>> Helmholtz-Zentrum Dresden-Rossendorf
>> Tel: +49 (0351) 260 3847
>> Stefan.Mueller_at_hzdr.de
>> http://www.hzdr.de
>>
>> Vorstand: Prof. Dr. Sebastian M. Schmidt, Dr. Diana Stiller
>> Vereinsregister: VR 1693 beim Amtsgericht Dresden
>>
>> On Wed, 20 Jan 2021, Giovanni Costantini wrote:
>>
>> > Dear Fluka experts,I have a question for you about dumping event
>> particle
>> > information with mgdraw. I built my subroutine in order to know all
>> energies
>> > deposition by every particle in the detector. I was wondering how the
>> > dumping on a file works. More precisely, which is the order in which
>> the
>> > particle's information is dumped?
>> >
>> > After I run simulations, I pass data to a colleague which applies a
>> > clustering algorithm, to reconstruct the clusters.
>> > She noticed that sometime happen the following issue: the dumping is
>> > switching between two particles close one to each other instead of
>> dumping
>> > every step of one particle and then the other one (I put a screenshot
>> of
>> an
>> > example, look at the ev (second column) 1, a negative pion and an
>> electron
>> > (pdg_code in the third column) are dumped in such a way. I also put an
>> input
>> > file and the mgdraw.f I am using).
>> >
>> > Is it related to the different tracks they belong to? Thus it happens
>> only
>> > with delta rays for example?
>> >
>> > The problem that I have is not strictly speaking with Fluka, it's just
>> that
>> > the algorithm she is using works in a precise way and I should try to
>> have
>> > the output of my simulations more similar as possible to the output
>> > requested, but I was hoping you can give me some hint about this
>> issue.
>> >
>> > Thank you in advance for your help,
>> >
>> > Giovanni Costantini
>> >
>> >
>> > Informativa sulla Privacy: http://www.unibs.it/node/8155
>> >
>> >
>
> --
>
>
> Informativa sulla Privacy: http://www.unibs.it/node/8155
> <http://www.unibs.it/node/8155>
>


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 Fri Jan 29 2021 - 10:38:48 CET

This archive was generated by hypermail 2.3.0 : Fri Jan 29 2021 - 10:38:51 CET