search

GEOS-ESM / GEOSgcm_App

Repo containing the scripts for running the GEOS Earth System Model GCM
Apache License 2.0
2 stars 1 forks source link

Non-Reynolds END_DATE code triggered erroneously in Coupled runs #409

Open mathomp4 opened 1 year ago

mathomp4 commented 1 year ago

Recently @zhaobin74 found an issue with this code in gcm_run.j when running coupled:

https://github.com/GEOS-ESM/GEOSgcm_App/blob/3323d122f96f2af8cb1247d9d55432a5b2085f84/gcm_run.j#L649-L660

The issue is that this code was intended for the non-Reynolds Data Oceans which have their SST and ICE data in yearly files. As such, you can't have an experiment that crosses a year boundary. So, gcm_run.j makes sure things stop at the end of the year, then the next submission will continue on with the next year's data.

But, the coupled ocean's grid is also not a Reynolds ocean, so it triggers this for no good reason. If you are running MOM6, you don't need to stop at yearly boundaries since you aren't reading yearly SST/ICE files.

The simple solution is that "if coupled" we delete this code from the resulting gcm_run.j that gcm_setup makes (we do this in other places).

But there are some scenarios which might need this per @zhaobin74. Not sure if that means we'd want to just comment it out?

zhaobin74 commented 1 year ago

@mathomp4, thanks for opening this issue. Here are a bit more contexts.

There are a couple of scenarios where coupled runs will also need this protection. One is the ODAS run which uses segments length longer than 12 days or so. Currently ODAS runs in 5-day segments. Since all the yearly SST files extend further to Jan 10 or 11 of the following year, the days beyond Jan 1 are covered.

Another type of coupled runs are called NOASSIM runs in REPLAY mode. The segments could vary but typically are 1-month. Often these runs start and end at the 1st day of the month so they are not affected by presence or absence of the block. Should one makes NOASSIM runs not ending at the end of the month with longer segments, the run could fail; so that protection is needed.

Maybe using both running coupled and doing replay as the condition for this block is worth considering.

mathomp4 commented 1 year ago

@zhaobin74 Hmm. Unfortunately, while we know if we run COUPLED at setup time, we don't know about replay until run time. I'll have to figure out if that logic is possible.