Skip to content
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

Draft
wants to merge 17 commits into
base: master
Choose a base branch
from

Conversation

psakievich
Copy link
Contributor

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.

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).
@psakievich psakievich marked this pull request as draft May 4, 2023 02:57
Copy link
Contributor

@alanw0 alanw0 left a 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 Show resolved Hide resolved
TKESSTNodeKernel::TKESSTNodeKernel(
const stk::mesh::MetaData& meta,
const FieldManager& manager,
stk::mesh::Part* part)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As @overfelt pointed out, if this is in the constructor it needs to take a partvec so all the parts are registered. Or we need a secondary registration process. Planning to pursue the former with #1183

Copy link
Contributor Author

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.

@psakievich psakievich requested a review from alanw0 April 18, 2024 06:33
@psakievich
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants