Hi Everybody,
the approach is valuable, stuppre is ok for the EM part. For the hadronic
pert one should probably have a stuprf.f instead.
All depend on what you exactly want to do with your particle history.
Again here on the forum there's some valuable information which I think you
already read
http://www.fluka.org/web_archive/earchive/new-fluka-discuss/1606.html
http://www.fluka.org/web_archive/earchive/new-fluka-discuss/1197.html
Information regarding initial and final states of interactions are
> available in user routine mgdraw (activated with the card USERDUMP) under
> entry USDRAW. Information on the parent particle can be read from common
> TRACKR, while those of the final state particles are in commons GENSTK.
The values in X,Y,ZTRACK are defined as "/soft/flukadev/flukaadd/(TRACKR)"
and represent the end-points of the (i-th) track segments, before the
interaction when the projectile disappears.
WIth a stupre.f you could look at XEMF([#secondary]) (YEMZ(), ZEMF())
which are the x-coordinate where the secondary is created
I can't post relevant code as I don't have access to it anymore...
Best,
V.
On Thu, Jun 26, 2014 at 1:25 PM, Franz Englbrecht <
franz.englbrecht_at_physik.uni-muenchen.de> wrote:
> On 20.06.2014 23:49, Vittorio Boccone wrote:
>
> Here's the trick...
> I though I wrote it in my previous email but I didn't. My fault.
>
> NTRACK tells you how many segments you have during this step. If you have
> no magnetic field where you change the track segmentation by splitting up
> segments this should be always 1 at the end of the step and 0 at the
> beginning. NTRACK is therefore used as an index of the track position (and
> dir. cosines) arrays. Personally I think I never used it.
>
> You find a lot of information for tracking and following the particles in
> "$FLUPRO/flukapro/(TRACKR)"
>
> To do what you say, you don't need to write anything in FLUKA but you
> need to analyze/post-process correctly your event. I used Icode toghether
> with some of the TRACKR variables to recontruct the history of the event.
>
> V.
>
> On Fri, Jun 20, 2014 at 6:23 PM, Georgios Dedes <
> G.Dedes_at_physik.uni-muenchen.de> wrote:
>
>> Hi Vittorio and rest of FLUKAers,
>>
>> thanks for the reply. As you recommended, I took another look into a
>> minimally modified mgdraw, trying to understand what I get. I attach the
>> routine.
>>
>> In line 70, I basically merged some of the output that was active in the
>> default mgdraw.
>> In line 295 (usdraw), I dump the same info as in line 70.
>>
>> So my conclusions/questions so far (I attach the file coming from MGDRAW
>> and USDRAW):
>>
>> - using the index 0 for the XTRACK, YTRACK, ZTRACK gives me the starting
>> location of the step while if I use 1 they give the end point of each step
>> (which alternate of course, the end of the previous step is the start of
>> the next one). So far so good.
>>
>> - in the mgdraw_Output I seem to be getting all the steps (I can see the
>> primary having a starting step location exactly where the source is
>> created), while in the usdraw_Output only a subset of them. As mentioned in
>> the online manual, usrdraw is called after each particle interaction. Are
>> the missing entries (as compared to the mgdraw_Output) due to continuous
>> energy loss for which the usrdraw is not called?
>>
>> - as far as it concerns NTRACK, in the default mgdraw writing to the
>> mgdraw_Output, NTRACK is always 1. When I access the same info from the
>> usdraw it's always 0 for the primary protons and 1 for the few electrons I
>> got (I used only 2 protons of 1GeV). So I still don't understand NTRACK. It
>> is definitely not incrementing for each particle step, but it is also 0
>> when accessed from usdraw. Any idea why?
>>
>> - a last question, which was actually the source of all my troubles. How
>> can I get from the mgdraw, which follows every particle through every step,
>> the position of generation of secondaries? Initially I thought that I could
>> use the NTRACK, which I wrongly thought that it would increment in every
>> step, along a particle trajectory
>>
>> Thanks for the feedback,
>> George
>>
>>
>>
>> Dr. Georgios DEDES
>> Ludwig-Maximilians-Universität München (LMU)
>> Medical Physics Chair (LS Parodi)
>> Am Coulombwall 1
>> 85748 Garching
>> Tel:+49 (0) 89 289-14022
>> Fax:+49 (0) 89 289-14072
>>
>> On 06/18/2014 11:11 PM, Vittorio Boccone wrote:
>>
>> Hi George,
>> mgdraw is a very powerful tool, but I see you already know what are
>> the different ingredients.
>> If you miss the successive steps I guess you activate it using the wrong
>> WHAT(3) in the USERDUMP card, or your threshold are too high and the
>> particles are "absorbed" in loco.
>>
>> I would suggest you to play around with the default mgdraw.f and maybe
>> to post your code. It's a bit complicate to tell you what is wrong if I
>> can't see what you do.
>>
>> I would leave NTRUCK aside for the time being.
>> Best
>>
>>
>> On Wed, Jun 18, 2014 at 3:12 PM, <G.Dedes_at_physik.uni-muenchen.de> wrote:
>>
>>> Dear FLUKAers,
>>>
>>> I'm trying to develop a short user routine (in mgdraw) for custom
>>> scoring and I got the following questions:
>>>
>>> - Shooting 100MeV protons in a water target and printing the JTRACK,
>>> ICODE, ETRACK, NTRACK, MTRACK, XSCO, YSCO, ZSCO , I see mostly what I
>>> expected to see when following my particle step by step along its
>>> trajectory. Nevertheless, the NTRACK (and the MTRACK as well), seems to be
>>> always 0. If the meaning of of the track segment is what I thought,
>>> shouldn't it be incrementing along the trajectory?
>>>
>>> - Then I see that there is also the variable NTRUCK, which represents
>>> the number of step points. When I print this in mgdraw, it's also always 0
>>> for my primary protons. So same question as above. In addition, I am not
>>> sure that I understand the difference between the track segment (~NTRACK)
>>> and the step (~NTRACK)
>>>
>>> - What I ultimately had in mind was to follow the particle in every step
>>> and -for example- store the newly generated secondary particle position
>>> (the starting point of the first track segment or step)
>>>
>>> Obviously I am missing something important here, so I would be grateful
>>> if you can help me on this or point me to some reference that clarifies it.
>>>
>>> Thanks in advance,
>>> George
>>>
>>>
>>
>>
> Dear Colleagues,
>
> can someone find find some explaining words regarding the following
> question of George, in which I am also interested:
>
>
> """- in the mgdraw_Output I seem to be getting all the steps (I can see
> the primary having a starting step location exactly where the source is
> created), while in the usdraw_Output only a subset of them. As mentioned in
> the online manual, usrdraw is called after each particle interaction. Are
> the missing entries (as compared to the mgdraw_Output) due to continuous
> energy loss for which the usrdraw is not called?"""
>
> Regarding the last question of George, I would like to contribute another
> approach than using mgdraw together with some small questions. Similar as
> George, I want to get the position of the generation of secondaries, in my
> case electrons resulting from a simple proton beam impinging on a water
> target.
>
> """- a last question, which was actually the source of all my troubles.
> How can I get from the mgdraw, which follows every particle through every
> step, the position of generation of secondaries? Initially I thought that I
> could use the NTRACK, which I wrongly thought that it would increment in
> every step, along a particle trajectory"""
>
> I wanted to avoid to identify the generation of secondary electrons based
> on an event-by-event evaluation using mgdraw. Since all secondary electrons
> generated by my primary proton beam get stored to be transported later,
> accessing this storage seemed meaningfull. Stupre.f was used by me since
> Page 42 in the attached Notes "AdvancedUserRoutines2012.pdf" from a Fluka
> course mentions:
>
> "STUPRE is called before loading into stack electrons" and "Also the
> region/position etc. are already set inside the stack arrays."
>
> I added to stupre.f:
>
> IF ( JTRACK .EQ. 3 ) THEN
> * If Stackparticle is an electron then
>
> WRITE(D_ID,*) SIZE(XTRACK)
> WRITE(D_ID,*) SIZE(YTRACK)
> WRITE(D_ID,*) SIZE(ZTRACK)
>
> WRITE(D_ID,*) 'TRK_0', XTRACK(0), YTRACK(0), ZTRACK(0)
> WRITE(D_ID,*) 'TRK_1', XTRACK(1), YTRACK(1), ZTRACK(1)
>
> WRITE(D_ID,*) 'X_TRK', XTRACK
> WRITE(D_ID,*) 'Y_TRK', YTRACK
> WRITE(D_ID,*) 'Z_TRK', ZTRACK
>
> END IF
>
> The Output is the file I attached: beam_list001_ELECTRON.
>
> *** Am I right in assuming that XTRACK(0), YTRACK(0), ZTRACK(0) give me
> the coordinates of the interaction-vertex, which generated the electron?
> *** Why are XTRACK, YTRACK and ZTRACK entries 0 and 1 filled and not only
> Arrayindex 0? There was no transport, so I would expect only the
> startingpoint (Arrayindex 0).
> *** Why are XTRACK(0) and XTRACK(1) the same value?
> *** What does the Size of the e.g. XTRACK Array tell me? Is it determined
> by the motherparticle?
>
> Is my approach to efficiently get the position of the electron-generation
> correct?
>
> Dear Vittorio, it would be nice if you could provice some of your code
> which you used for reconstructing the history of your event, which could be
> helpful.
>
> Tanks in advance!
>
> Best,
> Franz
>
Received on Thu Jun 26 2014 - 16:28:21 CEST