ESCOMP / CMEPS

NUOPC Community Mediator for Earth Prediction Systems
https://escomp.github.io/CMEPS/
24 stars 79 forks source link

add support for REST_OPTION end and always write a restart at end of … #221

Closed jedwards4b closed 3 years ago

jedwards4b commented 3 years ago

…run unless restart is none or never

Description of changes

Adds support for REST_OPTION='end', also all runs with any REST_OPTION other that none or never will write a restart file at the end of the run.

Specific notes

Contributors other than yourself, if any:

CMEPS Issues Fixed (include github issue #):

Are changes expected to change answers?

Any User Interface Changes (namelist or namelist defaults changes)?

Testing performed if application target is CESM:(either UFS-S2S or CESM testing is required):

Testing performed if application target is UFS-coupled:

Testing performed if application target is UFS-HAFS:

Hashes used for testing:

uturuncoglu commented 3 years ago

@jedwards4b i am getting following error when I try to compile this under HAFS

/work/noaa/gmtb/tufuk/hafs_sync_202107/CMEPS-interface/CMEPS/mediator/med.F90(2571): error #6285: There is no matching specific subroutine for this generic subroutine call.   [NUOPC_COMPCHECKSETCLOCK]
    call NUOPC_CompCheckSetClock(gcomp, driverClock, checkTimeStep=.false., rc=rc)
---------^

Is this CMEPS version requires specific version of ESMF?

jedwards4b commented 3 years ago

8_2_0 beta13 or newer

On Fri, Aug 6, 2021 at 10:25 AM Ufuk Turunçoğlu @.***> wrote:

@jedwards4b https://github.com/jedwards4b i am getting following error when I try to compile this under HAFS

/work/noaa/gmtb/tufuk/hafs_sync_202107/CMEPS-interface/CMEPS/mediator/med.F90(2571): error #6285: There is no matching specific subroutine for this generic subroutine call. [NUOPC_COMPCHECKSETCLOCK] call NUOPC_CompCheckSetClock(gcomp, driverClock, checkTimeStep=.false., rc=rc) ---------^

Is this CMEPS version requires specific version of ESMF?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CMEPS/pull/221#issuecomment-894372836, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOXUGCLKPLIRHIR7IX56X3T3QEGLANCNFSM5BUO2WEQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

-- Jim Edwards

CESM Software Engineer National Center for Atmospheric Research Boulder, CO

uturuncoglu commented 3 years ago

@jedwards4b The current version of UFS model uses ESMF 8.1.1 and updating CMEPS in the UFS side will require new HPC stack installation in all the supported platforms. It would be nice to add Denise as a reviewer and get her opinion about this PR.

DeniseWorthen commented 3 years ago

@uturuncoglu We are getting 8.2.0bs14 installed in the stack and will switch to it once it is available on all platforms. @jedwards4b did confirm that would be OK, since it does mean we will not be able to update CMEPS in EMC until that happens.

uturuncoglu commented 3 years ago

@DeniseWorthen okay. that is great. it is good to know. Is it possible to use new installation on Orion currently to test the CMEPS and CDEPS PRs. Otherwise, I assume that they are fine.

DeniseWorthen commented 3 years ago

I think you might be able to test on orion using hpc-stack v1.2.0. They've installed it there already.

uturuncoglu commented 3 years ago

Okay. Let me try.

uturuncoglu commented 3 years ago

@DeniseWorthen I could not see 1.2 under /apps/contrib/NCEP/libs/hpc-stack/. I think it would be installed to the same directory.

DeniseWorthen commented 3 years ago

I think I mis-read the issue page on hpc-stack. It looks like they did put it into hpc/1.1.0 also; I think it will be the only esmf going into hpc/1.2.0

uturuncoglu commented 3 years ago

I could see the installation in /apps/contrib/NCEP/libs/hpc-stack/intel-2018.4/impi-2018.4/esmf/8_2_0_beta_snapshot_14/ but I am not sure how this can be used under UFS model. I think it requires new module file under /apps/contrib/NCEP/libs/modulefiles/stack/hpc/ which I could not see.

DeniseWorthen commented 3 years ago

You should just be able to edit the esmf version in modulefiles/ufs_common and ufs_common_debug.

uturuncoglu commented 3 years ago

@DeniseWorthen Okay. I could use ESMF 8.2.0b14 now. I'll update you about the results of testing two cases for HAFS.

uturuncoglu commented 3 years ago

The test compiles without issue but crashed in the run time. I'll check the possible issues. Since, I am testing both PR together, the issue might be in CMEPS or CDEPS side. @jedwards4b is there any configuration option that we need to use.

uturuncoglu commented 3 years ago

@jedwards4b @DeniseWorthen It seems that UFS model is failing because CDEPS (in this configuration i am using data ocean) could not find the write_restart_at_endofrun. So, I need to add following to ALLCOMP_attributes:: section in the nems.configure

  stop_n = 6
  stop_option = nhours
  stop_ymd = -999
  write_restart_at_endofrun = true

So, stop_* also required to run the model.

uturuncoglu commented 3 years ago

I think it is also required for the fully coupled cases. I am testing now. I'll update you soon.

DeniseWorthen commented 3 years ago

Yes, I believe it would be. It seems the flag to write the restart is set false by default; without it in the nems.configure the restart file won't be written, and since we compare mediator restart files, the RT will fail.

I'm not sure I understand why the flag is false by default; the PR title seems to say that it will always write a restart unless you've set it none or never?

jedwards4b commented 3 years ago

@DeniseWorthen It will always write a restart unless REST_OPTION is none or never. We could set the default to true and negate it below if that's better for you.

uturuncoglu commented 3 years ago

@DeniseWorthen I checked fully coupled FV3+HYCOM and it worked without any issue. So, I think there is no need to add them for fully coupled cases but only configurations with CDEPS involves.

DeniseWorthen commented 3 years ago

@uturuncoglu That answer confuses me, so I must not understand what the various settings are doing. I'll look at it some more.

uturuncoglu commented 3 years ago

@DeniseWorthen I think the changes in the CDEPS side https://github.com/ESCOMP/CDEPS/pull/111 force those options. Since, I am testing both PRs together, only CDEPS configuration fails if those options are not available. The configurations with CMEPS is fine and FV3+HYCOM also checks the mediator restart file. In our nems.configure we are setting restart options explicitly,

  restart_n = 6
  restart_option = nhours
  restart_ymd = -999

So, that will ensure that the model will write the restart file at the end of the run (forecast length is also set to 6 in the model_configure).