-
Notifications
You must be signed in to change notification settings - Fork 191
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
Ability to construct field tuples with non-zero data #627
Conversation
Codecov Report
@@ Coverage Diff @@
## master #627 +/- ##
=========================================
Coverage ? 75.13%
=========================================
Files ? 118
Lines ? 2280
Branches ? 0
=========================================
Hits ? 1713
Misses ? 567
Partials ? 0
Continue to review full report at Codecov.
|
Couple quick questions:
|
Sorry I meant that we can now initialize field tuples (
Seems like a good idea. |
Sounds good. Just for the record,
Let's be specific here. |
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.
Lots of changes to wade through here so its hard to review in detail. But since tests pass and I support the spirit of this change I am approving.
@@ -1,62 +1,64 @@ | |||
""" | |||
VelocityFields(arch, grid) | |||
VelocityFields(arch, grid; u=zeros(arch, grid), v=zeros(arch, grid), w=zeros(arch, grid)) |
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.
I think this could be useful to users who want to partially-initialize velocities
with a predefined field for one of u, v w
, so I'm all for it.
Good point, I'll add a simple check for this during field creation. |
This PR is part 1/3 of making boundary conditions a field property.
I was refactoring the fields module, and in doing so I added optional kwargs to allow for data arrays to be passed.
This allows the checkpointer to be simplified as it no longer has to keep track of array references, and makes restoring/checkpointing large models possible. I will address this in part 2.
Changes:
AbstractLocatedField
has been removed. Now there is onlyAbstractField
.Fields can now be initialized with a data array. This will make restoring/checkpointing large models possible.
Right now
field.data
can store anything. We could check to make sure thatfield.data
has the same size as the grid, but this is extra code and could limit flexibility in the future so I did not add a check for this.Field tuple initializers (
VelocityFields
,TracerFields
, etc.) can now accept data arrays through keyword arguments.FaceFieldX
has been renamed toXFaceField
, and same for y and z.Note: This PR branches off #626.