CDO

Hi Barron,

CDO needs a time dimension and do not know that's TSTEP. The warning you got points exactly to the problem:

Warning (cdf_check_vars) : 4 dimensional variables without time dimension are not supported, skipped variable NOX!

Try to rename the time dimension with NCO's ncrename, first:

ncrename -d TSTEP,time ../ioapi/THU_cn27_2015_PPCB.nc outfile.nc

-Karin

Hi Karin and other,

The question is, "Is there a way to help CDO identify the time dimension?" As I said, I can rename TSTEP to time and it works fine (see 3rd sentence of original post). Right now, CDO infers the time dimension either by unlimited, by name ('time' or 'Time') or by units (see lines 42357 and 39159 of cdilib.c).

I am pointing to a usecase where the user knows the dimension name and can direct CDO. One solution would be to provide a switch or environmental variable that provides a list of time names. For example, replacing line 39166's two str_is_equal statements with a iteration over a list. The list could be, by default, ('time', 'Time'). A user could override with an environmental variable or command line option to provide a new list -- e.g., ('t', 'time', 'Time') or in my case ('time', 'Time', 'TSTEP').

This feature would help many others. I have seen examples in the forum where time was labeled 'z'. While that seems odd to me, this approach would allow the user to specify z as a time dimension. This will help users to not have to modify files that may be created by other programs (in this case CMAQ).

Below, I have created a patch (untested) that would move the names to an array. This allows for a variable number of timenames, but does not address the population of timenames from an option/environmental variable. The next step would be to populate the timenames array from an option or environmental variable.

Is there currently a cdiGetenvList function like the cdiGetenvInt?

$ diff -p cdilib.c ~/Downloads
*** cdilib.c    2018-04-03 08:45:02.909850100 -0400
--- /home/barronh/Downloads/cdilib.c    2018-04-03 08:44:49.514480000 -0400
*************** static
*** 39159,39169 ****
  int cdf_time_dimid(int fileID, int ndims, int nvars)
  {
    char dimname[80];
    for ( int dimid = 0; dimid < ndims; ++dimid )
      {
        dimname[0] = 0;
        cdf_inq_dimname(fileID, dimid, dimname);
!       if ( str_is_equal(dimname, "time") || str_is_equal(dimname, "Time") ) return dimid;
      }

    for ( int varid = 0; varid < nvars; ++varid )
--- 39159,39174 ----
  int cdf_time_dimid(int fileID, int ndims, int nvars)
  {
    char dimname[80];
+   char * timenames [] = { "time", "Time", "TSTEP" };
+   int ntimenames = sizeof(timenames) / sizeof(timenames[0]);
    for ( int dimid = 0; dimid < ndims; ++dimid )
      {
        dimname[0] = 0;
        cdf_inq_dimname(fileID, dimid, dimname);
!       for ( int timenameid = 0; timenameid < ntimenames; ++timenameid )
!         {
!           if ( str_is_equal(dimname, timenames[timenameid]) ) return dimid;
!         }
      }

    for ( int varid = 0; varid < nvars; ++varid )

Hi Barron!

Although your idea is appealing in the first place I have some arguments against it:

1. CDO requires the netcdf input to be CF-compliant. This is a well established and known standard. Just because modellers around the world still not follow the simplest rules for variable meta data like names and units, CDO should not jump in to fill the gab, they opened. Instead model developers should be asked, why they still do not follow these rules - writing general tools without a propper standard is impossible.
2. IMO if we support these kind of non-standard settings, we will end up with a source code very hard to maintain. ENV-variables may occure everywhere and ppl would love to get support for their personal data layout, no matter how weird it may be. CDO would transform into a general netcdf tool, and this is not the target. NCO does a very good job here. BTW, CDO already offers quite some operators to set meta data like names, units, time axes and so on.
3. Some technical reasoning: the netcdf-standard allows to change meta data (dimension names, variable/global attributes) without re-writing the data. the NCOs support this nice feature, which let them work incredibly fast on huge data sets (in case there is enough space left in the file area for meta data). CDO does not support this. Hence there already is a pretty complete toolset to change all kinds of meta data - it's just not CDO. And I dont see a good reason to rebuild this from scratch into CDO - would be a lot of work, just to make user do with CDO what they already can without it.
4. Even from the user perpective I dont see a benifit besides the need to install another tool. User would have to learn (a) NCO (tons of docu and examples) or (b) a completely new way of fine-tuning CDO calls through environment variables (docu still to be written).

hth
ralf

I certainly respect that perspective. Item 4 is the only one I take exception with (and the last part of 3 :).

Item 4: From the user perspective, I want to remap. With this feature, I need cdo. Without this feature, I need to install cdo and nco. nco is great for changing meta data, but that is not the root of the request.

Item 3: minor distinction, but you already support modifying the meta data (setgrid, settaxis, etc). This is simply letting the user access functions you already have.

Thanks for consideration. Obviously, this is just one users opinion.