Particles time of flight

Dear Fluka expert,

I whish to simulate a not mono-energetic particle beam. Is it possible to know the time T at which each particle enter and/or leave a region (supposing their flight starts at T = 0 s ) ?
Many thanks in advance.

Dear Tibe68,

it is possible to access all particle data with the mgdraw.f user routine.


In your case the BXDRAW section of the code is relevant. This is called, when a particle crosses a surface.
The particle information can be accessed via the common. The age of the particle is stored in the Atrack variable.


Hi Horvathd,

thanks a lot for your answer. I will surely try.


Hi again David,

I actually tried to do what you suggested in your answer but I’m clearly missing something (probably more than just “something”…).

I’ve put this USERDUMP card in my simulation


and I get five .dmpfil files but I don’t know how to exploit/plot these data.
I’d really need a “step-by-step” procedure (aka “Flair for dummies”) :slightly_smiling_face:
Many thanks in advance.
Al the best,


Hi @Tibe68, @horvathd’s suggestion implied that you had to customize the mentioned mgdraw.f user routine according to your needs, writing the suitable Fortran code at the indicated BXDRAW location and creating your own executable. Since this is a job for an advanced user, I’d advise you to rather use the built-in USRYIELD scoring card. This allows to score a particle time distribution on a region boundary, assuming exactly that the respective beam particle moves from its starting point at t=0.
To this purpose, you just need the input file and no user routine coding. Note that USRYIELD gives a double differential distribution, meaning that, in addition to time, you can filter the particles according to another quantity, as in the manual.
Good luck

Hi Francesco,

grazie mille :slightly_smiling_face:

Can you please explain me the meaning of the following error msg I get when I run Flair using the URSYELD card?

Error: /usr/local/fluka/bin/fluka executanle returned RC=144

Thanks !


Hi Tibe,

the error code suggest a stack fault. Could you share your .flair file, so we can check?


Hi David,

sure, please find joint the flle.
All the best,


test.flair (4.1 KB)

Hi Tibe,

the problem is that the USRYIELD card is incomplete. You need to specify the maximum of both scoring intervals because there is no default associated with these fields.

Also it is highly recommended to set a unit number as well, if you want to merge results from different cycles.

Plus the two regions in the scoring are not next to each other, so the scoring will return zero.


Moreover, also the USRYIELD ‘Kind’ field has to be set, selecting d2N/dx1dx2 (i.e. double differential particle yield). Forget about the Mat field, which is irrelevant here.
Pay special attention to @horvathd’s remark about region contiguity, since the logic is: “score on the boundary between two regions”. It’s clear that, if the two regions do not share any boundary, the scoring is null.

HI again ,

and thanks to you both. I’ve filled up the missing values in the USRYELD card following your suggestions but I still get an error msg (WARNING: No input data found for ‘test2.yie’).
I must confess (but it was already quite evident even without stressing it) that I am a litle bit confused about the way this card works. For instance I don’t understand if something changes putting the quantity we want to score as “ie” or as “ia”.
Anyway, I join again my (new) .flair file, hoping it helps.
Thanks again.



test2.flair (4.2 KB)

There is indeed a fundamental difference between the two scoring quantities. Since you are interested in a time distribution, your ie quantity should be time, for which you have then to define the interval limits and the number of bins defining your scoring resolution. The second quantity ia allows to implement a filter (“score only if its value is between the indicated ia limits”), so I’d suggest not to restrict at this stage your electron scoring. To this purpose, you may select as second quantity charge and indicate (-1.5) and (-0.5) as respective lower and upper limit (evidently, the requested electrons are included in this range, which has the additional advantage of being neutral from the normalization point of view, since its length is 1).

1 Like