First stab at importing tracing routines#3432
First stab at importing tracing routines#3432loganharbour wants to merge 30 commits intolibMesh:develfrom
Conversation
loganharbour
force-pushed
the
tracing
branch
2 times, most recently
from
888b673 to
954baa6
Compare
loganharbour
force-pushed
the
tracing
branch
5 times, most recently
from
a5f54c8 to
76ac32d
Compare
|
@roystgnr everything here is complete and fully tested - this is definitely only a chunk of it, but could be reviewed now. |
loganharbour
changed the title
|
I'll also add that I think I have the most of the non-tool changes made, that is the stuff to |
This should give us a bit more efficiency+flexibility.
loganharbour
force-pushed
the
tracing
branch
7 times, most recently
from
e0cbc3e to
db37bbc
Compare
|
@roystgnr - good to go. |
loganharbour
force-pushed
the
tracing
branch
from
db37bbc to
c430d89
Compare
- Add 1D edge support for at vertex - Add 2D support/testing for being at an edge (a side) - Add additional testing
loganharbour
force-pushed
the
tracing
branch
from
c430d89 to
c0bc3c1
Compare
|
Re the tolerance stuff: the last few tests run these scaled with element features on the order of [1e-8,1e8] |
| const Real tol) | ||
| { | ||
| for (const auto v : elem.vertex_index_range()) | ||
| if (elem.point(v).relative_fuzzy_equals(p, tol)) |
There was a problem hiding this comment.
This isn't a proper relative tolerance. Here relative_fuzzy_equals will use p+elem.point(v) to compare against, which is likely to be way too big in some cases (a tiny element far from the origin) and is going to be effectively zero in other cases (a huge element with a vertex at the origin).
I'd normally use elem.hmax() as a scale here, but that might be too expensive for you? If so, it wouldn't be unreasonable to have something like Elem::cheap_scale() that returns something like an l1 norm (how do we not already have that for TypeVector...) of (elem.point(1)-elem.point(0)). Kind of arbitrary for anisotropic meshes but so is the choice of hmax() over hmin().
| for (const auto i : make_range(elem.n_vertices_on_side(s))) | ||
| { | ||
| const auto v = side_node_map[i]; | ||
| if (elem.point(v).relative_fuzzy_equals(p, tol)) |
|
This is exciting! We'll be able to add volumetric mesh geometries to OpenMC after this is merged (at the moment only surface mesh geometries are allowed). OpenMC already optionally links to libmesh for volume mesh tallies, but this will make multiphysics coupling substantially more straightforward. 😄 |
|
Oh hi @gridley. Yeah, this is completely OpenMC driven after some conversations with @pshriwise. I've got another branch pulling over the rest of the routines, just haven't made a PR yet. On that note - thanks for the reminder to finish this up 😆 |
4 participants
No description provided.