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

Fixes #3096 - propagate time dependent changes #3119

Merged
merged 12 commits into from
Oct 28, 2024

Conversation

tclune
Copy link
Collaborator

@tclune tclune commented Oct 24, 2024

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.

Types of change(s)

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Trivial change (affects only documentation or cleanup)
  • Refactor (no functional changes, no api changes)

Checklist

  • Tested this change with a run of GEOSgcm
  • Ran the Unit Tests (make tests)

Description

Related Issue

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.
@tclune tclune added 🎁 New Feature This is a new feature 0 Diff The changes in this pull request have verified to be zero-diff with the target branch. 📈 MAPL3 MAPL 3 Related Changelog Skip Skips the Changelog Enforcer labels Oct 24, 2024
@tclune tclune requested a review from a team as a code owner October 24, 2024 13:56
field_utils/FieldDelta.F90 Outdated Show resolved Hide resolved
field_utils/FieldDelta.F90 Outdated Show resolved Hide resolved
field_utils/FieldDelta.F90 Outdated Show resolved Hide resolved
Copy link
Contributor

@darianboggs darianboggs left a 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.

@darianboggs
Copy link
Contributor

I'll take a look at this in the morning when I am more fresh.

@darianboggs
Copy link
Contributor

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.

@tclune
Copy link
Collaborator Author

tclune commented Oct 25, 2024

What is the distinction between Internal, Private, Shared, and normal keys? I've forgotte

  • PRIVATE: user-level info objects specific to a component
  • SHARED: user-level info objects that must be consistent across connections (couplers must copy along the chain)
  • INTERN: MAPL internal use only

@tclune
Copy link
Collaborator Author

tclune commented Oct 27, 2024

@darianboggs Please re-review. I had not gotten around to fixing a couple of minor issues until over the weekend.

darianboggs
darianboggs previously approved these changes Oct 28, 2024
Copy link
Contributor

@darianboggs darianboggs left a comment

Choose a reason for hiding this comment

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

Looks good

@tclune
Copy link
Collaborator Author

tclune commented Oct 28, 2024

Am merging without review/CI. Last change was just to remove debug prints.

@tclune tclune merged commit 0c46242 into release/MAPL-v3 Oct 28, 2024
8 of 21 checks passed
@tclune tclune deleted the feature/tclune/#3096-action-invalidate_phase branch October 28, 2024 17:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0 Diff The changes in this pull request have verified to be zero-diff with the target branch. Changelog Skip Skips the Changelog Enforcer 📈 MAPL3 MAPL 3 Related 🎁 New Feature This is a new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants