Weak enforcement of periodic boundary conditions

[ttruster]

Contribution: add enum parameter to periodic_boundary objects to differentiate strong and weak enforcement of periodic boundary conditions (PBC). Strong enforcement uses DOF constraint equations (current approach); weak enforcement would use surface integrals as part of the weak form of the boundary value problem. Also, add second version of topological_neighbor which returns both the neighbor element pointer and an integer pointer to the facet number.

Impact: allows PBC class to help with solving interface problems like cohesive zone modeling and to treat periodic conforming meshes using interface kernels instead of nodal constraints, allowing Nitsche/DG/mortar/penalty treatments.

References: idaholab/moose#22948 (reply in thread)

[roystgnr]

Let's not merge this until we're certain it's what you need on the MOOSE side of things too (which I haven't looked at yet), but the libMesh additions seem quite sensible, much cleaner than I'd been fearing.

I've kicked off the tests here as-is, just in case CI sees some damage to the existing PBC behavior which I missed.

Could I talk you into returning pair<const Elem *, unsigned int> instead of using an unsigned int * parameter for output? Not a strong preference on my part, it just feels more "C++" and less "C/Fortran" that way.

Could we get an explicit _enforcement_type(STRONG_ENFORCEMENT) in the constructor initializer lists? I'd guess there's some C++ rule about enum classes getting default initialized to their lowest entry and so this will work fine as-is, but I'd feel like it was safer (and more self-documenting) if we made the initialization explicit.

[roystgnr]

Skimming your MOOSE branch, I admit I see more code than I like, which makes me wonder if this definitely is the best solution ... but I can't say I see any bad code, so it looks like we've at least got a workable solution.

[moosebuild]

Job Coverage on 481e525 wanted to post the following:

Coverage

	170d48	#3525 481e52
	Total	Total	+/-	New
Rate	60.18%	60.16%	-0.01%	20.00%
Hits	49159	49161	+2	5
Misses	32533	32553	+20	20

Diff coverage report

Full coverage report

Warnings

• New new line coverage rate 20.00% is less than the suggested 90.0%

This comment will be updated on new commits.

[roystgnr]

I'd guess there's some C++ rule about enum classes getting default initialized to their lowest entry and so this will work fine as-is,

Or maybe I couldn't find such a rule because there is none? Test exodiff failures where the test names all include "periodic" or "phase_field" (which is almost always run periodic) can't be random. Oh, and there's one in a libMesh Periodic unit test too, so no complicated MOOSE interactions involved.

[ttruster]

I made those two changes; we'll see if the tests pass now. I am not familiar with the libmesh test system; it looks like a lot of it is running certain moose tests. If I should add some test files into the libmesh repo that call these functions, in order to improve coverage, let me know.

[roystgnr]

If I should add some test files into the libmesh repo that call these functions, in order to improve coverage, let me know.

That would definitely be a good idea. Our official coverage stats don't include MOOSE coverage, but more importantly it's a lot quicker to debug regressions when we have unit test coverage rather than just middleware or applications triggering them.