-
Notifications
You must be signed in to change notification settings - Fork 85
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
Example usage of FieldManager in an NGP Kernel #1182
base: master
Are you sure you want to change the base?
Conversation
This PR demonstrates how a Kernel can be converted to use a FieldManager. The main goal is to move the field registration away from higher level abstractions like realm and equationsystem, to lower ones (algs and kernels). This will essentially eliminate the need for `RegisterNodalFields` type calls, and will eliminate a range of bugs that can come in from not registering fields in the right place. Having kernels and algs register the fields they need will also reduce the amount of fixturing needed for unit tests since constructing the object will register the fields for you. You can then finalize the mesh and populate the fields with initial values. (Not demonstrated in this PR).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks good. I left one comment about string-literals. If multiple kernels use the same fields or overlapping subsets of fields, having duplicated string-names is error-prone.
src/node_kernels/TKESSTNodeKernel.C
Outdated
TKESSTNodeKernel::TKESSTNodeKernel( | ||
const stk::mesh::MetaData& meta, | ||
const FieldManager& manager, | ||
stk::mesh::Part* part) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually looking at this closer, I'm not so sure we need a part vec. I think the field registry process will just add more parts each time it is called after a field is registered since multiple identical registrations are a no-op in stk. It would be good to test it though.
Making some progress on this. I really want to get this swarmable in the next few weeks and work as a team to convert the code to use the fieldManager and SmartFields as much as possible. It would be a good way for a lot of newer people to see a lot of nalu-wind's structure. |
This PR demonstrates how a Kernel can be converted to use a FieldManager.
The main goal is to move the field registration away from higher level abstractions like realm and equationsystem, to lower ones (algs and kernels).
This will essentially eliminate the need for
RegisterNodalFields
type calls, and will eliminate a range of bugs that can come in from not registering fields in the right place. Having kernels and algs register the fields they need will also reduce the amount of fixturing needed for unit tests since constructing the object will register the fields for you. You can then finalize the mesh and populate the fields with initial values. (Not demonstrated in this PR).As a side bonus we don't need to store class members for field ordinals AND field pointers on kernels any more either.