Allow weak enforcement of periodicity

[dschwen]

Description of the enhancement or error report

For mechanics problems I need a boundary condition that (weakly) enforces the periodicity of the strain (i.e. the gradients of the displacement variables). I was thinking to create a new class of integrated boundary conditions that has access to both faces of the elements touching a periodic boundary on either side. This would be somewhat similar to the FaceFaceConstraints in the mortar system.

Rationale for the enhancement or information for reproducing the error

Such a BC will enable further degrees of freedom (in particular will it allow deformation that is not volume conserving).

Identified impact

New capability.

[permcody]

Should this be handled as a constraint instead of a BC?

[dschwen]

You tell me! Conceptually it looks and sounds like a boundary condition (duck) to me. But whatever is the easiest out cleanest way to implement this works for me.

[permcody]

I'm not so sure. Periodic boundaries technically aren't boundary conditions either despite the name. They really are constraints (the value of some DOFs directly depend on others). Your proposal here is similar expect for the "weak" part. I guess how you implement and what you call them are two different things but you might take a look at the constraints system before you go through all the process of gathering the pieces you need to make this work inside of a boundary condition. Maybe @jwpeterson or @andrsd will have some opinions on this too.

[jwpeterson]

Yes, we discussed it yesterday and what he's doing is basically an amalgamation of FaceFaceConstraints and Periodic BCs, where the master/slave pair are periodic neighbors. The "constraint" is on the gradients, something like (1/eps)*\int |grad u_master -grad u_slave|^2 rather than the values as is traditionally done for Periodic BCs.

[friedmud]

We should get @roystgnr in here. He might already know a good way to do this.

My suggestion for now is to use the constraint system for this.

[dschwen]

Ok, yeah, that's fine. I have obviously already looked at the constraint system. So to go forward should I derive a class PeriodicConstraint from Constraint that lives besides FaceFaceConstraint and has a similar interface? In there I could resolve the master-slave relationship using the PeriodicBoundaries object form libmesh. This might even be easier than the FaceFaceConstraint.

Looking at git blame @andrsd seems like the expert here.

[friedmud]

I swear we already did something similar.

@bwspenc @jasondhales didn't we create some sort of periodic constraint to enforce a "jump" in the value across periodic boundaries?

[dschwen]

sounds familiar, where might that be?

[andrsd]

@dschwen FaceFaceConstraint expects a mortar interface to exist. And you would have to put it in your mesh manually. That is the current limitation of mortar method in MOOSE, because we did not do the automatic mortar interface creation, yet. But theoretically you might be able to do it with this system. It may not be the easiest way, though...

[dschwen]

Well, I'd not be using FaceFace, but instead derive directly from Constraint, wouldn't I?

[andrsd]

Then, do you assume the nodes to line up? If not, then you would end up with something similar to FaceFace. If so, you will have something similar to FaceFace with simplified projections and probably no need for the mortar interface...

[dschwen]

Yes, just like with the regular periodic boundary conditions I'd assume them to line up.

[roystgnr]

He might already know a good way to do this.

I'm afraid the last time this discussion came up my main contribution was shooting down other people's ideas: https://github.com/libMesh/libmesh/issues/545

The last idea there might still be relevant, though: if you need, we can rejigger the libMesh internals to allow a PeriodicBoundary to be created with periodicity in no variables, so you'd still be responsible for adding the periodicity terms to your weak form, but you'd have library assistance with finding periodic-neighbor points, keeping periodic neighbors semilocal on ParallelMesh, and keeping AMR level-1 conforming.

[friedmud]

@roystgnr That sounds like a good idea... regardless of the outcome here!

I could use it for something else I'm working on...

[dschwen]

@roystgnr that would be useful in the long term. In the short term - as my plan is to utilize this in coupled mechanics / phase field simulations - I will not need the periodic boundaries without periodic variables. My phase field variables will all be periodic (in the traditional sense) so the periodic boundaries internals should be initialized in libmesh already.

[bwspenc]

@friedmud The periodic BC with a jump sounds familiar, but I wasn't involved in that, so I'm not much help. This sounds a lot like what @jiangwen84 is doing for enforcement of constraints across XFEM cut surfaces in pull request #6756 (which we'd love to get merged, by the way). He created an element to element constraint base class and an XFEM-specific class that derives from it. It uses Nitche's method, and is a function of the gradients in both elements. You can optionally specify a jump or a jump in the flux. It would be very straightforward to create a version of this that functioned as a periodic boundary condition.

[dschwen]

Ok, the first step I took is showing that regular periodicity can be emulated using mortar (0c1f428 ). This is pretty neat. @andrsd I may need help in pulling in the gradients correctly and adding the EqualGradientConstraint.

[dschwen]

Since having gradients in the constraint does not seem to work (d grad_u/du = 0 so there is no coupling between the lm and the non-linear variables) we may have to use a different approach (see my last comment in libmesh/libmesh#545)

[friedmud]

d grad_u/du is not zero... it's grad_phi[j]

On Thu, Apr 21, 2016 at 6:54 PM Daniel Schwen notifications@github.com wrote:

Since having gradients in the constraint does not seem to work (d grad_u/du = 0 so there is no coupling between the lm and the non-linear variables) we may have to use a different approach (see my last comment in libmesh/issues#545)

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub https://github.com/idaholab/moose/issues/6807#issuecomment-213150723

[dschwen]

Uhm... No. You are talking about d grad_u/dui

[friedmud]

But you should always be taking the derivative with respect to a degree of freedom - right?

[dschwen]

This is the derivative of the constraint, that goes into the residual! I'm not talking about a Jacobian here.

On Thu, Apr 21, 2016, 8:12 PM Derek Gaston notifications@github.com wrote:

But you should always be taking the derivative with respect to a degree of freedom - right?

— You are receiving this because you modified the open/close state.

Reply to this email directly or view it on GitHub https://github.com/idaholab/moose/issues/6807#issuecomment-213210975

[jiangwen84]

I hope this helps. :-)

[jwpeterson]

"\delta \lambda" corresponds to the test function for the Lagrange multiplier variable, "\delta u" corresponds to the test function for "u", called \phi in this context, normally we'd call it \psi in MOOSE docs.

[jwpeterson]

I'm not sure what the "w_i" is

[YaqiWang]

Wen, this still requires the lagrange multipler variable on the interface, right? I thought you guys want to use the penalty method to impose the condition more like DG.

[dschwen]

Yeah, it does. I've started implementing this now in the last two commits. Testing now. Anything that works would be a great first step!

[jiangwen84]

Yaqi, you are right. This one here uses lagrange multiplier and the one we added asElemElemConstraint uses penalty instead.

[jiangwen84]

"w_i" is just arbitrary node value for the test function. :-)

[dschwen]

The example throws an assertion:

Assertion `_elem_to_side_to_qp_to_quadrature_nodes.find(elem->id()) != _elem_to_side_to_qp_to_quadrature_nodes.end()' failed
Elem has no quadrature nodes!
at /Users/schwd/Programs/moose/framework/src/mesh/MooseMesh.C, line 873

:-/

Update: it was an input file issue