Applying nodal forcing function

[nathan-miller-LANL]

Hi All,

I have a forcing function that I know at the nodes but not at the quadrature points. I've tried to apply this function by using a NodalKernal but it appears that the value I've set gets added for as many elements are associated with any given node. Are there any examples of adding values directly to the residual at a given node without this duplication?

Thanks,
Nathan

[aeslaughter]

@lindsayad Can you help with this?

[nathan-miller-LANL]

I really need some help on this one since the inability to apply forces (this is in the concept of a solid mechanics simulation) to nodes is a showstopper.

[lindsayad]

the value I've set gets added for as many elements are associated with any given node

this would definitely be unexpected behavior. Your residual from your NodalKernel should just sum straight into the residual for the Lagrange DOF at the node (presuming you're using a Lagrange basis). See this code:

void
NodalKernel::computeResidual()
{
  if (_var.isNodalDefined())
  {
    const dof_id_type & dof_idx = _var.nodalDofIndex();
    _qp = 0;
    Real res = computeQpResidual();
    res *= _var.scalingFactor();
    _assembly.cacheResidual(dof_idx, res, _vector_tags);

No association with element connectivity there. If you can show us a minimal working example with this buggy behavior, then we would definitely fix it.

[nathan-miller-LANL]

@lindsayad Okay, I've attached the files which replicate the second error on my system. For the record, I updated libmesh and MOOSE this morning and I'm running on master. I did notice that the duplicate problem seems to be gone (thanks for that) but I still notice the error in residual calculation for the nodes which have a preset DirichletBC when a forcing function is being applied to the residual.

I'm using a uniaxial stress example only so that I can be sure of what the answer should be. I don't think this is a problem with tensor mechanics since I have observed this behavior with my own kernels in similar situations. The errors can be observed for any node on the x, y, or z=0 face. I expect to see the value of zero for the applied force (AppliedForce) in the x and y directions (FInternal_1 and FInternal_2) on every node and equal to the negative force in the z direction (FInternal_3) but this is not the case for the BC nodes. It seems like the residual is not updating for nodes on the boundaries?

MinimumExample.zip

[lindsayad]

So for a Dirichlet node, the residual seen by the nonlinear solver for the associated degree of freedom is determined entirely by how much the solution value for that degree of freedom deviates from the Dirichlet condition. It is a totally different kind of residual from your physics residuals (which in your case sound like force balances). In general I would not expect there to be a balance of forces (e.g. a zero "physics" residual) for Dirichlet nodes since presumably there is some external force that has to balance the internal forces such that the Dirichlet condition is satisfied. @bwspenc this makes me think of ReferenceResidualProblem where you actually rely on the fact that there are boundary loads in order to create some reference residual quantity. @bwspenc maybe you have some insight on @nathan-miller-LANL's issue here, that I don't?

[nathan-miller-LANL]

@lindsayad I think I see what's happening here, I got myself wound round backwards. A constant force / residual field does not result in a constant stress field. My mistake can be seen with a simple diffusion problem (du / dx_i = f). Because of the shape functions, the nodal forcing function values are not constant but will vary based on the volume integrated value of the node. In the earlier example I posted you can see that the deformation field isn't constant at each isovalue of z. I suspect it is this problem that leads to the non-zero residuals on the surfaces.

Thanks for taking the time to look into this.

[lindsayad]

No problem. Can we consider this discussion resolved/"answered"?

[nathan-miller-LANL]

@lindsayad Yes, with the bug fix and the clarification I think this is settled. I will probably start another issue to try and support the application that I was trying to implement.

[lindsayad]

Going to consider #16269 to be the answer here