Fix refinement with non-default diagonal selection

[roystgnr]

Pinging @lindsayad, who first noticed the problem, and @nmnobre, who I'm hoping hasn't also already been bitten by it.

Previously, when doing refinement with any diagonal selection except DIAG_02_13, we were failing to take account of the diagonal selection in parent_bracketing_nodes(), which would lead us to stitch up nodes between the new child elements wrongly, creating some horribly distorted elements. It seems that, when we just get our tets from a build_cube(), they're all neatly oriented to select DIAG_02_13 for the first level of refinement, and so only with the second level do you get some that choose a different diagonal and trigger the bug.

[moosebuild]

Job Coverage on 88567f6 wanted to post the following:

Coverage

	c7065b	#3772 88567f
	Total	Total	+/-	New
Rate	62.24%	62.24%	+0.01%	100.00%
Hits	68318	68328	+10	4
Misses	41456	41448	-8	0

Diff coverage report

Full coverage report

This comment will be updated on new commits.

[roystgnr]

Going to merge to see if I can get this to master in time to slip it into idaholab/moose#26462

It isn't breaking any tests, and it's fixing breakage in both the new unit test and a MOOSE input, so I feel like even if I'm still missing any bugs at least we're less buggy now.

[nmnobre]

Hi Roy, a bit too late I know. :/
If you want, I think you could write this whole 11-line block as:

CPPUNIT_ASSERT_EQUAL(elem->top_parent(), parent->top_parent());
CPPUNIT_ASSERT((n == 1) != (parent != elem->top_parent()));

or if that's too cumbersome,

CPPUNIT_ASSERT_EQUAL(elem->top_parent(), parent->top_parent());
if (n == 1)
  CPPUNIT_ASSERT_EQUAL(parent, elem->top_parent());
else
  CPPUNIT_ASSERT(parent != elem->top_parent());

[roystgnr]

I like that second one. Not enough to open a new PR for it, though. :-)

[nmnobre]

It seems that, when we just get our tets from a build_cube(), they're all neatly oriented to select DIAG_02_13 for the first level of refinement, and so only with the second level do you get some that choose a different diagonal and trigger the bug.

I think this might've shielded me from the bug indeed. :)
iirc, the MOOSE tests only did (do?) one-level refinement, from the 24 tets in a cube to 24 x 8 total tets.

[lindsayad]

thanks @roystgnr !

It isn't breaking any tests, and it's fixing breakage in both the new unit test and a MOOSE input

Is the MOOSE input @nmnobre's coupled_electrostatics.i?

[roystgnr]

That was the one you pointed me to in Slack, right? Yeah, it works with that for me after this PR.