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?idc_info
Received on Thu Dec 15 2016 - 16:14:41 CET