More tests are needed for the interface kernel

[YaqiWang]

Description of the enhancement or error report

Currently there is only one folder 1d_interface under moose/test/tests/interfacekernels. InterfaceKernel needs more tests because I can foresee more of its usage in the future. At this moment, I plan to add a 2D test and a 3D test. Because most times variables are block restricted when having the interface kernels, it is desired to have a mesh modifier to break the boundaries based on the subdomains that their sides attach, so that the boundary conditions can be properly applied.

Rationale for the enhancement or information for reproducing the error

More test coverage for an important MOOSE feature. I will work on this issue.

Identified impact

(i.e. Internal object changes, limited interface changes, public API change, or a list of specific applications impacted) No impact.

[mangerij]

Hey cool. I'm an intern this fall working with Daniel. He asked me to look into this class a bit to see if it could be used as an alternate way of making strains periodic in some elastic problem (what the Mortar system is trying to do in parallel). Having a 3d example to start from would be great.

[YaqiWang]

That will be tricky because elements on one boundary is not connected with the elements on the paired boundary in the mesh data structure. InterfaceKernel works with conforming mesh only as well. If the nodes on the two paired boundaries do not match, there will be no way to use InterfaceKernel. I am not sure if we can manipulate the mesh to set up the connection between elements connecting the two boundaries. Even so, domain decomposition will also be tricky. You also have to make sure the elements are rotated properly to match on both sides. @jwpeterson and libMesh developers could have more comments. I hate that Mortar is not working with MPI but you probably cannot directly use InterfaceKernel, and will have to implement something similar like PeriodicBoundaryCondition (this could be misleading because I donot know exactly how the current periodic boundary condition is imposed without mortar).

[dschwen]

The PeriodicBoundaryCondition is a special animal. It is not a MOOSE BC, but it uses the internal PBC capabilities of libMesh. What we want for the InterfaceKernel periodicity would have equivalent constraints as the regular periodicity: conforming meshes. We could think about having rotations in the future, but for now if we have a simple mapping for corresponding nodes or QPs that'd be fine. Mortar is really too powerful for this application. I think be either using or following the pattern of InterfaceKernels we can come up with a simpler method that works in parallel.

We need to figure out how to access elements across periodic boundaries, and we need to make sure we have ghosted data available. Maybe the new on-demand ghosting will be helpful here.

[YaqiWang]

Cannot agree you more on this comment 'Mortar is really too powerful' ;-) Not sure which approach you will use: Lagrange multiplier method or penalty method. The former will require primal variables defined on the periodical boundary.

[mangerij]

Is there a way to use addGhostedBoundary() and then use InterfaceKernel to ensure the flux condition between this ghosted boundary and the real boundary? You would only need four new boundaries. It would look like something like this.

Perhaps we wouldn't even need to use addGhostedBoundary(), you could just use a MeshModifier to make these new boundaries.

But, I don't understand how solution information from the opposite real mesh boundary (bold lines) could be transferred to the ghosted or MeshModifier boundary(dashed lines). We are doing a time dependent problem, could I just call the old solution?

[dschwen]

The boundaries are already there and addGhostedBoundary() only ghosts the geometry, but not the DoF data. Let's discuss this in a separate issue.