Negative track length error in DAGMC tet mesh tallies about dagmc

[gonuke]

Tim Bohm offered some additional diagnostics - curious is the fact that the identical numerical amount of track length seems to repeat with some frequency.

From Tim Bohm:

I built a modified version of dagmcnp with some added print outs in the TrackLengthMeshTally.cpp code. This is to help diagnose the negative track lengths I've been occasionally seeing with the conformal mesh tallies. I pasted some of the output below. It appears that the track length values are not small roundoff type of issues and the same values keep coming up. When I get some more time, I'll try to add some more diagnostics.
Tim

Warning-- negative track length.   Dubious continuation..
                   track length= -1.32431
Warning-- negative track length.   Dubious continuation..
                   track length= -0.29982
Warning-- negative track length.   Dubious continuation..
                   track length= -0.280101
Warning-- negative track length.   Dubious continuation..
                   track length= -1.32431
Warning-- negative track length.   Dubious continuation..
                   track length= -0.29982
Warning-- negative track length.   Dubious continuation..
                   track length= -0.280101
Warning-- negative track length.   Dubious continuation..
                   track length= -1.32431
Warning-- negative track length.   Dubious continuation..
                   track length= -0.29982
Warning-- negative track length.   Dubious continuation..
                   track length= -0.280101
Warning-- negative track length.   Dubious continuation..
                   track length= -1.32431
Warning-- negative track length.   Dubious continuation..
                   track length= -0.29982
Warning-- negative track length.   Dubious continuation..
                   track length= -0.280101
Warning-- negative track length.   Dubious continuation..
                   track length= -1.32431
Warning-- negative track length.   Dubious continuation..
                   track length= -0.29982
Warning-- negative track length.   Dubious continuation..
                   track length= -0.280101
Warning-- negative track length.   Dubious continuation..
                   track length= -1.32431
Warning-- negative track length.   Dubious continuation..
                   track length= -0.29982
Warning-- negative track length.   Dubious continuation..
                   track length= -0.280101
Warning-- negative track length.   Dubious continuation..
                   track length= -1.32431
Warning-- negative track length.   Dubious continuation..
                   track length= -0.29982
Warning-- negative track length.   Dubious continuation..
                   track length= -0.280101
 next interrupt will kill job.

[gonuke]

Next step: produce this error in a simple geometry in a repeatable way for easy debugging

[gonuke]

@cadangelo May have some simple problems that generate this too.

[kldunn]

I have been able to reproduce this error in two simple test cases that I had set up previously to verify the mesh tally work in DAG-MCNP. The first one is just a rectangular mesh that is conformal to a rectangular prism, and the second is a cylindrical mesh that is conformal to a cylindrical geometrical cell. If I do not include the "conformal" flag when setting up these tallies in the input files, then it produces the negative track length warning. This occurs whether you use DAGMC geometry or native MCNP geometry with the tracklen mesh tallies.

Has this error ever occurred when using the "conformal" flag? This flag removes the error message for both of my simple test cases.

[bohmt]

Can you share/point me to the location of your simple test problems? I'd like to take a look at them.

[kldunn]

These test problems are already in the DAGMC repository at DAG-MCNP/5.1.51/trunk/Testing/Meshtally/cases. Note that these input files have the conformal flag added for the tracklen tallies, so you will only have to remove this flag to see the negative track length error for these problems. The ones that I checked were the gradient_flux and the conformal_cyl1 cases, but it probably occurs for the others as well. As far as I remember from what I discussed with Steve when he wrote this code, the conformal flag is needed for these mesh tallies to use the correct logic for these problems when tracking particles near the overlapped mesh/geometry boundaries. That is why I was curious about whether or not it has ever occurred for problems with the conformal flag added.

[bohmt]

If I recall correctly (about 2-3 years ago when Steve wrote the conformal mesh tally code), he indicated to me that use of the conformal flag was optional and that it would likely result in many warning messages if the mesh generated for the mesh tally did not match the geometry faceting to a high precision.
Regardless, I set the conformal=cell flag in my mesh tally calculation of interest and now get many of the following warnings:

Warning: suspicious epsilon distance in conformal tally: 1.42154e-05
Warning: suspicious epsilon distance in conformal tally: 0.814529
ERROR: No triangle crossings found. Ending a meshtal track early.
Warning: suspicious epsilon distance in conformal tally: 7.04193e-06
Warning: suspicious epsilon distance in conformal tally: 0.76018
Warning: suspicious epsilon distance in conformal tally: 0.251779
ERROR: No triangle crossings found. Ending a meshtal track early.
Warning: suspicious epsilon distance in conformal tally: 3.94904e-06
Warning: suspicious epsilon distance in conformal tally: 1.21389e-05
Warning: suspicious epsilon distance in conformal tally: 0.433859
ERROR: No triangle crossings found. Ending a meshtal track early.
Warning: suspicious epsilon distance in conformal tally: 9.61757e-06
Warning: suspicious epsilon distance in conformal tally: 8.41674e-06
Warning: suspicious epsilon distance in conformal tally: 2.08491e-06
Warning: suspicious epsilon distance in conformal tally: 1.97171e-06
Warning: suspicious epsilon distance in conformal tally: 9.05566e-06
Warning: suspicious epsilon distance in conformal tally: 6.01607e-06
Warning: suspicious epsilon distance in conformal tally: 4.0706e-06
Warning: suspicious epsilon distance in conformal tally: 5.30275e-06
Warning: suspicious epsilon distance in conformal tally: 2.24141e-06

