'TransientCurveGrid' object has no attribute 'getWeights'

[yyplanton]

Hi,
I am trying to use the cdutil.averager function on cmip5 datasets.
Out of 43 models tested, 6 (BBC and GFDL models) return the same error when averaging oceanic variables (like 'tos')
I am using Transient Variables (MV2s) so weights must be generated:
Traceback (most recent call last):
File "test.py", line 15, in
d_ave_xy = CDUTILaverager(tos, axis='xy')
File "/usr/local/uvcdat/2.4.0/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/genutil/averager.py", line 1078, in averager
filled_wtoptions = __check_weightoptions(V, axis, weights)
File "/usr/local/uvcdat/2.4.0/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/genutil/averager.py", line 359, in __check_weightoptions
weightoptions = area_weights(x,axisoptions)
File "/usr/local/uvcdat/2.4.0/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/genutil/averager.py", line 159, in area_weights
latwts, lonwts = dsgr.getWeights()
AttributeError: 'TransientCurveGrid' object has no attribute 'getWeights'

Here is the grid:

tos.getGrid()
<TransientCurveGrid, id: grid_1, shape: (232, 360)>

I do not have the same problem when using other TransientCurveGrid models like CNRM-CM5

Models returning errors:
bcc-csm1-1-m, bcc-csm1-1, GFDL-CM2p1, GFDL-CM3, GFDL-ESM2G, GFDL-ESM2M
A common point between these models is that they use GFDL’s Modular Ocean Model (MOM) or Generalized Ocean Layer Dynamics (GOLD) (only GFDL-ESM2G).

Is there a problem with GFDL's ocean models? Is this error known?

Thanks
Yann

[jypeter]

I'm not even sure cdutil.averager can handle irregular grids. @doutriaux1 ?

It's probably better to use the areacello variable and compute the weights yourself, in that case

[dnadeau4]

@doutriaux1 can you help @yyplanton with this question.

[lee1043]

@gleckler1 @durack1 Any comment welcome. Maybe areacello variable should be adapted? Or maybe using esmf regrid to interpolatetos to regular grid as pre-process would be helpful?

[gleckler1]

@yyplanton GFDL did not use CMOR in CMIP5. While they were able to mimic it very well, we have run across subtle discrepancies. Can you show us your CDAT code, i.e., what is in your function CDUTILaverager?

[gleckler1]

@yyplanton @jypeter You are right JY, use MV.multiply(areacello, tos) ... cdutil does not yet work on native grids

[doutriaux1]

@yyplanton cdutil.averager only works with rectinlinear grids, not oceanic grids. There's no plans to immediately adapt it, although it's a good idea. But you would need to somehow provide weights. @dnadeau4 could we use esmf to generate the weights?
@yyplanton one way I have seen avergaing done in the past is to *trick a regridder, create a target grid with one cell only covering the whole globe, then regird your data to this grid and voila

globalGrid = cdms2.createGlobalMeanGrid(cdms2.createGaussianGrid(128))
mean = data.regrid(globalGrid)

[yyplanton]

Ok, thanks for the answers.
@doutriaux1, as I said, cdutil.averager works for CNRM-CM5 and some ther models using TransientCurveGrid. In the case of CNRM-CM5, the oceanic grid is a NEMO orca1 grid. But I am working on the equatorial Pacific and in this region the NEMO orca1 grid is very close to a rectinlinear grid.

[jypeter]

I'm surprised that it works with a TransientCurveGrid! @doutriaux1 @dnadeau4 does cdutil.averager check that it can safely operate? Maybe it should raise an exception when that's not the case. I have found an old issue about that CDAT/cdat#1464

I have just remembered an old related question: in the case when cdutil.averager is passed a regular grid, that has no bounds (because there were no bounds in the input file) and setAutoBounds is off, does averager now print a nice error message for the user, or does it still throw a scary (for beginning users!) traceback?

[doutriaux1]

@yyplanton I am surprised it works for curvilinear grid, can you send me the line you use. I suspect what you're actually doing is a straight average of the cell, not an area weighted average.

[lee1043]

It is interesting to see that CNRM-CM5 is working with `cdutil.averager'.

For curiosity, I simply visualized tos field itself by using below script.

import cdms2, cdutil, vcs

modpath = '/work/lee1043/ESGF/xmls/cmip5/historical/mo/VAR/cmip5.MOD.historical.r1i1p1.mo.VAR.xml'
modname = 'CNRM-CM5'
varname = 'tos'

filename = modpath.replace('MOD',modname).replace('VAR',varname)
print filename

f = cdms2.open(filename)
d = f(varname)

x = vcs.init()
x.plot(d)
x.png('test_'+modname+'_'+varname+'.png')

VCS plot (CDAT 3.0 beta version):

Ncview:

@doutriaux1 Why VCS plot show zonal band of missing values? Other question would be, (sorry not related to this issue though) does CDAT 3.0 use boxfill with discrete color as default?