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

Changes to allow GCHP to run in reverse mode for adjoint integration #1166

Closed
wants to merge 5 commits into from

Conversation

TerribleNews
Copy link

Description

This change adds a time loop to CapGridComp run the clock forward before the time loop that actually executes the grid components. There are also some small changes to handle issues with alarms not ringing properly in reverse.

Related Issue

#1144

Motivation and Context

This feature is to support to adjoint development in GCHP, which requires running the model in reverse. There may be other advantages to a generic capability to run MAPL in reverse as well.

This will be my first merge request to the team, so I am submitting mostly to start the conversation and get guidance / feedback.

How Has This Been Tested?

Unfortunately, because GCHP uses a fork of MAPL it is non-trivial to test code changes with the latest version. All these changes are patterned after changes that have been tested in GCHP using the verison of MAPL that is there, which is based on 2.6.3. Is there a way for me to test these exact changes?

Types of changes

  • 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)

Checklist:

  • I have tested this change with a run of GEOSgcm (if non-trivial)
  • I have added one of the required labels (0 diff, 0 diff trivial, 0 diff structural, non 0-diff)
  • I have updated the CHANGELOG.md accordingly following the style of Keep a Changelog

Colin Lee added 4 commits October 31, 2021 16:48
This commit adds code to allow the CapGridComp to run in reverse while maintaining
the ability to trigger history alarms. This may also require a small bugfix in
the ESMF 8.0 code.
GMAO doesn't like preprocessor defines so I removed most of them but had
forgotten to do the step_reverse function. This change fixes that.
I had made some changes in previous tests to get the reverse model running
but forgot to remove these two.
@TerribleNews TerribleNews requested a review from a team as a code owner November 1, 2021 22:34
@atrayano
Copy link
Contributor

atrayano commented Nov 2, 2021

@TerribleNews Thanks for submitting the PR. While many of your changes are very well protected and won't impact GEOS at all, some would require additional logic. My main concern are the changes in History, and in particular the usage of the existing variable "list(n)%backwards". GEOS also has an adjoint model, and this variable might be used there. My preference would be to leave the existing "backwards: logic intact, and add a new variable, for example "reverse_time". I have many more comments regarding style, for example, the usage of debugging prints, etc., but I will articulate them in separate comments

@TerribleNews
Copy link
Author

Thanks for the feedback @atrayano. I am not thrilled with the changes I made to the history alarms in general; they were mostly trial and error, and possibly not all of them are necessary / useful. For example, when there's a new alarm declared, if it's backwards, it's declared as sticky, but I couldn't get my alarms to ring without sticky=.false., but I couldn't never figure out exactly why, or why the original code was sticky. I have a somewhat limited testing platform. I used the backwards attribute because the comment said it's currently unused, but if GEOS is using it, then I don't want to mess that up. I think we have a few options here:

  1. I revert the backwards logic and add in a new reverse_time attribute to replace my changes
  2. I take the history changes out of this PR and we can come up with a plan to better test that part of the code so that I'm not just making changes to it willy-nilly
  3. Something else I haven't thought of

@stale
Copy link

stale bot commented Jan 2, 2022

This issue has been automatically marked as stale because it has not had recent activity. If there are no updates within 7 days, it will be closed. You can add the "long term" tag to prevent the Stale bot from closing this issue.

@stale stale bot added the ❄️ Stale This issue has been marked stale label Jan 2, 2022
@mathomp4 mathomp4 added ⌛ Long Term Long term issues and removed ❄️ Stale This issue has been marked stale labels Jan 3, 2022
@mathomp4
Copy link
Member

mathomp4 commented Jan 3, 2022

Huh. I didn't know the stale bot could mark PRs as stale. I think I need to look at how it's configured!

@mathomp4
Copy link
Member

@bena-nasa Something to think about with ESMF New Alarm: Running in reverse for Adjoint

Comment on lines +3470 to +3474
read(timestring( 1: 4),'(i4.4)') year
read(timestring( 6: 7),'(i2.2)') month
read(timestring( 9:10),'(i2.2)') day
read(timestring(12:13),'(i2.2)') hour
read(timestring(15:16),'(i2.2)') minute
Copy link
Collaborator

Choose a reason for hiding this comment

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

Aren't there better ways to get these directly from ESMF_Time?

Comment on lines +3582 to +3585
if (MAPL_am_I_Root()) THEN
WRITE(*, 1999) n
ENDIF
1999 FORMAT('Not Writing alarm ', i3, ' because end_alarm is ringing')
Copy link
Collaborator

Choose a reason for hiding this comment

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

Prefer to avoid FORMAT statements:

Suggested change
if (MAPL_am_I_Root()) THEN
WRITE(*, 1999) n
ENDIF
1999 FORMAT('Not Writing alarm ', i3, ' because end_alarm is ringing')
if (MAPL_am_I_Root()) THEN
WRITE(*, '("Not Writing arlarm ", i3, " because end alarm is ringing.") n
ENDIF

Copy link
Collaborator

@tclune tclune left a comment

Choose a reason for hiding this comment

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

Suggested one change and would like clarification from @bena-nasa on how to retrieve min/hr/... from an ESMF_Time.

I also note that the changes to CapGridComp are likely fragile under planned MAPL3 changes, and thus may require re-implementation down the road.

@tclune
Copy link
Collaborator

tclune commented Nov 9, 2022

Did a quick attempt to resolve conflicts. May easily have done damage.

@tclune tclune added the 0 Diff The changes in this pull request have verified to be zero-diff with the target branch. label Nov 9, 2022
@tclune
Copy link
Collaborator

tclune commented Nov 9, 2022

Closing here. Replaced by #1795 .

@tclune tclune closed this Nov 9, 2022
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. ⌛ Long Term Long term issues
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants