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

From: <yangt_at_ihep.ac.cn>
Date: Tue, 20 Nov 2018 01:37:59 +0800 (GMT+08:00)

Dear Andrea,
    Thanks for your help. In step 2, I use the subroutine and input file in the last email you sent me , however, I don't get the output file defined in the "endraw.f" and all elements of USRBIN output ("detector2001_fort.21") are all zero. It seems to be a problem of the user routine.
Then I check the source.f and I find that the weight of the particle specified in the source.f maybe wrong. It is as follows(Line 87):
      WEIPRI = WEIPRI + WT (ISAMPL)
I don't exactly know what the above code means.
At last I replace it by the original form as:
      WTFLK (NPFLKA) = ONEONE
      WEIPRI = WEIPRI + WTFLK (NPFLKA)
I get a non-zero output. But I have some problems that I can't handle:
1) Is the above modification correct for the weight of particle?
2) the output specified in the endraw.f only shows the α particle(ie, particle ID =-6, attachment "detector2001_endraw.dat"), but I specify both the two particles through code: "IF((JTRACK .EQ. -6) .OR. (JTRACK .EQ. -2)) THEN...". So why the Li+ information can't be written in?
3) the BEAM card should also be added though the source routine exists according to the manual. And the beam energy should be the maximum energy(P71 of manual) of particles to be transported in source routine. The BEAM card in your last email:
BEAM -2.5E-11 0.0 0.0 0.0 0.0 1.NEUTRON
which is the beam definition in step 1, and the energy 2.5E-11 GeV is obviously smaller than the energy of ion products(~MeV). I change this card as:
BEAM -2.5E-3 0.0 0.0 0.0 0.0 1.
However, the program doesn't run anymore and report a coredump error. I don't know why.
4) Is the primary number in the detector2.inp(START card) must same to the ions number generated in step 1 (ie 8587 in the simulation), and does the run cycle number must set to only ONE in the two steps?

Best regards
Yang





 
> -----原始邮件-----
> 发件人: "Andrea Fontana"
> 发送时间: 2018-11-18 00:33:06 (星期日)
> 收件人: yangt_at_ihep.ac.cn
> 抄送: "fluka-discuss_at_fluka.org"
> 主题: Re: [SPAM] Re: [fluka-discuss]: problems of two-steps method
>
> 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"
> > *抄送:* "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"
> > > 发送时间: 2018-11-13 00:30:58 (星期二)
> > > 收件人: "YANG Tao"
> > > 抄送: "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"
> > > > > 发送时间: 2018-11-10 19:35:25 (星期六)
> > > > > 收件人: "YANG Tao"
> > > > > 抄送: "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 &amp;
> > > > > > USRBIN 12. HEAVYION 22. gasbox ei
> > > > > > USRBIN gasbox &amp;
> > > > > >
> > > > > > 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 &amp; 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"
> > > > > > > 发送时间: 2018-11-09 05:28:40 (星期五)
> > > > > > > 收件人: "YANG Tao"
> > > > > > > 抄送: "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 &amp;
> > > > > > > USRBIN 12. HEAVYION 22. gasbox ei
> > > > > > > USRBIN gasbox &amp;
> > > > > > >
> > > > > > > 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&amp;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"
> > > > > > > > > 发送时间: 2018-11-06 02:45:18 (星期二)
> > > > > > > > > 收件人: "YANG Tao"
> > > > > > > > > 抄送: "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"
> > > > > > > > > > > 发送时间: 2018-11-05 00:59:05 (星期一)
> > > > > > > > > > > 收件人: "YANG Tao"
> > > > > > > > > > > 抄送: 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"
> > > > > > > > > > > > > 发送时间: 2018-11-03 18:53:56 (星期六)
> > > > > > > > > > > > > 收件人: "YANG Tao"
> > > > > > > > > > > > > 抄送: 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"
> > > > > > > > > > > > > >> 发送时间: 2018-11-02 19:16:20 (星期五)
> > > > > > > > > > > > > >> 收件人: "YANG Tao" , 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 Mon Nov 19 2018 - 20:12:48 CET

This archive was generated by hypermail 2.3.0 : Mon Nov 19 2018 - 20:12:50 CET