Access to material properties within computeProperties()

[albiedahal]

Hi all,

Can the material properties of other elements be accessed/modified when the computeProperties() method is being called for one element?

Regards,

Albert

[GiudGiud]

Hello

Not natively. It can be done with some hacking (reinit on neighbor element, compute, reinit on local)
You can access the neighbor material properties in interface_kernels though. If you are using those and the work performed in the material computeProperties() can be moved there, that is an option.

Could you please give us more details about your use case?

Second caveat:
It can be done in the functor material system which we are adding here, and which does not leverage computeProperties but does on-demand computation of matprops : #18395

Guillaume

[albiedahal]

Hi @GiudGiud,

I am trying to code in a nonlocal return mapping algorithm ( #19003 ). In the algorithm, the plastic multiplier is calculated for all the integration points of the domain simultaneously. I am currently calculating the plastic multiplier in separate std::vector. The vector is updated for each time the computeQpProperties() is called and after the final call for the last _qp in the domain, my std::vector has the correct values of the plastic multiplier and plastic strain for all of the quadrature poinst, which I want to assign to the _plastic_strain[_qp] for each element.

[dschwen]

@albiedahal you might want to look into compue = false materials, the getMaterial (not getMaterial_Property_!) call, and the computePropertiesAtQp call. This allows you to trigger material property re-computes on your own terms (e.g. multiple times within a local return mapping solve).

[GiudGiud]

so there is a global quantity that needs to be accessible when you compute the plastic_strain material property.

Can you lag it? Use the one from the previous iteration or even time step?

If so, retrieve an old material property using getMaterialPropertyOld
If not, I would create a UserObject to compute this quantity before computing material properties, then retrieve it when computing material properties.
Using a material property for this quantity does not work (unless you can use an old value) because all material properties are computed roughly (there is dependency resolution etc) at the same time

[GiudGiud]

Instead of the UO, I think @dschwen s solution is preferable btw

[hugary1995]

You are probably already aware of this, another issue here is that you are going to get a dense matrix using this approach, which may very likely bring you more trouble than it is worth.