Jacobians of materials with coupled variables

[NateAM]

I have a material that is a function of various solution variables (v). I have been able to compute the Jacobians within the material property and expose the Jacobians to a kernel. This kernel however does not explicitly depend on u so when computeOffDiagJacobian is called in my kernel the Kernel doesn't update.

Because these are very general materials, I don't always know what they will be functions of. Is there a way to have my kernel add the coupled solution variables for a given material property to it's own without having to add that to the input definition?

[GiudGiud]

Hello

Computing the Jacobian inside a material is not standard. It s the kernel's role to compute the Jacobian.

Did you verify that computeOffDiagJacobian is called? With some preconditioning in PFJNK it is not called unless a parameter is passed.

A kernel will not be able to modify the way a material property is being computed. The material property is pre-computed for all quadrature points when considering an element in the residual loop & jacobian loop

Guillaume

[NateAM]

Computing the Jacobian inside a material is not standard. It s the kernel's role to compute the Jacobian.

Sometimes you have materials that are functions of solution variables though (solid mechanics has this situation). Computing the consistent tangents of those materials in the same material object would seem seem to make sense, at least to me. Maybe I'm not thinking about it the way that the MOOSE dev team does.

Did you verify that computeOffDiagJacobian is called? With some preconditioning in PFJNK it is not called unless a parameter is passed.

Yes, I have gotten it to call. A solution is just to add a call to addCoupledVar to the kernel that the user has to specify which variables were used when computing the material. That works, but I was hoping there would be something less prone to error.

A kernel will not be able to modify the way a material property is being computed. The material property is pre-computed for all quadrature points when considering an element in the residual loop & jacobian loop

I don't want the kernel to modify what the material is doing, I want a kernel that consumes a material to know that it has more dependencies that will need Jacobian contributions due to the material's dependencies.

[GiudGiud]

If you use AD, it will capture that additional dependencies naturally when computeResidual is called for computing the Jacobian.

If you do not use AD, then implementing the computeOffDiagJacobian is where you need to capture all these dependencies, manually. You ll need to add the derivatives of the material properties with regards to the variables coupled in

[NateAM]

If you use AD, it will capture that additional dependencies naturally when computeResidual is called for computing the Jacobian.

Okay, that makes sense. This is a personal preference, but I like to use hand-coded Jacobians as a form of verification. I do understand the appeal of AD though.

If you do not use AD, then implementing the computeOffDiagJacobian is where you need to capture all these dependencies, manually. You ll need to add the derivatives of the material properties with regards to the variables coupled in

Okay, that's disappointing but I understand. Thanks!

[lindsayad]

@NateAM i think it makes sense to do the derivative calculations in the material especially if you are going to use it in multiple residual objects. But as you’ve noted there is no way to get around the requirement (at least not currently) that you need the explicit coupling via addCoupledVar in order to get the off diagonal Jacobian call for that variable. Sorry for the inconvenience!

[NateAM]

@NateAM i think it makes sense to do the derivative calculations in the material especially if you are going to use it in multiple residual objects. But as you’ve noted there is no way to get around the requirement (at least not currently) that you need the explicit coupling via addCoupledVar in order to get the off diagonal Jacobian call for that variable. Sorry for the inconvenience!

No worries! I just get so used to most things being possible here that I'm surprised when I run into something that isn't available yet!

[GiudGiud]

Thinking about it during my run, this seems totally fixable. I ll raise an issue. No timeline on the fix though