-
Notifications
You must be signed in to change notification settings - Fork 18
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
Fixes #3096 - propagate time dependent changes #3119
Fixes #3096 - propagate time dependent changes #3119
Conversation
This commit provides low level capabilities for computing the difference in metadata (units, typekind, geom, ...) between 2 fields or field bundles as well as applying diffs to a targeted field/bundle. The intent is for couplers to use this to propagate time-varying attributes between import and export. Changes will generally flow in each direction. Intermediate progress. May have to start over splitting into finer tasks. Update/reallocate on fields moved - New class FieldDelta and modified tests now in Test_FieldDelta.pf. - FieldBundleDelta only partially completed. Intermediate progress on FieldBudleDelta tests Tests pass. Still need more tests to check treatment of ungridded dims. FieldDelta and FieldBundleDelta pass tests. Have commented out logic for controlling time varying - saving for later feature.
…lidate_phase' into feature/tclune/#3096-action-invalidate_phase
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 have reviewed all the files.
I'll take a look at this in the morning when I am more fresh. |
My latest thoughts, @tclune: We could store the keys as named constants in the MAPL type modules to which they correspond. Those keys would be used to make/set ESMF_Info and get ESMF_Info. It would be hiearchical like ESMF_Info. An object would contain only the keys for values at it's own level of the hierarchy. It could be bound to the type, but I don't think it needs to be. This would help in our development because we could find the keys if we know which object we are dealing with, and they would named, so we would not need to use string literals. Beyond that, what you have makes sense. What is the distinction between Internal, Private, Shared, and normal keys? I've forgotten. Let me know if and when you want to discuss it further. |
|
- Introduced local `ignore_` that always has a value.
@darianboggs Please re-review. I had not gotten around to fixing a couple of minor issues until over the weekend. |
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.
Looks good
Am merging without review/CI. Last change was just to remove debug prints. |
This commit provides low level capabilities for computing the difference in metadata (units, typekind, geom, ...) between 2 fields or field bundles as well as applying diffs to a targeted field/bundle.
The intent is for couplers to use this to propagate time-varying attributes between import and export. Changes will generally flow in each direction.
Intermediate progress.
May have to start over splitting into finer tasks.
Update/reallocate on fields moved
Intermediate progress on FieldBudleDelta tests
Tests pass.
Still need more tests to check treatment of ungridded dims.
FieldDelta and FieldBundleDelta pass tests.
Have commented out logic for controlling time varying - saving for later feature.
Types of change(s)
Checklist
make tests
)Description
Related Issue