[VCS] x.plot(variable) fails with poorly defined bounds

[durack1]

This issue is reproducible:

>>> type(soAnom)
<class 'cdms2.tvariable.TransientVariable'>
>>> soAnom.shape
(50, 50, 300, 360)
>>> soAnom.getAxisIds()
['time', 'st_ocean', 'yt_ocean', 'xt_ocean']
>>> x = vcs.init()
>>> x.plot(soAnom[0,0,])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/uvcdat/2.4.0rc1/lib/python2.7/site-packages/vcs/Canvas.py", line 2524, in plot
    a = self.__plot(arglist, keyargs)
  File "/usr/local/uvcdat/2.4.0rc1/lib/python2.7/site-packages/vcs/Canvas.py", line 3628, in __plot
    arglist[0] = self._reconstruct_tv(arglist, keyargs)
  File "/usr/local/uvcdat/2.4.0rc1/lib/python2.7/site-packages/vcs/Canvas.py", line 757, in _reconstruct_tv
    mesh = grid.getMesh()
  File "/usr/local/uvcdat/2.4.0rc1/lib/python2.7/site-packages/cdms2/hgrid.py", line 236, in getMesh
    raise CDMSError, 'No boundary data is available for grid %s'%self.id
cdms2.error.CDMSError: No boundary data is available for grid grid_4

[doutriaux1]

That basically means your data are probably not CF compliant.

[durack1]

I can send you some files if you want to investigate this.. The ungraceful error above isn't a good first impression for someone who wants to use UV-CDAT on their fresh model fields..

[doutriaux1]

well it does tell you you do not have bounds info on your grid. You can't actually expect it to plot the data w/o this info. Let's take a look tomorrow.

[durack1]

@doutriaux1 might be a little quick on the close button there.. I'd reopen until I've provided you enough info to make it a user error case.. 😜

I'd add that the output from the GFDL MOM4p1 ocean model is about as CF-compliant out of the box as any data that I've ever seen.. So this is a good low water mark I think..

[doutriaux1]

well the error message is pointing to this. But I'll reopen to smooth your sleep tonight 😜

[durack1]

@doutriaux1 your comment "well it does tell you you do not have bounds info on your grid. You can't actually expect it to plot the data w/o this info." isn't what I'd expect.. Sure, warnings being thrown to the screen to say bounds aren't there so I'm guessing, but I would expect to see SOMETHING, rather than getting the error above.. In the case of ferret it just throws warnings saying I've guessed everything I needed to.. and throws something up.. That would be my preference..

What does it need bounds for to plot anyway? I mean I'm not trying to calculate area weighted volumes or anything.. Just plot an X x Y matrix..

[durack1]

@doutriaux1 this is what the input file looks like:

$ ncdump -h /work/durack1/Shared/model_data/140220_AusCOM1-0/AusCOM1-0.Salt.Omon.so.00011231-00501231.nc
netcdf AusCOM1-0.Salt.Omon.so.00011231-00501231 {
dimensions:
        time = UNLIMITED ; // (50 currently)
        bound = 2 ;
        st_ocean = 50 ;
        yt_ocean = 300 ;
        xt_ocean = 360 ;
variables:
        double time(time) ;
                time:bounds = "bounds_time" ;
                time:units = "days since 0001-01-01 00:00:00" ;
                time:calendar = "noleap" ;
                time:axis = "T" ;
        double bounds_time(time, bound) ;
        double st_ocean(st_ocean) ;
                st_ocean:units = "meters" ;
                st_ocean:positive = "down" ;
                st_ocean:edges = "st_edges_ocean" ;
                st_ocean:cartesian_axis = "Z" ;
                st_ocean:long_name = "tcell zstar depth" ;
        double yt_ocean(yt_ocean) ;
                yt_ocean:units = "degrees_N" ;
                yt_ocean:long_name = "tcell latitude" ;
                yt_ocean:cartesian_axis = "Y" ;
        double xt_ocean(xt_ocean) ;
                xt_ocean:units = "degrees_E" ;
                xt_ocean:long_name = "tcell longitude" ;
                xt_ocean:cartesian_axis = "X" ;
        float geolat_t(yt_ocean, xt_ocean) ;
                geolat_t:coordinates = "geolon_t geolat_t" ;
                geolat_t:valid_range = "[-91.  91.]" ;
                geolat_t:long_name = "tracer latitude" ;
                geolat_t:cell_methods = "time: point" ;
                geolat_t:units = "degrees_N" ;
                geolat_t:missing_value = 1.e+20f ;
        float geolon_t(yt_ocean, xt_ocean) ;
                geolon_t:coordinates = "geolon_t geolat_t" ;
                geolon_t:valid_range = "[-281.  361.]" ;
                geolon_t:long_name = "tracer longitude" ;
                geolon_t:cell_methods = "time: point" ;
                geolon_t:units = "degrees_E" ;
                geolon_t:missing_value = 1.e+20f ;
        float so(time, st_ocean, yt_ocean, xt_ocean) ;
                so:missing_value = -1.e+20f ;
                so:coordinates = "geolat_t geolon_t" ;

// global attributes:
                :Conventions = "CF-1.0" ;
}

[doutriaux1]

x/yt_ocean do not have the bounds attribute. Not CF compliant.

[durack1]

I might just start using ferret then.. robust plotting software.. 😉

Out of curiosity, why do you need bounds to plot up a matrix? I'm not calculating an area average..?

[durack1]

@doutriaux1 here's the "best guess" output from ferret - something similar in VCS would be great..

[doutriaux1]

@durack1 put this to 3.0 and put it as enhancement so that we fallback to just i/j plot if we can't get the mesh (with a warning)

[doutriaux1]

@durack1 please keep the data around as well. Thx.

[durack1]

@doutriaux1 no problem, I'm working with this data so can provide it when you want to take a look at this again..

[durack1]

@doutriaux1 @dnadeau4 I have hit a similar problem with the data found at:

crunch:/work/cmip5/fx/fx/areacello/cmip5.bcc-csm1-1-m.piControl.r0i0p0.fx.ocn.fx.areacello.ver-v20130307.latestX.xml
or
/cmip5_css01/data/cmip5/output1/BCC/bcc-csm1-1-m/piControl/fx/ocean/fx/r0i0p0/v20130307/areacello/

[doutriaux1]

migrated to vcs

[doutriaux1]

@durack1 data is gone of course, any chance you can find it again?

[doutriaux1]

could it be: http://aims3.llnl.gov/thredds/fileServer/cmip5_css01_data/cmip5/output1/BCC/bcc-csm1-1-m/piControl/fx/ocean/fx/r0i0p0/v20130307/areacello/areacello_fx_bcc-csm1-1-m_piControl_r0i0p0.nc

[doutriaux1]

migrated to vcs