RE: Stack Overflow Termination in fission experiment

From: Alfredo Ferrari <alfredo.ferrari_at_cern.ch>
Date: Fri, 24 Jul 2009 09:21:20 +0200

If you reach criticality the code will end in a stack overflow.
More exactly it will end up in stack overflow everytime the neutron
mutiplication factor is large enough to overcome the stack dimensions.
Note that even for a (slightly) subcritical system, fluctuations among
events (if you start at high energy) can still trigger a stack overflow.

There is a way to partially cope with this, I don't know if it is
documented in the manual. Please take also into account that the fission
neutrons are only the prompt ones.

At present we don't have a way in the code to estimate criticality,
and we don't want to have it, given the sensitivity of the issue.

                     Ciao
                    Alfredo

+----------------------------------------------------------------------+
| Alfredo Ferrari || Tel.: +41.22.76.76119 |
| CERN-EN/STI || Fax.: +41.22.76.69474 |
| 1211 Geneva 23 || e-mail: Alfredo.Ferrari_at_cern.ch |
| Switzerland || |
+----------------------------------------------------------------------+

On Fri, 24 Jul 2009, Joachim Vollaire wrote:

> Dear Jack
>
> I ran your problem and observed the same issue, it runs with lead but
> exceeds the size of the stack when using fissile material (U233). I
> tried to use the LOW-NEUT card (WHAT (6)) to artificially limit the
> fission neutron yield to 1 neutron (with a proportionally increased
> weight) to limit the chain reaction. It did not solve the problem. I
> then decreased the density of U233 to 0.05 g/cm3 as I suspected your
> problem to be close to criticality. It did work in that case, in the
> output file I had the following :
>
> Number of secondaries generated in inelastic interactions per beam =
> particle:
>
> Prompt radiation Radioactive decays
>
> 6.2000E+01 (100.%) 0.0000E+00 (100.%)
>
> 3.4000E+00 ( 5.5%) 0.0000E+00 ( 0.0%) PROTON
>
> 1.7800E+01 (28.7%) 0.0000E+00 ( 0.0%) PHOTON
>
> 3.9900E+01 (64.4%) 0.0000E+00 ( 0.0%) NEUTRON
>
> which seems ok to me starting with 1 GeV proton. However I am surprised
> by the number of secondaries created by low energy neutrons as shown
> below ... I suspect this is the cause of the stack overflow and I would
> appreciate any comments from colleagues which are experienced with fixed
> target experiments with protons.
>
> Number of secondaries created by low energy neutron per beam particle:
>
> Prompt radiation Radioactive decays
>
> 1.8729E+05 (100.%) 0.0000E+00 (100.%)
> 1.8545E+05 (99.0%) 0.0000E+00 ( 0.0%) NEUTRON
> 2.7424E+02 ( 0.1%) 0.0000E+00 ( 0.0%) fission NEUTRON
> 0.0000E+00 ( 0.0%) 0.0000E+00 ( 0.0%) PROTON
> 1.5590E+03 ( 0.8%) 0.0000E+00 ( 0.0%) PHOTON
>
> In general (I don t think this will solve your problem though), if you
> are only interested by the neutron fluence (based on your USRBIN card
> and not energy deposition) you could switch off the electromagnetic part
> of the problem (EMF card) to reduce the number of secondaries in the
> stack and decrease CPU time....
>
> Joachim
>
> ________________________________
>
> From: owner-fluka-discuss_at_mi.infn.it on behalf of
> J.B.Benton_at_warwick.ac.uk
> Sent: Wed 7/22/2009 5:59 PM
> To: fluka-discuss_at_fluka.org
> Subject: Stack Overflow Termination in fission experiment
>
>
>
> Dear Fluka team,
>
> I am new to fluka and while running a simulation i get the error message
> "Stack overflow in Feeder. Execution terminated." I am unsure what this
> means but i'm confident it is caused by my use of uranium 233 in a
> low-mat
> card. In this arrangement it is expected for the uranium to undergo
> fission (sub-critically) and i encounter the same problem when
> substituting for other fissionable materials (uranium 235, plutonium
> etc.)
> but not for regular materials such as uranium 238. Is this a limit of
> the
> code or can chain reactions be calculated successfully? I have attached
> my
> input file in case it is of use.
>
> Thank you for your help.
> Jack Benton
>
Received on Fri Jul 24 2009 - 10:29:17 CEST

This archive was generated by hypermail 2.2.0 : Fri Jul 24 2009 - 10:29:18 CEST