GitLab

For the SMHI piControl r1i1p1f1 run (#4 (closed)), nctime reports a broken time series for variables:

3hr:    tos
Oday:   omldamax, tos, tossq
SIday:  siconc, siu, siv, sithick

More specifically, the time series is broken like:

    siconc_SIday_EC-Earth3-Veg_piControl_r1i1p1f1_gn_19870101-19871218.nc
    BREAK
    siconc_SIday_EC-Earth3-Veg_piControl_r1i1p1f1_gn_19880101-19881231.nc

for all of the variables, i.e. always between the end of 1987 and beginning of 1988.

Checking the raw NEMO output, it turns out that indeed all daily files for 1987 (leg 138 of b601) are shorter (end on December 18th):

> for f in 138/b601_1d_19870101_19871231_*.nc ; do echo -n "$f: "; ncdump -h $f | grep "time_counter ="; done
138/b601_1d_19870101_19871231_lim_grid_T_2D.nc: 	time_counter = UNLIMITED ; // (352 currently)
138/b601_1d_19870101_19871231_lim_grid_U_2D.nc: 	time_counter = UNLIMITED ; // (352 currently)
138/b601_1d_19870101_19871231_lim_grid_V_2D.nc: 	time_counter = UNLIMITED ; // (352 currently)
138/b601_1d_19870101_19871231_opa_grid_T_2D.nc: 	time_counter = UNLIMITED ; // (352 currently)

The same is true for the 3hourly file (which contains only tos). This suggests that even the monthly files may somehow be affected, even though there is no formal problem as of now.

It is not known, at this stage, why the last days are missing. The corresponding NEMO log file indicates that the run continued to DATE Y/M/D = 1987/12/31 nday_year = 365 and the IFS files for the same year do not show any irregularities (as far as checked).