New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Functor System Enhancements #19420
Comments
My immediate issue can be resolved with |
The newest issue I had was that if I execute reconstruction on |
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):
A new Functor class could help with 1) I think. |
|
Once I have some time, I may try applying a |
…ant material, refs idaholab#19420 Add exception checks test to functor conversion material
… the AD converters Refs idaholab#19420
… the AD converters Refs idaholab#19420
…ant material, refs idaholab#19420 Add exception checks test to functor conversion material
… the AD converters Refs idaholab#19420
… the AD converters Refs idaholab#19420
Ideally, we would use a postprocessor that currently does not have an issue with insufficient ghosting when used on its own, see idaholab#19534. But I dont think there is one that will trigger the ghosting we want. I could admittedly make a new one, which would be a rework of SideAverageMaterialProperty, but it could make that one confusing. Use MatpropName and FunctorName instead of strings for parameters for the AD converters Refs idaholab#19420
Ideally, we would use a postprocessor that currently does not have an issue with insufficient ghosting when used on its own, see idaholab#19534. But I dont think there is one that will trigger the ghosting we want. I could admittedly make a new one, which would be a rework of SideAverageMaterialProperty, but it could make that one confusing. Use MatpropName and FunctorName instead of strings for parameters for the AD converters Refs idaholab#19420 Use interface diffusive flux instead of side to use both sides
Ideally, we would use a postprocessor that currently does not have an issue with insufficient ghosting when used on its own, see idaholab#19534. But I dont think there is one that will trigger the ghosting we want. I could admittedly make a new one, which would be a rework of SideAverageMaterialProperty, but it could make that one confusing. Use MatpropName and FunctorName instead of strings for parameters for the AD converters Refs idaholab#19420 Use interface diffusive flux instead of side to use both sides regold
@humrickhouse needs nodal "material property" evaluations |
Add test for converting vector functors refs idaholab#19420
Add test for converting vector functors refs idaholab#19420
Add test for converting vector functors refs idaholab#19420
…ic functor material To avoid conflicts with the GeneralFluidProps which define the time derivative but not the density refs idaholab#19420 refs idaholab/ncrc/bluecrab#228
…ic functor material To avoid conflicts with the GeneralFluidProps which define the time derivative but not the density refs idaholab#19420 refs idaholab/ncrc/bluecrab#228
Reason
Functors are great and we want more of them
Proposed updates
This is copying some of the items from #19420 (comment)
Priority:
Secondary:
Design
Functors that can be requested in the input file will need to inherit fromMooseObject
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
The text was updated successfully, but these errors were encountered: