Functor System Enhancements

lindsayad commented 2 years ago

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:

[x] nodal evaluations. So we can deprecate FunctionAux with FunctorAux and watch the world burn
[x] fv-type evaluations for FE variables
[x] fe-type evaluations for FV variables

Secondary:

[ ] interface to 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!)
[ ] make functors work better with the aux system. Details in #19396

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 other MooseObject with MooseObjectAction 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

lindsayad commented 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

lindsayad commented 2 years ago

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

GiudGiud commented 2 years ago

Let's summarize here what we have in functors now:

functions. Dependence on space and time mostly, usually not sub-dependence but could depend on other functors if needed. We attach a function definition, and the functor is just evaluating that definition.
variables and aux-variables. They are fields, so have a memory cost, and they cant be attached a functor, they are the functor. The functor is essentially an evaluation of that field at the request location, with the requested interpolation
functor material properties. We attach a functor (lambda) to them, and this lambda is the functor. This is done in the constructor.

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

field-less (eg no mesh storage) capability. This is only provided by Functions and FunctorMatprops.
chaining of functors. Comes with attaching a functor, so only Functions and FunctorMatprops

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.

lindsayad commented 2 years ago

FunctorAuxKernel refs #19396. However, I'm not sure if it's necessary any more. In my mind a FunctorMaterialProperty supplies the same desired functionality

lindsayad commented 2 years ago

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.

lindsayad commented 1 year ago

@humrickhouse needs nodal "material property" evaluations

idaholab / moose