Bounding box testing for $Entities in GmshIO #3903

roystgnr · 2024-07-11T20:36:40Z

This is the best solution we could come up with to #3899 - continue our existing behavior, but scream and die if the .msh file we're reading is definitely inconsistent with that behavior.

I'm ashamed that this is the first .msh file we've added to our test suite - LCOV confirms that our CI is not hitting GmshIO::read()! I'm almost hoping that this PR triggers test failures from inconsistent meshes downstream, just so I can see that there's been something hitting that code.

moosebuild · 2024-07-12T00:24:05Z

Job Coverage on cb9cbf5 wanted to post the following:

Coverage

	b76c44	#3903 cb9cbf
	Total	Total	+/-	New
Rate	62.84%	63.03%	+0.19%	100.00%
Hits	69469	69717	+248	59
Misses	41082	40890	-192	0

Diff coverage report

Full coverage report

This comment will be updated on new commits.

roystgnr · 2024-07-12T03:06:38Z

I'm almost hoping that this PR triggers test failures from inconsistent meshes downstream, just so I can see that there's been something hitting that code.

Oh, better yet, it triggered test failures from consistent meshes and let me catch a bug in it.

Right now we ignore the point locations and the curve/surface/volume bounding box extents in a GMSH $Entities section; this led to unexpected behavior in libMesh#3899 Let's insist that those locations and bounding boxes are accurate. False positives for these tests are an easy fix (edit the $Entities), whereas missed true positives lead to erroneous simulations.

roystgnr · 2024-07-12T15:45:54Z

s/a bug/bugs/

On the bright side, I'm getting more and more happy about our downstream coverage here.

If the $Entities list says the box bottoms out at 0 but we see 1e-17, that's okay.

moosebuild · 2024-07-16T23:43:40Z

Job Test MOOSE on eaeedd3 : invalidated by @roystgnr

time_steppers/time_adaptive.test can''t possibly be affected by this PR...

roystgnr · 2024-07-17T15:08:30Z

Okay, I'm not sure what's going on in the updated Mac environments, but this PR does not put a segfault in eigenproblems_ex4 and does not put compiler warnings in solid_mechanics/examples/umat_build.build

We ought to be ready to merge.

lindsayad · 2024-07-19T17:10:02Z

src/geom/bounding_box.C

