Re: [SPAM] Re: [fluka-discuss]: problems of two-steps method

From: Andrea Fontana <andrea.fontana_at_pv.infn.it>
Date: Thu, 8 Nov 2018 22:28:40 +0100

Dear Yang,
     I have checked your .inp and user routines and I have found the
following:

1) the .18 file is an auxiliary file written by Fluka when your request
    WHAT(3)=6 (i.e. trajectories and losses) in the USERDUMP card.
    If you simply request WHAT(3)=0 no extra files are generated and the
    user  output defined in MGDRAW does not change: unit 81 is the same.

2) in the second step, it seems to me that you are over-complicating
    the problem. If you want energy deposited by alpha and heavy ions
    in region "gasbox", why do not you use a simpler region based USRBIN?
    The use of the variable RULL in ENDRAW is not easy and not even
    encouraged - see for example this discussion:
http://www.fluka.org/web_archive/earchive/new-fluka-discuss/9938.html

    You can try this, for example:

    USRBIN           12.  4-HELIUM       21. gasbox                    ea
    USRBIN gasbox                                                   &
    USRBIN           12.  HEAVYION       22. gasbox                    ei
    USRBIN gasbox                                                   &

   In this way the correct tracking algorithm will take care of the
   energy deposition along the track. This would be a much better way
   to score the energy deposited by alpha and Li ions in your problem.

Hope this helps,
Andrea

