Closed jedwards4b closed 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?
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
@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.
@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.
@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.
I think you might be able to test on orion using hpc-stack v1.2.0. They've installed it there already.
Okay. Let me try.
@DeniseWorthen I could not see 1.2 under /apps/contrib/NCEP/libs/hpc-stack/
. I think it would be installed to the same directory.
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
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.
You should just be able to edit the esmf version in modulefiles/ufs_common and ufs_common_debug.
@DeniseWorthen Okay. I could use ESMF 8.2.0b14 now. I'll update you about the results of testing two cases for HAFS.
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.
@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.
I think it is also required for the fully coupled cases. I am testing now. I'll update you soon.
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?
@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.
@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.
@uturuncoglu That answer confuses me, so I must not understand what the various settings are doing. I'll look at it some more.
@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).
…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: