Lost particle with Multiphysics Interface

Report all good and bad behavior here
jesse.johns
Posts: 114
Joined: Wed Apr 20, 2011 5:19 am

Lost particle with Multiphysics Interface

Post by jesse.johns » Thu Mar 12, 2015 4:38 am

Hello,

I am using the mutliphysics interface with a completely enclosed, rectangular primse OpenFOAM mesh created with blockMesh. The simulation typically runs without a hitch, but every once in awhile it crashed with lost particles:

Code: Select all

Tracking error: infinite loop (possibly lost particle)

Particle type : neutron

(x,y,z)  =  3.36331E+01  9.04791E+02  3.46109E+00
(u,v,w)  = -3.91149E-01  5.34645E-06  9.20327E-01
E        =  5.24396E-01
material =  UO2
totxs    =  1.94493E-02
majorant =  1.94493E-02

Checking geometry errors (this may fail)...

No geometry errors.

Geometry structure at last position is printed below.
Some levels may not be printed correctly. Look for the
first level that fails: undefined region, suspicious
local coordinates, etc., and check the corresponding
geometry definition in the input.

Level 0 / universe 0 :
Cell universe / cell 1
(x,y,z)  =  3.36331E+01  9.04791E+02  3.46109E+00
(u,v,w)  = -3.91149E-01  5.34645E-06  9.20327E-01

Level 1 / universe 1 :
Unstructured mesh universe
(x,y,z)  =  3.36331E+01  9.04791E+02  3.46109E+00
(u,v,w)  = -3.91149E-01  5.34645E-06  9.20327E-01

Simulation aborted.
I do not suspect any error in the mesh. This might be a round-off issue, perhaps? Is there a means in which to increase the threshold for the number of lost particles?

This error is similar in nature to http://ttuki.vtt.fi/serpent/viewtopic.php?f=25&t=2143

I've defined the geometry as such, very simply:

Code: Select all

cell 1 0 fill 1  -1 
cell 2 0 outside  1
surf 1  cuboid  0 150 0 1000 -10 10
surf 3 inf
cell 4 2 void -3

solid 1 1 2 
1000 4 50 20 10 2
"constant/polyMesh/points"
"constant/polyMesh/faces"
"constant/polyMesh/owner"
"constant/polyMesh/neighbour"
"constant/polyMesh/materials"
Where surf 1 are the exact extents of the geometry.

orca.blu
Posts: 59
Joined: Wed Apr 20, 2011 1:39 pm

Re: Lost particle with Multiphysics Interface

Post by orca.blu » Thu Mar 12, 2015 11:33 am

Hi!
Did you performed a ``checkMesh´´ command on your mesh?
Ciao
Manuele Aufiero
LPSC/IN2P3/CNRS Grenoble

User avatar
Jaakko Leppänen
Site Admin
Posts: 2387
Joined: Thu Mar 18, 2010 10:43 pm
Security question 2: 0
Location: Espoo, Finland
Contact:

Re: Lost particle with Multiphysics Interface

Post by Jaakko Leppänen » Thu Mar 12, 2015 3:49 pm

The direction cosines: (u,v,w) = -3.91149E-01 5.34645E-06 9.20327E-01 look a bit suspicious in that the particle is traveling almost parallel to the xz-plane, so it may be a numerical error caused by surface-tracking stopping the particle at an xz-surface. Do you get this error frequently, or is it more of a random event? Have you tried running in full delta-tracking mode (set dt 1.0)?
- Jaakko

jesse.johns
Posts: 114
Joined: Wed Apr 20, 2011 5:19 am

Re: Lost particle with Multiphysics Interface

Post by jesse.johns » Thu Mar 12, 2015 5:27 pm

Hello,
Did you performed a ``checkMesh´´ command on your mesh?
Yes, I performed the "checkMesh" and in fact this geometry is used with OpenFOAM for some physics simulations.
Do you get this error frequently, or is it more of a random event?
It is more or less random. I had the issue every 5-10 simulations typically, which is a total of 50e6 particles per simulation. Just last night, I ran 130 simulations without a single fault. Just posting on the forum seemed to have cure my aliments for now. Quantum effects.
Have you tried running in full delta-tracking mode (set dt 1.0)?
I have not tried that. I will give it a go for the next round of simulations.

Thanks!

User avatar
Jaakko Leppänen
Site Admin
Posts: 2387
Joined: Thu Mar 18, 2010 10:43 pm
Security question 2: 0
Location: Espoo, Finland
Contact:

Re: Lost particle with Multiphysics Interface

Post by Jaakko Leppänen » Thu Mar 12, 2015 8:53 pm

If you manage to get the error early on, be sure to make a copy of the input and the .seed file. Debugging errors that are caused by random rare events can be extremely difficult.

Another way to find out if this is related to surface-tracking is to set the dt fraction to zero and see if you get the error more frequently.
- Jaakko

jesse.johns
Posts: 114
Joined: Wed Apr 20, 2011 5:19 am

Re: Lost particle with Multiphysics Interface

