Allow mesh material volume calculations outside model geometry - #4028
Allow mesh material volume calculations outside model geometry#4028paulromano wants to merge 8 commits into
Conversation
pshriwise
left a comment
pshriwise
left a comment
There was a problem hiding this comment.
Thanks for supporting this additional scenario @paulromano! The refactor of the algorithm is quite nice too. A few questions here but no major concerns from me.
|
|
||
| //! Determine volume of materials within each mesh element | ||
| //! | ||
| //! Portions of mesh elements outside the model geometry are treated as void. |
There was a problem hiding this comment.
This is a hypothetical, but if one wanted a "background" material homogenized into mesh elements exterior to the model could one add an exterior cell outside the existing model with such a material and expect that it is homogenized in such elements?
There was a problem hiding this comment.
Yes, I don't see any reason that wouldn't work. Only regions that are outside all root universe cells are assigned void.
| // assigned. In both cases, return an infinite distance and invalid surface | ||
| // index rather than marking a particle as lost. | ||
| if (settings::run_mode == RunMode::PLOTTING || | ||
| p->lowest_coord().cell() == C_NONE) |
There was a problem hiding this comment.
This looks reasonable, but our raytrace plots handle a similar scenario without this modification. I wonder why that is. I'm guessing an extra find_cell may be performed somewhere?
There was a problem hiding this comment.
Looking at the current algorithm for computing mesh material volumes, I'm a little confused. If the particle is located right after being source from site in a model with a DAGMC universe as its root universe, then it should wind up in the implicit complement right? Probably missing something here.
There was a problem hiding this comment.
That is essentially correct. Ray::trace has an initial phase that calls exhaustive_find_cell, repeatedly calls advance_to_boundary_from_void, and then calls exhaustive_find_cell again after each candidate model boundary. The plotting path treats a no-hit result while probing root cells as an infinite distance rather than as a lost particle, and stops when there is no further model surface. The MMV calculation now follows the same outside-to-boundary search pattern but it additionally scores each interval outside the model as void.
Regarding the second comment, the implicit complement fallback looks like it only applies when a DAGMC universe is within another one (see DAGUniverse::find_cell).
| bool neighbor_list_find_cell(GeometryState& p, bool verbose) | ||
| { | ||
|
|
||
| #ifdef OPENMC_DAGMC_ENABLED |
There was a problem hiding this comment.
Seems perfectly valid to place this check here too, but I'm curious as to why this needed to be moved out of the Particle::cross_surface method.
There was a problem hiding this comment.
Yeah, that's a good question and I probably should have preemptively explained this. The old location only covered the actual transport code path. Both Ray::trace and Mesh::material_volumes perform their own surface crossing and call neighbor_list_find_cell directly, so they bypassed Particle::cross_surface. That allowed stale DAGMC facet history to survive when a ray crossed a CSG surface into another instance of the same DAGMC universe (@jtramm surfaced this in a review with Claude Code). The reset is now centralized in neighbor_list_find_cell, which is the common point reached after these CSG crossings. This preserves the transport behavior while also covering raytrace plots and MMV.
| // Add the contribution from a ray segment. The positions used here are | ||
| // kept separate from the particle position because the latter is moved a | ||
| // tiny distance across each surface for robust geometry searches. | ||
| auto add_segment = [&](const Position& r0, const Position& r1, |
There was a problem hiding this comment.
This method makes me wonder how close we are to merging this capability with the raytrace plots algorithm.
There was a problem hiding this comment.
I would definitely like to go in this direction. I think we're getting pretty close!
| """Test a mesh extending outside a root DAGMC universe.""" | ||
| openmc.reset_auto_ids() | ||
|
|
||
| dagmc_path = (Path(__file__).parents[1] / |
There was a problem hiding this comment.
I wonder if we need some suite-wide fixtures for the DAGMC models. They're used in many places now. Not asking this of you here, but if you think it would be useful maybe make an issue and I can tackle that.
There was a problem hiding this comment.
Agreed! Several tests now construct models from the same DAGMC fixtures, so a suite-wide fixture/helper would be wise. Since you're volunteering, I'll let you handle it as a follow up 😄
|
@pshriwise I've responded to all your comments. Let me know if you think anything needs updating. @jtramm I've incorporated fixes for the issues that we discussed off line. Thanks to both of you for your time reviewing this! |
2 participants
Description
Updates
Mesh.material_volumesto support meshes that extend beyond the model geometry. During ray tracing, regions outside the geometry are simply treated as void material. This enables a user to, for example, use Cartesian meshes to cover geometries with a curved outside boundary (sphere, cylinder). The implementation follows the ray-traced plotting approach for locating model boundaries from undefined space (utilizingadvance_to_boundary_from_void). Tests have been updated, including a comparison against an equivalent geometry with an explicit enclosing void cell.Checklist