Re: Particle latching using MGDRAW+STUPRE+STUPRF

Hi Sharmalee,

> I still have some questions.
>
> In the same simulation, I have to record the steps( change in position,=
=20
> energy loss and energy deposited) that each particle take. So I was think=
ing=20
> to record steps through MGDRAW subroutine, while recording secondaries fo=
r=20
> each particle through the entry USRDRAW. Is this the right way to do this=
?

yes

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

The variable name is NUMPAR, not PARNUM (it is an integer, and all integers=
 in
FLUKA begin by I,J,K,L,M,N). Indeed you can use it as an ID.
NUMPAR values are not "saved": you can print them on a file together with o=
ther=20
particle properties if you wish, or save them in an array of your own. The=
=20
6500 dimension you mention is that of the FLUKA stack, and the characterist=
ics
of the current particle (including the particle number NUMPAR) occupy the=
=20
current upmost stack position, which is indicated by the value of the stack=
=20
pointer NPFLKA. The stack contains NPFLKA particles (max. 6500, but in gene=
ral=20
much fewer than that) waiting to be transported, each with its coordinates,
energy, weight, etc., and NUMPAR number.
Once a particle is downloaded from stack, NPFLKA is decreased by 1. So, you=
 can
see that the available 6500 values are only positions in the waiting list, =
they=20
are not used to save anything but just allocated when a particle is put on
the waiting list, and de-allocated when its turn to be transported is arriv=
ed.

Changing the the length of the FLKSTK is not possible, and anyway would not
help you at all. The present dimension of 6500 is more than sufficient for
all practical purposes: it only means that any given time you cannot have m=
ore
than 6500 particles waiting to be transported. As I said, normally you don'=
t
have more than a few hundreds, unless you have huge multiplicities as in
high energy heavy ion interactions.

NUMPAR can reach values much bigger than that!

Alberto

> Or Is there a better way to do this whole process?
>
> Thank You !!!
>
> Sharmalee
>
>
>
>
> Quoting Alberto Fasso' <fasso@slac.stanford.edu>:
>
>> Hi Sharmalee,
>>=20
>> you want to write a lot of things (I hope you will have enough disk=20
>> 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=
=2E
>> If you want to write them, you need to loop up to NP:
>> DO IP =3D 1, NP
>> WRITE(..,..) KPART(IP), WEI(IP), CXR(IP)......
>> END DO
>>=20
>> * Np =3D total number of secondaries =
 *
>> * Kpart (ip) =3D (Paprop) id of the ip_th secondary =
 *
>> * Cxr (ip) =3D x-axis direction cosine of the ip_th secondary =
 *
>> * Tki (ip) =3D laboratory kinetic energy of ip_th secondary (GeV=
)*
>> * Wei (ip) =3D statistical weight of the ip_th secondary =
 *
>> * etc. (look up the full list in $FLUPRO/flukapro/(GENSTK)
>>=20
>> 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 value=
s
>> such as the particle type). For instance (code 101 is an hadronic inelas=
tic
>> interaction):
>>
>> IF (ICODE.EQ.101) THEN
>> SPAUSR(1) =3D WTRACK
>> SPAUSR(2) =3D XSCO
>> SPAUSR(3) =3D YSCO
>> SPAUSR(4) =3D ZSCO
>> SPAUSR(5) =3D ETRACK
>> ..................
>> ISPUSR(1) =3D JTRACK
>> ISPUSR(2) =3D LTRACK
>> ..................
>> END IF
>>=20
>> At the moment these values are in TRACKR, which contains information abo=
ut
>> the current particle (i.e., the particle which is being transported and=
=20
>> which
>> has just had an inelastic interaction). When the secondaries
>> of the current particle will be transferred to the FLUKA stack, those=20
>> 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=20
>> 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 =3D 1, MKBMX1
>> SPAREK (ISPR,NPFLKA) =3D SPAUSR (ISPR)
>> 100 CONTINUE
>> DO 200 ISPR =3D 1, MKBMX2
>> ISPARK (ISPR,NPFLKA) =3D ISPUSR (ISPR)
>> 200 CONTINUE
>>=20
>> 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.
>>=20
>> 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 STU=
PRE
>> routine, because the secondaries inherit the user variables of the paren=
t=20
>> 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. F=
or
>> instance, STUPRF can be used to keep information also about the=20
>> "grandparent"
>>=20
>> * In the following lines we set a few user flags whenever a particle
>> * decays ( LDECAY =3D .TRUE.) or undergoes an inelastic interaction
>> * ( LINEVT =3D .TRUE. ). These flags will be inherited by all secondari=
es
>> * 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) =3D IJ
>> * | Save in Sparek(1) the parent total energy (GeV/c):
>> SPAREK (1,NPFLKA) =3D SQRT(PTRACK**2 + AM(IJ)**2)
>> * | Save in Sparek(2) the z coord. at which parent decayed or interact=
ed:
>> SPAREK (2,NPFLKA) =3D ZZ
>> * | Save in Ispark(2) the ID of the GrandParent (it was in Ispark(1)!!=
!):
>> ISPARK (2,NPFLKA) =3D ISPUSR(1)
>> * | Save in Sparek(3) the energy of the GrandParent (it was in=20
>> Sparek(1)!!!):
>> SPAREK (3,NPFLKA) =3D SPAUSR(1)
>> * | Save in Sparek(4) the z of the GrandParent (it was in Sparek(2)!!!=
):
>> SPAREK (4,NPFLKA) =3D SPAUSR(2)
>> ENDIF
>>=20
>> 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, mgdra=
w=20
>> had
>> not been needed.
>>=20
>> The matter is a bit complex, but I hope I have made clear enough
>>=20
>> Alberto
>>=20
>>=20
>>=20
>> On Wed, 21 May 2008, Sharmalee Randeniya wrote:
>>=20
>>> Dear FLUKA experts
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> If someone can provide me some guidance, that would be very very helpfu=
l.
>>>=20
>>>=20
>>> Thank You
>>>=20
>>> Sharmalee
>>=20
>>=20
>>=20
>

--=20
Alberto Fass=F2
SLAC-RP, MS 48, 2575 Sand Hill Road, Menlo Park CA 94025
Phone: (1 650) 926 4762 Fax: (1 650) 926 3569
fasso@slac.stanford.edu
--1334196310-550715816-1212598800=3D:11482--
Received on Wed Jun 4 20:58:49 2008