Re: ncl_convert2nc and cdo

Hi Daran,

Thanks for the suggestion. I'm not sure CDO is quite that particular
about a time dim/var and CF for all operations, but I went ahead and
gave it a shot anyway. Unfortunately, this has led me back to a problem
spawned by ncrename that breaks CDO in a completely different way.

ncrename -d initial_time0_hours,time -v initial_time0_hours,time
input.nc input_ren.nc
cdo sellonlatbox,-90,-55,0,360 input_ren.nc output_ren.nc
cdo sellonlatbox: Unsupported grid type: generic

cdo sellonlatbox (Abort): Unsupported grid type!

As I've documented in a thread at the NCO discussions site
(http://sourceforge.net/projects/nco/forums/forum/9830/topic/5135067),
the ncrename adds a generic grid to the file, which leads to the above
CDO failure. I haven't had time to do the further testing requested in
the NCO thread (mostly because I can get what I want another way).

To summarize (so far):
1) ncl_convert2nc seems to create a file that breaks CDO sellonlatbox in
one way
2) ncrename of this file (to set time var) adds a spurious (?) grid that
breaks CDO sellonlatbox in another way (and suggests something odd in
ncrename; further debugging pending)
3) avoiding ncl_convert2nc (i.e., doing grb->nc w/cdo) avoids both (1)
and (2) which at least suggests something odd in ncl_convert2nc

As I've said, I have a working methodology, but it'd be nice to know why
I'm seeing these other problems.

Happy to try any other ideas and/or things I can do to get more
debugging info out of these tools.

Cheers,
Dave

