cdutil.ANNUALCYCLE.climatology fails with "months since *" time axis

[durack1]

In a file that I downloaded, the time axis looks like:

netcdf argo_2005-2017_grd {                                                                                   
dimensions:                                                                                                   
        LONGITUDE = 360 ;                                                                                     
        LATITUDE = 180 ;                                                                                      
        LEVEL = 27 ;                                                                                          
        TIME = UNLIMITED ; // (150 currently)                                                                 
variables:                                                                                                    
...
        float TIME(TIME) ;
                TIME:units = "months since 2005-01-15" ;
                TIME:title = "Months in Monthly Means" ;
                TIME:long_name = "Months in Monthly Means" ;
                TIME:axis = "T" ;
...

When attempting to use cdutil.ANNUALCYCLE.climatology I get the following error:

import cdms2, cdutil
f = 'argo_2005-2017_grd.nc'
fH = cdms2.open(f)
t = fH('PTEMP',time=('2005','2017'))
# Calculate annualCycle climatology
tAnClim = cdutil.ANNUALCYCLE.climatology(t)

Traceback (most recent call last):                                                             
  File "makeObsClims.py", line 56, in <module>                                                 
    tAnClim = cdu.ANNUALCYCLE.climatology(t)                                                   
  File "/export/duro/anaconda2/envs/uvcdat2120/lib/python2.7/site-packages/cdutil/times.py", line 1451, in climatology
    tmp = TimeSlicer.get(self,slab,self.seasons[i],criteriaarg,statusbar=statusbar,weights=True,sum=sum)                 
  File "/export/duro/anaconda2/envs/uvcdat2120/lib/python2.7/site-packages/cdutil/times.py", line 433, in get         
    slices,bounds,norm=self.slicer(tim,slicerarg)                                                                        
  File "/export/duro/anaconda2/envs/uvcdat2120/lib/python2.7/site-packages/cdutil/times.py", line 680, in monthBasedSlicer
    b0=cdtime.reltime(bnds[i][0],units)                                                                                      
TypeError: 'NoneType' object has no attribute '__getitem__'

@dnadeau4 @doutriaux1

[dnadeau4]

Can you try with other units than "months since"? I think it is the problem. "months since" is not cf-1 compliant.

[durack1]

@dnadeau4 it seems I will have to impose a new time axis, but it would be great if the code either reported out the issue to a user, or even better, attempted to regenerate a valid time axis, threw a warning to a user and calculated the result anyway

[dnadeau4]

I think the difficulties with months since are "bounds" in the timeSlicer which are very difficult to handle especially in climatology. @doutriaux1 knows a lot about the timeSlicer.

[durack1]

@dnadeau4 as an FYI, the file in question doesn't include bounds, but I assume the code would need to generate these

[doutriaux1]

@durack1 that is your issue, no bounds, it used to throw a nicer error message.
And NO cdat will NEVER/EVER "fix" the data for the user. All we do is let the user know about the software being unable to go forward with the data as is and we thrive to provide a suggestion of what could be done about it. Obviously fail here.

[durack1]

@doutriaux1 fair enough, it would be useful to catch these months since * cases generically then, and throw an error saying this non-CF compliant time unit cannot be processed. I've now generated a workaround, so could throw that back to your for a bug fix problem data section of the website

[doutriaux1]

months since is not the issue. It's valid and very useful actually in this context when you want to weight every months the same in a season.

[durack1]

@doutriaux1 ok a question, if you believe these are valid, then if I inject a cdms2.setAutoBounds(1) should this work?

[doutriaux1]

no. It's actually why we stop generating month automatically. The bounds will be generated half way between the values so half december to half jan and you will end up with wrong results. What you really want is cdutil.setTimeBoundsMonthly(data)

[durack1]

@doutriaux1 @dnadeau4 ok so it works! Nice!

In [4]: import cdms2, cdutil, os
   ...: os.chdir('/export/duro/tmp')
   ...: f = 'argo_2005-2017_grd.nc'
   ...: fH = cdms2.open(f)
   ...: t = fH('PTEMP',time=('2005','2017'))
   ...: # Set time bounds to monthly
   ...: cdutil.setTimeBoundsMonthly(t)
   ...: # Calculate annualCycle climatology
   ...: tAnClim = cdutil.ANNUALCYCLE.climatology(t)

In [5]: t.shape
Out[5]: (145, 27, 180, 360)

In [6]: tAnClim.shape
Out[6]: (12, 27, 180, 360)

I wonder if time:units = "months since *, if you try cdutil.setTimeBoundsMonthly(data) as a first pass to attempt to process things for the user?

[jypeter]

Can you print a warning and stop, when the units are "months since *" and there are no time bounds? The warning just has to tell the user that the bounds are missing in the file, but that they can be generated by hand with cdutil.setTimeBoundsMonthly

What's the default for setAutoBounds this days? Is it on or off by default?

I used to get this 'NoneType' object has no attribute '__getitem__' error when using cdutil.averager on data that had no lon and lat bounds (when setAutoBounds was off by default). I knew what to do in that case, but my users were usually lost. Can somebody check if cdutil.averager will now print a useful warning as well?

[doutriaux1]

@jypeter that's what i believed it used to di. I have to see why it's not raising a warning when bounds are missing any longer.

[github-actions]

Marking issue as stale, since there has been no activity in 30 days.

Unless the issue is updated or the 'stale' tag is removed, this issue will be closed in 7 days.

[durack1]

@jasonb5 this could be solved if cdtime better dealt with this non-CF (http://cfconventions.org/cf-conventions/cf-conventions.html) time axis. At minimum an error or warning being thrown noting the time axis is does not conform to standards would be a usability improvement

[github-actions]

Marking issue as stale, since there has been no activity in 30 days.

Unless the issue is updated or the 'stale' tag is removed, this issue will be closed in 7 days.