Dear Yang,
I think that I have found the bug in your code. In the source.f of
step
two a line of code (NPFLKA = NPFLKA+1) was inadvertently removed and this
prevented FLUKA to perform a correct run. I have also rewritten and cleaned
up your source.f file (in attachment the new version).
In addition, I have increased the statistics to 10^7 events in step one:
this
generates 8587 primaries and this is the number of events that I read in
step two. I have also improved the geometry in detector2_2.inp: instead of
RPP bodies, it is much better to use infinite shapes and the define
regions by
intersecting them: this reduces the possibility of rounding problems,
particularly when the source is exactly at the boundary between two
regions,
as in your case. So I define the regions by intersecting a cylinder
with planes. You will also find a few USRBIN cards that I have used
to debug your problem and the check the energy deposit.
I hope that this will solve your problem and that you will be able to
make progress now.
Kind regards,
Andrea
Il 16/11/2018 15:20, yangt_at_ihep.ac.cn ha scritto:
> Dear Andrea,
>
> I am sorry to bother you again. Did you receive my last email?
>
> I comment the extra "WRITE" instructions in the bdx.f file and
> finally I get no extra output file. Then I changed the beam definition
> and add a source card in the detector2.inp file as:
>
> BEAM -2.5E-3 0.0 0.0 0.0 0.0 1.
> SOURCE
> Since the secondary particles emitting from the boundary have two
> kinds of ions, I don't specify the beam particle name in the "BEAM"
> card, the default particle is proton but I think it will be overwrited
> in the "source.f" file. Is that so?
>
> Then I changed the NLINES value as "PARAMETER (NLINES = 171)".
>
>
> After I complete the steps above, I run the file
> "detector2.inp+source.f+endraw.f", I get nothing. The screen displays
> "No additional files to move.",It seems the program doesn't run
> anything. So
>
> What's wrong with the program?
>
> I try to solve the problems recent days, but unfortunately these
> efforts are ultimately unsuccessful. So I beg for your help.
>
> best regards
>
> Yang.
>
>
>
>
> -----原始邮件-----
> *发件人:*yangt_at_ihep.ac.cn
> *发送时间:*2018-11-13 15:40:05 (星期二)
> *收件人:* "andrea fontana" <andrea.fontana_at_pv.infn.it>
> *抄送:* "fluka-discuss_at_fluka.org" <fluka-discuss_at_fluka.org>
> *主题:* Re: Re: [SPAM] Re: [fluka-discuss]: problems of two-steps
> method
>
> Dear Andrea,
>
> Thanks for your suggestions. I comment the extra "WRITE"
> instructions in the bdx.f file and finally I get no extra output
> file. Then I changed the beam definition and add a source card in
> the detector2.inp file as:
>
> BEAM -2.5E-3 0.0 0.0 0.0 0.0 1.
> SOURCE
> Since the secondary particles emitting from the boundary have two
> kinds of ions, I don't specify the beam particle name in the
> "BEAM" card, the default particle is proton but I think it will be
> overwrited in the "source.f" file. Is that so?
>
> Then I changed the NLINES value as "PARAMETER (NLINES = 171)".
>
>
> After I complete the steps above, I run the file
> "detector2.inp+source.f+endraw.f", I get nothing. The screen
> displays "No additional files to move.",It seems the program
> doesn't run anything. So
>
> What's wrong with the program?
>
>
> best regards
>
> Yang.
>
>
>
>
>
> > -----原始邮件-----
> > 发件人: "Andrea Fontana" <andrea.fontana_at_pv.infn.it>
> > 发送时间: 2018-11-13 00:30:58 (星期二)
> > 收件人: "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,
> >
> > 1) in step 1, I see that in the bdx.f file you keep WRITE instructions
> > in all the entry points of MGDRAW: if you remove them and only
> > have write instructions in the BXDRAW entry point, the _MGDRAW file
> > will not be written;
> >
> > 2,3) in step 2, I understand that you want to record energy from the
> > secondary electrons generated by the alphas and Li ions. I have
> > looked, for example, at your input spectrum for alphas and the energy
> > is below 2 MeV: in this case the maximum energy of the produced
> > electron is far below 1 keV, which is the minimum production and
> > transport threshold for electrons in Fluka. See also this discussion:
> > http://www.fluka.org/web_archive/earchive/new-fluka-discuss/10194.html
> >
> > Moreover you are running with the production and transport thresholds
> > of PRECISION defaults (i.e. 100 keV) and there is no way that you
> > see electrons from ionization at this low energy of alphas. You can
> > reduce the thresholds with the EMFCUT cards down to 1 keV, but you
> > are hitting a physical limit here. See also this thread (you might
> > know it already):
> > http://www.fluka.org/web_archive/earchive/new-fluka-discuss/10034.html
> >
> > 4) in the first case, without the SOURCE card, the external source from
> > the user routine is not activated and you generated a beam
> > of neutrons... ignoring the output file generated at step 1.
> > When you correctly include it, you still have an error since NLINES
> > is set to 10000, but the input file only has 171 lines. In the
> > random sampling from the input array, you exceed this value for
> > the index and this generates primaries with ID=0 and energy=0!
> > You can check this with SODRAW in MGDRAW, if you wish.
> >
> > Kind regards,
> > Andrea
> >
> >
> >
> > Il 11/11/2018 04:17, YANG Tao ha scritto:
> > >
> > > Dear Andrea,
> > >
> > > Thanks for your patient reply. I ran the input and subroutine file as you suggested, the program works and generates the output file. However, I still have some doubts about the output data:
> > >
> > > 1)
> > > I ran the file "detector.inp+bdx.f" in the 1st step , but the program still generates the extra file "detector001_MGDRAW" (see attachment) even I remove both unit and filename from the USERDUMP card.
> > > Although it is not a serious problem if the primary number is not very big, it may cause some problems if I set the primar number very big to reduce the statistical error.
> > >
> > > 2)
> > > I ran the file "detector2.inp+endraw.f+ source.f" in the 2nd step. As shown in file "detector001_fort.81", I get 171 ions entering the work gas region (67 α +104 Li+), which corresponds to a detection
>
> > >
> > > efficiency of 0.085% and it is reasonable. However, after I count the energy deposition event in the file "detector2001_endraw.dat", I find that the number of energy deposition event is only 101(α: 26, Li+：75),
>
> > >
> > > which is lower than the number of ions entering
> > > the work gas. As shown in figure "detector.BMP", an entire ion trajectory should generates many ionization events and the following energy deposition, so the number of energy deposition events should
>
> > >
> > > be much larger than that the number of ions entering the work gas, I can't understand why the former number is lower than the later one and why one trajectory only has one energy depositon event.
>
> > > Maybe I have some misunderstandings of the output,could you explain it?
> > >
> > > 3)
> > > when I sum the energy deposition value of file "detector2001_endraw.dat", the total energy depositon is 0.01545 GeV, then I divide it by the primary number(ie, 200,000 neutrons), I get the
> > > energy depostion per primary equal to 0.01545/200,000=7.725E-8 GeV/primary. Then I check the result by running the file "onestep.inp"(counting the total energy depositon in the work gas region in one step )
> > > , I get the response is about 8.1701E-7 GeV/primary (both of the two calculation is run in one cycle). The two response values per primary have obvious disagreement, I can't judge what happens.
>
> > >
> > >
> > > 4)
> > > The last but not the least, after I finish the calculation I find that I forget
>
> > > to add the "SOURCE" card in the file "detector2.inp"(it is my fault), which implies the source routine won't be actived according to the
>
> > >
> > > description of the manual(p360), so I add the "SOURCE" card in the input file(attachment detector2_2.inp), and change the BEAM card. Unfortunately, the program get nothing even a
>
> > > empty dump file("detector2001_endraw.dat")
> > > is not generated! I only add a source card, why does this happen? If I remove the source card, whether the program active the source routine "source.f"
>
> > > or not? I am very puzzled.
> > >
> > > Thanks again and I look forward to discuss with you.
> > >
> > > best regards
> > >
> > > Yang.
> > >
> > >
> > >
> > >
> > >
> > > > -----原始邮件-----
> > > > 发件人: "Andrea Fontana" <andrea.fontana_at_pv.infn.it>
> > > > 发送时间: 2018-11-10 19:35:25 (星期六)
> > > > 收件人: "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,
> > > > I see what you are trying to do and I can give you these further
> > > > suggestions:
> > > >
> > > > 1) simply remove both unit and filename from the USERDUMP card and this
> > > > extra file should disappear;
> > > >
> > > > 2) There is another possibility, since you can access the same
> > > > information
> > > > from the TRACKR common block (see also chapter 11 in the manual and
> > > > in particular the example given with the function MGREAD at pag. 342).
> > > >
> > > > I send you a modified version of the detector2.inp and of endraw.f
> > > > files: in the output now, for each energy deposition, you will
> > > > find the energy deposition position and value.
> > > >
> > > > Kind regards,
> > > > Andrea
> > > >
> > > >
> > > > Il 09/11/2018 17:46, YANG Tao ha scritto:
> > > > >
> > > > >
> > > > > Dear Andrea,
> > > > >
> > > > > Thanks for your suggestions.unfortunately, the problems remain unsolved.
> > > > >
> > > > > *1) I set the USERDUMP as:*
> > > > > * ..+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
> > > > > USERDUMP 100. 0. 1. try
> > > > > i.e., WHAT(3)=0 , but the results still have an extra file with size of ~20 MB(name:"detector001_try").In other words the previous extra file described named " "detector001_fort.18" disappears, but the new extra file generates,
>
> > >
> > > > > which has a bigger size. It's rather strange.
> > > > >
> > > > > *2) What I want to obtain is the energy deposition
> > > > > _position_ and energy deposition
> > > > > _value_ in the work gas region. Your suggested card:*
> > > > >
> > > > > USRBIN 12. 4-HELIUM 21. gasbox ea
> > > > > USRBIN gasbox &
> > > > > USRBIN 12. HEAVYION 22. gasbox ei
> > > > > USRBIN gasbox &
> > > > >
> > > > > What(2) of the USRBIN card is the
> > > > > particle name, thus we could only obtain the particle track-length in "gasbox". I can't even get the energy deposition value, and so on the energy deposition position. The output of One of the USRBIN card as:
> > > > > accurate deposition along the tracks requested
> > > > > this is a track-length binning
> > > > > 2.9940E-04
> > > > >
> > > > >
> > > > > So I think the two-steps method is necessary if I want to obtain the
> > > > > energy deposition position & value.
> > > > >
> > > > >
> > > > > I have been puzzled by the problem and tried to solve the problem for
> > > > > one whole week, now with your help, I think I approximate to work it
> > > > > out except one or two hard problems. Could you give me a further
> > > > > suggestions based on the attached files in the last email?
> > > > >
> > > > > Thanks again for your kind help and I look forward for your reply.
> > > > >
> > > > > Best regards!
> > > > >
> > > > > Yang
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > -----原始邮件-----
> > > > > > 发件人: "Andrea Fontana" <andrea.fontana_at_pv.infn.it>
> > > > > > 发送时间: 2018-11-09 05:28:40 (星期五)
> > > > > > 收件人: "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,
> > > > > > 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
> > > > > > ========================================================================
> > > > >
> > > >
> > > > --
> > > > ========================================================================
> > > > 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
========================================================================
__________________________________________________________________________
You can manage unsubscription from this mailing list at
https://www.fluka.org/fluka.php?id=acc_info
Received on Sat Nov 17 2018 - 19:25:10 CET