Re: [fluka-discuss]: Heavy Ion collision using DPMJET in FLUKA framework

From: Sourav Tarafdar <Sourav.Tarafdar_at_weizmann.ac.il>
Date: Fri, 28 Nov 2014 14:17:23 +0000

Dear Francesco,

Thanks for the clarification. I have couple of questions mostly concerning to protons and neutrons.


>> Do it also contain intranuclear
>> cascade protons and neutrons along with the ones produced in H.I.
>> collision ?
>
> yes.



Any way of disentangling the protons and neutrons coming from different processes in FLUKA ? As you confirmed protons and neutrons are also from H.I. collision so these as per spectator definition won’t be called as spectators. So I am mostly interested in selecting protons and neutrons from Fragmentation or Evaporation process. Unfortunately I don’t see any variable in FLKSTK which can distinguish protons / neutrons coming from different process.


>> 2) Does the FLKSTK stores final state nuclear fragments ? By final state I mean which
>> has already undergone fragmentation and evaporation .
>
> yes.

I think you also mean the deuteron, H3, He3, He4 are in final state ?

Thanks
-Sourav


On Nov 28, 2014, at 3:49 PM, Francesco Cerutti <Francesco.Cerutti_at_cern.ch> wrote:

>
> Dear Sourav
>
>> Do it also contain intranuclear
>> cascade protons and neutrons along with the ones produced in H.I.
>> collision ?
>
> yes.
>
>> 1) As I have only Evaporation as Physics process in my input file
>
> be careful. In your input file you are not switching on evaporation (which is always on), you are just saying that you want the most accurate version of evaporation, more CPU-consuming but including as emission channels also heavier fragments. As a general rule, in FLUKA (all) physics processes are on by default and are not intended to be manipulated by the user, apart from few exceptions - like heavy evaporation, coalescence, photonuclear reactions - which require to be switched on by the user when they are relevant.
>
>> 2) Does the FLKSTK stores final state nuclear fragments ? By final state I mean which
>> has already undergone fragmentation and evaporation .
>
> yes.
>
>> 3) Further the heavy fission fragments in FLKSTK has id based on the recipe of -((Z*1000)
>> +A )*100. I noticed the last digit varies between 7-12. Is it associated with the ID in
>> FHEAVY stack?
>
> Exactly.
>
> Ciao
>
> Francesco
>
> **************************************************
> Francesco Cerutti
> CERN-EN/STI
> CH-1211 Geneva 23
> Switzerland
> tel. ++41 22 7678962
> fax ++41 22 7668854
>
> On Fri, 28 Nov 2014, Sourav Tarafdar wrote:
>
>> Dear Francesco,
>> Thanks for your detailed explanations. I have couple of questions for which I have
>> attached a file with plots from FLUKA.
>>
>> 1) As I have only Evaporation as Physics process in my input file so is it that the free
>> protons and neutrons are coming only from evaporation of non
>> interacting part of Au nucleus in H.I. collision ? Do it also contain intranuclear
>> cascade protons and neutrons along with the ones produced in H.I.
>> collision ?
>> 2) Does the FLKSTK stores final state nuclear fragments ? By final state I mean which
>> has already undergone fragmentation and evaporation .
>> 3) Further the heavy fission fragments in FLKSTK has id based on the recipe of -((Z*1000)
>> +A )*100. I noticed the last digit varies between 7-12. Is it associated with the ID in
>> FHEAVY stack or they directs to some physics process contribution to their production ?
>> Thanks
>> -Sourav
>> On Nov 24, 2014, at 5:48 PM, Francesco Cerutti <Francesco.Cerutti_at_cern.ch> wrote:
>> >
>> > Dear Sourav,
>> >
>> > your message below is - among the 4 you circulated last week on the same subject - the
>> one closest to the correct procedure to adopt for your purposes, according to what I
>> suggested you at the beginning. In the following ones, apart from repeated typos in the
>> linking command (whose right version is just what you had written here, although "-m
>> fluka" is not needed since it is already included inside ldpmqmd), you decided to go with
>> other strategies (usreou.f and USDRAW of mgdraw.f) which cannot work.
>> >
>> > So let's stay with usrein.f - which as I said does not require any associated input
>> card in order to be activated -, remove the pointless INTEGER definition, write your own
>> output on a file with logical unit number > 20 (instead of LUNOUT, avoiding in addition
>> unit numbers already used in scoring cards present in the inp file), and forget about
>> FHEAVY.
>> > Among the NPFLKA Au+Au reaction products available in FLKSTK, you may find also nuclear
>> fragments (probably what you call spectator fragments) which are just the ones identified
>> by the strange IDs you were worrying about. In fact ILOFLK(II) = -6214308
>> > means 143Sm, according to the coding recipe (you can see for instance also in the
>> source.f user routine): - ((Z * 1000) + A) * 100.
>> >
>> > Best wishes
>> >
>> > Francesco
>> >
>> > **************************************************
>> > Francesco Cerutti
>> > CERN-EN/STI
>> > CH-1211 Geneva 23
>> > Switzerland
>> > tel. ++41 22 7678962
>> > fax ++41 22 7668854
>> >
>> > On Wed, 19 Nov 2014, Sourav Tarafdar wrote:
>> >
>> >> Dear Francesco, Eventually I can extract the kinematic information of particles in
>> >> FLKSTK . It will be helpful if you please confirm whether the steps followed by me is
>> in
>> >> order.
>> >> 1) Customizing usrein.f routine involves adding following lines in the routine
>> >> INCLUDE '(FLKSTK)’
>> >> INTEGER:: ii
>> >> DO ii = 1, NPFLKA
>> >> WRITE(LUNOUT, *) Iloflk(ii), Pmoflk(ii), Loflk(ii), Zflk(ii)
>> >> ENDDO
>> >> 2) Compiling usrein.f :
>> >> $FLUPRO/flutil/fff usrein.f generates usrein.o
>> >> 3) Creating executable with link to DPMJET-III generator :
>> >> $FLUPRO/flutil/ldmqmd -o executable_name -m fluka usrein.o
>> >> 4)Running Fluka
>> >> $FLUPRO/flutin/rfluka -e executable_name input_file
>> >> So now I am getting the particle kinematics information in my standard fluke output
>> file.
>> >> It will be helpful if you please confirm whether this is the right way to extract the
>> >> kinematic information of the particles and nuclear remnants from beam after H.I.
>> >> collision. Further I have few questions.
>> >> 1) So far I didn’t see any variable to distinguish between spectator fragments and
>> >> produced particles in Heavy Ion collision for FLKSTK. Can you please tell me whether
>> >> there is any tag to distinguish between spectator fragments and produced particles ?
>> If
>> >> not will it be more appropriate to look at contents of FHEAVY which will most probably
>> >> will contain spectator fragments ? But somehow I am worried that FHEAVY don’t provide
>> the
>> >> information of free protons and neutrons as it works from deuteron ?
>> >> 2) In the output for FLKSTK I noticed some of the particles had ID "-6214308 “ or is
>> >> short having 7 digits. What are these particles ?
>> >> Thanks
>> >> -Sourav
>> >> On Nov 17, 2014, at 7:02 PM, Sourav Tarafdar <Sourav.Tarafdar_at_weizmann.ac.il> wrote:
>> >>
>> >> Dear Francesco,
>> >>
>> >> Thanks for your help. Eventually it is running without any crash. However I
>> >> am still stuck at retrieving the kinematic information of particles and
>> >> nuclear fragments remained after H.I. collision. As per your suggestion I
>> >> needed to look at the FLKSTK content by adding INCLUDE (FLKSTK) in usrein.f
>> >> routine. However I am not sure which scoring card I need to use in my fluke
>> >> inout file for dumping out FLKSTK variables ? Further I am wondering if in
>> >> FLUKA no scoring card exist which can dump out FLKSTK variables in output
>> >> file then shall I have to customize usreou.f routine specifically for that
>> >> purpose ?
>> >>
>> >> I have another confusion. Looking at FLUKA user manual it says if primaries
>> >> are loaded by input option “BEAM” then there is one source particle per
>> >> event. In my case as I am using “BEAM” for defining type of beam , so I am
>> >> wondering whether the FLKSTK will store only my colliding beam kinematic
>> >> information or also all the particles and nuclear remnants from H.I.
>> >> collision ?
>> >>
>> >> It will be really helpful if I get step by step procedure to extract the
>> >> kinematic information of particles and nuclear fragments remained after H.I.
>> >> collision.
>> >>
>> >> Thanks
>> >> -Sourav
>> >>
>> >> On Nov 13, 2014, at 11:43 PM, Francesco Cerutti <Francesco.Cerutti_at_cern.ch>
>> >> wrote:
>> >>
>> >> Dear Sourav,
>> >>
>> >> i. your previous crash is due to the fact that your colliding
>> >> nuclei are ... not colliding, since in SPECSOUR you input the
>> >> same lab momentum for both, whereas they should have opposite
>> >> direction (i.e. negative z-component for one of the two).
>> >>
>> >> ii. Then please note that SPECSOUR requires the total momentum,
>> >> while HEAVYION in the BEAM card requires momentum or kinetic
>> >> energy per nucleon (in fact per nuclear mass unit). Moreover, in
>> >> the presence of SPECSOUR, the only relevant parameters in BEAM
>> >> are the particle species and the energy/momentum, with the latter
>> >> just used for transport initialization purposes (the upper limit
>> >> of stopping power tabulations is defined based on it).
>> >>
>> >> iii. You do not need EVENTYPE (obsolete), IONTRANS (ion transport
>> >> and interaction already on by default for HEAVYION beams), nor
>> >> the DPMJET card (whereas you obviously have to use - as I believe
>> >> you are doing - an executable where dpmjet is linked, like
>> >> flukadpm3 generated by the ldpmqmd script). You need instead a
>> >> PHYSICS card with SDUM=LIMITS, specifying an upper threshold for
>> >> nucleon CMS momentum (110 GeV/c is fine for your case). Standard
>> >> USERDUMP is not an useful option here.
>> >>
>> >> iv. Note also that the simulated Au-Au collisions are nuclear
>> >> non-elastic reactions, disregarding electromagnetic dissociation
>> >> (which has a much higher cross section, but in the present
>> >> release is not yet available for source collisions).
>> >>
>> >> v. Your XYP plane is useless since you set it exactly upon the
>> >> RPP downstream face, this way your regAu4 is empty (i.e. has got
>> >> zero volume). The two VACUUM ASSIGNMA are odd, since the first in
>> >> fact applies only to regAu4 (FROM regAu4 TO regAu3, but the
>> >> respective region numbers are such as 2[regAu3] < 3[regAu4]) and
>> >> the second anyway redefines the regAu4 material (keeping in mind
>> >> that this region is meaningless as just said).
>> >>
>> >> vi. Concerning CPU time, a 100GeV/n Au + 100GeV/n Au event takes
>> >> on my machine a bit more than half a second, so 1E5 collisions
>> >> require less than 20 hours of CPU, i.e. less than 2h on 10 cores,
>> >> which looks to me as a reasonable time.
>> >>
>> >> Kind regards
>> >>
>> >> Francesco
>> >>
>> >> **************************************************
>> >> Francesco Cerutti
>> >> CERN-EN/STI
>> >> CH-1211 Geneva 23
>> >> Switzerland
>> >> tel. ++41 22 7678962
>> >> fax ++41 22 7668854
>> >>
>> >> On Mon, 10 Nov 2014, Sourav Tarafdar wrote:
>> >>
>> >> Dear Fluka experts,
>> >> In continuation of the problem I came up with couple
>> >> of days ago I want to add few more
>> >> things. After removing “SPECSOUR” card from my input
>> >> file while keeping DPMJET physics
>> >> process and executing FLUKA after linking DPMJET to
>> >> it , “core dump” problem got removed.
>> >> So basically the input file is with just
>> >> unidirectional Au beam with momentum of
>> >> 100GeV/nucleon. For p+p collision by keeping
>> >> “SPECSOUR” card it takes forever to finish
>> >> even 1 FLUKA cycle. Is it some limitation regarding
>> >> SPECSOUR card for invoking heavy ion
>> >> collision or something related to it is missing in my
>> >> input file ? I am hereby attaching
>> >> my input file. The collision vertex is defined in
>> >> vacuum within +/- 0.001 cm along X-Y-Z
>> >> coordinate and it has been divided into upstream and
>> >> downstream along Z axis by XYP cut
>> >> plane.
>> >> Thanks
>> >> -Sourav
>> >> On Nov 9, 2014, at 12:44 PM, Sourav Tarafdar
>> >> <Sourav.Tarafdar_at_weizmann.ac.il> wrote:
>> >>
>> >> Dear Francesco,
>> >> Thanks for the suggestions. I implemented your
>> >> suggestions as far as defining the
>> >> collision vertex is concerned , i.e., inclusion of
>> >> BEAM card and HI-PROPE card on
>> >> top of SPECSOUR card. Also I removed Au material
>> >> region relevant for my collision
>> >> vertex. However I got the error on my terminal which
>> >> looks like
>> >> ======================= Running FLUKA for cycle # 1
>> >> =======================
>> >> $FLUPRO/flutil/rfluka: line 359: 13280 Floating point
>> >> exception(core dumped)
>> >> "${EXE}" < "$INPN" 2> "$LOGF" > "$LOGF"
>> >> Just wondering whether I am missing something in my
>> >> input file ? My error file and
>> >> output file are completely empty.
>> >> Thanks
>> >> -Sourav
>> >> On Nov 9, 2014, at 12:28 AM, Francesco Cerutti
>> >> <Francesco.Cerutti_at_cern.ch> wrote:
>> >>
>> >> Dear Sourav,
>> >>
>> >> 1) Shall I have to define Target region of
>> >> Au material at
>> >> collision vertex
>> >> ?
>> >>
>> >> not at all (unless your collisions are supposed
>> >> to take place in gold
>> >> instead of vacuum...). You defined the second
>> >> beam species in the
>> >> SPECSOUR card, where you have also said that your
>> >> first beam is made by
>> >> HEAVYIONs. So you need a HI-PROPE card to specify
>> >> the HEAVYION nature.
>> >> And you still need a BEAM card (where you shall
>> >> put HEAVYION - making
>> >> redudant your SPECSOUR WHAT(11) setting - and an
>> >> energy per nucleon
>> >> exceeding 100 GeV/n for transport initialization
>> >> purposes).
>> >>
>> >> 2) Which scoring card should be used in
>> >> order to retrieve
>> >> kinematic
>> >> information of produced particles and
>> >> nuclear remnants
>> >> after H.I. collision
>> >> ? So far I have used ???USRYIELD??? card.
>> >>
>> >> USRYIELD does not work yet for the SPECSOUR
>> >> collision event. You can
>> >> inspect the properties of the products by
>> >> customizing the usrein.f
>> >> routine - which is automatically called before
>> >> source particles start
>> >> to be transported - in order to look at the
>> >> FLKSTK content (to this
>> >> purpose remember to add the
>> >> INCLUDE '(FLKSTK)'
>> >> statement).
>> >>
>> >> Cheers
>> >>
>> >> Francesco
>> >>
>> >> **************************************************
>> >> Francesco Cerutti
>> >> CERN-EN/STI
>> >> CH-1211 Geneva 23
>> >> Switzerland
>> >> tel. ++41 22 7678962
>> >> fax ++41 22 7668854
>> >>
>> >> On Sat, 8 Nov 2014, Sourav Tarafdar wrote:
>> >>
>> >> Dear Fluka users,
>> >> I have been trying to simulate Au+Au
>> >> collision at C.M.
>> >> energy of 200
>> >> GeV/nucleon using DPMJET3 within FLUKA
>> >> framework. For
>> >> defining the colliding
>> >> beam I used SPECSOUR card with PPSOURCE
>> >> type. I am mostly
>> >> interested in
>> >> getting the kinematic variables (px, py,
>> >> pz, energy , pid
>> >> etc) of the
>> >> particles after the collision and also the
>> >> remnants of the
>> >> nuclei after
>> >> collision. My questions are
>> >> 1) Shall I have to define Target region of
>> >> Au material at
>> >> collision vertex
>> >> ?
>> >> 2) Which scoring card should be used in
>> >> order to retrieve
>> >> kinematic
>> >> information of produced particles and
>> >> nuclear remnants
>> >> after H.I. collision
>> >> ? So far I have used ???USRYIELD??? card.
>> >> Any suggestions will be of great help.
>> >> Please find the attached input file for
>> >> FLUKA and the
>> >> output file after
>> >> executing FLUKA using the command
>> >> $FLUPRO/flutil/rfluka -e
>> >> flukadpm3 test
>> >> Any suggestions will be of great help.
>> >> Thanks
>> >> -Sourav
>> >> <fluka_dpm_wotarg.inp>
Received on Fri Nov 28 2014 - 16:35:35 CET

This archive was generated by hypermail 2.3.0 : Fri Nov 28 2014 - 16:35:36 CET