[kldunn]

Yes, that is the same issue I had with the simple cylinder problem as well. I looked back at my emails from Steve when I asked about it and he said that this is because the conformal logic requires an exact match between the geometry and mesh. With curved surfaces this is not always the case, so these epsilon errors pop up. If you refine the mesh, the errors get smaller as the two surfaces get closer to one another. To resolve this for the cylinder testing problem, we had to use the dagmc pre-processing tool to replace the geometric surface with the mesh.

[kldunn]

Found an old bug ticket from Steve in my emails that explains this error a bit more...

"Track length mesh tallies run into numerical issues when the tetrahedral tally mesh has a boundary that exactly coincides with the triangular facets in DagMC. The tally code is not currently aware of surface crossings, but when tally tracks stop and start exactly on tally boundaries (e.g. at surface crossings), the tally tracking code can get confused. It is not very predictable whether a point exactly on a triangle boundary will appear to be inside or outside the associated tetrahedron.

I have committed a test case ("metroid") to the meshtal branch of DAG-MCNP that illustrates this issue, and am working towards a fix."

[kldunn]

A followup to the bug ticket from Steve...

"I know a way for the mesh tally code to monitor MCNP's notion of the current cell (by keeping track of MCNP's =icl= global). If this variable changes between two calls to =dagmc_fmesh_score=, then a surface crossing has occurred.

I propose to add a flag to the track length mesh tally input card, specifying that the tally is fully conformal to DagMC's surface geometry. When this flag is set, the tally code can monitor the =icl= variable to detect surface crossings, and use special logic to avoid numerical problems for track segments that touch the surface boundaries. In effect, ray firing at the tally boundaries can be skipped, because DagMC has already done those calculations. This may lead naturally towards a solution where fully conformal mesh tallies specify the MCNP cell(s) to which they conform."

[kldunn]

Ran another test case using spherical geometry, and this does not have the negative track warnings without the conformal flag (although not surprisingly it does have the epsilon warning with the conformal flag). So it appears as though only meshes with "flat" surfaces such as the rectangular prism and the cylinder cause the problem since they are exactly conformal to the geometry with the precision set by the track length mesh tally. This may help to explain why you see repeated tracks with the same negative values.

[kldunn]

Here are the instructions that Steve gave me for setting up conformal track length tallies that require geometric surfaces being replaced with mesh surfaces in order for the conformal logic to work properly:

1. Create your geometry CAD file, geometry.sat.

2. Load geometry.sat into cubit (be sure attributes are enabled with a command like set attrib on before loading).  Mesh whatever volume(s) you care about-- for this example we'll use volume 2.  Save only the meshed volumes as a .cub file with the following cubit command: export cubit 'mesh.cub' vol 2 .  This will give you mesh.cub with surface numbers identical to geometry.sat.

3. mbconvert mesh.cub mesh.h5m

4. Run dagmc_preproc -v --ftol [tolerance] -m mesh.h5m -o output.h5m geometry.sat.  The options are as follows:

• -v -- verbose output, which may be useful to follow the program's progress.
• --ftol [tolerance] -- this is optional, and lets you specify a faceting tolerance like you would on a dag-mcnp5 command line.  The tolerance will not apply to the surfaces that are replaced with mesh surfaces.
• -m mesh.h5m -- specifies the alternative mesh file.  Surfaces in this file will replace identically-numbered surfaces from geometry.sat
• -o output.h5m -- specify an output file name.
• geometry.sat -- the required input argument.

5. Create a dag-mcnp5 problem using output.h5m as the gcad file on the dag-mcnp5 command line.  Set up a conformal mesh tally using mesh.h5m as the input mesh, and add conformal=2 to the FC card.

[bohmt]

For some added background information, often in complex geometries such as seen with ITER, one does not want to mesh an entire volume since the mesh element count will get very high. Thus I often only mesh a portion of a geometry volume and so setting conformal=2 does not seem appropriate. Of course I can go back and modify the original geometry and create a volume in the place where I want a mesh tally, but in complex geometries such as seen with ITER, this can be very time consuming and problematic. So the bottom line is, I just want the option where the mesh tally is not necessarily conformal to the geometry to work.

[bohmt]

Based on some speculation with Kerry and Andy, I re-ran my ITER mesh tally calculation using a mesh generated on the same volume as before but scaled by 0.9999 This ran successfully.

[gonuke]

This has been deferred until a refactoring of the TrackLength and other mesh tallies is complete. #96

[makeclean]

Fixed as of commit ed40aec