Daran Rife said the following on 4/27/12 1:25 PM:
> Hi David,
>
> > From looking at your netCDF header, it is clear that your file
> is not Climate Forecast (CF) compliant.
>
> http://cf-pcmdi.llnl.gov/
>
> In particular, your file does not have the "time" coordinate
> defined according to the CF specifications.
>
> http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.htm
> l#time-coordinate
>
> CDO requires that your file conform to the CF convention,
> and must include the time coordinate. You have a "time"
> like coordinate, but these do not appear to conform to the CF
> convention. Note that your time coordinate must be named
> "time" as CDO will only recognize this. Coordinate (or
> record dimensions) can easily be renamed using netCDF
> Operators utility called ncrename.
>
> http://nco.sourceforge.net/nco.html#ncrename-netCDF-Renamer
>
> Syntax looks similar to this:
>
> % ncrename -d old_coord_name,new_coord_name.
>
> I do not recall whether NCL can be used to change the name of
> a coordinate variable, so I'll have to defer to one of the
> gurus for that.
>
> I hope this helps.
>
> Daran
>
> Daran Rife
> Head of Mesoscale Modeling
> GL Garrad Hassan
>
> 9665 Chesapeake Drive, Suite 435, San Diego, CA 92123, USA
> Tel: +1 303 271 1450 / Fax: +1 303 271 1450 / Mobile: +1 303 968 6821
> www.gl-garradhassan.com
>
> This email is issued on behalf of Garrad Hassan America, Inc. (trading
> as GL Garrad Hassan) and is subject to the GL Garrad Hassan email
> disclaimer (http://www.gl-garradhassan.com/emaildisclaimer). Garrad
> Hassan America, Inc. is registered in America No. 94-3402236 Registered
> Office: 45 Main Street, Suite 302, Peterborough, NH 03458, USA
>
> --
>
> Message: 9
> Date: Thu, 26 Apr 2012 16:04:07 -0600
> From: "David B. Reusch"<dreusch@ees.nmt.edu>
> Subject: ncl_convert2nc and cdo
> To: ncl-talk@ucar.edu
> Message-ID:<4F99C657.2000502@ees.nmt.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hello,
>
> I don't know if this is a NCL problem or a CDO problem, but since I can
> get it to work if I don't use the output of ncl_convert2nc, I thought
> I'd start with NCL. The problem is that I get the following when trying
>
> to use CDO on a netCDF file created by ncl_convert2nc:
>> cdo sellonlatbox,-90,-55,0,360 input.nc output.nc
>> cdf_get_vara_double : ncid = 65536 varid = 6
>>
>> Error (cdf_get_vara_double) : NetCDF: Index exceeds dimension bound
> If I apply cdo to the original grb file, I do not get this error.
>> cdo -f nc -t ecmwf sellonlatbox,-90,-55,0,360 input.grb output2.nc
>> cdo sellonlatbox: Processed 191889408 values from 1 variable over 1464
>> timesteps. ( 1.38s )
> The ncl_convert2nc command works without obvious errors:
>> ncl_convert2nc input.grb
>> Processing file: input.grb...
>> Copyright (C) 1995-2011 - All Rights Reserved
>> University Corporation for Atmospheric Research
>> NCAR Command Language Version 6.0.0
>> The use of this software is governed by a License Agreement.
>> See http://www.ncl.ucar.edu/ for more details.
>> Classic model NetCDF does not support string types, converting
>> initial_time0 to a character array
>> Dimension 'ncl_strlen_0' will be added
> The original file is a forecast file from ERA-Interim
> (ei.oper.fc.sfc.regn128sc.strd_175.1980). I copied it to input.grb to
> save typing!
>
> All of this is on bluefire. Files can be found in
> /glade/user/dbr/fc/ncl_cdo_test. See below for the ncdump output for
> the NCL-converted file.
>
> I've found alternate methods to get my needed processing done so this
> isn't an urgent problem. Mostly I'm just curious whether this is NCL or
>
> CDO (v1.5.3), and what the underlying cause might be.
>
> Thanks,
> Dave
>
> ncdump output:
> netcdf input {
> dimensions:
> initial_time0_hours = 732 ;
> forecast_time1 = 2 ;
> g4_lat_2 = 256 ;
> g4_lon_3 = 512 ;
> ncl_strlen_0 = 18 ;
> variables:
> char initial_time0(initial_time0_hours, ncl_strlen_0) ;
> initial_time0:NCL_converted_from_type = "string" ;
> initial_time0:units = "mm/dd/yyyy (hh:mm)" ;
> initial_time0:long_name = "Initial time of first
> record" ;
> int forecast_time1(forecast_time1) ;
> forecast_time1:units = "hours" ;
> forecast_time1:long_name = "Forecast offset from
> initial time" ;
> float g4_lon_3(g4_lon_3) ;
> g4_lon_3:La1 = 89.463f ;
> g4_lon_3:Lo1 = 0.f ;
> g4_lon_3:La2 = -89.463f ;
> g4_lon_3:Lo2 = 359.297f ;
> g4_lon_3:Di = 0.7031252f ;
> g4_lon_3:N = 128.f ;
> g4_lon_3:units = "degrees_east" ;
> g4_lon_3:GridType = "Gaussian Latitude/Longitude Grid"
> ;
> g4_lon_3:long_name = "longitude" ;
> float g4_lat_2(g4_lat_2) ;
> g4_lat_2:La1 = 89.463f ;
> g4_lat_2:Lo1 = 0.f ;
> g4_lat_2:La2 = -89.463f ;
> g4_lat_2:Lo2 = 359.297f ;
> g4_lat_2:Di = 0.7031252f ;
> g4_lat_2:N = 128.f ;
> g4_lat_2:units = "degrees_north" ;
> g4_lat_2:GridType = "Gaussian Latitude/Longitude Grid"
> ;
> g4_lat_2:long_name = "latitude" ;
> double initial_time0_encoded(initial_time0_hours) ;
> initial_time0_encoded:units = "yyyymmddhh.hh_frac" ;
> initial_time0_encoded:long_name = "initial time encoded
>
> as double" ;
> double initial_time0_hours(initial_time0_hours) ;
> initial_time0_hours:units = "hours since 1800-01-01
> 00:00" ;
> initial_time0_hours:long_name = "initial time" ;
> float STRD_GDS4_SFC(initial_time0_hours, forecast_time1,
> g4_lat_2, g4_lon_3) ;
> STRD_GDS4_SFC:parameter_number = 175 ;
> STRD_GDS4_SFC:parameter_table_version = 128 ;
> STRD_GDS4_SFC:gds_grid_type = 4 ;
> STRD_GDS4_SFC:level_indicator = 1 ;
> STRD_GDS4_SFC:_FillValue = 1.e+20f ;
> STRD_GDS4_SFC:units = "W m**-2 s" ;
> STRD_GDS4_SFC:long_name = "Surface thermal radiation
> downwards" ;
> STRD_GDS4_SFC:center = "European Center for
> Medium-Range Weather Forecasts (RSMC)" ;
>
> // global attributes:
> :creation_date = "Thu Apr 26 15:49:03 MDT 2012" ;
> :NCL_Version = "6.0.0" ;
> :system = "AIX be1005en 3 5 00CBF2314C00 AIX" ;
> :conventions = "None" ;
> :grib_source = "input.grb" ;
> :title = "NCL: convert-GRIB-to-netCDF" ;
> }
>
>
>
> _______________________________________________
> ncl-talk mailing list
> List instructions, subscriber options, unsubscribe:
> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>

-- 
Associate Research Professor of Climatology
Dept of Earth and Environmental Science
MSEC 304; 801 Leroy Place
New Mexico Tech
Socorro, NM 87801
_______________________________________________
ncl-talk mailing list
List instructions, subscriber options, unsubscribe:
http://mailman.ucar.edu/mailman/listinfo/ncl-talk