Re: [fluka-discuss]: problem with particle latching

From: Giuseppe Battistoni <giuseppe.battistoni_at_mi.infn.it>
Date: Tue, 18 Feb 2014 17:22:45 +0100

Dear Paolo
I go back to your question of Dec. 4. 2013.
Together with Alfredo Ferrari we have just verified that indeed in the
public version of FLUKA there is an asymmetry between the way USDRAW
is called after e.m. interactions with respect to hadronic ones.
The reason is historical: at the beginning it was not conceived to do this job in mgdraw.
It should work if you instead get the desired properties inside stupre.f
We shall discuss within the FLUKA group at a next meeting to see if there are no counter arguments
to change that logic.
Best regards
        Giuseppe


On 12/4/13 8:40 AM, maestro wrote:
> Dear FLUKA experts
> I would like to tag and write in a collision tape all the backscattered particles produced
> in e.m./hadronic showers generated by beam particles impinging a calorimeter.
> For each backscattered particle, I am interested in recording
> some properties of the parent (i.e.:ETRACK, JTRACK, LTRACK, etc.).
> To do that I have followed the procedure
> explained in this forum message "Particle latching using MGDRAW+STUPRE+STUPRF"
> (Alberto Fasso', 22/05/2008).
> In the USDRAW routine, I copied the parent properties
> in the SPAUSR and ISPUSR variables of TRACKR.
> That works well when USDRAW is called from Kascad and Kasneu, but
> it does not work when USDRAW is called from Emfsco.
> For instance, with an electron as beam particle, whenever a
> Moller scattering occurs, the secondary electron does not inherit the
> parent properties (i.e. all the SPAUSR/ISPUSR variables of TRACKR are zero but
> ISPUSR(11)). Instead in photonuclear interaction, the products
> correctly recall the parent properties.
> As far as I understood, the TRACKR user variables
> are copied by stuprf.f and stupre.f to the FLKSTK and EMFSTK particle stacks respectively,
> and then copied back to the TRACKR user variables when a secondary is downloaded from the stack to be transported.
> However in my simulation, I suspect this last step does not occur with EMFSTK.
> Why? Am I doing anything wrong ?
> Thank you
> Best regards
> Paolo Maestro


-- 
INFN Milano
via Celoria 16, 20133 Milano, Italy
tel: +39 02 50317307
fax: +39 02 50317617
Received on Tue Feb 18 2014 - 18:21:11 CET

This archive was generated by hypermail 2.3.0 : Tue Feb 18 2014 - 18:21:11 CET