Post by jesse.johns » Fri Mar 13, 2015 9:24 pm

Hi,

Thank you for the advice.

I believe that I found the issue. In particular, it is a result from of the cuboid boundary. I had originally set it in the middle of the mesh, so the box mesh has dimensions in x,y,z as ((0,150) (0,1000), (-10,10)). Because of a new search routene I wrote just prior to posting to the forum, the boundaries were set to those extents and ran without fault. The original boundary that resulted in the error was:

surf 1 cuboid 0 150 0 1000 0 10

rather than the correct boundary of:

surf 1 cuboid 0 150 0 1000 -10 10

The mesh is only one cell thick in the z-direction, so this was inherently cutting the cells in half. If you would like, I can generate that input file for you for testing.
Last edited by jesse.johns on Wed Mar 18, 2015 6:37 am, edited 1 time in total.

User avatar
Jaakko Leppänen
Site Admin
Posts: 2387
Joined: Thu Mar 18, 2010 10:43 pm
Security question 2: 0
Location: Espoo, Finland
Contact:

Re: Lost particle with Multiphysics Interface

Post by Jaakko Leppänen » Tue Mar 17, 2015 10:41 am

Yes, could you do that, please.
- Jaakko

jesse.johns
Posts: 114
Joined: Wed Apr 20, 2011 5:19 am

Re: Lost particle with Multiphysics Interface

Post by jesse.johns » Wed Mar 18, 2015 6:44 am

Alrighty. I've sent it to you in an e-mail.

Ville Valtavirta
Posts: 468
Joined: Fri Sep 07, 2012 1:43 pm
Security question 1: No
Security question 2: 92

Re: Lost particle with Multiphysics Interface

Post by Ville Valtavirta » Thu Mar 19, 2015 2:33 pm

Jesse,

thanks for the excellent test case. I've managed to reproduce the error and I think I also found the cause.

The problem arises when some neutrons end up into the part of your system with zero density. If these neutrons have a velocity vector very close to parallel to the xz-plane (which are the only black boundaries in your geometry) they will end up bouncing around with the same y-coordinate for nearly ever. Since the density of the material is zero, there won't be any real interactions to terminate or change the tracks before one of two things happen:

1) The neutrons manage to reach y-coordinates that contain materials with nonzero density.
2) The neutrons manage to reach the y-coordinate for the geometry boundary, since this is a black boundary in your case the tracks will terminate.

This can happen especially when the initial source is sampled. As the initial fission source is by default sampled over all the fissile materials, some of the source points will end up in the region where the density of your fuel material is zero. If the velocity vectors for these sampled neutrons happen to be almost parallel to the xz-plane trouble will arise. The other way for this to happen is to have a scattering to a very unlucky direction in the immediate surface of the non-zero-density fuel material.

So there is actually nothing wrong with the geometry or tracking per se. Having zero density volumes with reflective boundary conditions just produces infinite particle tracks in some cases.

Well, what should be done to avoid this problem then? I can think of several ways.

1) Increase the MAX_TRACK_LOOP value at header.h so that Serpent will give the unlucky neutrons more time to end up somewhere sensible (this will increase the calculation time in case of these neutrons and some very very unlucky particles can still end up killing the simulation).
2) Use full delta tracking (set dt 1) and make sure the majorant cross section for the fuel material is as low as possible by lowering the material density in the mat-card to the upper limit of your interface density, this should result in a longer mean-free-path for neutrons and they should get to the sensible parts of the geometry in less moves (some very very unlucky particles can still end up killing the simulation).
3) A NON PHYSICAL way of getting rid of these rare events would be to resample the particle velocity direction, if it seems that it's going to end up in this infinite tracking loop. The following addition to the beginning of the tracking loop (l. 153) in tracking.c should resample the direction cosines once.

Code: Select all

	  /* Resample direction cosines if close to infinite loop */

	  if (loop == (long)(MAX_TRACK_LOOP*0.95))
	    IsotropicDirection(&u, &v, &w, id);
4) Don't stop the simulation in the case of an infinite tracking loop, just tally the error somewhere. (can be dangerous in a case where there is a real tracking error / lost particle).

-Ville

jesse.johns
Posts: 114
Joined: Wed Apr 20, 2011 5:19 am

Re: Lost particle with Multiphysics Interface

Post by jesse.johns » Sat Mar 21, 2015 7:35 am

Hello Ville:
The problem arises when some neutrons end up into the part of your system with zero density
Following the rest of your description, I am not sure this accounts for the full breadth of what's going on. If you change the cuboid in the test case that I sent you to:

Code: Select all

surf 1  cuboid  0 150 0 1000 -10 10
Then simulations will not fail. I've run a considerable number without termination. Physically, the difference in the boundary does not alter the geometry or density distribution at all since the thicknes is 1 cell. I am wondering if the tetrahedral decomposition of the hex cells might account for this error since the openfoam mesh is being bisected by an xy plane in the Serpent universe.

I will test with this with another mesh, like the Stanford bunny, by adding in a symmetry plane.

Post Reply