period of list exceeds modulo period

[yz3062]

What version of the code are you using?
I'm running MOM6_examples/ice_ocean_SIS2/OM_1deg. I'm hoping to run the model for 50-100 years or until it reaches equilibrium.

Describe every step you took leading up to the problem:
In order to make the model to run for multiple years, I swapped the JRA forcing files in /INPUT/ from those in reanalysis-sample.tgz on the dataset FTP server to those in reanlysis.tgz. The files in reanlysis.tgz are padded in addition to its original one-year length. I also added modulo=" " as an attribute to all the JRA files, according to this post, in order for the model to loop over the one-year JRA forcing files as needed. Here's what one of the JRA files looks like:

ncdump -h huss_JRA_sample.nc | grep time
time = UNLIMITED ; // (2921 currently)
double time(time) ;
time:bounds = "time_bnds" ;
time:units = "days since 1900-01-01 00:00:00" ;
time:calendar = "gregorian" ;
time:axis = "T" ;
time:long_name = "time" ;
time:standard_name = "time" ;
time:modulo = " " ;
double time_bnds(time, bnds) ;
float huss(time, lat, lon) ;
huss:cell_methods = "area: mean time: point" ;
:history = "Thu Jul 31 19:45:22 2025: ncatted -a modulo,time,c,c, huss_JRA_sample.nc\n",

Describe your problem or question:
Before I added the module=" " attribute, the run fails at exactly the one-year mark. After I added the attribute, the run gives the following error after a couple of minutes:

FATAL from PE 0: time_interp_external 2: period of list exceeds modulo period,file=./INPUT/JRA_rlds.nc,field=rlds

This seems to be the same error reported previously in this post, but it can't be determined how they resolved the issue. I suspected it was an issue with the calendar (the JRA files are in gregorian, while the model runs on julian), but changing the calendar didn't help.

 

[yz3062]

Update: I swapped out the JRA forcing files and swapped in the corresponding forcing files from OM4_025/INPUT by consulting the respective data_table files. While I still don't know the root cause of the fatal error, this fix at least allowed the model to run beyond the one-year mark.

 

[marshallward]

My best guess is a mismatch between your time axis length (2921 = 3hr * 365 day + 1) vs gregorian, which may be 365 or 366 depending on the year. 1900 is not a leap year, but maybe the extra 3hr value is throwing it off.

The inputs in OM4_025 are better configured for these repeated multiyear runs. You may need to be more careful about calendar settings if you want to drop in JRA forcing.