+Real BoundingBox::max_size() const
+{
+  Real size = 0;
+  for (unsigned int d = 0; d != LIBMESH_DIM; ++d)


In the future, after #3895 goes in, we could use make_range with libmesh_dim here

lindsayad · 2024-07-19T17:15:04Z

src/geom/bounding_box.C

+  for (unsigned int d = 0; d != LIBMESH_DIM; ++d)
+    {
+      Real sized = this->second(d) - this->first(d);
+      if (!libmesh_isinf(sized))


This would return false if sized corresponded to std::numeric_limits<Real>::max(), wouldn't it? I just read https://en.cppreference.com/w/cpp/numeric/math/isinf to check. If I'm correct, then the behavior of this function doesn't match its doxygen

Yeah, I think you're right. Pushed a fix.

include/geom/bounding_box.h

lindsayad · 2024-07-19T17:16:16Z

src/geom/bounding_box.C

+
+
+bool BoundingBox::contains_point
+  (const Point & p, Real abs_tol, Real rel_tol) const


Suggested change

(const Point & p, Real abs_tol, Real rel_tol) const

(const Point & p, const Real abs_tol, const Real rel_tol) const

We generally don't pass parameters by const value. const on a reference parameter is making a promise to the user, but const on a value parameter means nothing to the API semantics (because the value is a copy or a temporary anyway depending on input, and in neither case will the calling code ever see it) but can require future changes to the implementation to change the API syntax.

You can leave it non-const in the header declaration for the reason you stated but mark it as const in the implementation as that helps communicate to the reader that the parameters (at least in the current implementation) do not change

lindsayad · 2024-07-19T17:17:51Z

src/geom/bounding_box.C

+  // Make local variables first to make things more clear in a moment
+  const Real my_min_x = this->first(0) - tol;
+  const Real my_max_x = this->second(0) + tol;
+  bool x_int = is_between(my_min_x, p(0), my_max_x);


Suggested change

bool x_int = is_between(my_min_x, p(0), my_max_x);

const bool x_int = is_between(my_min_x, p(0), my_max_x);

You could early return if x_int = false and so on through this function if you wanted to avoid some work

src/geom/bounding_box.C

src/mesh/gmsh_io.C

lindsayad · 2024-07-19T17:25:41Z

src/mesh/gmsh_io.C

+                    BoundingBox expected_bounding_box;
+                    std::swap(expected_bounding_box.min(),
+                              expected_bounding_box.max());
+
+                    if (auto it = entity_to_bounding_box.find
+                          (std::make_pair(entity_dim, entity_tag));
+                        it != entity_to_bounding_box.end())
+                      expected_bounding_box = it->second;
+
+                    Node * node = mesh.node_ptr(nodetrans[gmsh_node_id]);
+
+                    // We'll accept *mostly* consistent.  We have
+                    // files that claim a bounding box but still have
+                    // points epsilon outside it.
+                    libmesh_error_msg_if
+                      (!expected_bounding_box.contains_point
+                         (*node, 0, /* relative */ TOLERANCE),
+                       "$Elements dim " << entity_dim << " element "
+                       << gmsh_element_id << " (entity " << entity_tag <<
+                       ") has node at " << *static_cast<Node*>(node)
+                       << "\n outside entity physical bounding box " <<
+                       expected_bounding_box);


Seems like two repetitions of this code. Optionally could add a method/lambda

Co-authored-by: Alex Lindsay <[email protected]>

roystgnr force-pushed the gmsh_nodeset_fix branch from 14cc0d3 to 3c6e824 Compare July 12, 2024 03:05

roystgnr added 4 commits July 12, 2024 10:45

BoundingBox print and iostreams support

8ac14ed

Unit test for new Gmsh error testing

1802440

Re-bootstrap

95d841f

roystgnr force-pushed the gmsh_nodeset_fix branch from 3c6e824 to 95d841f Compare July 12, 2024 15:45

roystgnr added 4 commits July 16, 2024 12:15

Add BoundingBox::max_size()

e9ab243

Add BoundingBox::contains_point() with tolerances

8babc57

Use tolerances in Gmsh bounding box tests

3e3a033

If the $Entities list says the box bottoms out at 0 but we see 1e-17, that's okay.

Don't let casting confuse our new assertions

52d29fd

roystgnr force-pushed the gmsh_nodeset_fix branch 2 times, most recently from ad450bc to 85637c7 Compare July 16, 2024 18:47

Add a good .msh file (swiped from MOOSE) to tests

eaeedd3

roystgnr force-pushed the gmsh_nodeset_fix branch from 85637c7 to eaeedd3 Compare July 16, 2024 21:23

lindsayad reviewed Jul 19, 2024

View reviewed changes

roystgnr and others added 2 commits July 19, 2024 15:48

Apply suggestions from code review

8a0cc8e

Co-authored-by: Alex Lindsay <[email protected]>

Handle "basically" infinite bounding box extents

cb9cbf5

roystgnr force-pushed the gmsh_nodeset_fix branch from 3dc9778 to cb9cbf5 Compare July 19, 2024 21:27

lindsayad approved these changes Jul 19, 2024

View reviewed changes

roystgnr merged commit 29a86d1 into libMesh:devel Jul 20, 2024
18 of 20 checks passed

roystgnr deleted the gmsh_nodeset_fix branch July 20, 2024 18:14



		bool BoundingBox::contains_point
		(const Point & p, Real abs_tol, Real rel_tol) const

	(const Point & p, Real abs_tol, Real rel_tol) const
	(const Point & p, const Real abs_tol, const Real rel_tol) const

	bool x_int = is_between(my_min_x, p(0), my_max_x);
	const bool x_int = is_between(my_min_x, p(0), my_max_x);

Bounding box testing for $Entities in GmshIO #3903

Bounding box testing for $Entities in GmshIO #3903

Uh oh!

Conversation

roystgnr commented Jul 11, 2024

Uh oh!

moosebuild commented Jul 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Coverage

Uh oh!

roystgnr commented Jul 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

roystgnr commented Jul 12, 2024

Uh oh!

moosebuild commented Jul 16, 2024

Uh oh!

roystgnr commented Jul 17, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

moosebuild commented Jul 12, 2024 •

edited

Loading

roystgnr commented Jul 12, 2024 •

edited

Loading