Closed mnlevy1981 closed 2 years ago
Still waiting on my nsteps
job to start, but judging from the case
options in https://github.com/ESCOMP/CMEPS/blob/ef360eabd92e5dac3e3bae6e553c13fdea87d252/mediator/med_time_mod.F90#L150-L241 I think the culprit is a missing case (optNStep)
; I don't see any singular optN____
cases at all, so presumably nsecond
, nminute
, nhour
, nday
, nmonth
, and nyear
will all trigger this error
@mnlevy1981 - I've used every time step output many times with no problem. Can you please let me know how to reproduce your case?
@mnlevy1981 - according to @jedwards4b you need nsteps - but we should be updating CMEPS to handle either one.
I'm okay with using nsteps
instead of nstep
(and that did work for me), but the valid_values
listed in the XML file make it seem like either should work:
<entry id="HIST_OPTION" value="nsteps">
<type>char</type>
<valid_values>none,never,nsteps,nstep,nseconds,nsecond,nminutes,nminute,nhours,nhour,ndays,nday,nmonths,nmonth,nyears,nyear,date,ifdays0,end</valid_values>
<desc>Sets driver snapshot history file frequency (like REST_OPTION)</desc>
</entry>
It's great if the plan is to update CMEPS to handle either; if that ends up getting put on the back burner, could we update the valid_values
so that nstep
is no longer accepted? Otherwise I'm happy to leave everything as-is and close this issue when the singular value is acceptable again
@mlevy - thanks for catching this. I will update CMEPS to handle either.
I am trying to run for a couple of days with coupler history file every time step to see what fields coming into MOM6 look like. I ran
and now I'm
PET####.ESMF_LogFile
output with messages likeThe job appeared to hang, so I killed it after ~10 minutes. Currently trying with
nsteps
instead (nstep
is listed as a valid option inenv_run.xml
but maybe CMEPS only likes the plural option?). If this fails, I'll trynhours
.I'm running a modified
cesm2_3_beta09
sandbox, with thecmeps0.13.68
tag (andcime6.0.46
, if that matters)