moose
moose copied to clipboard
idaholab
getMaterialPropertyOld marks the property as regular
Bug Description
I have an object A that retrieves an old material property in its initialization list
_strain_old(getMaterialPropertyOldByName<RankTwoTensor>("total_strain"))
and an object B that declares an AD material property as
_total_strain(declareADProperty<RankTwoTensor>("total_strain"))
Then I get an error message like this
*** ERROR ***
Attempting to declare AD material property total_strain, but it is already retrieved/declared as a regular material property.
Steps to Reproduce
A MWE here.
Impact
This bug leads to errors that are construction order dependent.
To elaborate a bit more, if the first call involving a material property is just getting the old state, MOOSE sets up the property as non-AD. There is not much else that could be done within the current design, as the getMaterialPropertyOld calls do not distinguish between AD and non-AD.
If any of the AD/non-AD specific calls (like declareProperty/declareADProperty or getMaterialProperty/getADMaterialProperty) happen first, then MOOSE knows what flavor to set the property up as. And the successive getMaterialPropertyOld call will just fetch whatever flavor already exists.
Ok, @simopier just ran into this issue again. We might have to update that API to include an is_ad template parameter (getGenericmaterialPropertyOld?). Or did you find a workaround?
No, the requestor cannot possibly know whether the current state of the property needs to be AD or non-AD. Fetching an old state just cannot trigger the creation of a material property. This is going to be tough to resolve.
No, the requestor cannot possibly know whether the current state of the property needs to be AD or non-AD. Fetching an old state just cannot trigger the creation of a material property. This is going to be tough to resolve.
It might not be appropriate all the time, but could we assume that the current state of material property is the same type (AD or non-AD) as the material properties that the requestor would create?
Meaning, using the case above, object A would assume that object B would have the same type as object A. This is basically what it currently does anyway, but only for the non-AD case.
No, the requestor cannot possibly know whether the current state of the property needs to be AD or non-AD. Fetching an old state just cannot trigger the creation of a material property. This is going to be tough to resolve.
One design is to queue all the stateful requestors and wait to process all of them at the very end of the construction phase. That's the easiest solution I can think of at the moment.
What is this object A, a material? When using actions to add the object, developers will have control on when to add the user object but not always by MOOSE input syntax. In Griffin, we have a new task like add_aux_materials, which happens after add_materials and actions add some auxiliary materials after materials added through MOOSE syntax.
OK, after a quick discussion with @loganharbour we came up with a way forward that I'll implement.
