No intersection found with DAGMC cell

Running on DAGMC geometry I am getting the following error

RuntimeError: Maximum number of lost particles has been reached.

During the inactive cycles I am getting these warnings

 ====================>     K EIGENVALUE SIMULATION     <====================

  Bat./Gen.      k            Average k
  =========   ========   ====================
 WARNING: No intersection found with DAGMC cell 37
        1/1    0.01489
 WARNING: No intersection found with DAGMC cell 37
 WARNING: No intersection found with DAGMC cell 37
 WARNING: No intersection found with DAGMC cell 37
 WARNING: No intersection found with DAGMC cell 37
 WARNING: No intersection found with DAGMC cell 37
 WARNING: No intersection found with DAGMC cell 37
 WARNING: No intersection found with DAGMC cell 37
 WARNING: No intersection found with DAGMC cell 37
 WARNING: No intersection found with DAGMC cell 37

I’ve examined the .jou that comes from generating the .h5m file from cubit, and I can see that volume 37 is correctly assigned. I don’t see any issues with the geometry plot. It looks correctly scaled and the materials look correctly defined.

The model was working fine when I was exporting it from a single .step file. I see the above error when I am separating the model into two .step files – one for the control rod and one for the rest of the assembly – importing those into cubit and then exporting to a dagmc file.

It seems also that the one k_eff value that does come out above is very low. The first batch when running the working model (from a single .step file) is ~0.81.

Any ideas what might be going wrong? In general, what causes a particle to be ‘lost’?

Thanks,
Luke

Hi Luke,

Thanks for trying out DAGMC in OpenMC!

A couple of thoughts:

  • Was the model imprinted and merged after you imported both files into Cubit?

  • The first thing that comes to mind for the low k-eff value is missing boundary conditions. Any chance those got missed this time around?

Hey Patrick,

Thanks for the response. Yes the model is imprinted and merged in cubit and yes boundary conditions are set.

Turns out this was a geometry issue. I tried removing cell 37 and it worked, so I went back to the model and found a small overlap with that volume and another volume. It was within the source area and adjacent to the fuel volume so I guess that’s why it was failing due to lost particles so quickly.

Ah, I see. Glad you got it sorted out!

FWIW you can visualize overlaps in the OpenMC plotter. DAGMC also has an overlap checker tool that can help you discover such issues as well.

Hi Patrick,

Thanks for the info on visualizing overlaps in the OpenMC plotter, I didn’t realize this was a capability! I tried it on some of my DAGMC models, and it shows significant overlaps all over my geometry. However when I run the DAGMC overlap_check utility, no overlaps are detected, and when I run models, no particles get lost, no unusual behavior occurs, etc. So I’m wondering, should I be concerned about the OpenMC plotter showing all these overlaps if other methods of overlap checking aren’t?

Interesting! I’ll have to look into that. Of the two tools, I would trust the DAGMC overlap_check tool as it’s performing mesh-based ray tracing queries targeted at surface intersections whereas the plotter is doing point containment checks to color pixels. There are likely ambiguous scenarios on the boundary of volumes where the point containment routine identifies the location as being in both volumes. Still, if you have a share-able model that’s giving you large regions with overlaps I’d love to take a look!

Thanks for that guidance! As it turns out, I must’ve had some geometry problems after all because I did lose 6 particles in 10,000,000 histories. Still, the plotter shows overlaps all over the geometry, so I feel I probably would’ve lost even more if it were showing true errors.

Unfortunately I can’t share my model, but I’ll put together an analogous one if I can find some time.

Thanks!

Yeah I would agree that you would lose many more particles if there were large overlaps in your model.

Unfortunately I can’t share my model, but I’ll put together an analogous one if I can find some time.

Thanks! I’d love to dig into it to see what’s going on when I have time. If it’s too big to attach here or email you can drop it at DAGMC Model Drops and send me a message.