Enable (easy) assssembling to scalar variable residual and Jacobian from residual objects

[lindsayad]

Discussed in #22020

^{Originally posted by ttruster September 6, 2022}
I find myself needing to implement coupling between a scalar variable into a mortar constraint residual and Jacobian and vice versa. I have looked closely over the ScalarLagrangeMultiplier Kernel and the AverageValueConstraint Scalar Kernel for diffusion as well as Homogenization files (Constraint user object, scalar kernel, and off-diagonal Jacobian kernel) for the Tensor Mechanics system. It seems that the "MOOSE way" to do this would require a:

1. Mortar Constraint for the off-diagonal Jacobian (I have implemented)
2. Scalar Kernel to handle the residual and Jacobian of the scalar variable (I have made a hard-coded version)
3. A User Object that performs integration over a Mortar lower dimensional boundary object to compute the terms needed in the Scalar Kernel (non-existent in the MOOSE framework or modules; would require some framework expansion)

As a temporary work-around, I have tried adding direct assembly calls within the Mortar Constraint object for vector-residual and matrix-Jacobian blocks associated with the scalar variable. I'm using calls similar to those in ScalarLagrangeMultiplier and HomogenizedTotalLagrangianStressDivergence, which assembly to the upper and lower blocks of the Jacobian at the same time. They are happening through additional calls (quadrature loops and functions) that I embedded within the ComputeResidual and ComputeOffDiagonalJacobianScalar method calls of the MortarConstraint and MortarConstraintBase files. I have attached a sample of the source code with the loops.
src.txt

I can confirm from debug-mode that computations are occurring in the Residual Scalar calculation during the time when the Mortar Constraint ComputeResidual method is called. However, it doesn't seem like those values are getting into the global system residual, since the analysis finishes with a zero Nonlinear Residual norm.

So, question: am wondering if it is not possible to assemble residual contributions into other/coupled variables (i.e. the test function rows) different from the primary variable of the object, without modifying the tagging/caching/low-level assembly calls within MOOSE framework that are looping over the objects? The symmetric-block access for the Jacobian within ScalarLagrangeMultiplier gave me hope that would be possible. Of course it is not "appropriate" according to MOOSE design, but didn't know if it is technically not feasible.

The long term resolution is to make a user-object that has reference to the mortar subdomain mesh and system, to perform the quadrature. I might be able to get that to happen through either a SideUserObject.execute or a DomainUserObject.executeOnBoundary call, if I can get the Two Material System coupled into those. The MortarFrictionalPressureVectorAux AuxKernel gives me hope for doing that, since it also references the mortar mesh and data structure but outside of a Mortar Constraint object. Any clues for going down this route?

Thanks for reading, and suggestions welcome!

Tim

[lindsayad]

@ttruster, continuing from #22020:

There are enough routines in TestPeriodicBase it's hard for me to wrap my head around what is adding to what. Can you tell me exactly what routines do these couplings?

• field-scalar
• scalar-field

I assume field-scalar is done solely by computeOffDiagJacobianScalar, but I want to be sure.

[ttruster]

I did a better job in KernelScalarBase at separating out an naming the Jacobian contributions and assembly routine. As I'm looking back here now, I notice one method is called twice, so I'll need to look back at my flowchart for the naming.

In short:
computeOffDiagJacobianScalarM has two loops which handle field-scalar and scalar-field, and is called by computeOffDiagJacobianScalar
computeJacobianScalar has one loop and handles scalar-scalar contribution
computeResidualScalar has one loop and handles scalar contribution

In MortarConstraintBase:

• computeResidual() calls existing computeResidual(Moose::MortarType) to get residual for field, and adds the call for the scalar computeResidualScalar() (has assembly and quadrature loop)
• computeJacobian() calls existing computeJacobian(Moose::MortarType) for Jacobian of primary-secondary, etc.; and adds the call to computeJacobianScalar() (has assembly and quadrature loop)

In TestPeriodicBase:

• computeOffDiagJacobianScalar(jvar) is overridden and calls the new functions computeOffDiagJacobianScalarM(Moose::MortarType, jvar) which have 2 assembly and quadrature loops:
• first is computeQpBaseJacobian for field-scalar, second is computeQpConstraintJacobian for scalar-field
• that was similar names from HomogenizedTotalLagrangianStressDivergence
• computeOffDiagJacobianScalar(jvar) also calls computeJacobianScalar() again; this might be in error, but I notice that many computeOffDiagJacobian(var) calls also call computeJacobian when jvar = _var.number()

[ttruster]

I worked on a document the last couple days to see which couplings are or are not currently handled by the various residual objects; see the attached.
220922 Plan for assembly and scalar wrapping objects.pdf

Yellow is for currently missing blocks/couplings (because a need hasn't arisen yet); cyan is for blocks that are treated differently for AD and non-AD objects. And orange are for the methods within the wrappers I'm envisioning for the objects like I did in for the Kernel case.

We'll focus on the mortar object here; but seeing how the others are treated may guide the type of assembly added. Particularly, the differences for Jacobian only versus Full Jacobian assembly are apparent for mortar AD versus all the other objects.

[lindsayad]

thanks a lot for all the detailed info!!