I’m running a simulation with a single high energetic particle (proton 10 PeV) from the top of the atmosphere and extracting information about charged kaons, pions, and muons through the atmosphere regions and underground. To do so, I’m using the subroutine USRDRAW.
Muons usually are transported along the atmosphere and this transportation is registered in MGDRAW output file, sometimes, with hundreds or thousands of steps. I’m interested in these tracks, but also in the first and last step of each particle. To eliminate the duplicates, I post-process the data and create a unique number for each particle (unique_id) to keep the first and last step (i.e the point of creation and last point) of the particle. This post-process could contain errors and overcount some of the particles. I was wondering if from Fluka is possible to extract directly this unique id number.
If helps to understand what I’m trying, find attached a plot with, from left to right, all muons track, muons point creation (FIRST) muon point end (LAST).
Thank you for your question.
As far as I know, there is not a unique_id number by default, BUT you can define it using a user defined variable in TRACKR.
trackr.inc [TRACKs Recording] (properties of the currently transported particle and its path)
Here, you can get a lot of information of the particle you are transporting, many you probably know already:
Ntrack = number of track segments
Mtrack = number of energy deposition events along the track 0 < i < Ntrack
Xtrack = end x-point of the ith track segment
Ytrack = end y-point of the ith track segment
Ztrack = end z-point of the ith track segment 1 < i < Ntrack
Ttrack = length of the ith track segment 1 < j < Mtrack
Jtrack = identity number of the particle: for recoils or
kerma deposition it can be outside the allowed
particle id range, assuming values like:
208: "heavy" recoil
211: EM below threshold
308: low energy neutron kerma
in those cases the id of the particle originating
the interaction is saved inside J0trck (which othe-
rwise is zero)
Etrack = total energy of the particle
Ptrack = momentum of the particle (not always defined, if
< 0 must be obtained from Etrack)
Cx,y,ztrck = direction cosines of the current particle
Cx,y,ztrpl = polarization cosines of the current particle
Wtrack = weight of the particle
Ctrack = total curved path
Spausr = user defined spare variables for the current particle
Satrck = macroscopic absorption cross section for low energy neutron collisions (it can be negative for Pnab>1)
Ltrack = flag recording the generation number
Llouse = user defined flag for the current particle
Ispusr = user defined spare flags for the current particle
Lfsssc = logical flag for inelastic interactions ending with
fission (used also for low energy neutrons)
Lpkill = logical (user) flag for sudden particle death
I suggest you to use the variable LLOUSE to flag the muons when they appear for the first time in MGDRAW. In that way you will be able to know that the muon you follow is the right one.
Second option, but using a similar procedure, is to flag them when they are generate and stored in the stack.
Look at this thread which explains how to do this (It explains how to give information about the particles ancestors, but for your problem the difference is just in the info that you provide to the parameter ‘LLOUSE’).
Third option ( It is probably similar to what you are doing now)
Dumping from MGDRAW these variables:
NCASE: number of primaries treated so far (including current one) JTRACK, (X,Y,Z)TRACK and LTRACK
You can identify, postprocessing that information, all the tracks of your muons.
I hope this helps you, let me know in case you need more assistance,
Thanks a lot for your answer.
In fact, I’m getting particle information from the trackr.inc file and also using the LLOUSE flag to get information about the ancestors as mentioned in the link you’ve sent in option 2.
Reading you, I’ve realized that I’m not using the XYZ(track) but the XYZ(SCO) which maybe are not so useful. I’ll run some tests using these track coordinates and give the feedback here.
Nonetheless, I’m curious about your first suggestion.
I suggest you to use the variable LLOUSE to flag the muons when they appear for the first time in MGDRAW
If I understand it correctly, I should use LLOUSE without compiling the stuprf.f . As a variable from trackr.inc Which kind of value will return using it this way?
As you suggested, I’ve implemented in USRDRAW the XYZ(Track) but without very much success. From these variables, I’ve obtained very large arrays basically filled with 0.0 and the output becomes too large.
On the other hand, following some of your suggestions I’ve improved the results. Nonetheless, there are some outputs that I don’t know how to interpret. I’m exposing an example below. Please, if you think this information needs to be on a new topic, please let me know to open it.
The table columns are icode, kinetic energy (ekin), the id of the particle (id), ltrack, the parent id (id_anc), and the unique_id generated from post-processing.
The first two rows are the track tail of a muon+. The id and id_anc are the same because the muon is transported. Another muon+ is created at index 2297 by decay (icode 102) from a pi- (id_anc 13) and the next rows show its transport.
What I don’t know how to interpret is the creation of that pi- (index 2291) which shows a pi+ as parent id (id_anc 14). This combination of 13 as id and 14 as id_anc and vice versa happens several times.
It also appears a few times Kaon- creating a pion+ and vice-versa.
I’ve implemented in USRDRAW the XYZ(Track) but without very much success. From these variables, I’ve obtained very large arrays basically filled with 0.0 and the output becomes too large.
The Xtrack list will be filled with the x position with many track segments in case that the particle is transport in a magnetic field. If there is no field (as seems to be your case) the track segment of the particle will be given in Xtrack(0) and Xtrack(1) [Same situation for YZ].
With this you should be able to get the position of the particles.
If I understand it correctly, I should use LLOUSE without compiling the stuprf.f . As a variable from trackr.inc Which kind of value will return using it this way?
That’s the first option I suggested you.
In MGDRAW you can define a new integer variable (e.g. ‘MUNUMB’) and when a muon is produced, you can catch it with JTRACK, and copy the value MUNUMB to the variable LLOUSE, whose value by default is 0 (you can give initially a value of 1 to MUNUMB).
Then, in a potential future step of this same muon, you can filter if LLOUSE is different to 0. In that case, you don’t have to flag LLOUSE again because it is a muon already flaged.
If you have a new muon, LLOUSE will be 0, then you can increment the value of MUNUMB, and then the value of LLOUSE for this muon will be 2, and so on…
The third case is essentially the same, but you can flag the value of LLOUSE in stuprf.f.
To do this, you have to change the value of LOUSE:
LOUSE (NPFLKA) = MUNUMB
And, as the thread I sent you explains:
When a new particle is taken from the stack in order to transport it this particle is filled into TRACKR with the above variable saved on LLOUSE.
What I don’t know how to interpret is the creation of that pi- (index 2291) which shows a pi+ as parent id (id_anc 14). This combination of 13 as id and 14 as id_anc and vice versa happens several times.
Here I don’t have a good answer for the moment. How are you getting the id_anc?
Please, if you think this information needs to be on a new topic, please let me know to open it.
I think it is a good idea. Do it please, and share your routine and inputs. This will be helpful to understand in more detail what is happening.
I’ve marked your first post as a solution, but I appreciate the details in your second reply.
Also, I’ve opened a new post regarding the output data Strange outputs from data usrdraw. How to interpret them? where the input files and user routines have been attached.
