sidivvel Simon time axis

[oloapinivad]

I have noticed with QA-DKRZ time analysis - #504 comment 31 - that actually the sidivvel variable from SImon table has likely a wrong time axis associated with it.

Indeed, QA-DKRZ highlights that the file starts from February instead of January: however there are twelve records and if you inspect it you will see that:

$ cdo sinfo sidivvel_SImon_EC-Earth3_historical_r4i1p1f1_gn_185002-185101.nc
   File format : NetCDF4 classic zip
    -1 : Institut Source   T Steptype Levels Num    Points Num Dtype : Parameter ID
     1 : unknown  EC-Earth3 v instant       1   1    105704   1  F32z : -1            
   Grid coordinates :
     1 : curvilinear              : points=105704 (362x292)
                        longitude : 0.04980469 to 359.9949 degrees_east  circular
                         latitude : -78.57995 to 89.74177 degrees_north
                        available : cellbounds
                          mapping : undefined
                                i : 1 to 362 by 1 1
                                j : 1 to 292 by 1 1
   Vertical coordinates :
     1 : surface                  : levels=1
   Time coordinate :  12 steps
     RefTime =  1850-01-01 00:00:00  Units = days  Calendar = proleptic_gregorian
  YYYY-MM-DD hh:mm:ss  YYYY-MM-DD hh:mm:ss  YYYY-MM-DD hh:mm:ss  YYYY-MM-DD hh:mm:ss
  1850-02-01 00:00:00  1850-03-01 00:00:00  1850-04-01 00:00:00  1850-05-01 00:00:00
  1850-06-01 00:00:00  1850-07-01 00:00:00  1850-08-01 00:00:00  1850-09-01 00:00:00
  1850-10-01 00:00:00  1850-11-01 00:00:00  1850-12-01 00:00:00  1851-01-01 00:00:00
cdo sinfo: Processed 1 variable over 12 timesteps [1.54s 30MB]

So it seems we have instantaneous values at the END of the month: the frequency of sidivvel is monPt, which means "sampled monthly, at specified time point within the time period". Well, it may be okay having at the end of the month but I imagine it would be more correct to have it at the MIDDLE of the month.

That's not all, since the variables is produced by XIOS itself: here the time axis is - as it may be expected - in the middle of the month. Could it be that ece2cmor is rewriting the time axis for this variable?

$ cdo sinfo -selname,sidivvel chis_1m_18500101_18501231_lim_grid_T_2D.nc
cdo(2) selname: Process started
Warning (find_time_vars): Found more than one time variable, skipped variable time_centered!
Warning (find_time_vars): Found more than one time variable, skipped variable time_instant!
   File format : NetCDF4
    -1 : Institut Source   T Steptype Levels Num    Points Num Dtype : Parameter ID
     1 : unknown  unknown  v instant       1   1    105704   1  F32  : -4            
   Grid coordinates :
     1 : curvilinear              : points=105704 (362x292)
                          nav_lon : -179.9965 to 179.9903 degrees_east
                          nav_lat : -78.57995 to 89.74177 degrees_north
                        available : cellbounds area
   Vertical coordinates :
     1 : surface                  : levels=1
   Time coordinate :  12 steps
     RefTime =  1800-01-01 00:00:00  Units = seconds  Calendar = gregorian  Bounds = true
  YYYY-MM-DD hh:mm:ss  YYYY-MM-DD hh:mm:ss  YYYY-MM-DD hh:mm:ss  YYYY-MM-DD hh:mm:ss
  1850-01-16 12:00:00  1850-02-15 00:00:00  1850-03-16 12:00:00  1850-04-16 00:00:00
  1850-05-16 12:00:00  1850-06-16 00:00:00  1850-07-16 12:00:00  1850-08-16 12:00:00
  1850-09-16 00:00:00  1850-10-16 12:00:00  1850-11-16 00:00:00  1850-12-16 12:00:00
cdo(2) selname: Processed 1268448 values from 25 variables over 12 timesteps

Could someone confirm this?

[goord]

That must be the case, but I don't get that because nemo2cmor is supposed to read all time information from the XIOS output files...

[goord]

Paolo could you send me somehow that sea-ice file?

[oloapinivad]

Here is the output https://www.dropbox.com/s/vgd9ucnkqyvuaar/chis_1m_18500101_18501231_lim_grid_T_2D.nc?dl=0

Here is the cmorised file:
https://www.dropbox.com/s/dqwghqw00h4walm/sidivvel_SImon_EC-Earth3_historical_r4i1p1f1_gn_185002-185101.nc?dl=0

Let me know if you have problems in retrieving them...

[goord]

Hi Paolo, CDO prints the time_centered coordinate there, whereas ece2cmor3 uses the time_instant coordinate in the model output for this instantaneous variable, so I believe we are attaching the correct time stamps to the sidivvel samples. CDO just picks the wrong time coordinate (it's also reporting about this).

That leaves the question whether the sample points are appropriately chosen in the XIOS configuration... I think it's kind of arbitrary so no big deal?

[oloapinivad]

Hi Gijs, I see what you mean. I am however a bit puzzled because when you inspect the variable with ncdump you can see that in the original NEMO file there are both time_instant and time_counter
However, sidivvel (as all the other variables) is defined on time_counter.

ncdump -h chis_1m_18500101_18501231_lim_grid_T_2D.nc | grep sidivvel
	float sidivvel(time_counter, y, x) ;
		sidivvel:standard_name = "divergence_of_sea_ice_velocity" ;
		sidivvel:long_name = "Divergence of the sea-ice velocity field" ;
		sidivvel:units = "s-1" ;
		sidivvel:online_operation = "instant" ;
		sidivvel:interval_operation = "1 month" ;
		sidivvel:interval_write = "1 month" ;
		sidivvel:cell_methods = "time: point" ;
		sidivvel:cell_measures = "area: area" ;
		sidivvel:_FillValue = 1.e+20f ;
		sidivvel:missing_value = 1.e+20f ;
		sidivvel:coordinates = "time_instant nav_lat nav_lon" ;

Shouldn't be on time_instant ?

In any case, I don't think we can upload the variable on the ESGF in the current format - especially if the problem is in the XIOS side. @zklaus - you are by far the more expert - what do you think of this? thanks to all!

[goord]

Hi Paolo, both time_centered and time_instant depend on the dimension time_counter (as do all variables). So the connection between a variable and its time stamps is purely via metadata fields, such as the "coordinates" attribute you see attached to sidevvel.

[oloapinivad]

Perfectly clear, thanks. I didn't spot the "coordinates" dimension.
So the files are correctly handled by ece2cmor, the question is whether or not is ok to publish them since they are saved at the end of the month (and if we can fix this for future runs)

[zklaus]

Note that there is also a variable time_counter associated with the dimension time_counter that becomes the first dimension coordinate of sidivvel and all the other variables.

There definitely are problems with the xios file. Unfortunately I lack a bit of time now to examine it more closely. For now, I would not publish this data.

[treerink]

See also issue 690 at EC-Earth portal.