Dear Guang,
a) those settings depend on your geometry and magnetic field. The logics
is explained in the mentioned lecture, slides 34-37.
1 deg for alpha is by far too small (asking for excessive precision) and
is anyway overridden by Smin=1mm, which may be too large in your case.
Also the epsilon parameter is relevant and has to be suitably small in the
concerned regions.
Of course - apart from that - the geometry definition must not contain
errors.
b) for a looping ~MeV electron, 1s means 300,000 km, which indeed is a
not so effective termination condition (it takes quite a bit of tracking
time...).
On the other hand, 10ns are 3m.
In principle the cutoff time, applied to electrons only, should still
allow not looping electrons to go through your geometry.
Best
Francesco
**************************************************
Francesco Cerutti
CERN-EN/STI
CH-1211 Geneva 23
Switzerland
tel. ++41 22 7678962
fax ++41 22 7668854
On Thu, 15 Dec 2016, Guang Zhao wrote:
> Dear Cerutti,
> Thank you very much for your helpful advice. I still have the following two questions addressing to this problem:
> a) As for the MGNFIELD and STEPSIZE parameters, is there a systematic way to optimize them for my problem? I have checked the particles that lead to infinite loop, they are indeed soft electrons (< 5 MeV) transported in the vacuum. The minimum geometry dimension is about 2 cm and I have set the 1) Smin to 0.1 cm/0.2 cm, 2) alpha to 1 deg/30 deg. But it does not work as there are always some events be transported infinitely.
> b) As for the time-cut card, according to the manual, what (1) of time-cut means transport time cutoff (ns) and what (2) means transport time cutoff delay (ns). How do I set the cutoff threshold? I thought if I set the cutoff to a very large value, say 1s, it will solve my problem. But the fact is not so. The cutoff does not work unless it is set to about 10 ns instead of 1s. In your previous email, you said that the cutoff is the physical time instead of cpu time. My question is how to determine the optimal physical time threshold in my case? (10 ns is kind of arbitrary in my last try)
>
>
> Best regards,
> Guang
>
> ÔÚ 2016/12/14 ÏÂÎç10:17£¬¡°Francesco Cerutti¡±<owner-fluka-discuss_at_mi.infn.it ´ú±í Francesco.Cerutti_at_cern.ch> дÈë:
>
>
> Dear Guang,
>
> in case such an infinite loop is a real physical effect trapping low
> energy electrons in magnetic vacuum
> (rather than a precision issue related for instance to missing
> identification of a boundary with a material region, due to not optimized
> setting of MGNFIELD and STEPSIZE parameters, see
> https://indico.cern.ch/event/540415/contributions/2194782/attachments/1285
> 756/1912269/14_Ionization_and_Transport_2015.pdf),
> you can use the TIME-CUT card, allowing you to discard given types of
> particles after a desired *physical* (not CPU) time since their creation.
>
> Best regards
>
> Francesco
>
> **************************************************
> Francesco Cerutti
> CERN-EN/STI
> CH-1211 Geneva 23
> Switzerland
> tel. ++41 22 7678962
> fax ++41 22 7668854
>
> On Wed, 14 Dec 2016, Guang Zhao wrote:
>
> > Dear Cerutti,
> > Thank you very much for your advice. Now I am able to use the random
> file to re-produce the events. About the program abortion, it is actually
> not aborted. It is stuck due to some infinite loops. The reason is the
> magnetic field, which leads to very soft electrons tracking infinitely.
> >
> >
> >
> > Regards,
> > Guang
> >
> >
> > -----ÓʼþÔ¼þ-----
> > ·¢¼þÈË: owner-fluka-discuss_at_mi.infn.it
> [mailto:owner-fluka-discuss_at_mi.infn.it] ´ú±í Francesco Cerutti
> > ·¢ËÍʱ¼ä: 2016Äê12ÔÂ13ÈÕ 19:34
> > ÊÕ¼þÈË: Guang Zhao <zhaog_at_ihep.ac.cn>
> > ³ËÍ: FLUKA discussion <fluka-discuss_at_fluka.org>
> > Ö÷Ìâ: Re: [fluka-discuss]: How to use random seeds to reproduce a
> certain event?
> >
> >
> > Dear Guang,
> >
> > I do not see in the error file content you pasted any message relevant
> to the abort reason. So please make available in attachment your input
> file (and any other file you may need to run) as well as the mentioned
> ran* file in the fluka_XXXX temporary folder.
> > In order to directly reproduce your case, one has to put that ran*00N
> file in the directory where FLUKA is launched and to restart the run with
> cycle #N (being (N-1) the previous cycle to specify in the run command).
> >
> > Cheers
> >
> > Francesco
> >
> > **************************************************
> > Francesco Cerutti
> > CERN-EN/STI
> > CH-1211 Geneva 23
> > Switzerland
> > tel. ++41 22 7678962
> > fax ++41 22 7668854
> >
> > On Tue, 13 Dec 2016, Guang Zhao wrote:
> >
> >>
> >> Dear fluka experts and users,
> >>
> >>
> >>
> >> I am running fluka code and the program dies for some particular
> >> events. I have 5 runs and each run has 2000 events. Now I have the 4th
> >> .err file in the fluka_XXXX temporary folder contains the following
> information:
> >>
> >>
> >>
> >> ----------------------------------------------------------------------
> >> -----
> >> ----------------------------------------------------------------------
> >> -----
> >> ------------------------------------------------------------------
> >>
> >> NEXT SEEDS:1057C2CE 1 0 0 0 0 64
> >> 3039 0 0
> >>
> >> 1 1999 1999
> >> 1.5625000E-02 1.0000000E+30 0
> >>
> >> NEXT SEEDS:1057FD65 1 0 0 0 0 64
> >> 3039 0 0
> >>
> >> 2 1998 1998
> >> 4.6875000E-02 1.0000000E+30 9
> >>
> >> NEXT SEEDS:105D786C 1 0 0 0 0 64
> >> 3039 0 0
> >>
> >> 3 1997 1997
> >> 6.2500000E-02 1.0000000E+30 17
> >>
> >> NEXT SEEDS:1064821F 1 0 0 0 0 64
> >> 3039 0 0
> >>
> >> 4 1996 1996
> >> 4.6875000E-02 1.0000000E+30 17
> >>
> >> ¡¡¡.
> >>
> >> NEXT SEEDS:1113E2B8 1 0 0 0 0 64
> >> 3039 0 0
> >>
> >> 61 1939 1939
> >> 4.5850410E-02 1.0000000E+30 227
> >>
> >> NEXT SEEDS:1116F663 1 0 0 0 0 64
> >> 3039 0 0
> >>
> >> ----------------------------------------------------------------------
> >> -----
> >> ----------------------------------------------------------------------
> >> -----
> >> ------------------------------------------------------------------
> >>
> >>
> >>
> >> It is dead after the 61st event. And the ran* file contains these:
> >>
> >>
> >>
> >> ----------------------------------------------------------------------
> >> -----
> >> ----------------------------------------------------------------------
> >> -----
> >> ------------------------------------------------------------------
> >>
> >>
> >>
> >> 1116F663 1 64 3039B66B05FC
> >>
> >> 47 79415E9C83FDBB766
> >>
> >> 8F8590F13FEB1D75A799DE483FEAD21F373A1A6E3FD555E6C540927A3FDD3235
> >>
> >> 995F3EB3FE929A3 6F0EAF73FE3C2994DAE9F8C3FD29CB36D8DA0013FE6F647
> >>
> >> F6B68B373FE4B63F422CD4063FE927CC664E66AA3FE808307DC826C13FE8D97A
> >>
> >> 5B8999C43FD8EB9EE9898DC43FC5D52B79E65ED03FC683F3BB4A7C5B3FEC6D21
> >>
> >> FF0F94F43FDE65BE 6333D9D3FE3F3D014DFD1443FE82A9E49540E3B3FEE0FE4
> >>
> >> BAFDA503FA7E58A3EBD1E0D3FED84CBC8A9E6983FE7488F85CCDF743FE1D10C
> >>
> >> D833F7173FEABDA52FC528E23FDFA3F23991DAF93FEBB3EA2B8B5BE93FE35BDC
> >>
> >> BA8FF20A3FDE04B2C4FD56E23FDB7BC5121C06583FB3AFB1875F83D13FEA0FC4
> >>
> >> 8DE6B7283FE570D4 DAF7B023FE94601DC91CBF43FE9BC4D8BF551743FE6F890
> >>
> >> D6EFEC5C3FC1EFDDA4A4BEC43FCD35AF56713B263FE20852 A46C5043FD1B2C2
> >>
> >> 54C35B603FEA0C62F7F127783FD7BD744A0C20163FDCE662418152D83FD6F945
> >>
> >> D1075F973FE6377CBDB94A423FDD32013FA73DB63FDF2AAF88EF088F3FE9C00F
> >>
> >> C9FD83843FEB377DEA96DBBC3FDFC67B3C1D40FA3FDA59B25E46EBB43FED16B8
> >>
> >> 78BB65E33FECBFAA2D9E39343FCAB11178C564DC3FDAEE18EBBCFE6C3FDEA75A
> >>
> >> 514EC9A93FE140DC595384923FD269162B9869C73FE7153EC145E0CE3FD070A4
> >>
> >> C4C94E563FD37511860E29EE3FE105517E3755DA3FE139EFF889B7483FD9C9DF
> >>
> >> D006218A3FD9AAA7C234DD003FD7A14E63A519003F85027CC1DD1FD43FCED3C5
> >>
> >> 5BC678AA3FE7193B558552E23FDA6998AC830B803F7CA11DE1CB49043FCB80BB
> >>
> >> FDF383E43FD3759ABB74399B3FEA665DB5B1C4E03FAF4C7F78E179763FD57B23
> >>
> >> 3E2880743FE9857D88B730183FC9CDCC2B37110C3FCA8353D994344A3FEE6DE7
> >>
> >> 7A62CE53FE050AE7961F7903FC421B87B3A73583FE27CE6E9F20E403FA81141
> >>
> >> A14CD4AF3FE46A8F20A495FB3FE0D149BA107C183FDB265D6BD386473FEC8547
> >>
> >> 114E7EC13FE7CAEB494A37603FD5AABBF20365BA3FED1AAFEF517E083FDC3322
> >>
> >> DAEDA143FCBDA3EAD74FD683FC10F23B34999003F91A1B0EC0355A33FEC5345
> >>
> >> B2B37BE33FED4E24
> >>
> >> ----------------------------------------------------------------------
> >> -----
> >> ----------------------------------------------------------------------
> >> -----
> >> ------------------------------------------------------------------
> >>
> >>
> >>
> >> The program just dies and seems no error information printed. To be
> >> more efficient, I want to debug only with the problematic event
> >> (without running the previous events). According to the manuals, both
> >> of the hexadecimal numbers in these two files are called seeds. So, my
> >> question is that how can I reproduce the events where the program dies
> >> using these ¡°seeds¡±?
> >>
> >>
> >>
> >>
> >>
> >> Thanks in advance,
> >>
> >> Guang
> >>
> >>
> >>
> >
> >
> >
>
>
>
>
>
__________________________________________________________________________
You can manage unsubscription from this mailing list at
https://www.fluka.org/fluka.php?id=acc_info
Received on Thu Dec 15 2016 - 20:19:52 CET