Re: Particle latching using MGDRAW+STUPRE+STUPRF

(smtp1.mi.infn.it [192.84.138.69]); Mon, 02 Jun 2008 17:09:09 +0200 (CEST)
Sender: owner-fluka-discuss@mi.infn.it

Hi Alberto,

Thank you very much for the information about particle latching. I was
able to do that part.

I still have some questions.

In the same simulation, I have to record the steps( change in
position, energy loss and
energy deposited) that each particle take. So I was thinking to record
steps through
MGDRAW subroutine, while recording secondaries for each particle
through the entry
USRDRAW. Is this the right way to do this?

In order to identify the steps that belong to certain particle, I need
to have particle
ID. I saw PARNUM, in the common block FLKSTK. It can save only 6500
values. I am thinking
of running at least a million primaries in the actual simulation run.
Is this right
variable to use to identify a particle? Is it safe to change the
length of the array and
use PARNUM as the ID.

Or Is there a better way to do this whole process?

Thank You !!!

Sharmalee

Quoting Alberto Fasso' <fasso@slac.stanford.edu>:

> Hi Sharmalee,
>
> you want to write a lot of things (I hope you will have enough disk space...)
> Let's start with the secondaries.
> When you have an interaction, entry USDRAW of mgdraw is called with
> a code corresponding to that type of interaction. The properties of
> the secondaries produced in that interaction are stored in common GENSTK.
> If you want to write them, you need to loop up to NP:
> DO IP = 1, NP
> WRITE(..,..) KPART(IP), WEI(IP), CXR(IP)......
> END DO
>
> * Np = total number of secondaries *
> * Kpart (ip) = (Paprop) id of the ip_th secondary *
> * Cxr (ip) = x-axis direction cosine of the ip_th secondary *
> * Tki (ip) = laboratory kinetic energy of ip_th secondary (GeV)*
> * Wei (ip) = statistical weight of the ip_th secondary *
> * etc. (look up the full list in $FLUPRO/flukapro/(GENSTK)
>
> You can decide to save some of the properties of the parent in the
> TRACKR user variables SPAUSR(1)...SPAUSR(11) (for real values such as
> coordinates, energy, etc.) and ISPUSR(1)...ISPUSR(11) (for integer values
> such as the particle type). For instance (code 101 is an hadronic inelastic
> interaction):
>
> IF (ICODE.EQ.101) THEN
> SPAUSR(1) = WTRACK
> SPAUSR(2) = XSCO
> SPAUSR(3) = YSCO
> SPAUSR(4) = ZSCO
> SPAUSR(5) = ETRACK
> ..................
> ISPUSR(1) = JTRACK
> ISPUSR(2) = LTRACK
> ..................
> END IF
>
> At the moment these values are in TRACKR, which contains information about
> the current particle (i.e., the particle which is being transported and which
> has just had an inelastic interaction). When the secondaries
> of the current particle will be transferred to the FLUKA stack,
> those variable
> will be inherited by them. The 11 SPAUSR variables of the parent will be
> copied to corresponding SPAREK variables, and the 11 ISPUSR to corresponding
> ISPARK. This is done by the routines stupre.f and stuprf.f,
> which are called just before loading a particle into stack. The default
> version of stuprf, for instance, contains the following lines:
> DO 100 ISPR = 1, MKBMX1
> SPAREK (ISPR,NPFLKA) = SPAUSR (ISPR)
> 100 CONTINUE
> DO 200 ISPR = 1, MKBMX2
> ISPARK (ISPR,NPFLKA) = ISPUSR (ISPR)
> 200 CONTINUE
>
> When a particle is downloaded from the FLUKA stack for transport, its
> properties are copied to TRACKR, including the user variables
> (SPAREK to SPAUSR, ISPARK to ISPUSR), and in this way the information
> you have stored in them about the parent will be available.
>
> If everything you want to do is to keep the information about the
> parent particle, you will not need to worry about the STUPRF and the STUPRE
> routine, because the secondaries inherit the user variables of the parent by
> default. Those routines however can be used if you want to do some more
> sophisticated than just copying SPAUSR to SPAREK and ISPUSR to ISPARK. For
> instance, STUPRF can be used to keep information also about the "grandparent"
>
> * In the following lines we set a few user flags whenever a particle
> * decays ( LDECAY = .TRUE.) or undergoes an inelastic interaction
> * ( LINEVT = .TRUE. ). These flags will be inherited by all secondaries
> * produced in the decay or in the interaction and will be propagated to
> * all further generations. This allows, for example, to store
> * information about parent particles of any secondary.
> IF ( LINEVT .OR. LDECAY ) THEN
> * | Save in Ispark(1) the parent ID:
> ISPARK (1,NPFLKA) = IJ
> * | Save in Sparek(1) the parent total energy (GeV/c):
> SPAREK (1,NPFLKA) = SQRT(PTRACK**2 + AM(IJ)**2)
> * | Save in Sparek(2) the z coord. at which parent decayed or interacted:
> SPAREK (2,NPFLKA) = ZZ
> * | Save in Ispark(2) the ID of the GrandParent (it was in Ispark(1)!!!):
> ISPARK (2,NPFLKA) = ISPUSR(1)
> * | Save in Sparek(3) the energy of the GrandParent (it was in
> Sparek(1)!!!):
> SPAREK (3,NPFLKA) = SPAUSR(1)
> * | Save in Sparek(4) the z of the GrandParent (it was in Sparek(2)!!!):
> SPAREK (4,NPFLKA) = SPAUSR(2)
> ENDIF
>
> Note that in the above example the setting of the ISPARK and SPAREK
> is done directly, without setting first ISPUSR and SPAUSR in TRACKR, as
> shown before, and then letting them to be inherited. In this case, mgdraw had
> not been needed.
>
> The matter is a bit complex, but I hope I have made clear enough
>
> Alberto
>
>
>
> On Wed, 21 May 2008, Sharmalee Randeniya wrote:
>
>> Dear FLUKA experts
>>
>> I am trying to write a FLUKA collision tape for a proton therapy
>> simulation. The geometry consists of a nozzle(to adjust the range and
>> the shape the beam) and a water phantom. The beam passes through the
>> nozzle into the phantom.
>>
>> For each particle step(track segment) with in the phantom I want to
>> write down,
>> among several other things(particle type, energy, position), the
>> parent of the current particle, the parent step in which the current
>> particle is produced, the secondaries produced.
>>
>> I read the discussion under mgdraw.f, stupre.f and stuprf.f in the
>> manual(user routines) and the use of LTRACK(in fluka discussion
>> archive) to identify parents and secondaries. But I am not quite clear
>> how to do this.
>>
>> If someone can provide me some guidance, that would be very very helpful.
>>
>>
>> Thank You
>>
>> Sharmalee
>
>
>
Received on Mon Jun 2 23:28:42 2008