Il 06/11/2018 17:22, YANG Tao ha scritto:
>
> Dear Andrea,
>
> Thanks for your patient reply. I am sorry to forget to add the
> attachments in the last email. I changed the subroutine as you
> suggest, and it runs successfully. However, there are some puzzled
> problems as follows:
>
>
> 1) in the 1st step, I run detector.inp+bdx.f to obtain the secondary
> ions information at the boundary. I set the work gas region as
> blackhole to avoid the backscattering. File "detector001_fort.81" is
> the result, it shows the reaction yield  171 α or Li+ ions crossing
> the boundary, which is reasonable(i.e., detection efficiency~0.8%)
> compared to my previous research or other program,e.g. Geant4; But
> this step also generates an attached file "detector001_fort.18", which
> has size~10MB, but I never define this output unit either in the *.inp
> file or *.f file, so where is it from. Since I set the primary number
> is 20,000, the size is 10MB, In actual ruuning,primary     number is
> very big and the file size will be too huge to accept.
>
>
> 2) in the second step, I run detector2.inp+ eedraw.f+source.f to
> obtain the energy deposition information. I reset the work gasregion
> as ICGAS. The program works, but I think it is not correct. attachment
> "detector2001_endraw.dat" is the result, maybe there are three problems:
>
>     i) the last column is the energy deposition values which are all
> zero, I set sufficient precision to show the decimal. as is known,
> ions has strong ionization power, and we also regard the ions'
> transmission probability at the converter-gas boundary as the
> detection efficiency, which implies that every ion enters the work gas
>         region must deposit some energy in it (probability~1). I use
> the variable "RULL" to record the energy deposition value as the 
> manual says" RULL : energy amount deposited" in page 356;
>
>     ii) the recorded ionizing event number in step 2 only has 87 (in
> my simulation, may be a little different depending on a different 
> initial random number), which is rather small and obvious wrong. As is
> known, there are many ionizing events along a ion trajectory in some
> medium, so the ionizing event number should be >> ion         numbers
> crossing the boundary(i.e. 171 shownin the 1st step).
>
>     iii) Besides, I don't know when  ions penetrate a medium,
>   whether the energy loss process is continuous or discrete? I think
> it has both process for ions but only discrete process for γ and
> neutrons. I don't know whether the entire method is reasonable for
> determining the energy deposition position&value.  I think it is
> meaningful to record for discrete energy loss process such as γ or
> neutron interaction,  however,  if the continuousprocess is
> predominant, which implies every point along the trajectory has energy
> deposition, thus whether calculating the energy deposition position
> has meanings?
>
> Thanks again and I look forward your reply.
>
> Best regards
>
> Yang.
>
>
>
>
>
>
>
> > -----原始邮件-----
> > 发件人: "Andrea Fontana" <andrea.fontana_at_pv.infn.it>
> > 发送时间: 2018-11-06 02:45:18 (星期二)
> > 收件人: "YANG Tao" <yangt_at_ihep.ac.cn>
> > 抄送: "fluka-discuss_at_fluka.org" <fluka-discuss_at_fluka.org>
> > 主题: Re: [SPAM] Re: [fluka-discuss]: problems of two-steps method
> >
> > Dear Yang,
> >     it is indeed a rather complex and interesting problem!
> >
> > 1)
> > I could run and fix step 1: the problem is that region names are
> > FORTRAN strings up to 8 characters, but you have defined them as
> > 20 characters and there is garbage at the end of the region names.
> > Simply define the names as:
> >
> >        CHARACTER*8 MRGNAM, NRGNAM
> >
> > Moreover, if you open a file with the OPEN statement in bdx.f
> > (unit=81), do not put any unit number in the USERDUMP card.
> >
> > 2)
> > In principle in ENDRAW you should be able to select for which
> > particles you record the energy by using JTRACK, as you do
> > in BXDRAW.
> >
> > Please try this and let me know!
> >
> > Best,
> > Andrea
> >
> > PS
> > Please, keep the messages in the list: your example could be of interest
> > for other users that could contribute to the discussion.
> >
> >
> > Il 05/11/2018 13:01, YANG Tao ha scritto:
> > >
> > > *Dear **Andrea, *
> > >
> > > ***    Thanks for your reply.**Indeed I want to research the thermal
> > > neutron detector using the two-steps method, and I almost understand
> > > the method through the former example. As shown in the figure of
> > > attachments (detector.bmp) , the neutron detector are based on B4C
> > > neutron converter, and the secondary ions enter the work gas(Ar+CO2)
> > > after the reaction B(n,α)Li. Finally I want to score the energy
> > > deposition position and energy deposition value of the secondary ions
> > > along the whole trajectory. **The B4C layer has a thickness of 1μm,
> > > and the simulated efficiency is about 0.1%,   if using the one-step
> > > method, it may generate huge data files, so the two-steps method is
> > > necessary. *
> > > *        My simulation procedure is as follows:*
> > >
> > > *i) In the 1st step, score the secondary ions' position, energy,
> > > direction, weight etc at the converter-gas boundary using
> > > magdraw(BXDRAW) (attachment bdx.f);*
> > >
> > > *ii) In the 2nd step, read the output of the 1st step **as the
> > > source.(attachment source.f);*
> > >
> > > *iii) **score the energy deposition point**and energy deposition value
> > > for each secondary **α or Li+ along one whole trajectory in the work
> > > gas.(attachment ENDRAW.f)*
> > >
> > > *Due to the convection efficiency of **B(n,α)Li**, the data stored in
> > > the output of the 1st step can be rather small, and thus the following
> > > simulation can be carried out.*
> > >
> > > *since I never handle three user routines in one simulation, which
> > > involves the code calling to each other, so the simulation maybe a
> > > hard work to me. *
> > >
> > > *    However,  there are some problems:*
> > >
> > > *1) I encounter a problem in the 1st step, in **the bdx.f, I use
> > > region name rather than number to define the boundary, but the code
> > > can't work. However, code using the region number works.*
> > >
> > > *2) Can I obtain the energy deposition from the secondary ions?
> > > According to my former research, I always obtain the energy deposition
> > > resulting from the electrons in the mixed radiation field. If I want to *
> > >
> > > *   obtain the energy deposition along the ion trajectory, i.e.,
> > > energy deposition resulting from ion incident, is mgdraw ENDRAW
> > > sufficient to finish the work?***
> > >
> > > *3) Due to the 1st step is not finished(region name does't work in the
> > > mgdraw), I don't know whether the other subroutine is correct or not,
> > > could you point out the possible mistakes?*
> > >
> > > *Best regards!*
> > >
> > > *Yang*
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > > -----原始邮件-----
> > > > 发件人: "Andrea Fontana" <andrea.fontana_at_pv.infn.it>
> > > > 发送时间: 2018-11-05 00:59:05 (星期一)
> > > > 收件人: "YANG Tao" <yangt_at_ihep.ac.cn>
> > > > 抄送: fluka-discuss_at_fluka.org
> > > > 主题: [SPAM] Re: [fluka-discuss]: problems of two-steps method
> > > >
> > > > Dear Yang,
> > > >      the 20 in the DO loop instruction refers to line 181 that you
> > > > find at the end of the source.f the file:
> > > >
> > > >   20   CONTINUE
> > > >
> > > > and it is not the number of repetitions in the loop (this is NLINES,
> > > > equal to 10000 in your case). All the lines between the DO and
> > > > the CONTINUE are repeated NLINES times: therefore, for each event,
> > > > FLUKA will load 10000 primary particles in the stack at once
> > > > and track them as a single huge event. This cannot work and it
> > > > is likely to break the stack size (i.e. the memory that Fluka
> > > > allocates). You can try to run your code, which technically compiles,
> > > > but you will see  that the run will give you errors.
> > > >
> > > > The correct way to work with Fluka, is to sample one particle per event
> > > >   from the arrays that you fill at the initialization step
> > > > in source.f: the SOURCE function is called for each primary (you
> > > > should replace the 1 with 10000 for example in the START card in
> > > > 2.inp) and, at each call, a SINGLE primary particle is loaded in
> > > > the stack and tracked by Fluka, with all the secondaries.
> > > >
> > > > Moreover, also take into account that Fluka will give you results
> > > > normalized per primary, which is the number you indicate in the START
> > > > card.
> > > >
> > > > Hope this helps! You can find more information in the lecture on
> > > > user's routines given at the Fluka courses, for example at:
> > > >
> > > > https://indico.cern.ch/event/334606/contributions/779780/attachments/653355/898394/AdvancedUserRoutines2014.pdf
> > > >
> > > > Kind regards,
> > > > Andrea
> > > >
> > > >
> > > > Il 04/11/2018 16:43, YANG Tao ha scritto:
> > > > > Dear Andrea,
> > > > >    Thanks for your patient explanation, in fact, the example in the last emails are the one from others, I copied from the internet and wanted to study the two-steps method. Now I almost understand the procedure,
> > >
> > > > > except the second loop of the source.f file in the last email.
> > > > > I copy it as follows:
> > > > >       DO 20,  I = 1, NLINES
> > > > >       NPFLKA = NPFLKA + 1
> > > > >
> > > > > you changed it as:
> > > > >
> > > > >       ISAMPL = FLRNDM (DUMMY) * NLINES
> > > > >
> > > > >       ISAMPL = ISAMPL + 1
> > > > >
> > > > >
> > > > > indeed, I understand your code, does it mean we will sample the
> > > > > particle from the phase space file of the 1.f+1.inp output? Is the
> > > > > primary number defined in the 2.inp file("ie, START card")?
> > > > >
> > > > > Since the original code of the problem is not written by me, so I
> > > > > don't completely understand what the second loop means. I guess it
> > > > > reads all of the array elements from the 1st step output and repeats
> > > > > 20 times. I think this method is also correct, so what is the concrete
> > >
> > > > > mistake of this sampling method?
> > > > >
> > > > > Thanks again!
> > > > >
> > > > > Best regards
> > > > >
> > > > > Yang
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > -----原始邮件-----
> > > > > > 发件人: "Andrea Fontana" <andrea.fontana_at_pv.infn.it>
> > > > > > 发送时间: 2018-11-03 18:53:56 (星期六)
> > > > > > 收件人: "YANG Tao" <yangt_at_ihep.ac.cn>
> > > > > > 抄送: fluka-discuss_at_fluka.org
> > > > > > 主题: Re: [fluka-discuss]: problems of two-steps method
> > > > > >
> > > > > > Dear Yang,
> > > > > >     I had a better look and I see the reason of this geometry errors:
> > > > > > it is the READ format string that I have used in source.f (my fault),
> > > > > > which is different from the one you used in the WRITE statement at
> > > > > > step one. This is easy to fix.
> > > > > >
> > > > > > But, I see another error still in source.f: you read the file in the
> > > > > > inizialization step with a loop and this is fine. But then, you have
> > > > > > a second loop on all the file lines at each function call: you
> > > > > > should instead random sample from the arrays that you have already
> > > > > > stored in memory, one particle at each call. So I removed the
> > > > > > second loop and added a sampling instruction on the array index
> > > > > > (variable I becomes ISAMPL). See also this previous thread on
> > > > > > this problem:
> > > > > >
> > > > > > file:///C:/Users/Andrea/Desktop/Ricerca/Fluka/fluka-discuss_20180209/fluka-discuss/www.fluka.org/web_archive/earchive/new-fluka-discuss/8944.html
> > > > > >
> > > > > > I send you a corrected version of source.f.
> > > > > >
> > > > > > Your code should run now, but looking further at the .inp file
> > > > > > I see that you request radioactive decay, but only define IRRPROFI
> > > > > > without DCYTIMES and DCYSCORE cards: in this case I expect that you
> > > > > > will only record the prompt particles. But we can see this later...
> > > > > >
> > > > > > Please let me know,
> > > > > >
> > > > > > Kind regards,
> > > > > > Andrea
> > > > > >
> > > > > > Il 03/11/2018 04:15, YANG Tao ha scritto:
> > > > > > > Dear Andrea,
> > > > > > >      Thanks for your reply. I ran it as your suggestions,  unfortunately, it has some errors " STOP  TOO MANY ERRORS IN GEOMETRY: STOP", but I see no geometry errors in FLAIR, so I am very puzzled with the error, the geometry is not complex, so where are errors from?
> > > > > > > Thanks again.
> > > > > > > Best regards
> > > > > > > Yang
> > > > > > >> -----原始邮件-----
> > > > > > >> 发件人: "Andrea Fontana" <andrea.fontana_at_pv.infn.it>
> > > > > > >> 发送时间: 2018-11-02 19:16:20 (星期五)
> > > > > > >> 收件人: "YANG Tao" <yangt_at_ihep.ac.cn>, fluka-discuss_at_fluka.org
> > > > > > >> 抄送:
> > > > > > >> 主题: Re: [fluka-discuss]: problems of two-steps method
> > > > > > >>
> > > > > > >> Dear Yang,
> > > > > > >>       I ran your example and I have found a couple of FORTRAN errors
> > > > > > >> in the file I/O instructions:
> > > > > > >>
> > > > > > >> - in file 1.f in the OPEN instruction, you have put 'NEW' as status,
> > > > > > >>     but this will create a new file for each WRITE statement (the
> > > > > > >>     function is called at *each* boundary crossing): simply write
> > > > > > >>     'UNKNOWN' or do not specify the status.
> > > > > > >>     With this correction, at step 1 you write the Data1.dat file
> > > > > > >>     (named 1001_Data1.dat with Fluka naming conventions).
> > > > > > >>
> > > > > > >> - in file source.f, the problem is due to the fact that UNIT=88
> > > > > > >>     should be opened in the 2.inp file with the Fluka card OPEN
> > > > > > >>     and not directly in the FORTRAN code.
> > > > > > >>     Moreover, you read 20000 lines, but your file has only 10000:
> > > > > > >>     therefore you hit the end of file and this generates the EOF error.
> > > > > > >>     To be on the safe side, I have put a protection in the READ
> > > > > > >>     statement as:
> > > > > > >>
> > > > > > >>           READ (88,102,END=101)
> > > > > > >>     ......
> > > > > > >>     101 CONTINUE
> > > > > > >>
> > > > > > >>     so that the code knows how to handle this situation.
> > > > > > >>     At this point, step 2 also works, but the I have seen tracking
> > > > > > >>     errors, seemingly due to geometry problems...
> > > > > > >>
> > > > > > >> I leave it to you now, but I am available for further interactions
> > > > > > >> if needed.
> > > > > > >>
> > > > > > >> In attachment, a revised version of your files.
> > > > > > >>
> > > > > > >> Kind regards,
> > > > > > >> Andrea
> > > > > > >>
> > > > > > >> Il 02/11/2018 08:16, YANG Tao ha scritto:
> > > > > > >>> Hi, everyone!
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> Recently, I simulate  using so called two-steps method to simulate the
> > > > > > >>> activation problem. File 1.input and 1.f use FLUSCW.F +USRBDX to
> > > > > > >>> calculate the generated particles, and 2.f use the 1st step results as
> > > > > > >>> the source. But when I run the 2nd step, I get an error(seen in
> > > > > > >>> 2.log), "At line 73 of file source.f (unit = 88, file = '../try.dat')
> > > > > > >>> Fortran runtime error: End of file", I try many ways but cannot solve
> > > > > > >>> it. could anyone give a suggestion, any suggestion is appreciate!
> > > > > > >>>
> > > > > > >>> Best regards!
> > > > > > >>>
> > > > > > >>> Yang
> > > > > > >>>
> > > > > > >> --
> > > > > > >> ========================================================================
> > > > > > >> Dr. Andrea Fontana                    tel: +39 0382 987991
> > > > > > >> Istituto Nazionale                    fax: +39 0382 423241
> > > > > > >> di Fisica Nucleare
> > > > > > >> Sezione di Pavia                      e-mail: andrea.fontana_at_pv.infn.it
> > > > > > >> Via Bassi 6                           web   : www.pv.infn.it/~fontana
> > > > > > >> 27100 PAVIA, Italy
> > > > > > >> ========================================================================
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > ========================================================================
> > > > > > Dr. Andrea Fontana                    tel: +39 0382 987991
> > > > > > Istituto Nazionale                    fax: +39 0382 423241
> > > > > > di Fisica Nucleare
> > > > > > Sezione di Pavia                      e-mail: andrea.fontana_at_pv.infn.it
> > > > > > Via Bassi 6                           web   : www.pv.infn.it/~fontana
> > > > > > 27100 PAVIA, Italy
> > > > > > ========================================================================
> > > > > >
> > > > >
> > > > >
> > >
> > > >
> > > > --
> > > > ========================================================================
> > > > Dr. Andrea Fontana                    tel: +39 0382 987991
> > > > Istituto Nazionale                    fax: +39 0382 423241
> > > > di Fisica Nucleare
> > > > Sezione di Pavia                      e-mail: andrea.fontana_at_pv.infn.it
> > > > Via Bassi 6                           web   : www.pv.infn.it/~fontana
> > > > 27100 PAVIA, Italy
> > > > ========================================================================
> > > >
> > > > __________________________________________________________________________
> > > > You can manage unsubscription from this mailing list at https://www.fluka.org/fluka.php?id=acc_info
> > >
> > >
> > >
> >
> > --
> > ========================================================================
> > Dr. Andrea Fontana                    tel: +39 0382 987991
> > Istituto Nazionale                    fax: +39 0382 423241
> > di Fisica Nucleare
> > Sezione di Pavia                      e-mail: andrea.fontana_at_pv.infn.it
> > Via Bassi 6                           web   : www.pv.infn.it/~fontana
> > 27100 PAVIA, Italy
> > ========================================================================
>

-- 
========================================================================
Dr. Andrea Fontana                    tel: +39 0382 987991
Istituto Nazionale                    fax: +39 0382 423241
di Fisica Nucleare
Sezione di Pavia                      e-mail: andrea.fontana_at_pv.infn.it
Via Bassi 6                           web   : www.pv.infn.it/~fontana
27100 PAVIA, Italy
========================================================================
__________________________________________________________________________
You can manage unsubscription from this mailing list at https://www.fluka.org/fluka.php?id=acc_info
Received on Thu Nov 08 2018 - 23:59:45 CET

This archive was generated by hypermail 2.3.0 : Thu Nov 08 2018 - 23:59:55 CET