data-qa issueshttps://git.smhi.se/uwe.fladrich/data-qa/-/issues2019-07-11T08:21:35Zhttps://git.smhi.se/uwe.fladrich/data-qa/-/issues/9ssp1-1.9: Missing output control files2019-07-11T08:21:35ZUwe Fladrichssp1-1.9: Missing output control filesThere are no output control files present in the EC-Earth trunk for the ssp1-1.9 scenario, which formally prevents cmorisation. I guess the reason is that this scenario is not prioritised, but at least SMHI has made the r1i1p1f1 member f...There are no output control files present in the EC-Earth trunk for the ssp1-1.9 scenario, which formally prevents cmorisation. I guess the reason is that this scenario is not prioritised, but at least SMHI has made the r1i1p1f1 member for it.
My guess is that, at least for cmorisation, the `varlist.json` file from the other ScenarioMIP runs of the same model configuration (`EC-EARTH-Veg` in our case), would be fine, but I would like to confirm. Can I use one of the others (e.g. `cmip6-data-request-varlist-ScenarioMIP-ssp126-EC-EARTH-Veg.json`) for ssp1-1.9?https://git.smhi.se/uwe.fladrich/data-qa/-/issues/1piControl r1i1p1pf: Time series broken in NEMO files for 19872019-10-09T06:31:33ZUwe FladrichpiControl r1i1p1pf: Time series broken in NEMO files for 1987For the SMHI **piControl** **r1i1p1f1** run (#4), `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:
...For the SMHI **piControl** **r1i1p1f1** run (#4), `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).