Geofar error + biasing

Dear community,

I will be happy to get your advice on the following problem:

I am simulating a 12MeV proton beam on a Beryllium target for neutron generation. The target is surrounded by a vacuum chamber, which is surrounded by polyethylene and lead shielding. From the shielding, I have 3 pipes that are going outside to guide the neutrons.

Somehow I get a strange error, which I cannot explain:

Geofar: Particle in region 59 (cell # 0) in position 4.179814446E+02 -2.177151677E+02 4.988598895E+01
is now causing trouble, requesting a step of 6.894521548E-05 cm
to direction -9.048656239E-01 4.248661125E-01 2.658926783E-02, error count: 1
R2: 4.712837598E+02 R3: 4.739166532E+02 cm
XU (2D): -4.707168376E+02 XU (3D): -4.693904057E+02 cm
XUOLD(2D): -4.707086940E+02 XUOLD(3D): -4.693543452E+02 cm
Kloop: 126568945, Irsave: 59, Irsav2: 56, error code: -3 Nfrom: 21
old direction -9.048752011E-01 4.248103209E-01 2.714888082E-02, lagain, lstnew, lsense, lsnsct F T F F
Particle index 1 total energy 9.410037972E-01 GeV Nsurf 0

I found no error in the geometry in Flair or when activating the FLUKA geometry debugger via the GEOEND card. What is strange is that the error repeats itself with the same particle index and total energy of 9.410037972E-01 GeV.

When I change the biasing to only EMF and neurons, the problem disappears. Can you please help me understand the problem?

Thank you very much for your help!

Dear Rubi,

if you get the GEOFAR error, you usually have a (tiny) geometry error. Try finding it as it is shown on slide 28 of this lecture:

When you change the physics of the simulation then the generated particles (kind, energy, track, etc.) will also be different. Maybe no particle reaches the geometry error in the second case.

Cheers,
David

I’d like to underline that actually the problem does not necessarily imply a factual error in the geometry definition by the user.
These error messages are not lethal (unless the simulations stops due to their excess).
Even with a formally correct geometry, the tracking algorithm can meet precision inconsistencies in region boundary identification, which however manages to overcome. Here it happens for a few MeV proton (Particle index 1 total energy 9.410037972E-01 GeV) at the indicated location, for the indicated direction.
You may want to look closely at your geometry accordingly, and check the concerned region definition, but - in the absence of a geometry definition error - those message does not necessarily invalidate your results.

David

Thank you very much for your answer. I checked the geometry in all possible ways (like in the slides) but did not find the problem. The run does not stop but is slower because of the problem. So, I will be happy to avoid these errors. How can I prevent it?

Dear Rubi,

In your case — as Francesco mentioned — there is no real geometry error in your model, the issue is related to numerical precision, as a particle moving tangentially with the beampipe wall.

Since FLUKA can recover from this kind of error, it should not slow down your simulation though.

Enabling single scattering for hadrons at the boundary (via MULSOPT card) may prevent it, but it’s not a guarantee, the stepsize was already quite small.

However, there is a potential mistake regarding your BEAM card, which is completely unrelated to the Geofar error. Your beam is not along the Z axis, but the beam shape is defined in the XY plane. This leads to the problem described in slides 15-17 from

Cheers,
David

1 Like

Thank you very much for the help!

So, to define the beam correctly, I have to add the BEAMAXES card, right?

I changed this setting:

image

to this

image

Is that correct?

Dear Rubi,

yes, this looks correct.

You can see the beam direction in the Geometry window by selecting the BEAM under Objects in the list on the left.

Cheers,
David

A post was split to a new topic: Setting up weight window biasing