Open lindsayad opened 2 years ago
My immediate issue can be resolved with FVPropValPerSubdomain
, soon to be PiecewiseContactPerBlock
material. But as stated on Slack, I am fine continuing on with the existing functor derivatives as long as we can, but at some point I think allowing user creation and arbitrary chaining of evaluation events will be a great thing
The newest issue I had was that if I execute reconstruction on initialSetup
in the user object, the aux variable initial condition has not yet executed so the reconstructed field is zero everywhere 😭 But this again will be fixed by using FVPropValPerSubdomain
Let's summarize here what we have in functors now:
What we want in functors that isn't provided across the board (eg not all 3 forms, but 1 or 2 have it). This usually means you should just change the object you are trying to use
What we want in functors that isn't provided at all (currently): 1) ordering of execution of objects acting on functors. We should be able to chain auxkernels to act on an auxvariable. If we had a FunctorAuxKernel (or simply Functor) we could make them depend on each other 2) nodal evaluations. So we can deprecate FunctionAux with FunctorAux and watch the world burn. Helps for 3) 3) interface from regular material properties. This would give much wide adoption to the Functor system if people could ease into with a working yet slow interface (reinit before computing computeQp, then pick that value, then cache it!) 4) [x] interface to regular material properties. Users can code their new materials as functors, and have them be computed on computeQp 5) [x] implicit conversion between AD and non-AD for the types that are safe. Eg it should be possible to convert a non-AD function to an AD functor, an auxvariable to a non-AD functor etc. Basically all the ones where we dont lose the Jacobian. This would make mixed formulation input files much more tractable
A new Functor class could help with 1) I think.
FunctorAuxKernel
refs #19396. However, I'm not sure if it's necessary any more. In my mind a FunctorMaterialProperty
supplies the same desired functionality
Once I have some time, I may try applying a FunctorMaterialProperty
design to @tanoret's segregated application where he had to workaround the fact that we cannot currently chain aux kernel dependencies that leverage functors.
@humrickhouse needs nodal "material property" evaluations
Reason
Functors are great and we want more of them
Proposed updates
This is copying some of the items from https://github.com/idaholab/moose/issues/19420#issuecomment-971851106
Priority:
Secondary:
Design
~Functors that can be requested in the input file will need to inherit from
MooseObject
and then we'll set them up just like we do for any otherMooseObject
withMooseObjectAction
derivatives.~TBD
Impact
~Make for more flexible simulations and in my current context prevent, not abuse of but perhaps, overextension of aux variables.~
Make functors even greater