NetCDF issue?

[Matt Alonso]

Thanks Jennifer, I will take a look at this.  Unfortunately the netCDF is a
necessity because the graphics are generated on the fly based on coordinates
passed in based on a user's mouse click on an image.  Using netCDF the image
takes ~1 second to generate and the grib2 takes closer to 15 seconds as a
result of the increased I/O.  I will let you know how it goes.  That EDEF
sounds great; I guess I have been away from GrADS for too long.  Thanks so
much.

Matt

On Mon, Mar 17, 2008 at 4:22 PM, Jennifer Adams <jma at cola.iges.org> wrote:

>
>
> It should do the trick, since you'll be using the 'dtype netcdf' code path
> from 1.9, which is more robust.
>
>
> This is a GREAT example for using the E dimension to simplify your
> analysis! Here are excerpts from your 5D descriptor file:
>
> dset  ^%e.nc
> options template
> tdef 67 linear 00z16mar2008 6hr
> edef 7
> 00 61 12z17mar2008
> 01 61 06z17mar2008
> 02 61 00z17mar2008
> 03 61 18z16mar2008
> 04 61 12z16mar2008
> 05 61 06z16mar2008
> 06 61 00z16mar2008
> endedef
>
> The tdef statement describes a single time axis that spans all 7 ensembles
> (which are reallly forecasts with different initial times).
>
> An additional simplification might be to skip the conversion to NetCDF --
> you can read the grib2 files directly, templating over T and E. Once you've
> done the conversion, though, I/O will be faster with NetCDF, especially if X
> and Y don't vary. But definitely use EDEF instead of 'set dfile 'n. There's
> a lot more analysis you can do when your ensembles are not separate data
> sets.
>
> Jennifer
>
>
> --
> Jennifer M. Adams
> IGES/COLA
> 4041 Powder Mill Road, Suite 302
> Calverton, MD 20705
> jma at cola.iges.org
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20080317/516229c8/attachment.html