idaholab
Extend functors to aux system
Reason
As first outlined in #19366, on-the-fly variable evaluation currently relies on querying the solution vector. If we have a chain of aux kernels we have to make sure that the first aux ends up updating the solution vector or else a second aux kernel that relies on on-the-fly evaluation of the variable won't receive up-to-date information.
This method of making sure global information is up-to-date is fragile and conceptually troublesome as evidenced by the test failures on #19366. A natural way to fix this would be to make the aux kernel evaluation on-the-fly as well.
Design
Create something like a FunctorAuxKernel. This would also necessitate creation of a FunctorAuxVariable or something ... or would it? If a FunctorAuxKernel was on-the-fly, then its functor evaluation could actually be directly substituted in place of what was previously an aux variable.
Impact
Easily allow aux kernel dependencies within the functor on-the-fly evaluation schema.
Reopening because I think we would like to move in favor of granularity as opposed to having all-encompassing issues
I'm also interested in having InitialConditionBase inherit from NonADFunctorInterface.
So if I understand correctly, what needs to happen is that we capture any dependencies from using functors. Currently we have that functors may be:
- variables/aux variables
- functions
- functor material properties
- post-processors
- constants
Could we have getFunctor call some new virtual getFunctorDependencyHelper that we add to FunctorInterface? And that helper would be responsible for adding that functor to the appropriate lists (variables, PPs)? We would need something that would tell us if the functor is a variable or PP. I don't know how difficult that is... and then there are functor material properties, which themselves could depend on variables and such, so I guess that's another complication, right?
@GiudGiud
I think you could do that. I imagine it is to write a FunctorIC object, which would be very flexible Then:
- any PP you depend on in an IC should be executed before ICs, I imagine a lot of PPs wont give great results there
- any variable you depend on in an IC should be initialized first. That should be fine, but what if they are themselves initialized by a FunctorIC
- you would need to manage dependencies of functors at initialization, and at later stages (for example if the variables are set by a FunctorAux)
You can dynamic cast to find out if it's a variable.
If there's a need to dynamic cast, then the system is not working 100% as intended. I think that ideally (functor) aux kernels would be functors in which case you would not actually need/want an associated aux variable. Functor evaluations should be available on-demand so you shouldn't need a data structure for storage like an aux variable gives when an on-the-fly aux kernel functor could be available in its stead
Of course my last comment makes me immediately wonder what an aux kernel functor would supply that a functor material property doesn't already give you, especially considering that @GiudGiud made output of functor material properties easy