From Daniele.Gandini at ARPA.PIEMONTE.IT  Mon Oct  1 04:40:51 2007
From: Daniele.Gandini at ARPA.PIEMONTE.IT (Daniele Gandini)
Date: Mon, 1 Oct 2007 10:40:51 +0200
Subject: skew-T from ECMWF grid data
Message-ID: <MON.1.OCT.2007.104051.0200.>

Mario,

wind direction is clockwise from North:

'define wdir=180+atan2(u,v)*180/3.14'  

To see the moist adiabats set DrawThtw= 1   

Bye

Daniele



  ----- Original Message ----- 
  From: mario frangipane 
  To: GRADSUSR at LIST.CINECA.IT 
  Sent: Thursday, September 27, 2007 6:19 PM
  Subject: Re: skew-T from ECMWF grid data


  Daniele, thank you very very much for your message!

  I have created a Skew-T diagram using the script of Bob Hart and the ECMWF grid data.  :-)

  The archive of ECMWF do not contain the dewpoin temperature and wind direction and I must calculate them.

  But, how is calculated the wind direction? (clockwise? from nord?)

  Moreover, the moist adiabats are not drawn!  :-(

  Bob Hart write:

  http://moe.met.fsu.edu/~rhart/skewfaq.html#Q7

  "Some versions of 1.6 and 1.7 had a bug that produced math errors when calculations were performed in scripts. The lastest beta version (1.7 beta 9) fixes the error" 

  But I use GrADS 1.8!

  You can still help me?

  Thank you very much!

  Regards,

          Mario





  Daniele Gandini <Daniele.Gandini at ARPA.PIEMONTE.IT> ha scritto:
    Hello Mario,

    it is very simple.

    First you set on a lat-lon point and on all vertical levels:

    'set lon 'lonp
    'set lat 'latp
    'set z 1 '_NLEV

    then you run skew script written by Bob Hart that you can download from

    http://moe.met.fsu.edu/~rhart/skew.html



------------------------------------------------------------------------------
  Scopri la community di Yahoo! Mail: trucchi, novit?, consigli... e la tua opinione!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071001/a5eab074/attachment.html 

From hmjbarbosa at GMAIL.COM  Mon Oct  1 13:53:40 2007
From: hmjbarbosa at GMAIL.COM (Henrique Barbosa)
Date: Mon, 1 Oct 2007 14:53:40 -0300
Subject: Background topography maps in GRADS
In-Reply-To: <152E44DD-DBD7-4936-80D6-4F8CE47CCD8A@bandle.com>
Message-ID: <MON.1.OCT.2007.145340.0300.>

Kevin,

Their cloud field is not transparent. Look for instance at
7E 36N, near Tunisia, its not possible to see the mountains
under the clouds.

It seems to me that they have drawn the political boundaries
and cities on top of the cloud field. To get the topography
underneath, just use the printim command and add an
layer below (option -b) your plot while generating the gif
or png. Check all info here:

http://grads.iges.org/grads/gadoc/gradcomdprintim.html

Hope that helps.
Henrique

On 9/21/07, Frank Bandle <frank at bandle.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kevin: I sent you mail directly.
>
> Regards
> Dipl. Met. Frank Bandle
> CEO
>
> Weather365 LTD (Germany)
> Munich Airport - Germany
> www.weather365.net
> - ----------------------------------------------------------
> This communication is intended solely for the individual/entity to
> whom it is addressed. It may contain confidential or legally
> privileged information. Any unauthorized disclosure or copying is
> prohibited and may be unlawful.If you have received this
> communication in error, please notify the sender immediately and
> delete it from your system. Thank you.
>
>
>
> Am 20.09.2007 um 19:03 schrieb Kevin M Levey:
>
> > THU 20SEP07: 0950PDT
> >
> > I came across the following website that which uses GRADS to
> > produce really
> > good looking plots:
> >
> > http://www.weather365.net/component/option,com_wxmap_args_dynamic/
> > Itemid,117
> > /lang,en/
> >
> > 1] I was wondering about the background topography maps used for
> > their plots
> > - is there any documentation on how to do something like this. Is this
> > merely a topo dataset they are using? If so, where can we get these
> > topo
> > data sets to import into GrADS?
> >
> > 2] It also looks like from their cloud maps that the clouds are
> > "transparent" - any ideas how this done or is this merely a clever
> > use of
> > colors in their legend?
> >
> > Thanks.
> >
> >
> > Regards
> >
> > Kevin M Levey, MSc (University of Cape Town)
> > Director of Meteorological Operations
> > CustomWeather, Inc
> > San Francisco, CA, USA
> >
> > http://www.1stweather.com
> > http://www.myforecast.com
> > http://www.customweather.com
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (Darwin)
>
> iD8DBQFG88syMFroz4uLzCkRAsc8AJ92EFTL4BdQVXHidyrh6ydhczyMOQCfS2AQ
> Ljjp2nvGlMCUyAEFQtN/A4o=
> =Hgqe
> -----END PGP SIGNATURE-----
>


From hmjbarbosa at GMAIL.COM  Mon Oct  1 14:05:35 2007
From: hmjbarbosa at GMAIL.COM (Henrique Barbosa)
Date: Mon, 1 Oct 2007 15:05:35 -0300
Subject: 'False' color composition
In-Reply-To: <475023170709260811g7c2b7026mc651da02ee650fef@mail.gmail.com>
Message-ID: <MON.1.OCT.2007.150535.0300.>

Dear Christophe,

You can create any RGB colour with grads command:

set rgb color# R G B

where color# is the color number and must be between 16 and 99,
and R,G,B are integer values between 0 and 255. However, the
way grads works, you have to define clevs and ccols to be used.
I mean, you have to do something like:

set rgb 21 255 100 0
set rgb 22 100 255 10
set rgb 23 50 200 50
set ccol 21 22 23
set clevs 40 50

so that it will use color 21, for values below 40, color 22, for values
between 40 and 50 and so on.... You see? You cannot use the
value of the field at a grid box to specify its color. You have to
give grads a range of values and a color to associate with
that range.

Maybe you can do what you want with a GIS software like GRASS.

Cheers,
Henrique

On 9/26/07, Ricardo Marcelo <ricardom at acd.ufrj.br> wrote:
> 100? it is not 256? maybe should be good to take a look at rgb.gs script to
> get more information.
>
>
> On 9/26/07, Davide Sacchetti <davide.sacchetti at arpal.org> wrote:
> > sorry, grads handles 100 colors only ...
> > I'm afraid you have no chances to do it with grads (at least with
> > version 1.9)
> >
> > Bye bye
> > Davide
> >
> > On Tue, 2007-09-25 at 16:06 +0200, Christophe LAVAYSSE wrote:
> > > Dear all,
> > > I would like to create a 'false' color composition from satellite data
> where
> > > R - G and B colors intensities (O to 255) are defined by the intensity
> of
> > > three different variables (IRchannel1 - IRchannel2 and IRchannel3).
> > >
> > > Does anyone can help me ?
> > >
> > > Thx in advance
> > >
> > --
> > Sacchetti Davide
> > ARPAL UO3 Centro Meteo Idrologico Regione Liguria - Dir. Scientifica
> > V.le Brigare Partigiane 2 16121 Genova (I)
> > tel: +39 010 6437535
> > mail: davide.sacchetti at arpal.org   web: www.meteoliguria.it
> >
>
>
>
>  --
> ============================================================
> Ricardo Marcelo da Silva
> LAMMA - Laborat?rio de Modelagem de Processos Marinhos e Atmosf?ricos
> Depto de Meteorologia - Instituto de Geoci?ncias
> Centro de Ci?ncias Matem?ticas e da Natureza
> Universidade Federal do Rio de Janeiro
> e-mail: ricardom at acd.ufrj.br
> phone: 55 21 2598-9470 r 24
> ============================================================


From pbehling at WISC.EDU  Mon Oct  1 14:11:09 2007
From: pbehling at WISC.EDU (Pat Behling)
Date: Mon, 1 Oct 2007 13:11:09 -0500
Subject: xdf gaussian T42
In-Reply-To: <1184616978.5672.17.camel@anka>
Message-ID: <MON.1.OCT.2007.131109.0500.>

Is it possible to be able to build an xdf file using GAUST42 like
GAUST62 ? thanks,Pat

Pat Behling
Senior Information Processing Consultant
Center for Climatic Research
Gaylord Nelson Institute for Environmental Studies
University of Wisconsin
1225 W. Dayton St.
Madison, WI 53706-1695
phone: 608-262-8765
fax: 608-263-4190
email: pbehling at wisc.edu



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071001/6841ffc6/attachment.html 

From imspj at HAWAII.EDU  Wed Oct  3 01:15:20 2007
From: imspj at HAWAII.EDU (Ilukpitiya Mudi S P Jayawardena)
Date: Tue, 2 Oct 2007 19:15:20 -1000
Subject: computation of potential vorticity in GRADS
In-Reply-To: <e71668fa0710011105g7686bcffp2d0efae302521c55@mail.gmail.com>
Message-ID: <TUE.2.OCT.2007.191520.1000.>

Dear all

I want to compute potential vorticity in GRADS using NCEP/NCAR reanalysis data. The data set don't have theta surface data.

I can define theta ( Potential temperature ) but I don't know how to compute [d(theta)/d(p)] and p is for pressure.

I tried to use the commands
'define prs=lev'
'define z=prs'
" define dtheta=cdiff(theta,z)"

it does not work. It says
' Error from CDIFF: specification dimension non varying
 Operational error : Error from cdiff function
Error occurred at column 1
DEFINE error : Invalid expression.

Please help me

Thanks

Ilukpitiya


From shimon at CYCLONE.TAU.AC.IL  Wed Oct  3 04:40:57 2007
From: shimon at CYCLONE.TAU.AC.IL (Simon Krichak)
Date: Wed, 3 Oct 2007 10:40:57 +0200
Subject: computation of potential vorticity in GRADS
Message-ID: <WED.3.OCT.2007.104057.0200.>


Hi Ilukpitiya
Please find attached script posted by Ron Goodson in 2001.

Best,
    Simon

Simon Krichak,  Principal Research Scientist
 Tel Aviv, Israel.

----- Original Message -----
From: "Ilukpitiya Mudi S P Jayawardena" <imspj at HAWAII.EDU>
To: <GRADSUSR at LIST.CINECA.IT>
Sent: Wednesday, October 03, 2007 7:15 AM
Subject: computation of potential vorticity in GRADS


> Dear all
>
> I want to compute potential vorticity in GRADS using NCEP/NCAR reanalysis
> data. The data set don't have theta surface data.
>
> I can define theta ( Potential temperature ) but I don't know how to
> compute [d(theta)/d(p)] and p is for pressure.
>
> I tried to use the commands
> 'define prs=lev'
> 'define z=prs'
> " define dtheta=cdiff(theta,z)"
>
> it does not work. It says
> ' Error from CDIFF: specification dimension non varying
> Operational error : Error from cdiff function
> Error occurred at column 1
> DEFINE error : Invalid expression.
>
> Please help me
>
> Thanks
>
> Ilukpitiya
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pv.gs
Type: application/octet-stream
Size: 2316 bytes
Desc: not available
Url : http://gradsusr.org/pipermail/gradsusr/attachments/20071003/bed489bc/attachment.obj 

From darik777 at I.UA  Wed Oct  3 10:31:45 2007
From: darik777 at I.UA (Darya Yarovaya)
Date: Wed, 3 Oct 2007 16:31:45 +0200
Subject: rebuild GrADS
Message-ID: <WED.3.OCT.2007.163145.0200.>

Hi,

Does anyone know how to rebuild GrADS for linux? (I need it to add 360-
calendar option to the original GrADS).
I tried the command
cc -o grads grads.c ?lm

but it results in numerous mistakes

grads.c: In function ?main?:
grads.c:103: error: expected ?)? before ?GRADS_VERSION?
grads.c:157: error: ?BYTEORDER? undeclared (first use in this function)
grads.c:157: error: (Each undeclared identifier is reported only once
grads.c:157: error: for each function it appears in.)
grads.c:206: warning: incompatible implicit declaration of built-in
function ?strcpy?
grads.c: In function ?command_line_help?:
grads.c:468: error: expected ?)? before ?GRADS_VERSION?

Regards, Daria


From jma at COLA.IGES.ORG  Thu Oct  4 09:19:07 2007
From: jma at COLA.IGES.ORG (Jennifer Adams)
Date: Thu, 4 Oct 2007 09:19:07 -0400
Subject: rebuild GrADS
In-Reply-To: <20071003143205.55CB01FF18@mx2.cineca.it>
Message-ID: <THU.4.OCT.2007.091907.0400.>


On Oct 3, 2007, at 10:31 AM, Darya Yarovaya wrote:

> Hi,
>
> Does anyone know how to rebuild GrADS for linux?
> I tried the command
> cc -o grads grads.c ?lm
Ah, if only it were that simple....
If you run the 'configure' script, then 'make', you'll see that there  
is a long series of steps in the compilation and linking process.

> (I need it to add 360-calendar option to the original GrADS).
This will not be easy -- it involves tweaking all the date-handling  
routines, the conversions of grid<---->world coordinates, and there  
are plenty of other places in the code that the subtleties of these  
changes would have to be assessed to make sure you're doing the I/O  
properly.

I can think of two other options:
1. Use GrADS as it is, but stick to use of grid indices for time axis  
management (a kludge).
2. Try to convert your data to 365-day calendar by padding it with  
missing data.

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/20071004/737961e2/attachment.html 

From klevey at CUSTOMWEATHER.COM  Thu Oct  4 12:13:35 2007
From: klevey at CUSTOMWEATHER.COM (Kevin M Levey)
Date: Thu, 4 Oct 2007 09:13:35 -0700
Subject: Background topography maps in GRADS
In-Reply-To: <e71668fa0710011053u5a58b8d7gd5247d71efaddf5d@mail.gmail.com>
Message-ID: <THU.4.OCT.2007.091335.0700.>

THU 07OCT07: 0915PDT

Dear Henrique

Many thanks for getting back to me. The owner of weathernet had responded to
me personally too.

Take care


Regards

Kevin M Levey, MSc (University of Cape Town)
Director of Meteorological Operations
CustomWeather, Inc
San Francisco, CA, USA

http://www.1stweather.com
http://www.myforecast.com
http://www.customweather.com


> -----Original Message-----
> From: GRADSUSR at LIST.CINECA.IT [mailto:GRADSUSR at LIST.CINECA.IT] On
> Behalf Of Henrique Barbosa
> Sent: Monday, October 01, 2007 10:54 AM
> To: GRADSUSR at LIST.CINECA.IT
> Subject: Re: Background topography maps in GRADS
>
> Kevin,
>
> Their cloud field is not transparent. Look for instance at
> 7E 36N, near Tunisia, its not possible to see the mountains
> under the clouds.
>
> It seems to me that they have drawn the political boundaries
> and cities on top of the cloud field. To get the topography
> underneath, just use the printim command and add an
> layer below (option -b) your plot while generating the gif
> or png. Check all info here:
>
> http://grads.iges.org/grads/gadoc/gradcomdprintim.html
>
> Hope that helps.
> Henrique
>
> On 9/21/07, Frank Bandle <frank at bandle.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Kevin: I sent you mail directly.
> >
> > Regards
> > Dipl. Met. Frank Bandle
> > CEO
> >
> > Weather365 LTD (Germany)
> > Munich Airport - Germany
> > www.weather365.net
> > - ----------------------------------------------------------
> > This communication is intended solely for the individual/entity to
> > whom it is addressed. It may contain confidential or legally
> > privileged information. Any unauthorized disclosure or copying is
> > prohibited and may be unlawful.If you have received this
> > communication in error, please notify the sender immediately and
> > delete it from your system. Thank you.
> >
> >
> >
> > Am 20.09.2007 um 19:03 schrieb Kevin M Levey:
> >
> > > THU 20SEP07: 0950PDT
> > >
> > > I came across the following website that which uses GRADS to
> > > produce really
> > > good looking plots:
> > >
> > >
> http://www.weather365.net/component/option,com_wxmap_args_dynamic/
> > > Itemid,117
> > > /lang,en/
> > >
> > > 1] I was wondering about the background topography maps used for
> > > their plots
> > > - is there any documentation on how to do something like this. Is this
> > > merely a topo dataset they are using? If so, where can we get these
> > > topo
> > > data sets to import into GrADS?
> > >
> > > 2] It also looks like from their cloud maps that the clouds are
> > > "transparent" - any ideas how this done or is this merely a clever
> > > use of
> > > colors in their legend?
> > >
> > > Thanks.
> > >
> > >
> > > Regards
> > >
> > > Kevin M Levey, MSc (University of Cape Town)
> > > Director of Meteorological Operations
> > > CustomWeather, Inc
> > > San Francisco, CA, USA
> > >
> > > http://www.1stweather.com
> > > http://www.myforecast.com
> > > http://www.customweather.com
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.7 (Darwin)
> >
> >
> iD8DBQFG88syMFroz4uLzCkRAsc8AJ92EFTL4BdQVXHidyrh6ydhczyMOQCfS2A
> Q
> > Ljjp2nvGlMCUyAEFQtN/A4o=
> > =Hgqe
> > -----END PGP SIGNATURE-----
> >


From preuter at LABRI.FR  Sun Oct  7 09:37:33 2007
From: preuter at LABRI.FR (Patrick Reuter)
Date: Sun, 7 Oct 2007 15:37:33 +0200
Subject: degrib msg and submsg
Message-ID: <SUN.7.OCT.2007.153733.0200.>

Dear all,

I download grib2 files and have problems to degrib into Grads.

I have the following inventory :

1:115:d=2007100706:HGT:850 mb:15 hour fcst
2:227347:d=2007100706:TMP:850 mb:15 hour fcst
3:315793:d=2007100706:RH:850 mb:15 hour fcst
4.1:411471:d=2007100706:UGRD:850 mb:15 hour fcst
4.2:411471:d=2007100706:VGRD:850 mb:15 hour fcst

And I want to extract BOTH the UGRD/VGRD values. Here are my degrib commands :

./degrib grib2file -C -msg 4.1 -Flt -Interp -GrADS -out UGRD
./degrib grib2file -C -msg 4.2 -Flt -Interp -GrADS -out VGRD

The first command works fine, but in the second command, I always get
the following error message :

ERROR: In call to Grib2Convert.
ERROR: In call to ReadGrib2Record.
ERROR: Unpack library error code (0 2)

In other words, since the VGRD data is always stored in GRIB2
submessages, I can't access to it.

Is anybody familiar with my problem ?

Thanks in advance

   Patrick


From bruyerec at UCAR.EDU  Sun Oct  7 10:00:10 2007
From: bruyerec at UCAR.EDU (Cindy Bruyere)
Date: Sun, 7 Oct 2007 08:00:10 -0600
Subject: degrib msg and submsg
In-Reply-To: <20071007153733.2y0fatnin4gw4o84@webmail.labri.fr>
Message-ID: <SUN.7.OCT.2007.080010.0600.>

I will be out of the office till October 29.


From ashishroutray at REDIFFMAIL.COM  Mon Oct  8 08:15:22 2007
From: ashishroutray at REDIFFMAIL.COM (ashish no routray)
Date: Mon, 8 Oct 2007 12:15:22 -0000
Subject: Plot multiple files with one control file
Message-ID: <MON.8.OCT.2007.121522.0000.ASHISHROUTRAY@REDIFFMAIL.COM>

Dear Users
I need your kind help to plot the multile binary files in using one .ctl file.
I downloaded TRMM 03 hourly data for a period and also .ctl file from TRMM site. we are trying to plot 24hrs accumulated rainfall from all 9 files.Files are look like:

3B42.020601.00z.6.precipitation.bin
3B42.020601.03z.6.precipitation.bin
......
......
3B42.020602.00z.6.precipitation.bin 

Here I am giving the .ctl file as follow:

***************************************************
dset ./3B42.%y2%m2%d2.%h2z.6.precipitation.bin
options template byteswapped
title TRMM 3B42 V6 three hourly TRMM rainfall
undef -9999.0
xdef 1440 linear -179.875 0.25000000
ydef 400  linear -49.8750000 0.25000000
zdef 1 levels 1000
tdef 9 linear 00:00Z01jan1998 3hr
* end_time 21:00Z31aug2007 (this_is_comment_line)
vars 1
r         0   99 Hourly Rain Rate (mm/hr)
endvars

**************************************************

We are running the .ctl in IBM(P5) machine.
It showing Gridded are undefined. I hope it could not open the files. when I plot individual files alone it is ploting properly.
Please help in this regards.
Thanks in advance.

With best regards
Sincerely
Ashish



ASHISH ROUTRAY
Project Scientist & Research Scholar
Centre for Atmospheric Sciences
Indian Institute of Technology Delhi
Hauz Khas
New Delhi-110016
India
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071008/b9d5b6ce/attachment.html 

From mcroke at AIRDAT.COM  Tue Oct  9 10:18:46 2007
From: mcroke at AIRDAT.COM (Meredith Croke)
Date: Tue, 9 Oct 2007 16:18:46 +0200
Subject: 1971-2000 gridded Normals
Message-ID: <TUE.9.OCT.2007.161846.0200.>

Hi Everyone,

I am looking for a gridded dataset of the 1971-2000 daily normals, or
climatology for this period of time.  Specifically I would like to get the
30 year average for 850 mb Tmp, Surface Tmp, and 500 mb GPH.  I know I can
ftp each year's files, but I was wondering if anyone has a file that has
already computed the 30 year average.

Thank you.

Meredith


From Wesley.Ebisuzaki at NOAA.GOV  Tue Oct  9 10:33:14 2007
From: Wesley.Ebisuzaki at NOAA.GOV (Wesley Ebisuzaki)
Date: Tue, 9 Oct 2007 10:33:14 -0400
Subject: degrib msg and submsg
In-Reply-To: <20071007153733.2y0fatnin4gw4o84@webmail.labri.fr>
Message-ID: <TUE.9.OCT.2007.103314.0400.>

Patrick,

Patrick Reuter wrote:
> Dear all,
>
> I download grib2 files and have problems to degrib into Grads.
>
> I have the following inventory :
>
> 1:115:d=2007100706:HGT:850 mb:15 hour fcst
> 2:227347:d=2007100706:TMP:850 mb:15 hour fcst
> 3:315793:d=2007100706:RH:850 mb:15 hour fcst
> 4.1:411471:d=2007100706:UGRD:850 mb:15 hour fcst
> 4.2:411471:d=2007100706:VGRD:850 mb:15 hour fcst
>
> And I want to extract BOTH the UGRD/VGRD values. Here are my degrib
> commands :
>
> ./degrib grib2file -C -msg 4.1 -Flt -Interp -GrADS -out UGRD
> ./degrib grib2file -C -msg 4.2 -Flt -Interp -GrADS -out VGRD
>
The notation 4.1 (message #4, submessage #1) is unique to wgrib2.  You
should consult the degrib documentation to see how they handle submessages.

If all else fails, you can also use wgrib2 to convert submessages to
messages by

          wgrib2 -grib new_grib old_grib

> The first command works fine, but in the second command, I always get
> the following error message :
>
> ERROR: In call to Grib2Convert.
> ERROR: In call to ReadGrib2Record.
> ERROR: Unpack library error code (0 2)
>
> In other words, since the VGRD data is always stored in GRIB2
> submessages, I can't access to it.
>
> Is anybody familiar with my problem ?
>
> Thanks in advance
>
>   Patrick
BTW if the grib2 files are lat-lon/mercator/gaussian-grid then you should
consider converting the files into netcdf using wgrib2.  The netcdf files
can be opened by GrADS using the sdfopen command.  I believe that
degrib can produce netcdf files too.

   Wesley


From bernd.becker at METOFFICE.GOV.UK  Tue Oct  9 12:14:38 2007
From: bernd.becker at METOFFICE.GOV.UK (Bernd Becker)
Date: Tue, 9 Oct 2007 17:14:38 +0100
Subject: degrib msg and submsg
In-Reply-To: <470B912A.6060700@noaa.gov>
Message-ID: <TUE.9.OCT.2007.171438.0100.>

Wesley,

see below:

On Tue, 2007-10-09 at 10:33 -0400, Wesley Ebisuzaki wrote:
> Patrick,
>
> Patrick Reuter wrote:
> > Dear all,
> >
> > I download grib2 files and have problems to degrib into Grads.
> >
> > I have the following inventory :
> >
> > 1:115:d=2007100706:HGT:850 mb:15 hour fcst
> > 2:227347:d=2007100706:TMP:850 mb:15 hour fcst
> > 3:315793:d=2007100706:RH:850 mb:15 hour fcst
> > 4.1:411471:d=2007100706:UGRD:850 mb:15 hour fcst
> > 4.2:411471:d=2007100706:VGRD:850 mb:15 hour fcst
> >
> > And I want to extract BOTH the UGRD/VGRD values. Here are my degrib
> > commands :
> >
> > ./degrib grib2file -C -msg 4.1 -Flt -Interp -GrADS -out UGRD
> > ./degrib grib2file -C -msg 4.2 -Flt -Interp -GrADS -out VGRD
> >
> The notation 4.1 (message #4, submessage #1) is unique to wgrib2.  You
> should consult the degrib documentation to see how they handle submessages.
>
> If all else fails, you can also use wgrib2 to convert submessages to
> messages by
>
>           wgrib2 -grib new_grib old_grib
>
> > The first command works fine, but in the second command, I always get
> > the following error message :
> >
> > ERROR: In call to Grib2Convert.
> > ERROR: In call to ReadGrib2Record.
> > ERROR: Unpack library error code (0 2)
> >
> > In other words, since the VGRD data is always stored in GRIB2
> > submessages, I can't access to it.
> >
> > Is anybody familiar with my problem ?
> >
> > Thanks in advance
> >
> >   Patrick
> BTW if the grib2 files are lat-lon/mercator/gaussian-grid then you should
> consider converting the files into netcdf using wgrib2.  The netcdf files
> can be opened by GrADS using the sdfopen command.  I believe that
> degrib can produce netcdf files too.
>

Is netcdf the death-knell for GRIB1 and 2 data on a global scale?
I suppose the NEtcdf files will be about 4 times larger  on average.
This would increase I/O times and storage requirements.

When will NetCdf use compression?

Thanks,
Bernd.

>    Wesley
--
Bernd Becker   The Monthly Outlook
Met Office  FitzRoy Road  Exeter   Devon EX1 3PB  United Kingdom
Tel.: +44 (0) 1392 884511 Fax: +44 (0)870 900 5050
E-mail:bernd.becker at metoffice.com  -  http://www.metoffice.com


From Wesley.Ebisuzaki at NOAA.GOV  Tue Oct  9 13:55:04 2007
From: Wesley.Ebisuzaki at NOAA.GOV (Wesley Ebisuzaki)
Date: Tue, 9 Oct 2007 13:55:04 -0400
Subject: degrib msg and submsg
In-Reply-To: <1191946478.9192.6.camel@eld313.metoffice.com>
Message-ID: <TUE.9.OCT.2007.135504.0400.>

Bernd,

     IMHO grib1 is doomed as grib2's compression is too good (~1/5 of grib1
size for operational model files)  and compression will increase as the
world goes
to higher resolution files.  Since grib1 is 1/3 the size of a netcdf
file, you will
see pretty big (uncompressed) netcdf files.   (Your 4x expansion is a big
underestimate.)

       Wesley






Bernd Becker wrote:
> Wesley,
>
> see below:
>
> On Tue, 2007-10-09 at 10:33 -0400, Wesley Ebisuzaki wrote:
>
>> Patrick,
>>
>> Patrick Reuter wrote:
>>
>>> Dear all,
>>>
>>> I download grib2 files and have problems to degrib into Grads.
>>>
>>> I have the following inventory :
>>>
>>> 1:115:d=2007100706:HGT:850 mb:15 hour fcst
>>> 2:227347:d=2007100706:TMP:850 mb:15 hour fcst
>>> 3:315793:d=2007100706:RH:850 mb:15 hour fcst
>>> 4.1:411471:d=2007100706:UGRD:850 mb:15 hour fcst
>>> 4.2:411471:d=2007100706:VGRD:850 mb:15 hour fcst
>>>
>>> And I want to extract BOTH the UGRD/VGRD values. Here are my degrib
>>> commands :
>>>
>>> ./degrib grib2file -C -msg 4.1 -Flt -Interp -GrADS -out UGRD
>>> ./degrib grib2file -C -msg 4.2 -Flt -Interp -GrADS -out VGRD
>>>
>>>
>> The notation 4.1 (message #4, submessage #1) is unique to wgrib2.  You
>> should consult the degrib documentation to see how they handle submessages.
>>
>> If all else fails, you can also use wgrib2 to convert submessages to
>> messages by
>>
>>           wgrib2 -grib new_grib old_grib
>>
>>
>>> The first command works fine, but in the second command, I always get
>>> the following error message :
>>>
>>> ERROR: In call to Grib2Convert.
>>> ERROR: In call to ReadGrib2Record.
>>> ERROR: Unpack library error code (0 2)
>>>
>>> In other words, since the VGRD data is always stored in GRIB2
>>> submessages, I can't access to it.
>>>
>>> Is anybody familiar with my problem ?
>>>
>>> Thanks in advance
>>>
>>>   Patrick
>>>
>> BTW if the grib2 files are lat-lon/mercator/gaussian-grid then you should
>> consider converting the files into netcdf using wgrib2.  The netcdf files
>> can be opened by GrADS using the sdfopen command.  I believe that
>> degrib can produce netcdf files too.
>>
>>
>
> Is netcdf the death-knell for GRIB1 and 2 data on a global scale?
> I suppose the NEtcdf files will be about 4 times larger  on average.
> This would increase I/O times and storage requirements.
>
> When will NetCdf use compression?
>
> Thanks,
> Bernd.
>
>
>>    Wesley
>>
> --
> Bernd Becker   The Monthly Outlook
> Met Office  FitzRoy Road  Exeter   Devon EX1 3PB  United Kingdom
> Tel.: +44 (0) 1392 884511 Fax: +44 (0)870 900 5050
> E-mail:bernd.becker at metoffice.com  -  http://www.metoffice.com
>


From dasilva at ALUM.MIT.EDU  Tue Oct  9 17:12:31 2007
From: dasilva at ALUM.MIT.EDU (Arlindo da Silva)
Date: Tue, 9 Oct 2007 17:12:31 -0400
Subject: Plot multiple files with one control file
In-Reply-To: <20071008121522.17521.qmail@webmail81.rediffmail.com>
Message-ID: <TUE.9.OCT.2007.171231.0400.>

On 10/8/07, ashish no routray <ashishroutray at rediffmail.com> wrote:
>
> Dear Users
> I need your kind help to plot the multile binary files in using one .ctl
> file.
> I downloaded TRMM 03 hourly data for a period and also .ctl file from TRMM
> site
>

It is always a good idea to give the URL so that someone could try to
download the same files and reproduce the problem... Also, provide the
output of "q config" and "!uname -a" so that we can know which version you
are using...

. we are trying to plot 24hrs accumulated rainfall from all 9
files.Filesare look like:
>
> 3B42.020601.00z.6.precipitation.bin
> 3B42.020601.03z.6.precipitation.bin
> ......
> ......
> 3B42.020602.00z.6.precipitation.bin
>
> Here I am giving the .ctl file as follow:
>

I am assuming that the individual ctl provided with data works fine.

***************************************************
> dset ./3B42.%y2%m2%d2.%h2z.6.precipitation.bin
> options template byteswapped
>
The option "byteswapped" is deprecated. Use either "big_endian" or
"little_endian", depending on the endianess of the machine TRMM used to
write the data.

title TRMM 3B42 V6 three hourly TRMM rainfall
> undef -9999.0
> xdef 1440 linear -179.875 0.25000000
> ydef 400  linear -49.8750000 0.25000000
> zdef 1 levels 1000
>
So far, so good...

tdef 9 linear 00:00Z01jan1998 3hr
>

Why "9"? You need the enter the total number of time steps from 1998 to
2007.


> * end_time 21:00Z31aug2007 (this_is_comment_line)
> vars 1
> r        0  99 Hourly Rain Rate (mm/hr)
> endvars
>
> **************************************************
>
> We are running the .ctl in IBM(P5) machine.
> It showing Gridded are undefined. I hope it could not open the files. when
> I plot individual files alone it is ploting properly.
>

Can you plot t=1 through t=9 with the template version of the  ctl?

--
Arlindo da Silva
dasilva at alum.mit.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071009/10055677/attachment.html 

From aidab at PDX.EDU  Tue Oct  9 18:35:39 2007
From: aidab at PDX.EDU (Aida Biberic)
Date: Wed, 10 Oct 2007 00:35:39 +0200
Subject: 'calloc' error
Message-ID: <WED.10.OCT.2007.003539.0200.>

I am getting the following error message:

gcc -DHAVE_CONFIG_H -I. -I. -I. -I../supplibs/include -I/usr/X11R6/include
  -g -O -c `test -f 'gxdxwd.c' || echo './'`gxdxwd.c
gxdxwd.c:25: error: conflicting types for 'calloc'
gxdxwd.c:25: error: conflicting types for 'calloc'

I am running Intelx86_64 with Linux. Please help.

Aida


From jma at COLA.IGES.ORG  Tue Oct  9 20:35:15 2007
From: jma at COLA.IGES.ORG (Jennifer Adams)
Date: Tue, 9 Oct 2007 20:35:15 -0400
Subject: 'calloc' error
In-Reply-To: <20071009223600.5C43420044@mx2.cineca.it>
Message-ID: <TUE.9.OCT.2007.203515.0400.>

Just comment out line 24 (or so) in gxdxwd.c that has the calloc
declaration in it. --Jennifer

On Oct 9, 2007, at 6:35 PM, Aida Biberic wrote:

> I am getting the following error message:
>
> gcc -DHAVE_CONFIG_H -I. -I. -I. -I../supplibs/include -I/usr/X11R6/
> include
>   -g -O -c `test -f 'gxdxwd.c' || echo './'`gxdxwd.c
> gxdxwd.c:25: error: conflicting types for 'calloc'
> gxdxwd.c:25: error: conflicting types for 'calloc'
>
> I am running Intelx86_64 with Linux. Please help.
>
> Aida

--
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/20071009/c4f23f1b/attachment.html 

From bernd.becker at METOFFICE.GOV.UK  Wed Oct 10 04:04:55 2007
From: bernd.becker at METOFFICE.GOV.UK (Bernd Becker)
Date: Wed, 10 Oct 2007 09:04:55 +0100
Subject: degrib msg and submsg
In-Reply-To: <470BC078.80808@noaa.gov>
Message-ID: <WED.10.OCT.2007.090455.0100.>

Wesley,


Hmmm,  assume you maintain a forecast  archive
and from one day to the next, you switch from grib 1 data to grib 2
data. Each grib  file has its meta data stored separately in one ctl and
idx file each.
Is it  then possible to read the whole archive in one grads job,
despite the mix of grib1 and grib 2 data?
(when) is grads able to read grib2 data?

Many thanks,
Bernd.

On Tue, 2007-10-09 at 13:55 -0400, Wesley Ebisuzaki wrote:
> Bernd,
>
>      IMHO grib1 is doomed as grib2's compression is too good (~1/5 of grib1
> size for operational model files)  and compression will increase as the
> world goes
> to higher resolution files.  Since grib1 is 1/3 the size of a netcdf
> file, you will
> see pretty big (uncompressed) netcdf files.   (Your 4x expansion is a big
> underestimate.)
>
>        Wesley
>
>
>
>
>
>
> Bernd Becker wrote:
> > Wesley,
> >
> > see below:
> >
> > On Tue, 2007-10-09 at 10:33 -0400, Wesley Ebisuzaki wrote:
> >
> >> Patrick,
> >>
> >> Patrick Reuter wrote:
> >>
> >>> Dear all,
> >>>
> >>> I download grib2 files and have problems to degrib into Grads.
> >>>
> >>> I have the following inventory :
> >>>
> >>> 1:115:d=2007100706:HGT:850 mb:15 hour fcst
> >>> 2:227347:d=2007100706:TMP:850 mb:15 hour fcst
> >>> 3:315793:d=2007100706:RH:850 mb:15 hour fcst
> >>> 4.1:411471:d=2007100706:UGRD:850 mb:15 hour fcst
> >>> 4.2:411471:d=2007100706:VGRD:850 mb:15 hour fcst
> >>>
> >>> And I want to extract BOTH the UGRD/VGRD values. Here are my degrib
> >>> commands :
> >>>
> >>> ./degrib grib2file -C -msg 4.1 -Flt -Interp -GrADS -out UGRD
> >>> ./degrib grib2file -C -msg 4.2 -Flt -Interp -GrADS -out VGRD
> >>>
> >>>
> >> The notation 4.1 (message #4, submessage #1) is unique to wgrib2.  You
> >> should consult the degrib documentation to see how they handle submessages.
> >>
> >> If all else fails, you can also use wgrib2 to convert submessages to
> >> messages by
> >>
> >>           wgrib2 -grib new_grib old_grib
> >>
> >>
> >>> The first command works fine, but in the second command, I always get
> >>> the following error message :
> >>>
> >>> ERROR: In call to Grib2Convert.
> >>> ERROR: In call to ReadGrib2Record.
> >>> ERROR: Unpack library error code (0 2)
> >>>
> >>> In other words, since the VGRD data is always stored in GRIB2
> >>> submessages, I can't access to it.
> >>>
> >>> Is anybody familiar with my problem ?
> >>>
> >>> Thanks in advance
> >>>
> >>>   Patrick
> >>>
> >> BTW if the grib2 files are lat-lon/mercator/gaussian-grid then you should
> >> consider converting the files into netcdf using wgrib2.  The netcdf files
> >> can be opened by GrADS using the sdfopen command.  I believe that
> >> degrib can produce netcdf files too.
> >>
> >>
> >
> > Is netcdf the death-knell for GRIB1 and 2 data on a global scale?
> > I suppose the NEtcdf files will be about 4 times larger  on average.
> > This would increase I/O times and storage requirements.
> >
> > When will NetCdf use compression?
> >
> > Thanks,
> > Bernd.
> >
> >
> >>    Wesley
> >>
> > --
> > Bernd Becker   The Monthly Outlook
> > Met Office  FitzRoy Road  Exeter   Devon EX1 3PB  United Kingdom
> > Tel.: +44 (0) 1392 884511 Fax: +44 (0)870 900 5050
> > E-mail:bernd.becker at metoffice.com  -  http://www.metoffice.com
> >
--
Bernd Becker   The Monthly Outlook
Met Office  FitzRoy Road  Exeter   Devon EX1 3PB  United Kingdom
Tel.: +44 (0) 1392 884511 Fax: +44 (0)870 900 5050
E-mail:bernd.becker at metoffice.com  -  http://www.metoffice.com


From bernd.becker at METOFFICE.GOV.UK  Wed Oct 10 05:39:54 2007
From: bernd.becker at METOFFICE.GOV.UK (Bernd Becker)
Date: Wed, 10 Oct 2007 10:39:54 +0100
Subject: lists and fields in scripting
Message-ID: <WED.10.OCT.2007.103954.0100.>

Hi,
I just found myself documenting a grads script, saying:

* This is spaghetti code mainly because of the use of indexed scalar
variables.
* Lists, vectors and fields cannot be handled in grads yet.

But is it true?

I use variables like this:

ab.i.j where i and j are used as if they were indexes of
a 2D field.

Does grads scripting language offer something more appropriate?
i.e. ab(i,j) = 13.32 ?

Thanks,
Bernd.
--
Bernd Becker   The Monthly Outlook
Met Office  FitzRoy Road  Exeter   Devon EX1 3PB  United Kingdom
Tel.: +44 (0) 1392 884511 Fax: +44 (0)870 900 5050
E-mail:bernd.becker at metoffice.com  -  http://www.metoffice.com


From giavvns at ATH.HCMR.GR  Wed Oct 10 05:58:46 2007
From: giavvns at ATH.HCMR.GR (Ioannis A. Vamvakas)
Date: Wed, 10 Oct 2007 11:58:46 +0200
Subject: lats4d: Trouble in generating correct center name and code
Message-ID: <WED.10.OCT.2007.115846.0200.>

Hello,

I've been using lats4d to convert a netCDF file into grib1.
Everything works just fine but the Center name/id. It won't
see the name I provide in the lookup table and will use the
default name (=pcmdi) and code (=100).

The command I use to do this is:

lats4d -i <file>.nc -o <file> -format grib -table mytable

where, 'mytable', is a copy of '.grads.lats.table' with a
line at the center section added as follows:

hcmr | 96 | 0 | 0

Any help is appreciated.

Thanks in advance,

IAV


From jma at COLA.IGES.ORG  Wed Oct 10 08:57:43 2007
From: jma at COLA.IGES.ORG (Jennifer Adams)
Date: Wed, 10 Oct 2007 08:57:43 -0400
Subject: GRIB2: the good, the bad, and the ugly
In-Reply-To: <1192003495.19732.4.camel@eld313.metoffice.com>
Message-ID: <WED.10.OCT.2007.085743.0400.>


The size of grib2 files is impressive given what's packed inside.
However, once you bring those files to your local disk lickety-split
there will be some drawbacks when it comes to doing the I/O. Because
the grids are compressed, you need to unpack and expand them before
you can read any data. In GrADS terms, that means you must read the
entire lat/lon grid into memory before you can pick out a single grid
point. For displays in the X and Y dimensions, there is no evident
performance hit. For displays that have Z or T varying, it means you
must read grids at all levels or times before drawing the plot --
this is bad, but tolerable, and once you've got those grids in
memory, the 2nd plot you draw is very fast. The ugly part is when you
want to draw a Z-T plot -- each point in the Z-T domain requires a
global grid read into memory. This is where you make up for the time
saved when you downloaded the files. There is no such thing as a free
lunch -- high resolution data gobbles resources no matter what data
format you use.

By the way, the above is based on two days of testing -- Monday was
the first day that the GRIB2 interface in GrADS 2.0 was working. I
still have a lot of testing to do, but am working hard to get a
source tar file out there for alpha testing as soon as I can.

Jennifer



On Oct 10, 2007, at 4:04 AM, Bernd Becker wrote:

> Wesley,
>
>
> Hmmm,  assume you maintain a forecast  archive
> and from one day to the next, you switch from grib 1 data to grib 2
> data. Each grib  file has its meta data stored separately in one
> ctl and
> idx file each.
> Is it  then possible to read the whole archive in one grads job,
> despite the mix of grib1 and grib 2 data?
> (when) is grads able to read grib2 data?

>
> Many thanks,
> Bernd.
>
> On Tue, 2007-10-09 at 13:55 -0400, Wesley Ebisuzaki wrote:
>> Bernd,
>>
>>      IMHO grib1 is doomed as grib2's compression is too good (~1/5
>> of grib1
>> size for operational model files)  and compression will increase
>> as the
>> world goes
>> to higher resolution files.  Since grib1 is 1/3 the size of a netcdf
>> file, you will
>> see pretty big (uncompressed) netcdf files.   (Your 4x expansion
>> is a big
>> underestimate.)
>>
>>        Wesley
>>
>>
>>
>>
>>
>>
>> Bernd Becker wrote:
>>> Wesley,
>>>
>>> see below:
>>>
>>> On Tue, 2007-10-09 at 10:33 -0400, Wesley Ebisuzaki wrote:
>>>
>>>> Patrick,
>>>>
>>>> Patrick Reuter wrote:
>>>>
>>>>> Dear all,
>>>>>
>>>>> I download grib2 files and have problems to degrib into Grads.
>>>>>
>>>>> I have the following inventory :
>>>>>
>>>>> 1:115:d=2007100706:HGT:850 mb:15 hour fcst
>>>>> 2:227347:d=2007100706:TMP:850 mb:15 hour fcst
>>>>> 3:315793:d=2007100706:RH:850 mb:15 hour fcst
>>>>> 4.1:411471:d=2007100706:UGRD:850 mb:15 hour fcst
>>>>> 4.2:411471:d=2007100706:VGRD:850 mb:15 hour fcst
>>>>>
>>>>> And I want to extract BOTH the UGRD/VGRD values. Here are my
>>>>> degrib
>>>>> commands :
>>>>>
>>>>> ./degrib grib2file -C -msg 4.1 -Flt -Interp -GrADS -out UGRD
>>>>> ./degrib grib2file -C -msg 4.2 -Flt -Interp -GrADS -out VGRD
>>>>>
>>>>>
>>>> The notation 4.1 (message #4, submessage #1) is unique to
>>>> wgrib2.  You
>>>> should consult the degrib documentation to see how they handle
>>>> submessages.
>>>>
>>>> If all else fails, you can also use wgrib2 to convert
>>>> submessages to
>>>> messages by
>>>>
>>>>           wgrib2 -grib new_grib old_grib
>>>>
>>>>
>>>>> The first command works fine, but in the second command, I
>>>>> always get
>>>>> the following error message :
>>>>>
>>>>> ERROR: In call to Grib2Convert.
>>>>> ERROR: In call to ReadGrib2Record.
>>>>> ERROR: Unpack library error code (0 2)
>>>>>
>>>>> In other words, since the VGRD data is always stored in GRIB2
>>>>> submessages, I can't access to it.
>>>>>
>>>>> Is anybody familiar with my problem ?
>>>>>
>>>>> Thanks in advance
>>>>>
>>>>>   Patrick
>>>>>
>>>> BTW if the grib2 files are lat-lon/mercator/gaussian-grid then
>>>> you should
>>>> consider converting the files into netcdf using wgrib2.  The
>>>> netcdf files
>>>> can be opened by GrADS using the sdfopen command.  I believe that
>>>> degrib can produce netcdf files too.
>>>>
>>>>
>>>
>>> Is netcdf the death-knell for GRIB1 and 2 data on a global scale?
>>> I suppose the NEtcdf files will be about 4 times larger  on average.
>>> This would increase I/O times and storage requirements.
>>>
>>> When will NetCdf use compression?
>>>
>>> Thanks,
>>> Bernd.
>>>
>>>
>>>>    Wesley
>>>>
>>> --
>>> Bernd Becker   The Monthly Outlook
>>> Met Office  FitzRoy Road  Exeter   Devon EX1 3PB  United Kingdom
>>> Tel.: +44 (0) 1392 884511 Fax: +44 (0)870 900 5050
>>> E-mail:bernd.becker at metoffice.com  -  http://www.metoffice.com
>>>
> --
> Bernd Becker   The Monthly Outlook
> Met Office  FitzRoy Road  Exeter   Devon EX1 3PB  United Kingdom
> Tel.: +44 (0) 1392 884511 Fax: +44 (0)870 900 5050
> E-mail:bernd.becker at metoffice.com  -  http://www.metoffice.com

--
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/20071010/7de44dd5/attachment.html 

From theedge981 at GMAIL.COM  Wed Oct 10 09:28:44 2007
From: theedge981 at GMAIL.COM (Dan Leins)
Date: Wed, 10 Oct 2007 08:28:44 -0500
Subject: Regrid problem at specific latitude
In-Reply-To: <46e821750709141737l311cae77q470779092fd198b5@mail.gmail.com>
Message-ID: <WED.10.OCT.2007.082844.0500.>

 All,

I apologize for the re-post of this topic, but I still haven't had any luck
with this problem.

I recently emailed about regridding some observed snowfall data. I've had
mixed success since, but one of the lingering problems I've had is an
artifical line showing up around 41.5N, with garbled data north of that to
the top of my domain. I'm attaching an image showing the "regridded" data.
I'm also showing what the data SHOULD look like before I regridded it.
Anyone have any idea why the line is showing up? I wouldn't care if the line
were around 42.5N, but it cuts right through the area I'm interested in.

Here is the command I used to regrid the snowfall data

define actual=regrid2(snow,0.03,0.03,bl_p1,-88,39)

Any ideas? I'm absolutely stuck!

Thanks,
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071010/456dc170/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: incorrect.png
Type: image/png
Size: 13230 bytes
Desc: not available
Url : http://gradsusr.org/pipermail/gradsusr/attachments/20071010/456dc170/attachment.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: correct.png
Type: image/png
Size: 16540 bytes
Desc: not available
Url : http://gradsusr.org/pipermail/gradsusr/attachments/20071010/456dc170/attachment-0001.png 

From Wesley.Ebisuzaki at NOAA.GOV  Wed Oct 10 09:56:50 2007
From: Wesley.Ebisuzaki at NOAA.GOV (Wesley Ebisuzaki)
Date: Wed, 10 Oct 2007 09:56:50 -0400
Subject: GRIB2: the good, the bad, and the ugly
In-Reply-To: <CAFF7086-A01A-436B-AB7D-BA2A8D0B4308@cola.iges.org>
Message-ID: <WED.10.OCT.2007.095650.0400.>

Jennifer,

     The NCEP grib2 files are packed using JPEG2000 compression.  This
provides very good compression
at the expense of being much slower to decode.  If you go to complex
packing with (1st or 2nd order
differences)  a sample file grows from 25MB to 30MB; however, the decode
time decreases from 30 seconds
to 12 seconds (1 second more than grib1).   For reasonable performance,
you may change the packing.

      Wesley

Jennifer Adams wrote:
>
> The size of grib2 files is impressive given what's packed inside.
> However, once you bring those files to your local disk lickety-split
> there will be some drawbacks when it comes to doing the I/O. Because
> the grids are compressed, you need to unpack and expand them before
> you can read any data. In GrADS terms, that means you must read the
> entire lat/lon grid into memory before you can pick out a single grid
> point. For displays in the X and Y dimensions, there is no evident
> performance hit. For displays that have Z or T varying, it means you
> must read grids at all levels or times before drawing the plot -- this
> is bad, but tolerable, and once you've got those grids in memory, the
> 2nd plot you draw is very fast. The ugly part is when you want to draw
> a Z-T plot -- each point in the Z-T domain requires a global grid read
> into memory. This is where you make up for the time saved when you
> downloaded the files. There is no such thing as a free lunch -- high
> resolution data gobbles resources no matter what data format you use.
>
> By the way, the above is based on two days of testing -- Monday was
> the first day that the GRIB2 interface in GrADS 2.0 was working. I
> still have a lot of testing to do, but am working hard to get a source
> tar file out there for alpha testing as soon as I can.
>
> Jennifer
>
>
>
> On Oct 10, 2007, at 4:04 AM, Bernd Becker wrote:
>
>> Wesley,
>>
>>
>> Hmmm,  assume you maintain a forecast  archive
>> and from one day to the next, you switch from grib 1 data to grib 2
>> data. Each grib  file has its meta data stored separately in one ctl and
>> idx file each.
>> Is it  then possible to read the whole archive in one grads job,
>> despite the mix of grib1 and grib 2 data?
>> (when) is grads able to read grib2 data?
>
>>
>> Many thanks,
>> Bernd.
>>
>> On Tue, 2007-10-09 at 13:55 -0400, Wesley Ebisuzaki wrote:
>>> Bernd,
>>>
>>>      IMHO grib1 is doomed as grib2's compression is too good (~1/5
>>> of grib1
>>> size for operational model files)  and compression will increase as the
>>> world goes
>>> to higher resolution files.  Since grib1 is 1/3 the size of a netcdf
>>> file, you will
>>> see pretty big (uncompressed) netcdf files.   (Your 4x expansion is
>>> a big
>>> underestimate.)
>>>
>>>        Wesley
>>>
>>>
>>>
>>>
>>>
>>>
>>> Bernd Becker wrote:
>>>> Wesley,
>>>>
>>>> see below:
>>>>
>>>> On Tue, 2007-10-09 at 10:33 -0400, Wesley Ebisuzaki wrote:
>>>>
>>>>> Patrick,
>>>>>
>>>>> Patrick Reuter wrote:
>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> I download grib2 files and have problems to degrib into Grads.
>>>>>>
>>>>>> I have the following inventory :
>>>>>>
>>>>>> 1:115:d=2007100706:HGT:850 mb:15 hour fcst
>>>>>> 2:227347:d=2007100706:TMP:850 mb:15 hour fcst
>>>>>> 3:315793:d=2007100706:RH:850 mb:15 hour fcst
>>>>>> 4.1:411471:d=2007100706:UGRD:850 mb:15 hour fcst
>>>>>> 4.2:411471:d=2007100706:VGRD:850 mb:15 hour fcst
>>>>>>
>>>>>> And I want to extract BOTH the UGRD/VGRD values. Here are my degrib
>>>>>> commands :
>>>>>>
>>>>>> ./degrib grib2file -C -msg 4.1 -Flt -Interp -GrADS -out UGRD
>>>>>> ./degrib grib2file -C -msg 4.2 -Flt -Interp -GrADS -out VGRD
>>>>>>
>>>>>>
>>>>> The notation 4.1 (message #4, submessage #1) is unique to wgrib2.  You
>>>>> should consult the degrib documentation to see how they handle
>>>>> submessages.
>>>>>
>>>>> If all else fails, you can also use wgrib2 to convert submessages to
>>>>> messages by
>>>>>
>>>>>           wgrib2 -grib new_grib old_grib
>>>>>
>>>>>
>>>>>> The first command works fine, but in the second command, I always get
>>>>>> the following error message :
>>>>>>
>>>>>> ERROR: In call to Grib2Convert.
>>>>>> ERROR: In call to ReadGrib2Record.
>>>>>> ERROR: Unpack library error code (0 2)
>>>>>>
>>>>>> In other words, since the VGRD data is always stored in GRIB2
>>>>>> submessages, I can't access to it.
>>>>>>
>>>>>> Is anybody familiar with my problem ?
>>>>>>
>>>>>> Thanks in advance
>>>>>>
>>>>>>   Patrick
>>>>>>
>>>>> BTW if the grib2 files are lat-lon/mercator/gaussian-grid then you
>>>>> should
>>>>> consider converting the files into netcdf using wgrib2.  The
>>>>> netcdf files
>>>>> can be opened by GrADS using the sdfopen command.  I believe that
>>>>> degrib can produce netcdf files too.
>>>>>
>>>>>
>>>>
>>>> Is netcdf the death-knell for GRIB1 and 2 data on a global scale?
>>>> I suppose the NEtcdf files will be about 4 times larger  on average.
>>>> This would increase I/O times and storage requirements.
>>>>
>>>> When will NetCdf use compression?
>>>>
>>>> Thanks,
>>>> Bernd.
>>>>
>>>>
>>>>>    Wesley
>>>>>
>>>> --
>>>> Bernd Becker   The Monthly Outlook
>>>> Met Office  FitzRoy Road  Exeter   Devon EX1 3PB  United Kingdom
>>>> Tel.: +44 (0) 1392 884511 Fax: +44 (0)870 900 5050
>>>> E-mail:bernd.becker at metoffice.com
>>>> <mailto:bernd.becker at metoffice.com>  -  http://www.metoffice.com
>>>>
>> --
>> Bernd Becker   The Monthly Outlook
>> Met Office  FitzRoy Road  Exeter   Devon EX1 3PB  United Kingdom
>> Tel.: +44 (0) 1392 884511 Fax: +44 (0)870 900 5050
>> E-mail:bernd.becker at metoffice.com
>> <mailto:bernd.becker at metoffice.com>  -  http://www.metoffice.com
>
> --
> Jennifer M. Adams
> IGES/COLA
> 4041 Powder Mill Road, Suite 302
> Calverton, MD 20705
> jma at cola.iges.org <mailto:jma at cola.iges.org>
>
>
>


From Wesley.Ebisuzaki at NOAA.GOV  Wed Oct 10 11:33:20 2007
From: Wesley.Ebisuzaki at NOAA.GOV (Wesley Ebisuzaki)
Date: Wed, 10 Oct 2007 11:33:20 -0400
Subject: degrib msg and submsg
In-Reply-To: <1192003495.19732.4.camel@eld313.metoffice.com>
Message-ID: <WED.10.OCT.2007.113320.0400.>

Bernd,

     Why not convert all your grib1 files to grib2?  Save disk space.

        Wesley


Bernd Becker wrote:
> Wesley,
>
>
> Hmmm,  assume you maintain a forecast  archive
> and from one day to the next, you switch from grib 1 data to grib 2
> data. Each grib  file has its meta data stored separately in one ctl and
> idx file each.
> Is it  then possible to read the whole archive in one grads job,
> despite the mix of grib1 and grib 2 data?
> (when) is grads able to read grib2 data?
>
> Many thanks,
> Bernd.
>


From jma at COLA.IGES.ORG  Wed Oct 10 12:11:23 2007
From: jma at COLA.IGES.ORG (Jennifer Adams)
Date: Wed, 10 Oct 2007 12:11:23 -0400
Subject: GRIB2: the good, the bad, and the ugly
In-Reply-To: <470CDA22.7030201@noaa.gov>
Message-ID: <WED.10.OCT.2007.121123.0400.>


That's a very good point. But is there a quick and easy way to change
the packing technique? You'd probably have to write out a new file to
do that. And if you have to write out a new file, why not just create
a binary file instead?

Inside GrADS, grib2 is handled like a completely new data format --
borrowing from grib1, but at the I/O level it is completely separate.
GrADS relies heavily on g2clib, which does all the unpacking and
expanding for us, regardless of what packing technique is used. I
would like to find out whether it would make a difference to GrADS if
the grib2 data were not compressed. If changing the packing from JPEG
to noJPEG doesn't improve the performance ... then we would have to
tweak the grib2 interface for optimization down the road.

Are there any grib2 files being distributed to the public that don't
use JPEG compression?

Jennifer

On Oct 10, 2007, at 9:56 AM, Wesley Ebisuzaki wrote:

> Jennifer,
>
>     The NCEP grib2 files are packed using JPEG2000 compression.  This
> provides very good compression
> at the expense of being much slower to decode.  If you go to complex
> packing with (1st or 2nd order
> differences)  a sample file grows from 25MB to 30MB; however, the
> decode
> time decreases from 30 seconds
> to 12 seconds (1 second more than grib1).   For reasonable
> performance,
> you may change the packing.



>
>      Wesley
>
> Jennifer Adams wrote:
>>
>> The size of grib2 files is impressive given what's packed inside.
>> However, once you bring those files to your local disk lickety-split
>> there will be some drawbacks when it comes to doing the I/O. Because
>> the grids are compressed, you need to unpack and expand them before
>> you can read any data. In GrADS terms, that means you must read the
>> entire lat/lon grid into memory before you can pick out a single grid
>> point. For displays in the X and Y dimensions, there is no evident
>> performance hit. For displays that have Z or T varying, it means you
>> must read grids at all levels or times before drawing the plot --
>> this
>> is bad, but tolerable, and once you've got those grids in memory, the
>> 2nd plot you draw is very fast. The ugly part is when you want to
>> draw
>> a Z-T plot -- each point in the Z-T domain requires a global grid
>> read
>> into memory. This is where you make up for the time saved when you
>> downloaded the files. There is no such thing as a free lunch -- high
>> resolution data gobbles resources no matter what data format you use.
>>
>> By the way, the above is based on two days of testing -- Monday was
>> the first day that the GRIB2 interface in GrADS 2.0 was working. I
>> still have a lot of testing to do, but am working hard to get a
>> source
>> tar file out there for alpha testing as soon as I can.
>>
>> Jennifer
>>
>>
>>
>> On Oct 10, 2007, at 4:04 AM, Bernd Becker wrote:
>>
>>> Wesley,
>>>
>>>
>>> Hmmm,  assume you maintain a forecast  archive
>>> and from one day to the next, you switch from grib 1 data to grib 2
>>> data. Each grib  file has its meta data stored separately in one
>>> ctl and
>>> idx file each.
>>> Is it  then possible to read the whole archive in one grads job,
>>> despite the mix of grib1 and grib 2 data?
>>> (when) is grads able to read grib2 data?
>>
>>>
>>> Many thanks,
>>> Bernd.
>>>
>>> On Tue, 2007-10-09 at 13:55 -0400, Wesley Ebisuzaki wrote:
>>>> Bernd,
>>>>
>>>>      IMHO grib1 is doomed as grib2's compression is too good (~1/5
>>>> of grib1
>>>> size for operational model files)  and compression will increase
>>>> as the
>>>> world goes
>>>> to higher resolution files.  Since grib1 is 1/3 the size of a
>>>> netcdf
>>>> file, you will
>>>> see pretty big (uncompressed) netcdf files.   (Your 4x expansion is
>>>> a big
>>>> underestimate.)
>>>>
>>>>        Wesley
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Bernd Becker wrote:
>>>>> Wesley,
>>>>>
>>>>> see below:
>>>>>
>>>>> On Tue, 2007-10-09 at 10:33 -0400, Wesley Ebisuzaki wrote:
>>>>>
>>>>>> Patrick,
>>>>>>
>>>>>> Patrick Reuter wrote:
>>>>>>
>>>>>>> Dear all,
>>>>>>>
>>>>>>> I download grib2 files and have problems to degrib into Grads.
>>>>>>>
>>>>>>> I have the following inventory :
>>>>>>>
>>>>>>> 1:115:d=2007100706:HGT:850 mb:15 hour fcst
>>>>>>> 2:227347:d=2007100706:TMP:850 mb:15 hour fcst
>>>>>>> 3:315793:d=2007100706:RH:850 mb:15 hour fcst
>>>>>>> 4.1:411471:d=2007100706:UGRD:850 mb:15 hour fcst
>>>>>>> 4.2:411471:d=2007100706:VGRD:850 mb:15 hour fcst
>>>>>>>
>>>>>>> And I want to extract BOTH the UGRD/VGRD values. Here are my
>>>>>>> degrib
>>>>>>> commands :
>>>>>>>
>>>>>>> ./degrib grib2file -C -msg 4.1 -Flt -Interp -GrADS -out UGRD
>>>>>>> ./degrib grib2file -C -msg 4.2 -Flt -Interp -GrADS -out VGRD
>>>>>>>
>>>>>>>
>>>>>> The notation 4.1 (message #4, submessage #1) is unique to
>>>>>> wgrib2.  You
>>>>>> should consult the degrib documentation to see how they handle
>>>>>> submessages.
>>>>>>
>>>>>> If all else fails, you can also use wgrib2 to convert
>>>>>> submessages to
>>>>>> messages by
>>>>>>
>>>>>>           wgrib2 -grib new_grib old_grib
>>>>>>
>>>>>>
>>>>>>> The first command works fine, but in the second command, I
>>>>>>> always get
>>>>>>> the following error message :
>>>>>>>
>>>>>>> ERROR: In call to Grib2Convert.
>>>>>>> ERROR: In call to ReadGrib2Record.
>>>>>>> ERROR: Unpack library error code (0 2)
>>>>>>>
>>>>>>> In other words, since the VGRD data is always stored in GRIB2
>>>>>>> submessages, I can't access to it.
>>>>>>>
>>>>>>> Is anybody familiar with my problem ?
>>>>>>>
>>>>>>> Thanks in advance
>>>>>>>
>>>>>>>   Patrick
>>>>>>>
>>>>>> BTW if the grib2 files are lat-lon/mercator/gaussian-grid then
>>>>>> you
>>>>>> should
>>>>>> consider converting the files into netcdf using wgrib2.  The
>>>>>> netcdf files
>>>>>> can be opened by GrADS using the sdfopen command.  I believe that
>>>>>> degrib can produce netcdf files too.
>>>>>>
>>>>>>
>>>>>
>>>>> Is netcdf the death-knell for GRIB1 and 2 data on a global scale?
>>>>> I suppose the NEtcdf files will be about 4 times larger  on
>>>>> average.
>>>>> This would increase I/O times and storage requirements.
>>>>>
>>>>> When will NetCdf use compression?
>>>>>
>>>>> Thanks,
>>>>> Bernd.
>>>>>
>>>>>
>>>>>>    Wesley
>>>>>>
>>>>> --
>>>>> Bernd Becker   The Monthly Outlook
>>>>> Met Office  FitzRoy Road  Exeter   Devon EX1 3PB  United Kingdom
>>>>> Tel.: +44 (0) 1392 884511 Fax: +44 (0)870 900 5050
>>>>> E-mail:bernd.becker at metoffice.com
>>>>> <mailto:bernd.becker at metoffice.com>  -  http://www.metoffice.com
>>>>>
>>> --
>>> Bernd Becker   The Monthly Outlook
>>> Met Office  FitzRoy Road  Exeter   Devon EX1 3PB  United Kingdom
>>> Tel.: +44 (0) 1392 884511 Fax: +44 (0)870 900 5050
>>> E-mail:bernd.becker at metoffice.com
>>> <mailto:bernd.becker at metoffice.com>  -  http://www.metoffice.com
>>
>> --
>> Jennifer M. Adams
>> IGES/COLA
>> 4041 Powder Mill Road, Suite 302
>> Calverton, MD 20705
>> jma at cola.iges.org <mailto:jma at cola.iges.org>
>>
>>
>>

--
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/20071010/f2eaf40c/attachment.html 

From Wesley.Ebisuzaki at NOAA.GOV  Wed Oct 10 13:23:49 2007
From: Wesley.Ebisuzaki at NOAA.GOV (Wesley Ebisuzaki)
Date: Wed, 10 Oct 2007 13:23:49 -0400
Subject: GRIB2: the good, the bad, and the ugly
In-Reply-To: <DFFBFB2C-269C-4484-B539-50F5CE3102BE@cola.iges.org>
Message-ID: <WED.10.OCT.2007.132349.0400.>

Jennifer,

Jennifer Adams wrote:
>
> That's a very good point. But is there a quick and easy way to change
> the packing technique? You'd probably have to write out a new file to
> do that. And if you have to write out a new file, why not just create
> a binary file instead?
But grib2 complex packing can give very good compression with roughly
the same decode time as grib1.
>
> Inside GrADS, grib2 is handled like a completely new data format --
> borrowing from grib1, but at the I/O level it is completely
> separate. GrADS relies heavily on g2clib, which does all the unpacking
> and expanding for us, regardless of what packing technique is used.
g2clib will handle JPEG2000 and complex packing automatically, so you
don't have to change your code.

> I would like to find out whether it would make a difference to GrADS
> if the grib2 data were not compressed. If changing the packing from
> JPEG to noJPEG doesn't improve the performance ... then we would have
> to tweak the grib2 interface for optimization down the road.
>
> Are there any grib2 files being distributed to the public that don't
> use JPEG compression?
You can use

    cnvgrib -p31 -g22 old.grb2 new.grb2

I works on our AIX.  May have issues on non-AIX machines.
If you need, I can send you a test file.

          Wesley

>
> Jennifer
>
> On Oct 10, 2007, at 9:56 AM, Wesley Ebisuzaki wrote:
>
>> Jennifer,
>>
>>     The NCEP grib2 files are packed using JPEG2000 compression.  This
>> provides very good compression
>> at the expense of being much slower to decode.  If you go to complex
>> packing with (1st or 2nd order
>> differences)  a sample file grows from 25MB to 30MB; however, the decode
>> time decreases from 30 seconds
>> to 12 seconds (1 second more than grib1).   For reasonable performance,
>> you may change the packing.
>
>
>
>>
>>      Wesley
>>
>> Jennifer Adams wrote:
>>>
>>> The size of grib2 files is impressive given what's packed inside.
>>> However, once you bring those files to your local disk lickety-split
>>> there will be some drawbacks when it comes to doing the I/O. Because
>>> the grids are compressed, you need to unpack and expand them before
>>> you can read any data. In GrADS terms, that means you must read the
>>> entire lat/lon grid into memory before you can pick out a single grid
>>> point. For displays in the X and Y dimensions, there is no evident
>>> performance hit. For displays that have Z or T varying, it means you
>>> must read grids at all levels or times before drawing the plot -- this
>>> is bad, but tolerable, and once you've got those grids in memory, the
>>> 2nd plot you draw is very fast. The ugly part is when you want to draw
>>> a Z-T plot -- each point in the Z-T domain requires a global grid read
>>> into memory. This is where you make up for the time saved when you
>>> downloaded the files. There is no such thing as a free lunch -- high
>>> resolution data gobbles resources no matter what data format you use.
>>>
>>> By the way, the above is based on two days of testing -- Monday was
>>> the first day that the GRIB2 interface in GrADS 2.0 was working. I
>>> still have a lot of testing to do, but am working hard to get a source
>>> tar file out there for alpha testing as soon as I can.
>>>
>>> Jennifer
>>>
>>>
>>>
>>> On Oct 10, 2007, at 4:04 AM, Bernd Becker wrote:
>>>
>>>> Wesley,
>>>>
>>>>
>>>> Hmmm,  assume you maintain a forecast  archive
>>>> and from one day to the next, you switch from grib 1 data to grib 2
>>>> data. Each grib  file has its meta data stored separately in one
>>>> ctl and
>>>> idx file each.
>>>> Is it  then possible to read the whole archive in one grads job,
>>>> despite the mix of grib1 and grib 2 data?
>>>> (when) is grads able to read grib2 data?
>>>
>>>>
>>>> Many thanks,
>>>> Bernd.
>>>>
>>>> On Tue, 2007-10-09 at 13:55 -0400, Wesley Ebisuzaki wrote:
>>>>> Bernd,
>>>>>
>>>>>      IMHO grib1 is doomed as grib2's compression is too good (~1/5
>>>>> of grib1
>>>>> size for operational model files)  and compression will increase
>>>>> as the
>>>>> world goes
>>>>> to higher resolution files.  Since grib1 is 1/3 the size of a netcdf
>>>>> file, you will
>>>>> see pretty big (uncompressed) netcdf files.   (Your 4x expansion is
>>>>> a big
>>>>> underestimate.)
>>>>>
>>>>>        Wesley
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Bernd Becker wrote:
>>>>>> Wesley,
>>>>>>
>>>>>> see below:
>>>>>>
>>>>>> On Tue, 2007-10-09 at 10:33 -0400, Wesley Ebisuzaki wrote:
>>>>>>
>>>>>>> Patrick,
>>>>>>>
>>>>>>> Patrick Reuter wrote:
>>>>>>>
>>>>>>>> Dear all,
>>>>>>>>
>>>>>>>> I download grib2 files and have problems to degrib into Grads.
>>>>>>>>
>>>>>>>> I have the following inventory :
>>>>>>>>
>>>>>>>> 1:115:d=2007100706:HGT:850 mb:15 hour fcst
>>>>>>>> 2:227347:d=2007100706:TMP:850 mb:15 hour fcst
>>>>>>>> 3:315793:d=2007100706:RH:850 mb:15 hour fcst
>>>>>>>> 4.1:411471:d=2007100706:UGRD:850 mb:15 hour fcst
>>>>>>>> 4.2:411471:d=2007100706:VGRD:850 mb:15 hour fcst
>>>>>>>>
>>>>>>>> And I want to extract BOTH the UGRD/VGRD values. Here are my degrib
>>>>>>>> commands :
>>>>>>>>
>>>>>>>> ./degrib grib2file -C -msg 4.1 -Flt -Interp -GrADS -out UGRD
>>>>>>>> ./degrib grib2file -C -msg 4.2 -Flt -Interp -GrADS -out VGRD
>>>>>>>>
>>>>>>>>
>>>>>>> The notation 4.1 (message #4, submessage #1) is unique to
>>>>>>> wgrib2.  You
>>>>>>> should consult the degrib documentation to see how they handle
>>>>>>> submessages.
>>>>>>>
>>>>>>> If all else fails, you can also use wgrib2 to convert submessages to
>>>>>>> messages by
>>>>>>>
>>>>>>>           wgrib2 -grib new_grib old_grib
>>>>>>>
>>>>>>>
>>>>>>>> The first command works fine, but in the second command, I
>>>>>>>> always get
>>>>>>>> the following error message :
>>>>>>>>
>>>>>>>> ERROR: In call to Grib2Convert.
>>>>>>>> ERROR: In call to ReadGrib2Record.
>>>>>>>> ERROR: Unpack library error code (0 2)
>>>>>>>>
>>>>>>>> In other words, since the VGRD data is always stored in GRIB2
>>>>>>>> submessages, I can't access to it.
>>>>>>>>
>>>>>>>> Is anybody familiar with my problem ?
>>>>>>>>
>>>>>>>> Thanks in advance
>>>>>>>>
>>>>>>>>   Patrick
>>>>>>>>
>>>>>>> BTW if the grib2 files are lat-lon/mercator/gaussian-grid then you
>>>>>>> should
>>>>>>> consider converting the files into netcdf using wgrib2.  The
>>>>>>> netcdf files
>>>>>>> can be opened by GrADS using the sdfopen command.  I believe that
>>>>>>> degrib can produce netcdf files too.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Is netcdf the death-knell for GRIB1 and 2 data on a global scale?
>>>>>> I suppose the NEtcdf files will be about 4 times larger  on average.
>>>>>> This would increase I/O times and storage requirements.
>>>>>>
>>>>>> When will NetCdf use compression?
>>>>>>
>>>>>> Thanks,
>>>>>> Bernd.
>>>>>>
>>>>>>
>>>>>>>    Wesley
>>>>>>>
>>>>>> --
>>>>>> Bernd Becker   The Monthly Outlook
>>>>>> Met Office  FitzRoy Road  Exeter   Devon EX1 3PB  United Kingdom
>>>>>> Tel.: +44 (0) 1392 884511 Fax: +44 (0)870 900 5050
>>>>>> E-mail:bernd.becker at metoffice.com <mailto:bernd.becker at metoffice.com>
>>>>>> <mailto:bernd.becker at metoffice.com>  -  http://www.metoffice.com
>>>>>>
>>>> --
>>>> Bernd Becker   The Monthly Outlook
>>>> Met Office  FitzRoy Road  Exeter   Devon EX1 3PB  United Kingdom
>>>> Tel.: +44 (0) 1392 884511 Fax: +44 (0)870 900 5050
>>>> E-mail:bernd.becker at metoffice.com <mailto:bernd.becker at metoffice.com>
>>>> <mailto:bernd.becker at metoffice.com>  -  http://www.metoffice.com
>>>
>>> --
>>> Jennifer M. Adams
>>> IGES/COLA
>>> 4041 Powder Mill Road, Suite 302
>>> Calverton, MD 20705
>>> jma at cola.iges.org <mailto:jma at cola.iges.org>
>>>
>>>
>>>
>
> --
> Jennifer M. Adams
> IGES/COLA
> 4041 Powder Mill Road, Suite 302
> Calverton, MD 20705
> jma at cola.iges.org <mailto:jma at cola.iges.org>
>
>
>


From jma at COLA.IGES.ORG  Wed Oct 10 13:47:14 2007
From: jma at COLA.IGES.ORG (Jennifer Adams)
Date: Wed, 10 Oct 2007 13:47:14 -0400
Subject: GRIB2: the good, the bad, and the ugly
In-Reply-To: <470D0AA5.3000302@noaa.gov>
Message-ID: <WED.10.OCT.2007.134714.0400.>


On Oct 10, 2007, at 1:23 PM, Wesley Ebisuzaki wrote:

> Jennifer,
>
> Jennifer Adams wrote:
>>
>> That's a very good point. But is there a quick and easy way to change
>> the packing technique? You'd probably have to write out a new file to
>> do that. And if you have to write out a new file, why not just create
>> a binary file instead?
> But grib2 complex packing can give very good compression with roughly
> the same decode time as grib1.
>>
>> Inside GrADS, grib2 is handled like a completely new data format --
>> borrowing from grib1, but at the I/O level it is completely
>> separate. GrADS relies heavily on g2clib, which does all the
>> unpacking
>> and expanding for us, regardless of what packing technique is used.
> g2clib will handle JPEG2000 and complex packing automatically, so you
> don't have to change your code.

Right -- I'm not going to change the GrADS code -- what I want to
find out Is if g2clib routines (called by GrADS) will return a grid
faster when it has complex packing compared to JPEG compression.

>> I would like to find out whether it would make a difference to GrADS
>> if the grib2 data were not compressed. If changing the packing from
>> JPEG to noJPEG doesn't improve the performance ... then we would have
>> to tweak the grib2 interface for optimization down the road.
>>
>> Are there any grib2 files being distributed to the public that don't
>> use JPEG compression?
> You can use
>
>    cnvgrib -p31 -g22 old.grb2 new.grb2
>
> I works on our AIX.  May have issues on non-AIX machines.
> If you need, I can send you a test file.

I will ask my fortran guru to build cnvgrib for me and will convert a
GFS 0.5-degree forecast and see how it compares.

Jennifer


>
>          Wesley
>
>>
>> Jennifer
>>
>> On Oct 10, 2007, at 9:56 AM, Wesley Ebisuzaki wrote:
>>
>>> Jennifer,
>>>
>>>     The NCEP grib2 files are packed using JPEG2000 compression.
>>> This
>>> provides very good compression
>>> at the expense of being much slower to decode.  If you go to complex
>>> packing with (1st or 2nd order
>>> differences)  a sample file grows from 25MB to 30MB; however, the
>>> decode
>>> time decreases from 30 seconds
>>> to 12 seconds (1 second more than grib1).   For reasonable
>>> performance,
>>> you may change the packing.
>>
>>
>>
>>>
>>>      Wesley
>>>
>>> Jennifer Adams wrote:
>>>>
>>>> The size of grib2 files is impressive given what's packed inside.
>>>> However, once you bring those files to your local disk lickety-
>>>> split
>>>> there will be some drawbacks when it comes to doing the I/O.
>>>> Because
>>>> the grids are compressed, you need to unpack and expand them before
>>>> you can read any data. In GrADS terms, that means you must read the
>>>> entire lat/lon grid into memory before you can pick out a single
>>>> grid
>>>> point. For displays in the X and Y dimensions, there is no evident
>>>> performance hit. For displays that have Z or T varying, it means
>>>> you
>>>> must read grids at all levels or times before drawing the plot
>>>> -- this
>>>> is bad, but tolerable, and once you've got those grids in
>>>> memory, the
>>>> 2nd plot you draw is very fast. The ugly part is when you want
>>>> to draw
>>>> a Z-T plot -- each point in the Z-T domain requires a global
>>>> grid read
>>>> into memory. This is where you make up for the time saved when you
>>>> downloaded the files. There is no such thing as a free lunch --
>>>> high
>>>> resolution data gobbles resources no matter what data format you
>>>> use.
>>>>
>>>> By the way, the above is based on two days of testing -- Monday was
>>>> the first day that the GRIB2 interface in GrADS 2.0 was working. I
>>>> still have a lot of testing to do, but am working hard to get a
>>>> source
>>>> tar file out there for alpha testing as soon as I can.
>>>>
>>>> Jennifer
>>>>
>>>>
>>>>
>>>> On Oct 10, 2007, at 4:04 AM, Bernd Becker wrote:
>>>>
>>>>> Wesley,
>>>>>
>>>>>
>>>>> Hmmm,  assume you maintain a forecast  archive
>>>>> and from one day to the next, you switch from grib 1 data to
>>>>> grib 2
>>>>> data. Each grib  file has its meta data stored separately in one
>>>>> ctl and
>>>>> idx file each.
>>>>> Is it  then possible to read the whole archive in one grads job,
>>>>> despite the mix of grib1 and grib 2 data?
>>>>> (when) is grads able to read grib2 data?
>>>>
>>>>>
>>>>> Many thanks,
>>>>> Bernd.
>>>>>
>>>>> On Tue, 2007-10-09 at 13:55 -0400, Wesley Ebisuzaki wrote:
>>>>>> Bernd,
>>>>>>
>>>>>>      IMHO grib1 is doomed as grib2's compression is too good
>>>>>> (~1/5
>>>>>> of grib1
>>>>>> size for operational model files)  and compression will increase
>>>>>> as the
>>>>>> world goes
>>>>>> to higher resolution files.  Since grib1 is 1/3 the size of a
>>>>>> netcdf
>>>>>> file, you will
>>>>>> see pretty big (uncompressed) netcdf files.   (Your 4x
>>>>>> expansion is
>>>>>> a big
>>>>>> underestimate.)
>>>>>>
>>>>>>        Wesley
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Bernd Becker wrote:
>>>>>>> Wesley,
>>>>>>>
>>>>>>> see below:
>>>>>>>
>>>>>>> On Tue, 2007-10-09 at 10:33 -0400, Wesley Ebisuzaki wrote:
>>>>>>>
>>>>>>>> Patrick,
>>>>>>>>
>>>>>>>> Patrick Reuter wrote:
>>>>>>>>
>>>>>>>>> Dear all,
>>>>>>>>>
>>>>>>>>> I download grib2 files and have problems to degrib into Grads.
>>>>>>>>>
>>>>>>>>> I have the following inventory :
>>>>>>>>>
>>>>>>>>> 1:115:d=2007100706:HGT:850 mb:15 hour fcst
>>>>>>>>> 2:227347:d=2007100706:TMP:850 mb:15 hour fcst
>>>>>>>>> 3:315793:d=2007100706:RH:850 mb:15 hour fcst
>>>>>>>>> 4.1:411471:d=2007100706:UGRD:850 mb:15 hour fcst
>>>>>>>>> 4.2:411471:d=2007100706:VGRD:850 mb:15 hour fcst
>>>>>>>>>
>>>>>>>>> And I want to extract BOTH the UGRD/VGRD values. Here are
>>>>>>>>> my degrib
>>>>>>>>> commands :
>>>>>>>>>
>>>>>>>>> ./degrib grib2file -C -msg 4.1 -Flt -Interp -GrADS -out UGRD
>>>>>>>>> ./degrib grib2file -C -msg 4.2 -Flt -Interp -GrADS -out VGRD
>>>>>>>>>
>>>>>>>>>
>>>>>>>> The notation 4.1 (message #4, submessage #1) is unique to
>>>>>>>> wgrib2.  You
>>>>>>>> should consult the degrib documentation to see how they handle
>>>>>>>> submessages.
>>>>>>>>
>>>>>>>> If all else fails, you can also use wgrib2 to convert
>>>>>>>> submessages to
>>>>>>>> messages by
>>>>>>>>
>>>>>>>>           wgrib2 -grib new_grib old_grib
>>>>>>>>
>>>>>>>>
>>>>>>>>> The first command works fine, but in the second command, I
>>>>>>>>> always get
>>>>>>>>> the following error message :
>>>>>>>>>
>>>>>>>>> ERROR: In call to Grib2Convert.
>>>>>>>>> ERROR: In call to ReadGrib2Record.
>>>>>>>>> ERROR: Unpack library error code (0 2)
>>>>>>>>>
>>>>>>>>> In other words, since the VGRD data is always stored in GRIB2
>>>>>>>>> submessages, I can't access to it.
>>>>>>>>>
>>>>>>>>> Is anybody familiar with my problem ?
>>>>>>>>>
>>>>>>>>> Thanks in advance
>>>>>>>>>
>>>>>>>>>   Patrick
>>>>>>>>>
>>>>>>>> BTW if the grib2 files are lat-lon/mercator/gaussian-grid
>>>>>>>> then you
>>>>>>>> should
>>>>>>>> consider converting the files into netcdf using wgrib2.  The
>>>>>>>> netcdf files
>>>>>>>> can be opened by GrADS using the sdfopen command.  I believe
>>>>>>>> that
>>>>>>>> degrib can produce netcdf files too.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Is netcdf the death-knell for GRIB1 and 2 data on a global
>>>>>>> scale?
>>>>>>> I suppose the NEtcdf files will be about 4 times larger  on
>>>>>>> average.
>>>>>>> This would increase I/O times and storage requirements.
>>>>>>>
>>>>>>> When will NetCdf use compression?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Bernd.
>>>>>>>
>>>>>>>
>>>>>>>>    Wesley
>>>>>>>>
>>>>>>> --
>>>>>>> Bernd Becker   The Monthly Outlook
>>>>>>> Met Office  FitzRoy Road  Exeter   Devon EX1 3PB  United Kingdom
>>>>>>> Tel.: +44 (0) 1392 884511 Fax: +44 (0)870 900 5050
>>>>>>> E-mail:bernd.becker at metoffice.com
>>>>>>> <mailto:bernd.becker at metoffice.com>
>>>>>>> <mailto:bernd.becker at metoffice.com>  -  http://www.metoffice.com
>>>>>>>
>>>>> --
>>>>> Bernd Becker   The Monthly Outlook
>>>>> Met Office  FitzRoy Road  Exeter   Devon EX1 3PB  United Kingdom
>>>>> Tel.: +44 (0) 1392 884511 Fax: +44 (0)870 900 5050
>>>>> E-mail:bernd.becker at metoffice.com
>>>>> <mailto:bernd.becker at metoffice.com>
>>>>> <mailto:bernd.becker at metoffice.com>  -  http://www.metoffice.com
>>>>
>>>> --
>>>> Jennifer M. Adams
>>>> IGES/COLA
>>>> 4041 Powder Mill Road, Suite 302
>>>> Calverton, MD 20705
>>>> jma at cola.iges.org <mailto:jma at cola.iges.org>
>>>>
>>>>
>>>>
>>
>> --
>> Jennifer M. Adams
>> IGES/COLA
>> 4041 Powder Mill Road, Suite 302
>> Calverton, MD 20705
>> jma at cola.iges.org <mailto:jma at cola.iges.org>
>>
>>
>>

--
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/20071010/0c8a774c/attachment.html 

From dasilva at ALUM.MIT.EDU  Thu Oct 11 13:55:49 2007
From: dasilva at ALUM.MIT.EDU (Arlindo da Silva)
Date: Thu, 11 Oct 2007 13:55:49 -0400
Subject: lats4d: Trouble in generating correct center name and code
In-Reply-To: <20071010095906.E0BA6206DC@mx2.cineca.it>
Message-ID: <THU.11.OCT.2007.135549.0400.>

On 10/10/07, Ioannis A. Vamvakas <giavvns at ath.hcmr.gr> wrote:
>
> Hello,
>
> I've been using lats4d to convert a netCDF file into grib1.
> Everything works just fine but the Center name/id.


Do you mean the originating or the processing center?

It won't
> see the name I provide in the lookup table and will use the
> default name (=pcmdi) and code (=100).
>
> The command I use to do this is:
>
> lats4d -i <file>.nc -o <file> -format grib -table mytable
>
> where, 'mytable', is a copy of '.grads.lats.table' with a
> line at the center section added as follows:
>
> hcmr | 96 | 0 | 0


The description of the center record in the lats table reads:

# The format of each record is:
#   center | GRIB_id | GRIB_center | GRIB_subcenter
#
# center = mnemonic for the center
# GRIB_id = GRIB generating process id (PDS octet 6)
# GRIB_center = the id of center managing the data (for AMIP II this is
PCMDI) -
 see GRIB Table 0
# GRIB_subcenter = the id of the subcenter


"0" is not a valid grib center; I believe this is being changed into 100.
Try something like this:

hcmr | 96 | 96 | 2

Here is what "wgrib -V" reports:

rec 190:1133616:date 1987010500 DIST kpds5=8 kpds6=100 kpds7=100
levels=(0,100) grid=255 100 mb anl: bitmap: 3312 undef
  DIST=Geometric height [m]
  timerange 0 P1 0 P2 0 TimeU 2  nx 72 ny 46 GDS grid 0 num_in_ave 0 missing
0
  center 96 subcenter 2 process 96 Table 128 scan: WE:NS winds(N/S)
  latlon: lat  -90.000000 to 90.000000 by 4.000000  nxny 3312
          long 0.000000 to 355.000000 by 5.000000, (72 x 46) scan 2 mode 128
bdsgrid 1
  min/max data 3.40282e+38 -3.40282e+38  num bits 16  BDS_Ref 3.40282e+38
DecScale 0 BinScale -32766

  Good Luck,

--
Arlindo da Silva
dasilva at alum.mit.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071011/dc6b7397/attachment.html 

From msponsler at COMCAST.NET  Thu Oct 11 14:04:20 2007
From: msponsler at COMCAST.NET (Mark Sponsler)
Date: Thu, 11 Oct 2007 20:04:20 +0200
Subject: WGRIB2 Question
Message-ID: <THU.11.OCT.2007.200420.0200.>

Is it possible to write the invetory from wgrib2 out to a text file? I
don't need the actual data values in the grib, just the inventory.  The
best I can do now is using the -spread option, which writes a snipet of
the invetory out along with all the data (which will work in a pinch):
wgrib2.exe grib_file -v -d 1 | wgrib2.exe -i grib_file -spread
rec1_out.txt

Just trying to get the 'date' out of the first record so I can automate
building a ctl file.

Any help would be appreciated.

Thanks,
Mark


From marco at SIMEPAR.BR  Thu Oct 11 14:08:57 2007
From: marco at SIMEPAR.BR (Marco Jusevicius)
Date: Thu, 11 Oct 2007 15:08:57 -0300
Subject: Plot variables of different files
Message-ID: <THU.11.OCT.2007.150857.0300.>

Hi folks.

How can I plot variables of different files together in the same panel?

Example: NCEP reanalysis files

sea level pressure and temperature in 850 hPa

ncdump -h of that files:

slp.2007.nc

netcdf slp.2007 {
dimensions:
        lon = 144 ;
        lat = 73 ;
        time = UNLIMITED ; // (56 currently)

air.2007.nc

netcdf air.2007 {
dimensions:
        lon = 144 ;
        lat = 73 ;
        level = 17 ;
        time = UNLIMITED ; // (56 currently)

In slp it has no level and in air it has 17 levels. I suppose that is
the problem...

Someone has any suggestion?

Thanks a lot!

Marco.

--
Marco Antonio Rodrigues Jusevicius
Meteorologista
Insituto Tecnol?gico SIMEPAR - Curitiba/PR
Fone: (41)-3320-2072
e-mail: marco at simepar.br


From Wesley.Ebisuzaki at NOAA.GOV  Thu Oct 11 15:27:43 2007
From: Wesley.Ebisuzaki at NOAA.GOV (Wesley Ebisuzaki)
Date: Thu, 11 Oct 2007 15:27:43 -0400
Subject: WGRIB2 Question
In-Reply-To: <20071011180440.CA7EE20747@mx2.cineca.it>
Message-ID: <THU.11.OCT.2007.152743.0400.>

Mark Sponsler wrote:
> Is it possible to write the invetory from wgrib2 out to a text file? I
> don't need the actual data values in the grib, just the inventory.  The
> best I can do now is using the -spread option, which writes a snipet of
> the invetory out along with all the data (which will work in a pinch):
> wgrib2.exe grib_file -v -d 1 | wgrib2.exe -i grib_file -spread
> rec1_out.txt
>
> Just trying to get the 'date' out of the first record so I can automate
> building a ctl file.
>
> Any help would be appreciated.
>
> Thanks,
> Mark
>
Mark,

   How about

    wgrib2 grib -d 1  > line1

or

   date=`wgrib2  new.grb2 -d 1 -t  | sed 's/.*d=//'`

        Wesley


From msponsler at COMCAST.NET  Thu Oct 11 18:10:45 2007
From: msponsler at COMCAST.NET (Mark Sponsler)
Date: Thu, 11 Oct 2007 22:10:45 +0000
Subject: WGRIB2 Question
Message-ID: <THU.11.OCT.2007.221045.0000.>

Wesley,
The first suggestion works like a charm on my limited Windows XP system.
The second one looks to require s Unix OS.  Either way, it's a solution!
Thanks very much.
--
Thanks,
Mark

-------------- Original message --------------
From: Wesley Ebisuzaki <Wesley.Ebisuzaki at NOAA.GOV>

> Mark Sponsler wrote:
> > Is it possible to write the invetory from wgrib2 out to a text file? I
> > don't need the actual data values in the grib, just the inventory. The
> > best I can do now is using the -spread option, which writes a snipet of
> > the invetory out along with all the data (which will work in a pinch):
> > wgrib2.exe grib_file -v -d 1 | wgrib2.exe -i grib_file -spread
> > rec1_out.txt
> >
> > Just trying to get the 'date' out of the first record so I can automate
> > building a ctl file.
> >
> > Any help would be appreciated.
> >
> > Thanks,
> > Mark
> >
> Mark,
>
> How about
>
> wgrib2 grib -d 1 > line1
>
> or
>
> date=`wgrib2 new.grb2 -d 1 -t | sed 's/.*d=//'`
>
> Wesley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071011/607597f8/attachment.html 

From aidab at PDX.EDU  Thu Oct 11 20:48:41 2007
From: aidab at PDX.EDU (Aida Biberic)
Date: Fri, 12 Oct 2007 02:48:41 +0200
Subject: File too big
Message-ID: <FRI.12.OCT.2007.024841.0200.>

I am not able to open a netcdf file that is about 4 GB in size. Following is
the message:

ga-> sdfopen h0004.nc
Scanning self-describing file:  h0004.nc
nc_open failure:
File too large
h0004.nc does not exist or is not a netCDF file.

Couldn't ingest SDF metadata.
If this was an HDF-SDS file, try gradshdf.


I have GrADS 1.9b4 on a x86_64 running Linux.
Please help.

Aida


From wlz at TEA.AC.CN  Fri Oct 12 03:08:16 2007
From: wlz at TEA.AC.CN (Wang Lizhi)
Date: Fri, 12 Oct 2007 15:08:16 +0800
Subject: Plot multiple files with one control file
Message-ID: <FRI.12.OCT.2007.150816.0800.>

Dear Users,

I download the NCEP reanalysis-2 dataset from the site http://nomad3.ncep.noaa.gov/pub/raid1/reanalysis-2/month/  and use the following step to convert the GRIB data
grib2ctl.pl datfile > datfile.ctl
gribmap -i datfile.ctl -0

then every month the file as following: datfile, datfile.ctl and datfile.idx

I want to display multiple file with one control file, so I have the whole control file named ncep.ctl as :

dset ^flx.ft06.%y4%m2.avrg.grib
index ^flx.ft06.%ym%m2.avrg.grib.idx
options template
.....
*  dataset from 197901 to 200709
tdef 345 linear 00Z01jan1979 1mo
vars 54
.....
endvars

when I display the file, the following error is displayed:
Open Error:  Can't open Station/Index map file flx.ft06.%y4%m2.avrg.grib.idx
  --> The invalid description file record is:
  --> index ^flx.ft06.%y4%m2.avrg.grib.idx

How can I read the multiple index files with grads?

Grads:  v1.8SL11 32-bit   OS: SuSE 10 with kernel 2.6.16.27-0.9-smp x86_64

thanks

lizhi


----- Original Message -----
From: "Arlindo da Silva" <dasilva at ALUM.MIT.EDU>
To: <GRADSUSR at LIST.CINECA.IT>
Sent: Wednesday, October 10, 2007 5:12 AM
Subject: Re: Plot multiple files with one control file


> On 10/8/07, ashish no routray <ashishroutray at rediffmail.com> wrote:
>>
>> Dear Users
>> I need your kind help to plot the multile binary files in using one .ctl
>> file.
>> I downloaded TRMM 03 hourly data for a period and also .ctl file from TRMM
>> site
>>
>
> It is always a good idea to give the URL so that someone could try to
> download the same files and reproduce the problem... Also, provide the
> output of "q config" and "!uname -a" so that we can know which version you
> are using...
>
> . we are trying to plot 24hrs accumulated rainfall from all 9
> files.Filesare look like:
>>
>> 3B42.020601.00z.6.precipitation.bin
>> 3B42.020601.03z.6.precipitation.bin
>> ......
>> ......
>> 3B42.020602.00z.6.precipitation.bin
>>
>> Here I am giving the .ctl file as follow:
>>
>
> I am assuming that the individual ctl provided with data works fine.
>
> ***************************************************
>> dset ./3B42.%y2%m2%d2.%h2z.6.precipitation.bin
>> options template byteswapped
>>
> The option "byteswapped" is deprecated. Use either "big_endian" or
> "little_endian", depending on the endianess of the machine TRMM used to
> write the data.
>
> title TRMM 3B42 V6 three hourly TRMM rainfall
>> undef -9999.0
>> xdef 1440 linear -179.875 0.25000000
>> ydef 400  linear -49.8750000 0.25000000
>> zdef 1 levels 1000
>>
> So far, so good...
>
> tdef 9 linear 00:00Z01jan1998 3hr
>>
>
> Why "9"? You need the enter the total number of time steps from 1998 to
> 2007.
>
>
>> * end_time 21:00Z31aug2007 (this_is_comment_line)
>> vars 1
>> r        0  99 Hourly Rain Rate (mm/hr)
>> endvars
>>
>> **************************************************
>>
>> We are running the .ctl in IBM(P5) machine.
>> It showing Gridded are undefined. I hope it could not open the files. when
>> I plot individual files alone it is ploting properly.
>>
>
> Can you plot t=1 through t=9 with the template version of the  ctl?
>
> --
> Arlindo da Silva
> dasilva at alum.mit.edu
>


From vsm at RIAM.KYUSHU-U.AC.JP  Fri Oct 12 05:14:49 2007
From: vsm at RIAM.KYUSHU-U.AC.JP (Sergey Varlamov)
Date: Fri, 12 Oct 2007 18:14:49 +0900
Subject: Plot multiple files with one control file
In-Reply-To: <DE0E67CB43644217AFD0F359C3E314A2@test.tea.ac.cn>
Message-ID: <FRI.12.OCT.2007.181449.0900.>

Dear Wang Lizhi,

Grads do not support templates in index file names, but:
1) please change "index" line in your ctl file to some fixed name, like

index ^flx.ft06.avrg.grib.idx

then create this 'single' index file:

gribmap -v -i ncep.ctl -0

It must work, -v is for the verbose output:
if work goes, you will see a lot of MATCH strings,
else - look on your ctl file again.

Best regards,

Sergey Varlamov
vsm at riam.kyushu-u.ac.jp


Wang Lizhi wrote:

>Dear Users,
>
>I download the NCEP reanalysis-2 dataset from the site http://nomad3.ncep.noaa.gov/pub/raid1/reanalysis-2/month/  and use the following step to convert the GRIB data
>grib2ctl.pl datfile > datfile.ctl
>gribmap -i datfile.ctl -0
>
>then every month the file as following: datfile, datfile.ctl and datfile.idx
>
>I want to display multiple file with one control file, so I have the whole control file named ncep.ctl as :
>
>dset ^flx.ft06.%y4%m2.avrg.grib
>index ^flx.ft06.%ym%m2.avrg.grib.idx
>options template
>.....
>*  dataset from 197901 to 200709
>tdef 345 linear 00Z01jan1979 1mo
>vars 54
>.....
>endvars
>
>when I display the file, the following error is displayed:
>Open Error:  Can't open Station/Index map file flx.ft06.%y4%m2.avrg.grib.idx
>  --> The invalid description file record is:
>  --> index ^flx.ft06.%y4%m2.avrg.grib.idx
>
>How can I read the multiple index files with grads?
>
>Grads:  v1.8SL11 32-bit   OS: SuSE 10 with kernel 2.6.16.27-0.9-smp x86_64
>
>thanks
>
>lizhi
>
>
>----- Original Message -----
>From: "Arlindo da Silva" <dasilva at ALUM.MIT.EDU>
>To: <GRADSUSR at LIST.CINECA.IT>
>Sent: Wednesday, October 10, 2007 5:12 AM
>Subject: Re: Plot multiple files with one control file
>
>
>
>
>>On 10/8/07, ashish no routray <ashishroutray at rediffmail.com> wrote:
>>
>>
>>>Dear Users
>>>I need your kind help to plot the multile binary files in using one .ctl
>>>file.
>>>I downloaded TRMM 03 hourly data for a period and also .ctl file from TRMM
>>>site
>>>
>>>
>>>
>>It is always a good idea to give the URL so that someone could try to
>>download the same files and reproduce the problem... Also, provide the
>>output of "q config" and "!uname -a" so that we can know which version you
>>are using...
>>
>>. we are trying to plot 24hrs accumulated rainfall from all 9
>>files.Filesare look like:
>>
>>
>>>3B42.020601.00z.6.precipitation.bin
>>>3B42.020601.03z.6.precipitation.bin
>>>......
>>>......
>>>3B42.020602.00z.6.precipitation.bin
>>>
>>>Here I am giving the .ctl file as follow:
>>>
>>>
>>>
>>I am assuming that the individual ctl provided with data works fine.
>>
>>***************************************************
>>
>>
>>>dset ./3B42.%y2%m2%d2.%h2z.6.precipitation.bin
>>>options template byteswapped
>>>
>>>
>>>
>>The option "byteswapped" is deprecated. Use either "big_endian" or
>>"little_endian", depending on the endianess of the machine TRMM used to
>>write the data.
>>
>>title TRMM 3B42 V6 three hourly TRMM rainfall
>>
>>
>>>undef -9999.0
>>>xdef 1440 linear -179.875 0.25000000
>>>ydef 400  linear -49.8750000 0.25000000
>>>zdef 1 levels 1000
>>>
>>>
>>>
>>So far, so good...
>>
>>tdef 9 linear 00:00Z01jan1998 3hr
>>
>>
>>Why "9"? You need the enter the total number of time steps from 1998 to
>>2007.
>>
>>
>>
>>
>>>* end_time 21:00Z31aug2007 (this_is_comment_line)
>>>vars 1
>>>r        0  99 Hourly Rain Rate (mm/hr)
>>>endvars
>>>
>>>**************************************************
>>>
>>>We are running the .ctl in IBM(P5) machine.
>>>It showing Gridded are undefined. I hope it could not open the files. when
>>>I plot individual files alone it is ploting properly.
>>>
>>>
>>>
>>Can you plot t=1 through t=9 with the template version of the  ctl?
>>
>>--
>>Arlindo da Silva
>>dasilva at alum.mit.edu
>>
>>
>>
>
>
>
>


From wlz at TEA.AC.CN  Fri Oct 12 07:04:34 2007
From: wlz at TEA.AC.CN (Wang Lizhi)
Date: Fri, 12 Oct 2007 19:04:34 +0800
Subject: Plot multiple files with one control file
Message-ID: <FRI.12.OCT.2007.190434.0800.>

Dear Sergey Varlamov,

It works.

Thank you very much.

Best regards,

lizhi

----- Original Message -----
From: "Sergey Varlamov" <vsm at RIAM.KYUSHU-U.AC.JP>
To: <GRADSUSR at LIST.CINECA.IT>
Sent: Friday, October 12, 2007 5:14 PM
Subject: Re: Plot multiple files with one control file


> Dear Wang Lizhi,
>
> Grads do not support templates in index file names, but:
> 1) please change "index" line in your ctl file to some fixed name, like
>
> index ^flx.ft06.avrg.grib.idx
>
> then create this 'single' index file:
>
> gribmap -v -i ncep.ctl -0
>
> It must work, -v is for the verbose output:
> if work goes, you will see a lot of MATCH strings,
> else - look on your ctl file again.
>
> Best regards,
>
> Sergey Varlamov
> vsm at riam.kyushu-u.ac.jp
>
>
> Wang Lizhi wrote:
>
>>Dear Users,
>>
>>I download the NCEP reanalysis-2 dataset from the site http://nomad3.ncep.noaa.gov/pub/raid1/reanalysis-2/month/  and use the following step to convert the GRIB data
>>grib2ctl.pl datfile > datfile.ctl
>>gribmap -i datfile.ctl -0
>>
>>then every month the file as following: datfile, datfile.ctl and datfile.idx
>>
>>I want to display multiple file with one control file, so I have the whole control file named ncep.ctl as :
>>
>>dset ^flx.ft06.%y4%m2.avrg.grib
>>index ^flx.ft06.%ym%m2.avrg.grib.idx
>>options template
>>.....
>>*  dataset from 197901 to 200709
>>tdef 345 linear 00Z01jan1979 1mo
>>vars 54
>>.....
>>endvars
>>
>>when I display the file, the following error is displayed:
>>Open Error:  Can't open Station/Index map file flx.ft06.%y4%m2.avrg.grib.idx
>>  --> The invalid description file record is:
>>  --> index ^flx.ft06.%y4%m2.avrg.grib.idx
>>
>>How can I read the multiple index files with grads?
>>
>>Grads:  v1.8SL11 32-bit   OS: SuSE 10 with kernel 2.6.16.27-0.9-smp x86_64
>>
>>thanks
>>
>>lizhi
>>
>>
>>----- Original Message -----
>>From: "Arlindo da Silva" <dasilva at ALUM.MIT.EDU>
>>To: <GRADSUSR at LIST.CINECA.IT>
>>Sent: Wednesday, October 10, 2007 5:12 AM
>>Subject: Re: Plot multiple files with one control file
>>
>>
>>
>>
>>>On 10/8/07, ashish no routray <ashishroutray at rediffmail.com> wrote:
>>>
>>>
>>>>Dear Users
>>>>I need your kind help to plot the multile binary files in using one .ctl
>>>>file.
>>>>I downloaded TRMM 03 hourly data for a period and also .ctl file from TRMM
>>>>site
>>>>
>>>>
>>>>
>>>It is always a good idea to give the URL so that someone could try to
>>>download the same files and reproduce the problem... Also, provide the
>>>output of "q config" and "!uname -a" so that we can know which version you
>>>are using...
>>>
>>>. we are trying to plot 24hrs accumulated rainfall from all 9
>>>files.Filesare look like:
>>>
>>>
>>>>3B42.020601.00z.6.precipitation.bin
>>>>3B42.020601.03z.6.precipitation.bin
>>>>......
>>>>......
>>>>3B42.020602.00z.6.precipitation.bin
>>>>
>>>>Here I am giving the .ctl file as follow:
>>>>
>>>>
>>>>
>>>I am assuming that the individual ctl provided with data works fine.
>>>
>>>***************************************************
>>>
>>>
>>>>dset ./3B42.%y2%m2%d2.%h2z.6.precipitation.bin
>>>>options template byteswapped
>>>>
>>>>
>>>>
>>>The option "byteswapped" is deprecated. Use either "big_endian" or
>>>"little_endian", depending on the endianess of the machine TRMM used to
>>>write the data.
>>>
>>>title TRMM 3B42 V6 three hourly TRMM rainfall
>>>
>>>
>>>>undef -9999.0
>>>>xdef 1440 linear -179.875 0.25000000
>>>>ydef 400  linear -49.8750000 0.25000000
>>>>zdef 1 levels 1000
>>>>
>>>>
>>>>
>>>So far, so good...
>>>
>>>tdef 9 linear 00:00Z01jan1998 3hr
>>>
>>>
>>>Why "9"? You need the enter the total number of time steps from 1998 to
>>>2007.
>>>
>>>
>>>
>>>
>>>>* end_time 21:00Z31aug2007 (this_is_comment_line)
>>>>vars 1
>>>>r        0  99 Hourly Rain Rate (mm/hr)
>>>>endvars
>>>>
>>>>**************************************************
>>>>
>>>>We are running the .ctl in IBM(P5) machine.
>>>>It showing Gridded are undefined. I hope it could not open the files. when
>>>>I plot individual files alone it is ploting properly.
>>>>
>>>>
>>>>
>>>Can you plot t=1 through t=9 with the template version of the  ctl?
>>>
>>>--
>>>Arlindo da Silva
>>>dasilva at alum.mit.edu
>>>
>>>
>>>
>>
>>
>>
>>


From stegert at IFM.UNI-HAMBURG.DE  Fri Oct 12 07:34:25 2007
From: stegert at IFM.UNI-HAMBURG.DE (Stegert)
Date: Fri, 12 Oct 2007 13:34:25 +0200
Subject: Plot variables of different files
In-Reply-To: <470E66B9.70500@simepar.br>
Message-ID: <FRI.12.OCT.2007.133425.0200.>

Dear Marco,

I have no experience with nc-files but I guess it should be
similar as to handling ctl-files!?

You can open several files and switch by "set dfile N" (N be the
N-th file you've opened).

I'm not sure if you'd like to put both into a
single figure or two figure next to each other.

Case 1: open air-file
set lev 1 (e.g. to plot the first temperature level -
which I guess is the surface nearest?)
set t ...
set gxout shaded
d air
open slp-file
set dfile 2
set gxout contour
d slp (plots contours of pressure above the temperature field)

Case 2:
open air-file
set vpage (adjusted to the left or top)
set lev ...
d air
open slp-file
set vpage (now adjusted to the right or bottom)
set dfile 2
d slp

Hope this gets, what you wanted...
Christoph

Marco Jusevicius schrieb:
> Hi folks.
>
> How can I plot variables of different files together in the same panel?
> Example: NCEP reanalysis files
> sea level pressure and temperature in 850 hPa
> ncdump -h of that files:
>
> slp.2007.nc
> netcdf slp.2007 {
> dimensions:
>        lon = 144 ;
>        lat = 73 ;
>        time = UNLIMITED ; // (56 currently)
>
> air.2007.nc
> netcdf air.2007 {
> dimensions:
>        lon = 144 ;
>        lat = 73 ;
>        level = 17 ;
>        time = UNLIMITED ; // (56 currently)
>
> In slp it has no level and in air it has 17 levels. I suppose that is
> the problem...
> Someone has any suggestion?
> Thanks a lot!
> Marco.

--
Christoph Stegert
Institute for Oceanography - Ecological Modelling group
University of Hamburg, GER - (ZMK/ZMAW alliance member)
Bundesstr.53 20146 Hamburg - +49-40/42838-7486 Room 348


From aidab at PDX.EDU  Fri Oct 12 15:17:10 2007
From: aidab at PDX.EDU (Aida Biberic)
Date: Fri, 12 Oct 2007 21:17:10 +0200
Subject: File size limit
Message-ID: <FRI.12.OCT.2007.211710.0200.>

Hi,

Is there a limitation on the size of a file that can be opened with GrADS?
If not would anybody point out what the problem in my configuration is since
I am not able to open a 4GB file. Files that are about 1 GB are not a
problem, (all NetCDF files, outputs of the same model). Following are error
message, config.out, and ncdump -c.

Thanks,

Aida



Error message from GrADS:

ga-> sdfopen h0003.nc
Scanning self-describing file:  h0003.nc
nc_open failure:
File too large
h0003.nc does not exist or is not a netCDF file.

Couldn't ingest SDF metadata.
If this was an HDF-SDS file, try gradshdf.




Here is my configuration output:

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by GrADS configure 1.9b4, which was
generated by GNU Autoconf 2.57.  Invocation command line was

  $ ./configure prefix = /usr/local/grads-1.9b4/

## --------- ##
## Platform. ##
## --------- ##

hostname = climate1.sb2.pdx.edu
uname -m = x86_64
uname -r = 2.6.9-55.ELsmp
uname -s = Linux
uname -v = #1 SMP Fri Apr 20 16:36:54 EDT 2007

/usr/bin/uname -p = unknown
/bin/uname -X     = unknown

/bin/arch              = x86_64
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
hostinfo               = unknown
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: /usr/kerberos/sbin
PATH: /usr/kerberos/bin
PATH: /usr/local/bin
PATH: /usr/bin
PATH: /bin
PATH: /usr/X11R6/bin
PATH: /home/user/bin
PATH: /opt/pgi/linux86-64/7.0/bin
PATH: /opt/pgi


## ----------- ##
## Core tests. ##
## ----------- ##

configure:1372: checking for a BSD-compatible install
configure:1426: result: /usr/bin/install -c
configure:1437: checking whether build environment is sane
configure:1480: result: yes
configure:1513: checking for gawk
configure:1529: found /usr/bin/gawk
configure:1539: result: gawk
configure:1549: checking whether make sets $(MAKE)
configure:1569: result: yes
configure:1716: checking whether to enable maintainer-specific portions of
Makefiles
configure:1725: result: no
configure:1840: checking for gawk
configure:1866: result: gawk
configure:1884: checking for prefix-gcc
configure:1913: result: no
configure:1922: checking for gcc
configure:1938: found /usr/bin/gcc
configure:1948: result: gcc
configure:2192: checking for C compiler version
configure:2195: gcc --version </dev/null >&5
gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-8)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:2198: $? = 0
configure:2200: gcc -v </dev/null >&5
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-8)
configure:2203: $? = 0
configure:2205: gcc -V </dev/null >&5
gcc: `-V' option must have argument
configure:2208: $? = 1
configure:2232: checking for C compiler default output
configure:2235: gcc -g -O   conftest.c  >&5
configure:2238: $? = 0
configure:2284: result: a.out
configure:2289: checking whether the C compiler works
configure:2295: ./a.out
configure:2298: $? = 0
configure:2315: result: yes
configure:2322: checking whether we are cross compiling
configure:2324: result: no
configure:2327: checking for suffix of executables
configure:2329: gcc -o conftest -g -O   conftest.c  >&5
configure:2332: $? = 0
configure:2357: result:
configure:2363: checking for suffix of object files
configure:2385: gcc -c -g -O  conftest.c >&5
configure:2388: $? = 0
configure:2410: result: o
configure:2414: checking whether we are using the GNU C compiler
configure:2439: gcc -c -g -O  conftest.c >&5
configure:2442: $? = 0
configure:2445: test -s conftest.o
configure:2448: $? = 0
configure:2461: result: yes
configure:2467: checking whether gcc accepts -g
configure:2489: gcc -c -g  conftest.c >&5
configure:2492: $? = 0
configure:2495: test -s conftest.o
configure:2498: $? = 0
configure:2509: result: yes
configure:2526: checking for gcc option to accept ANSI C
configure:2587: gcc  -c -g -O  conftest.c >&5
configure:2590: $? = 0
configure:2593: test -s conftest.o
configure:2596: $? = 0
configure:2614: result: none needed
configure:2632: gcc -c -g -O  conftest.c >&5
conftest.c:2: error: syntax error before "me"
configure:2635: $? = 1
configure: failed program was:
| #ifndef __cplusplus
|   choke me
| #endif
configure:2754: checking for prefix-g++
configure:2783: result: no
configure:2754: checking for prefix-c++
configure:2783: result: no
configure:2754: checking for prefix-gpp
configure:2783: result: no
configure:2754: checking for prefix-aCC
configure:2783: result: no
configure:2754: checking for prefix-CC
configure:2783: result: no
configure:2754: checking for prefix-cxx
configure:2783: result: no
configure:2754: checking for prefix-cc++
configure:2783: result: no
configure:2754: checking for prefix-cl
configure:2783: result: no
configure:2754: checking for prefix-FCC
configure:2783: result: no
configure:2754: checking for prefix-KCC
configure:2783: result: no
configure:2754: checking for prefix-RCC
configure:2783: result: no
configure:2754: checking for prefix-xlC_r
configure:2783: result: no
configure:2754: checking for prefix-xlC
configure:2783: result: no
configure:2796: checking for g++
configure:2812: found /usr/bin/g++
configure:2822: result: g++
configure:2838: checking for C++ compiler version
configure:2841: g++ --version </dev/null >&5
g++ (GCC) 3.4.6 20060404 (Red Hat 3.4.6-8)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:2844: $? = 0
configure:2846: g++ -v </dev/null >&5
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-8)
configure:2849: $? = 0
configure:2851: g++ -V </dev/null >&5
g++: `-V' option must have argument
configure:2854: $? = 1
configure:2857: checking whether we are using the GNU C++ compiler
configure:2882: g++ -c   conftest.cc >&5
configure:2885: $? = 0
configure:2888: test -s conftest.o
configure:2891: $? = 0
configure:2904: result: yes
configure:2910: checking whether g++ accepts -g
configure:2932: g++ -c -g  conftest.cc >&5
configure:2935: $? = 0
configure:2938: test -s conftest.o
configure:2941: $? = 0
configure:2952: result: yes
configure:2996: g++ -c -g -O2  conftest.cc >&5
configure:2999: $? = 0
configure:3002: test -s conftest.o
configure:3005: $? = 0
configure:3032: g++ -c -g -O2  conftest.cc >&5
configure: In function `int main()':
configure:3027: error: `exit' was not declared in this scope
configure:3035: $? = 1
configure: failed program was:
| #line 3015 "configure"
| /* confdefs.h.  */
|
| #define PACKAGE_NAME "GrADS"
| #define PACKAGE_TARNAME "grads"
| #define PACKAGE_VERSION "1.9b4"
| #define PACKAGE_STRING "GrADS 1.9b4"
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h.  */
|
| int
| main ()
| {
| exit (42);
|   ;
|   return 0;
| }
configure:2996: g++ -c -g -O2  conftest.cc >&5
configure:2999: $? = 0
configure:3002: test -s conftest.o
configure:3005: $? = 0
configure:3032: g++ -c -g -O2  conftest.cc >&5
configure:3035: $? = 0
configure:3038: test -s conftest.o
configure:3041: $? = 0
configure:3076: checking for a BSD-compatible install
configure:3130: result: /usr/bin/install -c
configure:3141: checking whether ln -s works
configure:3145: result: yes
configure:3167: checking build system type
configure:3180: error: /bin/sh etc/config.sub prefix failed

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_build=
ac_cv_build_alias=prefix
ac_cv_c_compiler_gnu=yes
ac_cv_cxx_compiler_gnu=yes
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_CXXFLAGS_set=
ac_cv_env_CXXFLAGS_value=
ac_cv_env_CXX_set=
ac_cv_env_CXX_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_SUPPLIBS_set=
ac_cv_env_SUPPLIBS_value=
ac_cv_env_build_alias_set=set
ac_cv_env_build_alias_value=prefix
ac_cv_env_host_alias_set=set
ac_cv_env_host_alias_value=prefix
ac_cv_env_target_alias_set=set
ac_cv_env_target_alias_value=prefix
ac_cv_exeext=
ac_cv_objext=o
ac_cv_path_install='/usr/bin/install -c'
ac_cv_prog_AWK=gawk
ac_cv_prog_ac_ct_CC=gcc
ac_cv_prog_ac_ct_CXX=g++
ac_cv_prog_cc_g=yes
ac_cv_prog_cc_stdc=
ac_cv_prog_cxx_g=yes
ac_cv_prog_make_make_set=yes

## ----------------- ##
## Output variables. ##
## ----------------- ##

ACLOCAL='${SHELL} /usr/local/grads-1.9b4/etc/missing --run aclocal-1.6'
AMTAR='${SHELL} /usr/local/grads-1.9b4/etc/missing --run tar'
AUTOCONF='${SHELL} /usr/local/grads-1.9b4/etc/missing --run autoconf'
AUTOHEADER='${SHELL} /usr/local/grads-1.9b4/etc/missing --run autoheader'
AUTOMAKE='${SHELL} /usr/local/grads-1.9b4/etc/missing --run automake-1.6'
AWK='gawk'
CC='gcc'
CFLAGS='-g -O'
CPP=''
CPPFLAGS=''
CXX='g++'
CXXFLAGS='-g -O2'
DEFS=''
DODS_DARWIN_FALSE=''
DODS_DARWIN_TRUE=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EGREP=''
EXEEXT=''
GXPNG_FALSE=''
GXPNG_TRUE=''
INSTALL_DATA='${INSTALL} -m 644'
INSTALL_PROGRAM='${INSTALL}'
INSTALL_SCRIPT='${INSTALL}'
INSTALL_STRIP_PROGRAM='${SHELL} $(install_sh) -c -s'
LDFLAGS=''
LIBOBJS=''
LIBS=''
LN_S='ln -s'
LTLIBOBJS=''
MAINT='#'
MAINTAINER_MODE_FALSE=''
MAINTAINER_MODE_TRUE='#'
MAKEINFO='${SHELL} /usr/local/grads-1.9b4/etc/missing --run makeinfo'
OBJEXT='o'
PACKAGE='grads'
PACKAGE_BUGREPORT=''
PACKAGE_NAME='GrADS'
PACKAGE_STRING='GrADS 1.9b4'
PACKAGE_TARNAME='grads'
PACKAGE_VERSION='1.9b4'
PATH_SEPARATOR=':'
READLINE_FALSE=''
READLINE_TRUE=''
SET_MAKE=''
SHELL='/bin/sh'
STRIP=''
SUPPLIBS=''
USEDODS_FALSE=''
USEDODS_TRUE=''
USEGADODS_FALSE=''
USEGADODS_TRUE=''
USEGUI_FALSE=''
USEGUI_TRUE=''
USEHDF_FALSE=''
USEHDF_TRUE=''
USEIMG_FALSE=''
USEIMG_TRUE=''
USELATS_FALSE=''
USELATS_TRUE=''
USENC_FALSE=''
USENC_TRUE=''
VERSION='1.9b4'
XLIBEMU_FALSE=''
XLIBEMU_TRUE=''
X_CFLAGS=''
X_EXTRA_LIBS=''
X_LIBS=''
X_PRE_LIBS=''
ac_ct_CC='gcc'
ac_ct_CXX='g++'
ac_ct_STRIP=''
bindir='${exec_prefix}/bin'
build='prefix'
build_alias='prefix'
build_cpu=''
build_os=''
build_vendor=''
datadir='${prefix}/share'
dods_libs=''
exec_prefix='NONE'
extra_bins=''
extra_utils=''
gadods_def=''
gui_libs=''
hdf_libs=''
host='prefix'
host_alias='prefix'
host_cpu=''
host_ldadd=''
host_os=''
host_vendor=''
includedir='${prefix}/include'
infodir='${prefix}/info'
install_sh='/usr/local/grads-1.9b4/etc/install-sh'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localstatedir='${prefix}/var'
mandir='${prefix}/man'
nc_libs=''
oldincludedir='/usr/include'
prefix='NONE'
printim_libs=''
program_transform_name='s,x,x,'
readline_libs=''
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='${prefix}/etc'
target_alias='prefix'
wi_libadd=''
wi_libs=''
xlibemu_libs=''

## ----------- ##
## confdefs.h. ##
## ----------- ##

#define PACKAGE_BUGREPORT ""
#define PACKAGE_NAME "GrADS"
#define PACKAGE_STRING "GrADS 1.9b4"
#define PACKAGE_TARNAME "grads"
#define PACKAGE_VERSION "1.9b4"
#endif
#ifdef __cplusplus
#include <stdlib.h>

configure: exit 1


ncdump -c:


netcdf h0003 {
dimensions:
 lon = 128 ;
 lev = 28 ;
 ilev = 29 ;
 lat = 64 ;
 time = UNLIMITED ; // (30 currently)
 nchar = 80 ;
variables:
 float P0 ;
  P0:long_name = "reference pressure" ;
  P0:units = "Pa" ;
 int ntrm ;
  ntrm:long_name = "spectral truncation parameter M" ;
 int ntrn ;
  ntrn:long_name = "spectral truncation parameter N" ;
 int ntrk ;
  ntrk:long_name = "spectral truncation parameter K" ;
 int ndbase ;
  ndbase:long_name = "base day for this case" ;
 int nsbase ;
  nsbase:long_name = "seconds to complete base day" ;
  nsbase:units = "s" ;
 int nbdate ;
  nbdate:long_name = "base date as 6 digit integer (YYMMDD)" ;
 int nbsec ;
  nbsec:long_name = "seconds to complete base date" ;
  nbsec:units = "s" ;
 int mdt ;
  mdt:long_name = "model timestep" ;
  mdt:units = "s" ;
 int mhisf ;
  mhisf:long_name = "frequency of model writes (timesteps)" ;
 char current_mss(nchar) ;
  current_mss:long_name = "MSS pathname of this file" ;
 char first_mss(nchar) ;
  first_mss:long_name = "MSS pathname of first file for this case" ;
 float hyai(ilev) ;
  hyai:long_name = "hybrid A coefficient at layer interfaces" ;
 float hybi(ilev) ;
  hybi:long_name = "hybrid B coefficient at layer interfaces" ;
 float ilev(ilev) ;
  ilev:long_name = "hybrid level at layer interface (1000*(A+B))" ;
  ilev:units = "hybrid_sigma_pressure" ;
  ilev:positive = "down" ;
  ilev:A_var = "hyam" ;
  ilev:B_var = "hybm" ;
  ilev:P0_var = "P0" ;
  ilev:PS_var = "PS" ;
  ilev:bounds = "ilev" ;
 float hyam(lev) ;
  hyam:long_name = "hybrid A coefficient at layer midpoints" ;
 float hybm(lev) ;
  hybm:long_name = "hybrid B coefficient at layer midpoints" ;
 float lev(lev) ;
  lev:long_name = "hybrid level at layer midpoints (1000*(A+B))" ;
  lev:units = "hybrid_sigma_pressure" ;
  lev:positive = "down" ;
  lev:A_var = "hyam" ;
  lev:B_var = "hybm" ;
  lev:P0_var = "P0" ;
  lev:PS_var = "PS" ;
  lev:bounds = "ilev" ;
 float lat(lat) ;
  lat:long_name = "latitude" ;
  lat:units = "degrees_north" ;
 float gw(lat) ;
  gw:long_name = "gauss weights" ;
 float lon(lon) ;
  lon:long_name = "longitude" ;
  lon:units = "degrees_east" ;
 int days(time) ;
  days:long_name = "elapsed simulation days for this case" ;
 int secs(time) ;
  secs:long_name = "seconds to complete elapsed days" ;
  secs:units = "s" ;
 int date(time) ;
  date:long_name = "current date as 6 digit integer (YYMMDD)" ;
 int datesec(time) ;
  datesec:long_name = "seconds to complete current date" ;
  datesec:units = "s" ;
 double time(time) ;
  time:long_name = "simulation time" ;
  time:units = "days since 0000-01-01 00:00:00" ;
  time:calendar = "365_days" ;
 int timestep_index(time) ;
  timestep_index:long_name = "iteration counter for current case" ;
 float PS(time, lat, lon) ;
  PS:units = "PA" ;
 float T(time, lev, lat, lon) ;
  T:units = "K" ;
 float J_001_inst(time, lev, lat, lon) ;
  J_001_inst:units = "/CM3/S" ;
 float J_002_inst(time, lev, lat, lon) ;
  J_002_inst:units = "/CM3/S" ;
 float J_003_inst(time, lev, lat, lon) ;
  J_003_inst:units = "/CM3/S" ;
 float J_004_inst(time, lev, lat, lon) ;
  J_004_inst:units = "/CM3/S" ;
 float J_005_inst(time, lev, lat, lon) ;
  J_005_inst:units = "/CM3/S" ;
 float J_006_inst(time, lev, lat, lon) ;
  J_006_inst:units = "/CM3/S" ;
 float J_007_inst(time, lev, lat, lon) ;
  J_007_inst:units = "/CM3/S" ;
 float J_008_inst(time, lev, lat, lon) ;
  J_008_inst:units = "/CM3/S" ;
 float J_009_inst(time, lev, lat, lon) ;
  J_009_inst:units = "/CM3/S" ;
 float J_010_inst(time, lev, lat, lon) ;
  J_010_inst:units = "/CM3/S" ;
 float J_011_inst(time, lev, lat, lon) ;
  J_011_inst:units = "/CM3/S" ;
 float J_012_inst(time, lev, lat, lon) ;
  J_012_inst:units = "/CM3/S" ;
 float J_013_inst(time, lev, lat, lon) ;
  J_013_inst:units = "/CM3/S" ;
 float J_014_inst(time, lev, lat, lon) ;
  J_014_inst:units = "/CM3/S" ;
 float J_015_inst(time, lev, lat, lon) ;
  J_015_inst:units = "/CM3/S" ;
 float J_016_inst(time, lev, lat, lon) ;
  J_016_inst:units = "/CM3/S" ;
 float J_017_inst(time, lev, lat, lon) ;
  J_017_inst:units = "/CM3/S" ;
 float J_018_inst(time, lev, lat, lon) ;
  J_018_inst:units = "/CM3/S" ;
 float J_019_inst(time, lev, lat, lon) ;
  J_019_inst:units = "/CM3/S" ;
 float J_020_inst(time, lev, lat, lon) ;
  J_020_inst:units = "/CM3/S" ;
 float J_021_inst(time, lev, lat, lon) ;
  J_021_inst:units = "/CM3/S" ;
 float J_022_inst(time, lev, lat, lon) ;
  J_022_inst:units = "/CM3/S" ;
 float J_023_inst(time, lev, lat, lon) ;
  J_023_inst:units = "/CM3/S" ;
 float J_024_inst(time, lev, lat, lon) ;
  J_024_inst:units = "/CM3/S" ;
 float J_025_inst(time, lev, lat, lon) ;
  J_025_inst:units = "/CM3/S" ;
 float J_026_inst(time, lev, lat, lon) ;
  J_026_inst:units = "/CM3/S" ;
 float J_027_inst(time, lev, lat, lon) ;
  J_027_inst:units = "/CM3/S" ;
 float J_028_inst(time, lev, lat, lon) ;
  J_028_inst:units = "/CM3/S" ;
 float J_029_inst(time, lev, lat, lon) ;
  J_029_inst:units = "/CM3/S" ;
 float J_030_inst(time, lev, lat, lon) ;
  J_030_inst:units = "/CM3/S" ;
 float J_031_inst(time, lev, lat, lon) ;
  J_031_inst:units = "/CM3/S" ;
 float J_032_inst(time, lev, lat, lon) ;
  J_032_inst:units = "/CM3/S" ;
 float J_033_inst(time, lev, lat, lon) ;
  J_033_inst:units = "/CM3/S" ;
 float OX_ADV_inst(time, lev, lat, lon) ;
  OX_ADV_inst:units = "KG" ;
 float OX_DPS_inst(time, lev, lat, lon) ;
  OX_DPS_inst:units = "KG" ;
 float OX_CNV_inst(time, lev, lat, lon) ;
  OX_CNV_inst:units = "KG" ;
 float OX_DIF_inst(time, lev, lat, lon) ;
  OX_DIF_inst:units = "KG" ;
 float OX_CHM_inst(time, lev, lat, lon) ;
  OX_CHM_inst:units = "KG" ;
 float OX_XFLX_inst(time, lev, lat, lon) ;
  OX_XFLX_inst:units = "KG" ;
 float OX_YFLX_inst(time, lev, lat, lon) ;
  OX_YFLX_inst:units = "KG" ;
 float OX_ZFLX_inst(time, lev, lat, lon) ;
  OX_ZFLX_inst:units = "KG" ;
 float TROPLEV(time, lat, lon) ;
  TROPLEV:units = "KM" ;
 float CWAT(time, lev, lat, lon) ;
  CWAT:units = "KG/KG" ;
 float Q(time, lev, lat, lon) ;
  Q:units = "KG/KG" ;
 float LNO_PROD(time, lat, lon) ;
  LNO_PROD:units = "TG N/YR" ;
 float OX_VMR_avrg(time, lev, lat, lon) ;
  OX_VMR_avrg:units = "VMR" ;
 float N2O_VMR_avrg(time, lev, lat, lon) ;
  N2O_VMR_avrg:units = "VMR" ;
 float N_VMR_avrg(time, lev, lat, lon) ;
  N_VMR_avrg:units = "VMR" ;
 float NO_VMR_avrg(time, lev, lat, lon) ;
  NO_VMR_avrg:units = "VMR" ;
 float NO2_VMR_avrg(time, lev, lat, lon) ;
  NO2_VMR_avrg:units = "VMR" ;
 float NO3_VMR_avrg(time, lev, lat, lon) ;
  NO3_VMR_avrg:units = "VMR" ;
 float HNO3_VMR_avrg(time, lev, lat, lon) ;
  HNO3_VMR_avrg:units = "VMR" ;
 float HO2NO2_VMR_avrg(time, lev, lat, lon) ;
  HO2NO2_VMR_avrg:units = "VMR" ;
 float N2O5_VMR_avrg(time, lev, lat, lon) ;
  N2O5_VMR_avrg:units = "VMR" ;
 float CH4_VMR_avrg(time, lev, lat, lon) ;
  CH4_VMR_avrg:units = "VMR" ;
 float CH3O2_VMR_avrg(time, lev, lat, lon) ;
  CH3O2_VMR_avrg:units = "VMR" ;
 float CH3OOH_VMR_avrg(time, lev, lat, lon) ;
  CH3OOH_VMR_avrg:units = "VMR" ;
 float CH2O_VMR_avrg(time, lev, lat, lon) ;
  CH2O_VMR_avrg:units = "VMR" ;
 float CO_VMR_avrg(time, lev, lat, lon) ;
  CO_VMR_avrg:units = "VMR" ;
 float OH_VMR_avrg(time, lev, lat, lon) ;
  OH_VMR_avrg:units = "VMR" ;
 float HO2_VMR_avrg(time, lev, lat, lon) ;
  HO2_VMR_avrg:units = "VMR" ;
 float H2O2_VMR_avrg(time, lev, lat, lon) ;
  H2O2_VMR_avrg:units = "VMR" ;
 float C3H6_VMR_avrg(time, lev, lat, lon) ;
  C3H6_VMR_avrg:units = "VMR" ;
 float ISOP_VMR_avrg(time, lev, lat, lon) ;
  ISOP_VMR_avrg:units = "VMR" ;
 float PO2_VMR_avrg(time, lev, lat, lon) ;
  PO2_VMR_avrg:units = "VMR" ;
 float CH3CHO_VMR_avrg(time, lev, lat, lon) ;
  CH3CHO_VMR_avrg:units = "VMR" ;
 float POOH_VMR_avrg(time, lev, lat, lon) ;
  POOH_VMR_avrg:units = "VMR" ;
 float CH3CO3_VMR_avrg(time, lev, lat, lon) ;
  CH3CO3_VMR_avrg:units = "VMR" ;
 float CH3COOOH_VMR_avrg(time, lev, lat, lon) ;
  CH3COOOH_VMR_avrg:units = "VMR" ;
 float PAN_VMR_avrg(time, lev, lat, lon) ;
  PAN_VMR_avrg:units = "VMR" ;
 float ONIT_VMR_avrg(time, lev, lat, lon) ;
  ONIT_VMR_avrg:units = "VMR" ;
 float C2H6_VMR_avrg(time, lev, lat, lon) ;
  C2H6_VMR_avrg:units = "VMR" ;
 float C2H4_VMR_avrg(time, lev, lat, lon) ;
  C2H4_VMR_avrg:units = "VMR" ;
 float C4H10_VMR_avrg(time, lev, lat, lon) ;
  C4H10_VMR_avrg:units = "VMR" ;
 float MPAN_VMR_avrg(time, lev, lat, lon) ;
  MPAN_VMR_avrg:units = "VMR" ;
 float ISOPO2_VMR_avrg(time, lev, lat, lon) ;
  ISOPO2_VMR_avrg:units = "VMR" ;
 float MVK_VMR_avrg(time, lev, lat, lon) ;
  MVK_VMR_avrg:units = "VMR" ;
 float MACR_VMR_avrg(time, lev, lat, lon) ;
  MACR_VMR_avrg:units = "VMR" ;
 float MACRO2_VMR_avrg(time, lev, lat, lon) ;
  MACRO2_VMR_avrg:units = "VMR" ;
 float MACROOH_VMR_avrg(time, lev, lat, lon) ;
  MACROOH_VMR_avrg:units = "VMR" ;
 float MCO3_VMR_avrg(time, lev, lat, lon) ;
  MCO3_VMR_avrg:units = "VMR" ;
 float C2H5O2_VMR_avrg(time, lev, lat, lon) ;
  C2H5O2_VMR_avrg:units = "VMR" ;
 float C2H5OOH_VMR_avrg(time, lev, lat, lon) ;
  C2H5OOH_VMR_avrg:units = "VMR" ;
 float C10H16_VMR_avrg(time, lev, lat, lon) ;
  C10H16_VMR_avrg:units = "VMR" ;
 float C3H8_VMR_avrg(time, lev, lat, lon) ;
  C3H8_VMR_avrg:units = "VMR" ;
 float C3H7O2_VMR_avrg(time, lev, lat, lon) ;
  C3H7O2_VMR_avrg:units = "VMR" ;
 float C3H7OOH_VMR_avrg(time, lev, lat, lon) ;
  C3H7OOH_VMR_avrg:units = "VMR" ;
 float CH3COCH3_VMR_avrg(time, lev, lat, lon) ;
  CH3COCH3_VMR_avrg:units = "VMR" ;
 float ROOH_VMR_avrg(time, lev, lat, lon) ;
  ROOH_VMR_avrg:units = "VMR" ;
 float CH3OH_VMR_avrg(time, lev, lat, lon) ;
  CH3OH_VMR_avrg:units = "VMR" ;
 float C2H5OH_VMR_avrg(time, lev, lat, lon) ;
  C2H5OH_VMR_avrg:units = "VMR" ;
 float GLYALD_VMR_avrg(time, lev, lat, lon) ;
  GLYALD_VMR_avrg:units = "VMR" ;
 float HYAC_VMR_avrg(time, lev, lat, lon) ;
  HYAC_VMR_avrg:units = "VMR" ;
 float EO2_VMR_avrg(time, lev, lat, lon) ;
  EO2_VMR_avrg:units = "VMR" ;
 float EO_VMR_avrg(time, lev, lat, lon) ;
  EO_VMR_avrg:units = "VMR" ;
 float HYDRALD_VMR_avrg(time, lev, lat, lon) ;
  HYDRALD_VMR_avrg:units = "VMR" ;
 float RO2_VMR_avrg(time, lev, lat, lon) ;
  RO2_VMR_avrg:units = "VMR" ;
 float CH3COCHO_VMR_avrg(time, lev, lat, lon) ;
  CH3COCHO_VMR_avrg:units = "VMR" ;
 float Rn_VMR_avrg(time, lev, lat, lon) ;
  Rn_VMR_avrg:units = "VMR" ;
 float Pb_VMR_avrg(time, lev, lat, lon) ;
  Pb_VMR_avrg:units = "VMR" ;
 float ISOPNO3_VMR_avrg(time, lev, lat, lon) ;
  ISOPNO3_VMR_avrg:units = "VMR" ;
 float ONITR_VMR_avrg(time, lev, lat, lon) ;
  ONITR_VMR_avrg:units = "VMR" ;
 float XO2_VMR_avrg(time, lev, lat, lon) ;
  XO2_VMR_avrg:units = "VMR" ;
 float XOOH_VMR_avrg(time, lev, lat, lon) ;
  XOOH_VMR_avrg:units = "VMR" ;
 float ISOPOOH_VMR_avrg(time, lev, lat, lon) ;
  ISOPOOH_VMR_avrg:units = "VMR" ;
 float H2_VMR_avrg(time, lev, lat, lon) ;
  H2_VMR_avrg:units = "VMR" ;
 float O3S_VMR_avrg(time, lev, lat, lon) ;
  O3S_VMR_avrg:units = "VMR" ;
 float O3INERT_VMR_avrg(time, lev, lat, lon) ;
  O3INERT_VMR_avrg:units = "VMR" ;
 float O3_VMR_avrg(time, lev, lat, lon) ;
  O3_VMR_avrg:units = "VMR" ;
 float O1D_VMR_avrg(time, lev, lat, lon) ;
  O1D_VMR_avrg:units = "VMR" ;
 float O_VMR_avrg(time, lev, lat, lon) ;
  O_VMR_avrg:units = "VMR" ;
 float NO_SRF_EMIS_avrg(time, lat, lon) ;
  NO_SRF_EMIS_avrg:units = "KG/M2/S" ;
 float N2O_SRF_EMIS_avrg(time, lat, lon) ;
  N2O_SRF_EMIS_avrg:units = "KG/M2/S" ;
 float CH4_SRF_EMIS_avrg(time, lat, lon) ;
  CH4_SRF_EMIS_avrg:units = "KG/M2/S" ;
 float CH2O_SRF_EMIS_avrg(time, lat, lon) ;
  CH2O_SRF_EMIS_avrg:units = "KG/M2/S" ;
 float CO_SRF_EMIS_avrg(time, lat, lon) ;
  CO_SRF_EMIS_avrg:units = "KG/M2/S" ;
 float C3H6_SRF_EMIS_avrg(time, lat, lon) ;
  C3H6_SRF_EMIS_avrg:units = "KG/M2/S" ;
 float ISOP_SRF_EMIS_avrg(time, lat, lon) ;
  ISOP_SRF_EMIS_avrg:units = "KG/M2/S" ;
 float C10H16_SRF_EMIS_avrg(time, lat, lon) ;
  C10H16_SRF_EMIS_avrg:units = "KG/M2/S" ;
 float C2H4_SRF_EMIS_avrg(time, lat, lon) ;
  C2H4_SRF_EMIS_avrg:units = "KG/M2/S" ;
 float C2H6_SRF_EMIS_avrg(time, lat, lon) ;
  C2H6_SRF_EMIS_avrg:units = "KG/M2/S" ;
 float C4H10_SRF_EMIS_avrg(time, lat, lon) ;
  C4H10_SRF_EMIS_avrg:units = "KG/M2/S" ;
 float C3H8_SRF_EMIS_avrg(time, lat, lon) ;
  C3H8_SRF_EMIS_avrg:units = "KG/M2/S" ;
 float CH3COCH3_SRF_EMIS_avrg(time, lat, lon) ;
  CH3COCH3_SRF_EMIS_avrg:units = "KG/M2/S" ;
 float Rn_SRF_EMIS_avrg(time, lat, lon) ;
  Rn_SRF_EMIS_avrg:units = "KG/M2/S" ;
 float H2_SRF_EMIS_avrg(time, lat, lon) ;
  H2_SRF_EMIS_avrg:units = "KG/M2/S" ;
 float CH3OH_SRF_EMIS_avrg(time, lat, lon) ;
  CH3OH_SRF_EMIS_avrg:units = "KG/M2/S" ;
 float OX_DEP_VEL_avrg(time, lat, lon) ;
  OX_DEP_VEL_avrg:units = "CM/S" ;
 float NO2_DEP_VEL_avrg(time, lat, lon) ;
  NO2_DEP_VEL_avrg:units = "CM/S" ;
 float HNO3_DEP_VEL_avrg(time, lat, lon) ;
  HNO3_DEP_VEL_avrg:units = "CM/S" ;
 float CH4_DEP_VEL_avrg(time, lat, lon) ;
  CH4_DEP_VEL_avrg:units = "CM/S" ;
 float CH3OOH_DEP_VEL_avrg(time, lat, lon) ;
  CH3OOH_DEP_VEL_avrg:units = "CM/S" ;
 float CH2O_DEP_VEL_avrg(time, lat, lon) ;
  CH2O_DEP_VEL_avrg:units = "CM/S" ;
 float CO_DEP_VEL_avrg(time, lat, lon) ;
  CO_DEP_VEL_avrg:units = "CM/S" ;
 float H2O2_DEP_VEL_avrg(time, lat, lon) ;
  H2O2_DEP_VEL_avrg:units = "CM/S" ;
 float POOH_DEP_VEL_avrg(time, lat, lon) ;
  POOH_DEP_VEL_avrg:units = "CM/S" ;
 float CH3COOOH_DEP_VEL_avrg(time, lat, lon) ;
  CH3COOOH_DEP_VEL_avrg:units = "CM/S" ;
 float PAN_DEP_VEL_avrg(time, lat, lon) ;
  PAN_DEP_VEL_avrg:units = "CM/S" ;
 float MPAN_DEP_VEL_avrg(time, lat, lon) ;
  MPAN_DEP_VEL_avrg:units = "CM/S" ;
 float C2H5OOH_DEP_VEL_avrg(time, lat, lon) ;
  C2H5OOH_DEP_VEL_avrg:units = "CM/S" ;
 float ONIT_DEP_VEL_avrg(time, lat, lon) ;
  ONIT_DEP_VEL_avrg:units = "CM/S" ;
 float C3H7OOH_DEP_VEL_avrg(time, lat, lon) ;
  C3H7OOH_DEP_VEL_avrg:units = "CM/S" ;
 float ROOH_DEP_VEL_avrg(time, lat, lon) ;
  ROOH_DEP_VEL_avrg:units = "CM/S" ;
 float CH3COCHO_DEP_VEL_avrg(time, lat, lon) ;
  CH3COCHO_DEP_VEL_avrg:units = "CM/S" ;
 float CH3COCH3_DEP_VEL_avrg(time, lat, lon) ;
  CH3COCH3_DEP_VEL_avrg:units = "CM/S" ;
 float Pb_DEP_VEL_avrg(time, lat, lon) ;
  Pb_DEP_VEL_avrg:units = "CM/S" ;
 float O3INERT_DEP_VEL_avrg(time, lat, lon) ;
  O3INERT_DEP_VEL_avrg:units = "CM/S" ;
 float O3S_DEP_VEL_avrg(time, lat, lon) ;
  O3S_DEP_VEL_avrg:units = "CM/S" ;
 float H2_DEP_VEL_avrg(time, lat, lon) ;
  H2_DEP_VEL_avrg:units = "CM/S" ;
 float ONITR_DEP_VEL_avrg(time, lat, lon) ;
  ONITR_DEP_VEL_avrg:units = "CM/S" ;
 float MACROOH_DEP_VEL_avrg(time, lat, lon) ;
  MACROOH_DEP_VEL_avrg:units = "CM/S" ;
 float XOOH_DEP_VEL_avrg(time, lat, lon) ;
  XOOH_DEP_VEL_avrg:units = "CM/S" ;
 float ISOPOOH_DEP_VEL_avrg(time, lat, lon) ;
  ISOPOOH_DEP_VEL_avrg:units = "CM/S" ;
 float CH3CHO_DEP_VEL_avrg(time, lat, lon) ;
  CH3CHO_DEP_VEL_avrg:units = "CM/S" ;
 float NO_DEP_VEL_avrg(time, lat, lon) ;
  NO_DEP_VEL_avrg:units = "CM/S" ;
 float HO2NO2_DEP_VEL_avrg(time, lat, lon) ;
  HO2NO2_DEP_VEL_avrg:units = "CM/S" ;
 float GLYALD_DEP_VEL_avrg(time, lat, lon) ;
  GLYALD_DEP_VEL_avrg:units = "CM/S" ;
 float HYAC_DEP_VEL_avrg(time, lat, lon) ;
  HYAC_DEP_VEL_avrg:units = "CM/S" ;
 float CH3OH_DEP_VEL_avrg(time, lat, lon) ;
  CH3OH_DEP_VEL_avrg:units = "CM/S" ;
 float C2H5OH_DEP_VEL_avrg(time, lat, lon) ;
  C2H5OH_DEP_VEL_avrg:units = "CM/S" ;
 float HYDRALD_DEP_VEL_avrg(time, lat, lon) ;
  HYDRALD_DEP_VEL_avrg:units = "CM/S" ;
 float H2O2_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  H2O2_WET_DEP_RATE_avrg:units = "/S" ;
 float HNO3_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  HNO3_WET_DEP_RATE_avrg:units = "/S" ;
 float CH2O_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  CH2O_WET_DEP_RATE_avrg:units = "/S" ;
 float CH3OOH_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  CH3OOH_WET_DEP_RATE_avrg:units = "/S" ;
 float POOH_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  POOH_WET_DEP_RATE_avrg:units = "/S" ;
 float CH3COOOH_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  CH3COOOH_WET_DEP_RATE_avrg:units = "/S" ;
 float HO2NO2_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  HO2NO2_WET_DEP_RATE_avrg:units = "/S" ;
 float ONIT_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  ONIT_WET_DEP_RATE_avrg:units = "/S" ;
 float MVK_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  MVK_WET_DEP_RATE_avrg:units = "/S" ;
 float MACR_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  MACR_WET_DEP_RATE_avrg:units = "/S" ;
 float C2H5OOH_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  C2H5OOH_WET_DEP_RATE_avrg:units = "/S" ;
 float C3H7OOH_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  C3H7OOH_WET_DEP_RATE_avrg:units = "/S" ;
 float ROOH_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  ROOH_WET_DEP_RATE_avrg:units = "/S" ;
 float CH3COCHO_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  CH3COCHO_WET_DEP_RATE_avrg:units = "/S" ;
 float Pb_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  Pb_WET_DEP_RATE_avrg:units = "/S" ;
 float MACROOH_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  MACROOH_WET_DEP_RATE_avrg:units = "/S" ;
 float XOOH_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  XOOH_WET_DEP_RATE_avrg:units = "/S" ;
 float ONITR_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  ONITR_WET_DEP_RATE_avrg:units = "/S" ;
 float ISOPOOH_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  ISOPOOH_WET_DEP_RATE_avrg:units = "/S" ;
 float GLYALD_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  GLYALD_WET_DEP_RATE_avrg:units = "/S" ;
 float HYAC_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  HYAC_WET_DEP_RATE_avrg:units = "/S" ;
 float CH3OH_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  CH3OH_WET_DEP_RATE_avrg:units = "/S" ;
 float C2H5OH_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  C2H5OH_WET_DEP_RATE_avrg:units = "/S" ;
 float HYDRALD_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
  HYDRALD_WET_DEP_RATE_avrg:units = "/S" ;
 float NO_EXT_FRC_avrg(time, lev, lat, lon) ;
  NO_EXT_FRC_avrg:units = "/CM3/S" ;
 float CH4_EXT_FRC_avrg(time, lev, lat, lon) ;
  CH4_EXT_FRC_avrg:units = "/CM3/S" ;
 float CO_EXT_FRC_avrg(time, lev, lat, lon) ;
  CO_EXT_FRC_avrg:units = "/CM3/S" ;
 float OX_PROD_avrg(time, lev, lat, lon) ;
  OX_PROD_avrg:units = "/CM3/S" ;
 float OX_LOSS_avrg(time, lev, lat, lon) ;
  OX_LOSS_avrg:units = "/CM3/S" ;
 float OX_ADV_avrg(time, lev, lat, lon) ;
  OX_ADV_avrg:units = "KG" ;
 float OX_DPS_avrg(time, lev, lat, lon) ;
  OX_DPS_avrg:units = "KG" ;
 float OX_CNV_avrg(time, lev, lat, lon) ;
  OX_CNV_avrg:units = "KG" ;
 float OX_DIF_avrg(time, lev, lat, lon) ;
  OX_DIF_avrg:units = "KG" ;
 float OX_CHM_avrg(time, lev, lat, lon) ;
  OX_CHM_avrg:units = "KG" ;
 float OX_XFLX_avrg(time, lev, lat, lon) ;
  OX_XFLX_avrg:units = "KG" ;
 float OX_YFLX_avrg(time, lev, lat, lon) ;
  OX_YFLX_avrg:units = "KG" ;
 float OX_ZFLX_avrg(time, lev, lat, lon) ;
  OX_ZFLX_avrg:units = "KG" ;
 float OX_DRY_DEP_FLX_avrg(time, lat, lon) ;
  OX_DRY_DEP_FLX_avrg:units = "KG" ;
 float O3S_DRY_DEP_FLX_avrg(time, lat, lon) ;
  O3S_DRY_DEP_FLX_avrg:units = "KG" ;
 float CO_DRY_DEP_FLX_avrg(time, lat, lon) ;
  CO_DRY_DEP_FLX_avrg:units = "KG" ;
 float NO_DRY_DEP_FLX_avrg(time, lat, lon) ;
  NO_DRY_DEP_FLX_avrg:units = "KG" ;
 float NO2_DRY_DEP_FLX_avrg(time, lat, lon) ;
  NO2_DRY_DEP_FLX_avrg:units = "KG" ;
 float HNO3_DRY_DEP_FLX_avrg(time, lat, lon) ;
  HNO3_DRY_DEP_FLX_avrg:units = "KG" ;
 float PAN_DRY_DEP_FLX_avrg(time, lat, lon) ;
  PAN_DRY_DEP_FLX_avrg:units = "KG" ;
 float MPAN_DRY_DEP_FLX_avrg(time, lat, lon) ;
  MPAN_DRY_DEP_FLX_avrg:units = "KG" ;

// global attributes:
  :Conventions = "NCAR-CSM" ;
  :case = "debug                           " ;
  :title = "MOZART2-v2.4
                " ;
data:

 ilev = 0.54, 5.4, 14.8, 21.8, 35.8, 47.8, 68.2, 88.2, 117.4, 147.8, 188.6,
    231.6, 284.8, 340.2, 403.8, 467.6, 535.7999, 600.4, 665.4, 723.2,
    778.3999, 824.4001, 867.1998, 900.4001, 931.3999, 953.6001, 975.1999,
    989, 1000 ;

 lev = 2.7, 10.1, 18.3, 28.8, 41.8, 58, 78.2, 102.8, 132.6, 168.2, 210.1,
    258.2, 312.5, 372, 435.7, 501.7, 568.1, 632.9, 694.3, 750.7999, 801.4,
    845.8, 883.8, 915.9, 942.5, 964.4, 982.1, 994.9999 ;

 lat = -90, -87.14286, -84.28571, -81.42857, -78.57143, -75.71429, -72.85714,
    -70, -67.14286, -64.28571, -61.42857, -58.57143, -55.71429, -52.85714,
    -50, -47.14286, -44.28571, -41.42857, -38.57143, -35.71429, -32.85714,
    -30, -27.14286, -24.28572, -21.42857, -18.57143, -15.71429, -12.85714,
    -10, -7.142857, -4.285714, -1.428571, 1.428571, 4.285714, 7.142857, 10,
    12.85714, 15.71429, 18.57143, 21.42857, 24.28572, 27.14286, 30, 32.85714,
    35.71429, 38.57143, 41.42857, 44.28571, 47.14286, 50, 52.85714, 55.71429,
    58.57143, 61.42857, 64.28571, 67.14286, 70, 72.85714, 75.71429, 78.57143,
    81.42857, 84.28571, 87.14286, 90 ;

 lon = 0, 2.8125, 5.625, 8.4375, 11.25, 14.0625, 16.875, 19.6875, 22.5,
    25.3125, 28.125, 30.9375, 33.75, 36.5625, 39.375, 42.1875, 45, 47.8125,
    50.625, 53.4375, 56.25, 59.0625, 61.875, 64.6875, 67.5, 70.3125, 73.125,
    75.9375, 78.75, 81.5625, 84.375, 87.1875, 90, 92.8125, 95.625, 98.4375,
    101.25, 104.0625, 106.875, 109.6875, 112.5, 115.3125, 118.125, 120.9375,
    123.75, 126.5625, 129.375, 132.1875, 135, 137.8125, 140.625, 143.4375,
    146.25, 149.0625, 151.875, 154.6875, 157.5, 160.3125, 163.125, 165.9375,
    168.75, 171.5625, 174.375, 177.1875, 180, 182.8125, 185.625, 188.4375,
    191.25, 194.0625, 196.875, 199.6875, 202.5, 205.3125, 208.125, 210.9375,
    213.75, 216.5625, 219.375, 222.1875, 225, 227.8125, 230.625, 233.4375,
    236.25, 239.0625, 241.875, 244.6875, 247.5, 250.3125, 253.125, 255.9375,
    258.75, 261.5625, 264.375, 267.1875, 270, 272.8125, 275.625, 278.4375,
    281.25, 284.0625, 286.875, 289.6875, 292.5, 295.3125, 298.125, 300.9375,
    303.75, 306.5625, 309.375, 312.1875, 315, 317.8125, 320.625, 323.4375,
    326.25, 329.0625, 331.875, 334.6875, 337.5, 340.3125, 343.125, 345.9375,
    348.75, 351.5625, 354.375, 357.1875 ;

 time = 731886.125, 731887.125, 731888.125, 731889.125, 731890.125,
    731891.125, 731892.125, 731893.125, 731894.125, 731895.125, 731896.125,
    731897.125, 731898.125, 731899.125, 731900.125, 731901.125, 731902.125,
    731903.125, 731904.125, 731905.125, 731906.125, 731907.125, 731908.125,
    731909.125, 731910.125, 731911.125, 731912.125, 731913.125, 731914.125,
    731915.125 ;
}


From heiner at MISU.SU.SE  Sat Oct 13 04:35:19 2007
From: heiner at MISU.SU.SE (Heiner =?ISO-8859-1?Q?K=F6rnich?=)
Date: Sat, 13 Oct 2007 10:35:19 +0200
Subject: File size limit
In-Reply-To: <20071012191731.4A135201E3@mx2.cineca.it>
Message-ID: <SAT.13.OCT.2007.103519.0200.>

Hi,

I don't have an idea, but 4 GB sounds too large. You could try to
separate the
data in several smaller files with the tools from NCO (netcdf
operators?).
If needed, you can try to write an additional control-file (.ctl) with
the
option template in order to combine the files in GrADS.

Sorry but I have no better idea.
Heiner

On Fri, 2007-10-12 at 21:17 +0200, Aida Biberic wrote:
> Hi,
>
> Is there a limitation on the size of a file that can be opened with GrADS?
> If not would anybody point out what the problem in my configuration is since
> I am not able to open a 4GB file. Files that are about 1 GB are not a
> problem, (all NetCDF files, outputs of the same model). Following are error
> message, config.out, and ncdump -c.
>
> Thanks,
>
> Aida
>
>
>
> Error message from GrADS:
>
> ga-> sdfopen h0003.nc
> Scanning self-describing file:  h0003.nc
> nc_open failure:
> File too large
> h0003.nc does not exist or is not a netCDF file.
>
> Couldn't ingest SDF metadata.
> If this was an HDF-SDS file, try gradshdf.
>
>
>
>
> Here is my configuration output:
>
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
>
> It was created by GrADS configure 1.9b4, which was
> generated by GNU Autoconf 2.57.  Invocation command line was
>
>   $ ./configure prefix = /usr/local/grads-1.9b4/
>
> ## --------- ##
> ## Platform. ##
> ## --------- ##
>
> hostname = climate1.sb2.pdx.edu
> uname -m = x86_64
> uname -r = 2.6.9-55.ELsmp
> uname -s = Linux
> uname -v = #1 SMP Fri Apr 20 16:36:54 EDT 2007
>
> /usr/bin/uname -p = unknown
> /bin/uname -X     = unknown
>
> /bin/arch              = x86_64
> /usr/bin/arch -k       = unknown
> /usr/convex/getsysinfo = unknown
> hostinfo               = unknown
> /bin/machine           = unknown
> /usr/bin/oslevel       = unknown
> /bin/universe          = unknown
>
> PATH: /usr/kerberos/sbin
> PATH: /usr/kerberos/bin
> PATH: /usr/local/bin
> PATH: /usr/bin
> PATH: /bin
> PATH: /usr/X11R6/bin
> PATH: /home/user/bin
> PATH: /opt/pgi/linux86-64/7.0/bin
> PATH: /opt/pgi
>
>
> ## ----------- ##
> ## Core tests. ##
> ## ----------- ##
>
> configure:1372: checking for a BSD-compatible install
> configure:1426: result: /usr/bin/install -c
> configure:1437: checking whether build environment is sane
> configure:1480: result: yes
> configure:1513: checking for gawk
> configure:1529: found /usr/bin/gawk
> configure:1539: result: gawk
> configure:1549: checking whether make sets $(MAKE)
> configure:1569: result: yes
> configure:1716: checking whether to enable maintainer-specific portions of
> Makefiles
> configure:1725: result: no
> configure:1840: checking for gawk
> configure:1866: result: gawk
> configure:1884: checking for prefix-gcc
> configure:1913: result: no
> configure:1922: checking for gcc
> configure:1938: found /usr/bin/gcc
> configure:1948: result: gcc
> configure:2192: checking for C compiler version
> configure:2195: gcc --version </dev/null >&5
> gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-8)
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> configure:2198: $? = 0
> configure:2200: gcc -v </dev/null >&5
> Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-shared --enable-threads=posix
> --disable-checking --with-system-zlib --enable-__cxa_atexit
> --disable-libunwind-exceptions --enable-java-awt=gtk --host=x86_64-redhat-linux
> Thread model: posix
> gcc version 3.4.6 20060404 (Red Hat 3.4.6-8)
> configure:2203: $? = 0
> configure:2205: gcc -V </dev/null >&5
> gcc: `-V' option must have argument
> configure:2208: $? = 1
> configure:2232: checking for C compiler default output
> configure:2235: gcc -g -O   conftest.c  >&5
> configure:2238: $? = 0
> configure:2284: result: a.out
> configure:2289: checking whether the C compiler works
> configure:2295: ./a.out
> configure:2298: $? = 0
> configure:2315: result: yes
> configure:2322: checking whether we are cross compiling
> configure:2324: result: no
> configure:2327: checking for suffix of executables
> configure:2329: gcc -o conftest -g -O   conftest.c  >&5
> configure:2332: $? = 0
> configure:2357: result:
> configure:2363: checking for suffix of object files
> configure:2385: gcc -c -g -O  conftest.c >&5
> configure:2388: $? = 0
> configure:2410: result: o
> configure:2414: checking whether we are using the GNU C compiler
> configure:2439: gcc -c -g -O  conftest.c >&5
> configure:2442: $? = 0
> configure:2445: test -s conftest.o
> configure:2448: $? = 0
> configure:2461: result: yes
> configure:2467: checking whether gcc accepts -g
> configure:2489: gcc -c -g  conftest.c >&5
> configure:2492: $? = 0
> configure:2495: test -s conftest.o
> configure:2498: $? = 0
> configure:2509: result: yes
> configure:2526: checking for gcc option to accept ANSI C
> configure:2587: gcc  -c -g -O  conftest.c >&5
> configure:2590: $? = 0
> configure:2593: test -s conftest.o
> configure:2596: $? = 0
> configure:2614: result: none needed
> configure:2632: gcc -c -g -O  conftest.c >&5
> conftest.c:2: error: syntax error before "me"
> configure:2635: $? = 1
> configure: failed program was:
> | #ifndef __cplusplus
> |   choke me
> | #endif
> configure:2754: checking for prefix-g++
> configure:2783: result: no
> configure:2754: checking for prefix-c++
> configure:2783: result: no
> configure:2754: checking for prefix-gpp
> configure:2783: result: no
> configure:2754: checking for prefix-aCC
> configure:2783: result: no
> configure:2754: checking for prefix-CC
> configure:2783: result: no
> configure:2754: checking for prefix-cxx
> configure:2783: result: no
> configure:2754: checking for prefix-cc++
> configure:2783: result: no
> configure:2754: checking for prefix-cl
> configure:2783: result: no
> configure:2754: checking for prefix-FCC
> configure:2783: result: no
> configure:2754: checking for prefix-KCC
> configure:2783: result: no
> configure:2754: checking for prefix-RCC
> configure:2783: result: no
> configure:2754: checking for prefix-xlC_r
> configure:2783: result: no
> configure:2754: checking for prefix-xlC
> configure:2783: result: no
> configure:2796: checking for g++
> configure:2812: found /usr/bin/g++
> configure:2822: result: g++
> configure:2838: checking for C++ compiler version
> configure:2841: g++ --version </dev/null >&5
> g++ (GCC) 3.4.6 20060404 (Red Hat 3.4.6-8)
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> configure:2844: $? = 0
> configure:2846: g++ -v </dev/null >&5
> Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-shared --enable-threads=posix
> --disable-checking --with-system-zlib --enable-__cxa_atexit
> --disable-libunwind-exceptions --enable-java-awt=gtk --host=x86_64-redhat-linux
> Thread model: posix
> gcc version 3.4.6 20060404 (Red Hat 3.4.6-8)
> configure:2849: $? = 0
> configure:2851: g++ -V </dev/null >&5
> g++: `-V' option must have argument
> configure:2854: $? = 1
> configure:2857: checking whether we are using the GNU C++ compiler
> configure:2882: g++ -c   conftest.cc >&5
> configure:2885: $? = 0
> configure:2888: test -s conftest.o
> configure:2891: $? = 0
> configure:2904: result: yes
> configure:2910: checking whether g++ accepts -g
> configure:2932: g++ -c -g  conftest.cc >&5
> configure:2935: $? = 0
> configure:2938: test -s conftest.o
> configure:2941: $? = 0
> configure:2952: result: yes
> configure:2996: g++ -c -g -O2  conftest.cc >&5
> configure:2999: $? = 0
> configure:3002: test -s conftest.o
> configure:3005: $? = 0
> configure:3032: g++ -c -g -O2  conftest.cc >&5
> configure: In function `int main()':
> configure:3027: error: `exit' was not declared in this scope
> configure:3035: $? = 1
> configure: failed program was:
> | #line 3015 "configure"
> | /* confdefs.h.  */
> |
> | #define PACKAGE_NAME "GrADS"
> | #define PACKAGE_TARNAME "grads"
> | #define PACKAGE_VERSION "1.9b4"
> | #define PACKAGE_STRING "GrADS 1.9b4"
> | #define PACKAGE_BUGREPORT ""
> | /* end confdefs.h.  */
> |
> | int
> | main ()
> | {
> | exit (42);
> |   ;
> |   return 0;
> | }
> configure:2996: g++ -c -g -O2  conftest.cc >&5
> configure:2999: $? = 0
> configure:3002: test -s conftest.o
> configure:3005: $? = 0
> configure:3032: g++ -c -g -O2  conftest.cc >&5
> configure:3035: $? = 0
> configure:3038: test -s conftest.o
> configure:3041: $? = 0
> configure:3076: checking for a BSD-compatible install
> configure:3130: result: /usr/bin/install -c
> configure:3141: checking whether ln -s works
> configure:3145: result: yes
> configure:3167: checking build system type
> configure:3180: error: /bin/sh etc/config.sub prefix failed
>
> ## ---------------- ##
> ## Cache variables. ##
> ## ---------------- ##
>
> ac_cv_build=
> ac_cv_build_alias=prefix
> ac_cv_c_compiler_gnu=yes
> ac_cv_cxx_compiler_gnu=yes
> ac_cv_env_CC_set=
> ac_cv_env_CC_value=
> ac_cv_env_CFLAGS_set=
> ac_cv_env_CFLAGS_value=
> ac_cv_env_CPPFLAGS_set=
> ac_cv_env_CPPFLAGS_value=
> ac_cv_env_CPP_set=
> ac_cv_env_CPP_value=
> ac_cv_env_CXXFLAGS_set=
> ac_cv_env_CXXFLAGS_value=
> ac_cv_env_CXX_set=
> ac_cv_env_CXX_value=
> ac_cv_env_LDFLAGS_set=
> ac_cv_env_LDFLAGS_value=
> ac_cv_env_SUPPLIBS_set=
> ac_cv_env_SUPPLIBS_value=
> ac_cv_env_build_alias_set=set
> ac_cv_env_build_alias_value=prefix
> ac_cv_env_host_alias_set=set
> ac_cv_env_host_alias_value=prefix
> ac_cv_env_target_alias_set=set
> ac_cv_env_target_alias_value=prefix
> ac_cv_exeext=
> ac_cv_objext=o
> ac_cv_path_install='/usr/bin/install -c'
> ac_cv_prog_AWK=gawk
> ac_cv_prog_ac_ct_CC=gcc
> ac_cv_prog_ac_ct_CXX=g++
> ac_cv_prog_cc_g=yes
> ac_cv_prog_cc_stdc=
> ac_cv_prog_cxx_g=yes
> ac_cv_prog_make_make_set=yes
>
> ## ----------------- ##
> ## Output variables. ##
> ## ----------------- ##
>
> ACLOCAL='${SHELL} /usr/local/grads-1.9b4/etc/missing --run aclocal-1.6'
> AMTAR='${SHELL} /usr/local/grads-1.9b4/etc/missing --run tar'
> AUTOCONF='${SHELL} /usr/local/grads-1.9b4/etc/missing --run autoconf'
> AUTOHEADER='${SHELL} /usr/local/grads-1.9b4/etc/missing --run autoheader'
> AUTOMAKE='${SHELL} /usr/local/grads-1.9b4/etc/missing --run automake-1.6'
> AWK='gawk'
> CC='gcc'
> CFLAGS='-g -O'
> CPP=''
> CPPFLAGS=''
> CXX='g++'
> CXXFLAGS='-g -O2'
> DEFS=''
> DODS_DARWIN_FALSE=''
> DODS_DARWIN_TRUE=''
> ECHO_C=''
> ECHO_N='-n'
> ECHO_T=''
> EGREP=''
> EXEEXT=''
> GXPNG_FALSE=''
> GXPNG_TRUE=''
> INSTALL_DATA='${INSTALL} -m 644'
> INSTALL_PROGRAM='${INSTALL}'
> INSTALL_SCRIPT='${INSTALL}'
> INSTALL_STRIP_PROGRAM='${SHELL} $(install_sh) -c -s'
> LDFLAGS=''
> LIBOBJS=''
> LIBS=''
> LN_S='ln -s'
> LTLIBOBJS=''
> MAINT='#'
> MAINTAINER_MODE_FALSE=''
> MAINTAINER_MODE_TRUE='#'
> MAKEINFO='${SHELL} /usr/local/grads-1.9b4/etc/missing --run makeinfo'
> OBJEXT='o'
> PACKAGE='grads'
> PACKAGE_BUGREPORT=''
> PACKAGE_NAME='GrADS'
> PACKAGE_STRING='GrADS 1.9b4'
> PACKAGE_TARNAME='grads'
> PACKAGE_VERSION='1.9b4'
> PATH_SEPARATOR=':'
> READLINE_FALSE=''
> READLINE_TRUE=''
> SET_MAKE=''
> SHELL='/bin/sh'
> STRIP=''
> SUPPLIBS=''
> USEDODS_FALSE=''
> USEDODS_TRUE=''
> USEGADODS_FALSE=''
> USEGADODS_TRUE=''
> USEGUI_FALSE=''
> USEGUI_TRUE=''
> USEHDF_FALSE=''
> USEHDF_TRUE=''
> USEIMG_FALSE=''
> USEIMG_TRUE=''
> USELATS_FALSE=''
> USELATS_TRUE=''
> USENC_FALSE=''
> USENC_TRUE=''
> VERSION='1.9b4'
> XLIBEMU_FALSE=''
> XLIBEMU_TRUE=''
> X_CFLAGS=''
> X_EXTRA_LIBS=''
> X_LIBS=''
> X_PRE_LIBS=''
> ac_ct_CC='gcc'
> ac_ct_CXX='g++'
> ac_ct_STRIP=''
> bindir='${exec_prefix}/bin'
> build='prefix'
> build_alias='prefix'
> build_cpu=''
> build_os=''
> build_vendor=''
> datadir='${prefix}/share'
> dods_libs=''
> exec_prefix='NONE'
> extra_bins=''
> extra_utils=''
> gadods_def=''
> gui_libs=''
> hdf_libs=''
> host='prefix'
> host_alias='prefix'
> host_cpu=''
> host_ldadd=''
> host_os=''
> host_vendor=''
> includedir='${prefix}/include'
> infodir='${prefix}/info'
> install_sh='/usr/local/grads-1.9b4/etc/install-sh'
> libdir='${exec_prefix}/lib'
> libexecdir='${exec_prefix}/libexec'
> localstatedir='${prefix}/var'
> mandir='${prefix}/man'
> nc_libs=''
> oldincludedir='/usr/include'
> prefix='NONE'
> printim_libs=''
> program_transform_name='s,x,x,'
> readline_libs=''
> sbindir='${exec_prefix}/sbin'
> sharedstatedir='${prefix}/com'
> sysconfdir='${prefix}/etc'
> target_alias='prefix'
> wi_libadd=''
> wi_libs=''
> xlibemu_libs=''
>
> ## ----------- ##
> ## confdefs.h. ##
> ## ----------- ##
>
> #define PACKAGE_BUGREPORT ""
> #define PACKAGE_NAME "GrADS"
> #define PACKAGE_STRING "GrADS 1.9b4"
> #define PACKAGE_TARNAME "grads"
> #define PACKAGE_VERSION "1.9b4"
> #endif
> #ifdef __cplusplus
> #include <stdlib.h>
>
> configure: exit 1
>
>
> ncdump -c:
>
>
> netcdf h0003 {
> dimensions:
>  lon = 128 ;
>  lev = 28 ;
>  ilev = 29 ;
>  lat = 64 ;
>  time = UNLIMITED ; // (30 currently)
>  nchar = 80 ;
> variables:
>  float P0 ;
>   P0:long_name = "reference pressure" ;
>   P0:units = "Pa" ;
>  int ntrm ;
>   ntrm:long_name = "spectral truncation parameter M" ;
>  int ntrn ;
>   ntrn:long_name = "spectral truncation parameter N" ;
>  int ntrk ;
>   ntrk:long_name = "spectral truncation parameter K" ;
>  int ndbase ;
>   ndbase:long_name = "base day for this case" ;
>  int nsbase ;
>   nsbase:long_name = "seconds to complete base day" ;
>   nsbase:units = "s" ;
>  int nbdate ;
>   nbdate:long_name = "base date as 6 digit integer (YYMMDD)" ;
>  int nbsec ;
>   nbsec:long_name = "seconds to complete base date" ;
>   nbsec:units = "s" ;
>  int mdt ;
>   mdt:long_name = "model timestep" ;
>   mdt:units = "s" ;
>  int mhisf ;
>   mhisf:long_name = "frequency of model writes (timesteps)" ;
>  char current_mss(nchar) ;
>   current_mss:long_name = "MSS pathname of this file" ;
>  char first_mss(nchar) ;
>   first_mss:long_name = "MSS pathname of first file for this case" ;
>  float hyai(ilev) ;
>   hyai:long_name = "hybrid A coefficient at layer interfaces" ;
>  float hybi(ilev) ;
>   hybi:long_name = "hybrid B coefficient at layer interfaces" ;
>  float ilev(ilev) ;
>   ilev:long_name = "hybrid level at layer interface (1000*(A+B))" ;
>   ilev:units = "hybrid_sigma_pressure" ;
>   ilev:positive = "down" ;
>   ilev:A_var = "hyam" ;
>   ilev:B_var = "hybm" ;
>   ilev:P0_var = "P0" ;
>   ilev:PS_var = "PS" ;
>   ilev:bounds = "ilev" ;
>  float hyam(lev) ;
>   hyam:long_name = "hybrid A coefficient at layer midpoints" ;
>  float hybm(lev) ;
>   hybm:long_name = "hybrid B coefficient at layer midpoints" ;
>  float lev(lev) ;
>   lev:long_name = "hybrid level at layer midpoints (1000*(A+B))" ;
>   lev:units = "hybrid_sigma_pressure" ;
>   lev:positive = "down" ;
>   lev:A_var = "hyam" ;
>   lev:B_var = "hybm" ;
>   lev:P0_var = "P0" ;
>   lev:PS_var = "PS" ;
>   lev:bounds = "ilev" ;
>  float lat(lat) ;
>   lat:long_name = "latitude" ;
>   lat:units = "degrees_north" ;
>  float gw(lat) ;
>   gw:long_name = "gauss weights" ;
>  float lon(lon) ;
>   lon:long_name = "longitude" ;
>   lon:units = "degrees_east" ;
>  int days(time) ;
>   days:long_name = "elapsed simulation days for this case" ;
>  int secs(time) ;
>   secs:long_name = "seconds to complete elapsed days" ;
>   secs:units = "s" ;
>  int date(time) ;
>   date:long_name = "current date as 6 digit integer (YYMMDD)" ;
>  int datesec(time) ;
>   datesec:long_name = "seconds to complete current date" ;
>   datesec:units = "s" ;
>  double time(time) ;
>   time:long_name = "simulation time" ;
>   time:units = "days since 0000-01-01 00:00:00" ;
>   time:calendar = "365_days" ;
>  int timestep_index(time) ;
>   timestep_index:long_name = "iteration counter for current case" ;
>  float PS(time, lat, lon) ;
>   PS:units = "PA" ;
>  float T(time, lev, lat, lon) ;
>   T:units = "K" ;
>  float J_001_inst(time, lev, lat, lon) ;
>   J_001_inst:units = "/CM3/S" ;
>  float J_002_inst(time, lev, lat, lon) ;
>   J_002_inst:units = "/CM3/S" ;
>  float J_003_inst(time, lev, lat, lon) ;
>   J_003_inst:units = "/CM3/S" ;
>  float J_004_inst(time, lev, lat, lon) ;
>   J_004_inst:units = "/CM3/S" ;
>  float J_005_inst(time, lev, lat, lon) ;
>   J_005_inst:units = "/CM3/S" ;
>  float J_006_inst(time, lev, lat, lon) ;
>   J_006_inst:units = "/CM3/S" ;
>  float J_007_inst(time, lev, lat, lon) ;
>   J_007_inst:units = "/CM3/S" ;
>  float J_008_inst(time, lev, lat, lon) ;
>   J_008_inst:units = "/CM3/S" ;
>  float J_009_inst(time, lev, lat, lon) ;
>   J_009_inst:units = "/CM3/S" ;
>  float J_010_inst(time, lev, lat, lon) ;
>   J_010_inst:units = "/CM3/S" ;
>  float J_011_inst(time, lev, lat, lon) ;
>   J_011_inst:units = "/CM3/S" ;
>  float J_012_inst(time, lev, lat, lon) ;
>   J_012_inst:units = "/CM3/S" ;
>  float J_013_inst(time, lev, lat, lon) ;
>   J_013_inst:units = "/CM3/S" ;
>  float J_014_inst(time, lev, lat, lon) ;
>   J_014_inst:units = "/CM3/S" ;
>  float J_015_inst(time, lev, lat, lon) ;
>   J_015_inst:units = "/CM3/S" ;
>  float J_016_inst(time, lev, lat, lon) ;
>   J_016_inst:units = "/CM3/S" ;
>  float J_017_inst(time, lev, lat, lon) ;
>   J_017_inst:units = "/CM3/S" ;
>  float J_018_inst(time, lev, lat, lon) ;
>   J_018_inst:units = "/CM3/S" ;
>  float J_019_inst(time, lev, lat, lon) ;
>   J_019_inst:units = "/CM3/S" ;
>  float J_020_inst(time, lev, lat, lon) ;
>   J_020_inst:units = "/CM3/S" ;
>  float J_021_inst(time, lev, lat, lon) ;
>   J_021_inst:units = "/CM3/S" ;
>  float J_022_inst(time, lev, lat, lon) ;
>   J_022_inst:units = "/CM3/S" ;
>  float J_023_inst(time, lev, lat, lon) ;
>   J_023_inst:units = "/CM3/S" ;
>  float J_024_inst(time, lev, lat, lon) ;
>   J_024_inst:units = "/CM3/S" ;
>  float J_025_inst(time, lev, lat, lon) ;
>   J_025_inst:units = "/CM3/S" ;
>  float J_026_inst(time, lev, lat, lon) ;
>   J_026_inst:units = "/CM3/S" ;
>  float J_027_inst(time, lev, lat, lon) ;
>   J_027_inst:units = "/CM3/S" ;
>  float J_028_inst(time, lev, lat, lon) ;
>   J_028_inst:units = "/CM3/S" ;
>  float J_029_inst(time, lev, lat, lon) ;
>   J_029_inst:units = "/CM3/S" ;
>  float J_030_inst(time, lev, lat, lon) ;
>   J_030_inst:units = "/CM3/S" ;
>  float J_031_inst(time, lev, lat, lon) ;
>   J_031_inst:units = "/CM3/S" ;
>  float J_032_inst(time, lev, lat, lon) ;
>   J_032_inst:units = "/CM3/S" ;
>  float J_033_inst(time, lev, lat, lon) ;
>   J_033_inst:units = "/CM3/S" ;
>  float OX_ADV_inst(time, lev, lat, lon) ;
>   OX_ADV_inst:units = "KG" ;
>  float OX_DPS_inst(time, lev, lat, lon) ;
>   OX_DPS_inst:units = "KG" ;
>  float OX_CNV_inst(time, lev, lat, lon) ;
>   OX_CNV_inst:units = "KG" ;
>  float OX_DIF_inst(time, lev, lat, lon) ;
>   OX_DIF_inst:units = "KG" ;
>  float OX_CHM_inst(time, lev, lat, lon) ;
>   OX_CHM_inst:units = "KG" ;
>  float OX_XFLX_inst(time, lev, lat, lon) ;
>   OX_XFLX_inst:units = "KG" ;
>  float OX_YFLX_inst(time, lev, lat, lon) ;
>   OX_YFLX_inst:units = "KG" ;
>  float OX_ZFLX_inst(time, lev, lat, lon) ;
>   OX_ZFLX_inst:units = "KG" ;
>  float TROPLEV(time, lat, lon) ;
>   TROPLEV:units = "KM" ;
>  float CWAT(time, lev, lat, lon) ;
>   CWAT:units = "KG/KG" ;
>  float Q(time, lev, lat, lon) ;
>   Q:units = "KG/KG" ;
>  float LNO_PROD(time, lat, lon) ;
>   LNO_PROD:units = "TG N/YR" ;
>  float OX_VMR_avrg(time, lev, lat, lon) ;
>   OX_VMR_avrg:units = "VMR" ;
>  float N2O_VMR_avrg(time, lev, lat, lon) ;
>   N2O_VMR_avrg:units = "VMR" ;
>  float N_VMR_avrg(time, lev, lat, lon) ;
>   N_VMR_avrg:units = "VMR" ;
>  float NO_VMR_avrg(time, lev, lat, lon) ;
>   NO_VMR_avrg:units = "VMR" ;
>  float NO2_VMR_avrg(time, lev, lat, lon) ;
>   NO2_VMR_avrg:units = "VMR" ;
>  float NO3_VMR_avrg(time, lev, lat, lon) ;
>   NO3_VMR_avrg:units = "VMR" ;
>  float HNO3_VMR_avrg(time, lev, lat, lon) ;
>   HNO3_VMR_avrg:units = "VMR" ;
>  float HO2NO2_VMR_avrg(time, lev, lat, lon) ;
>   HO2NO2_VMR_avrg:units = "VMR" ;
>  float N2O5_VMR_avrg(time, lev, lat, lon) ;
>   N2O5_VMR_avrg:units = "VMR" ;
>  float CH4_VMR_avrg(time, lev, lat, lon) ;
>   CH4_VMR_avrg:units = "VMR" ;
>  float CH3O2_VMR_avrg(time, lev, lat, lon) ;
>   CH3O2_VMR_avrg:units = "VMR" ;
>  float CH3OOH_VMR_avrg(time, lev, lat, lon) ;
>   CH3OOH_VMR_avrg:units = "VMR" ;
>  float CH2O_VMR_avrg(time, lev, lat, lon) ;
>   CH2O_VMR_avrg:units = "VMR" ;
>  float CO_VMR_avrg(time, lev, lat, lon) ;
>   CO_VMR_avrg:units = "VMR" ;
>  float OH_VMR_avrg(time, lev, lat, lon) ;
>   OH_VMR_avrg:units = "VMR" ;
>  float HO2_VMR_avrg(time, lev, lat, lon) ;
>   HO2_VMR_avrg:units = "VMR" ;
>  float H2O2_VMR_avrg(time, lev, lat, lon) ;
>   H2O2_VMR_avrg:units = "VMR" ;
>  float C3H6_VMR_avrg(time, lev, lat, lon) ;
>   C3H6_VMR_avrg:units = "VMR" ;
>  float ISOP_VMR_avrg(time, lev, lat, lon) ;
>   ISOP_VMR_avrg:units = "VMR" ;
>  float PO2_VMR_avrg(time, lev, lat, lon) ;
>   PO2_VMR_avrg:units = "VMR" ;
>  float CH3CHO_VMR_avrg(time, lev, lat, lon) ;
>   CH3CHO_VMR_avrg:units = "VMR" ;
>  float POOH_VMR_avrg(time, lev, lat, lon) ;
>   POOH_VMR_avrg:units = "VMR" ;
>  float CH3CO3_VMR_avrg(time, lev, lat, lon) ;
>   CH3CO3_VMR_avrg:units = "VMR" ;
>  float CH3COOOH_VMR_avrg(time, lev, lat, lon) ;
>   CH3COOOH_VMR_avrg:units = "VMR" ;
>  float PAN_VMR_avrg(time, lev, lat, lon) ;
>   PAN_VMR_avrg:units = "VMR" ;
>  float ONIT_VMR_avrg(time, lev, lat, lon) ;
>   ONIT_VMR_avrg:units = "VMR" ;
>  float C2H6_VMR_avrg(time, lev, lat, lon) ;
>   C2H6_VMR_avrg:units = "VMR" ;
>  float C2H4_VMR_avrg(time, lev, lat, lon) ;
>   C2H4_VMR_avrg:units = "VMR" ;
>  float C4H10_VMR_avrg(time, lev, lat, lon) ;
>   C4H10_VMR_avrg:units = "VMR" ;
>  float MPAN_VMR_avrg(time, lev, lat, lon) ;
>   MPAN_VMR_avrg:units = "VMR" ;
>  float ISOPO2_VMR_avrg(time, lev, lat, lon) ;
>   ISOPO2_VMR_avrg:units = "VMR" ;
>  float MVK_VMR_avrg(time, lev, lat, lon) ;
>   MVK_VMR_avrg:units = "VMR" ;
>  float MACR_VMR_avrg(time, lev, lat, lon) ;
>   MACR_VMR_avrg:units = "VMR" ;
>  float MACRO2_VMR_avrg(time, lev, lat, lon) ;
>   MACRO2_VMR_avrg:units = "VMR" ;
>  float MACROOH_VMR_avrg(time, lev, lat, lon) ;
>   MACROOH_VMR_avrg:units = "VMR" ;
>  float MCO3_VMR_avrg(time, lev, lat, lon) ;
>   MCO3_VMR_avrg:units = "VMR" ;
>  float C2H5O2_VMR_avrg(time, lev, lat, lon) ;
>   C2H5O2_VMR_avrg:units = "VMR" ;
>  float C2H5OOH_VMR_avrg(time, lev, lat, lon) ;
>   C2H5OOH_VMR_avrg:units = "VMR" ;
>  float C10H16_VMR_avrg(time, lev, lat, lon) ;
>   C10H16_VMR_avrg:units = "VMR" ;
>  float C3H8_VMR_avrg(time, lev, lat, lon) ;
>   C3H8_VMR_avrg:units = "VMR" ;
>  float C3H7O2_VMR_avrg(time, lev, lat, lon) ;
>   C3H7O2_VMR_avrg:units = "VMR" ;
>  float C3H7OOH_VMR_avrg(time, lev, lat, lon) ;
>   C3H7OOH_VMR_avrg:units = "VMR" ;
>  float CH3COCH3_VMR_avrg(time, lev, lat, lon) ;
>   CH3COCH3_VMR_avrg:units = "VMR" ;
>  float ROOH_VMR_avrg(time, lev, lat, lon) ;
>   ROOH_VMR_avrg:units = "VMR" ;
>  float CH3OH_VMR_avrg(time, lev, lat, lon) ;
>   CH3OH_VMR_avrg:units = "VMR" ;
>  float C2H5OH_VMR_avrg(time, lev, lat, lon) ;
>   C2H5OH_VMR_avrg:units = "VMR" ;
>  float GLYALD_VMR_avrg(time, lev, lat, lon) ;
>   GLYALD_VMR_avrg:units = "VMR" ;
>  float HYAC_VMR_avrg(time, lev, lat, lon) ;
>   HYAC_VMR_avrg:units = "VMR" ;
>  float EO2_VMR_avrg(time, lev, lat, lon) ;
>   EO2_VMR_avrg:units = "VMR" ;
>  float EO_VMR_avrg(time, lev, lat, lon) ;
>   EO_VMR_avrg:units = "VMR" ;
>  float HYDRALD_VMR_avrg(time, lev, lat, lon) ;
>   HYDRALD_VMR_avrg:units = "VMR" ;
>  float RO2_VMR_avrg(time, lev, lat, lon) ;
>   RO2_VMR_avrg:units = "VMR" ;
>  float CH3COCHO_VMR_avrg(time, lev, lat, lon) ;
>   CH3COCHO_VMR_avrg:units = "VMR" ;
>  float Rn_VMR_avrg(time, lev, lat, lon) ;
>   Rn_VMR_avrg:units = "VMR" ;
>  float Pb_VMR_avrg(time, lev, lat, lon) ;
>   Pb_VMR_avrg:units = "VMR" ;
>  float ISOPNO3_VMR_avrg(time, lev, lat, lon) ;
>   ISOPNO3_VMR_avrg:units = "VMR" ;
>  float ONITR_VMR_avrg(time, lev, lat, lon) ;
>   ONITR_VMR_avrg:units = "VMR" ;
>  float XO2_VMR_avrg(time, lev, lat, lon) ;
>   XO2_VMR_avrg:units = "VMR" ;
>  float XOOH_VMR_avrg(time, lev, lat, lon) ;
>   XOOH_VMR_avrg:units = "VMR" ;
>  float ISOPOOH_VMR_avrg(time, lev, lat, lon) ;
>   ISOPOOH_VMR_avrg:units = "VMR" ;
>  float H2_VMR_avrg(time, lev, lat, lon) ;
>   H2_VMR_avrg:units = "VMR" ;
>  float O3S_VMR_avrg(time, lev, lat, lon) ;
>   O3S_VMR_avrg:units = "VMR" ;
>  float O3INERT_VMR_avrg(time, lev, lat, lon) ;
>   O3INERT_VMR_avrg:units = "VMR" ;
>  float O3_VMR_avrg(time, lev, lat, lon) ;
>   O3_VMR_avrg:units = "VMR" ;
>  float O1D_VMR_avrg(time, lev, lat, lon) ;
>   O1D_VMR_avrg:units = "VMR" ;
>  float O_VMR_avrg(time, lev, lat, lon) ;
>   O_VMR_avrg:units = "VMR" ;
>  float NO_SRF_EMIS_avrg(time, lat, lon) ;
>   NO_SRF_EMIS_avrg:units = "KG/M2/S" ;
>  float N2O_SRF_EMIS_avrg(time, lat, lon) ;
>   N2O_SRF_EMIS_avrg:units = "KG/M2/S" ;
>  float CH4_SRF_EMIS_avrg(time, lat, lon) ;
>   CH4_SRF_EMIS_avrg:units = "KG/M2/S" ;
>  float CH2O_SRF_EMIS_avrg(time, lat, lon) ;
>   CH2O_SRF_EMIS_avrg:units = "KG/M2/S" ;
>  float CO_SRF_EMIS_avrg(time, lat, lon) ;
>   CO_SRF_EMIS_avrg:units = "KG/M2/S" ;
>  float C3H6_SRF_EMIS_avrg(time, lat, lon) ;
>   C3H6_SRF_EMIS_avrg:units = "KG/M2/S" ;
>  float ISOP_SRF_EMIS_avrg(time, lat, lon) ;
>   ISOP_SRF_EMIS_avrg:units = "KG/M2/S" ;
>  float C10H16_SRF_EMIS_avrg(time, lat, lon) ;
>   C10H16_SRF_EMIS_avrg:units = "KG/M2/S" ;
>  float C2H4_SRF_EMIS_avrg(time, lat, lon) ;
>   C2H4_SRF_EMIS_avrg:units = "KG/M2/S" ;
>  float C2H6_SRF_EMIS_avrg(time, lat, lon) ;
>   C2H6_SRF_EMIS_avrg:units = "KG/M2/S" ;
>  float C4H10_SRF_EMIS_avrg(time, lat, lon) ;
>   C4H10_SRF_EMIS_avrg:units = "KG/M2/S" ;
>  float C3H8_SRF_EMIS_avrg(time, lat, lon) ;
>   C3H8_SRF_EMIS_avrg:units = "KG/M2/S" ;
>  float CH3COCH3_SRF_EMIS_avrg(time, lat, lon) ;
>   CH3COCH3_SRF_EMIS_avrg:units = "KG/M2/S" ;
>  float Rn_SRF_EMIS_avrg(time, lat, lon) ;
>   Rn_SRF_EMIS_avrg:units = "KG/M2/S" ;
>  float H2_SRF_EMIS_avrg(time, lat, lon) ;
>   H2_SRF_EMIS_avrg:units = "KG/M2/S" ;
>  float CH3OH_SRF_EMIS_avrg(time, lat, lon) ;
>   CH3OH_SRF_EMIS_avrg:units = "KG/M2/S" ;
>  float OX_DEP_VEL_avrg(time, lat, lon) ;
>   OX_DEP_VEL_avrg:units = "CM/S" ;
>  float NO2_DEP_VEL_avrg(time, lat, lon) ;
>   NO2_DEP_VEL_avrg:units = "CM/S" ;
>  float HNO3_DEP_VEL_avrg(time, lat, lon) ;
>   HNO3_DEP_VEL_avrg:units = "CM/S" ;
>  float CH4_DEP_VEL_avrg(time, lat, lon) ;
>   CH4_DEP_VEL_avrg:units = "CM/S" ;
>  float CH3OOH_DEP_VEL_avrg(time, lat, lon) ;
>   CH3OOH_DEP_VEL_avrg:units = "CM/S" ;
>  float CH2O_DEP_VEL_avrg(time, lat, lon) ;
>   CH2O_DEP_VEL_avrg:units = "CM/S" ;
>  float CO_DEP_VEL_avrg(time, lat, lon) ;
>   CO_DEP_VEL_avrg:units = "CM/S" ;
>  float H2O2_DEP_VEL_avrg(time, lat, lon) ;
>   H2O2_DEP_VEL_avrg:units = "CM/S" ;
>  float POOH_DEP_VEL_avrg(time, lat, lon) ;
>   POOH_DEP_VEL_avrg:units = "CM/S" ;
>  float CH3COOOH_DEP_VEL_avrg(time, lat, lon) ;
>   CH3COOOH_DEP_VEL_avrg:units = "CM/S" ;
>  float PAN_DEP_VEL_avrg(time, lat, lon) ;
>   PAN_DEP_VEL_avrg:units = "CM/S" ;
>  float MPAN_DEP_VEL_avrg(time, lat, lon) ;
>   MPAN_DEP_VEL_avrg:units = "CM/S" ;
>  float C2H5OOH_DEP_VEL_avrg(time, lat, lon) ;
>   C2H5OOH_DEP_VEL_avrg:units = "CM/S" ;
>  float ONIT_DEP_VEL_avrg(time, lat, lon) ;
>   ONIT_DEP_VEL_avrg:units = "CM/S" ;
>  float C3H7OOH_DEP_VEL_avrg(time, lat, lon) ;
>   C3H7OOH_DEP_VEL_avrg:units = "CM/S" ;
>  float ROOH_DEP_VEL_avrg(time, lat, lon) ;
>   ROOH_DEP_VEL_avrg:units = "CM/S" ;
>  float CH3COCHO_DEP_VEL_avrg(time, lat, lon) ;
>   CH3COCHO_DEP_VEL_avrg:units = "CM/S" ;
>  float CH3COCH3_DEP_VEL_avrg(time, lat, lon) ;
>   CH3COCH3_DEP_VEL_avrg:units = "CM/S" ;
>  float Pb_DEP_VEL_avrg(time, lat, lon) ;
>   Pb_DEP_VEL_avrg:units = "CM/S" ;
>  float O3INERT_DEP_VEL_avrg(time, lat, lon) ;
>   O3INERT_DEP_VEL_avrg:units = "CM/S" ;
>  float O3S_DEP_VEL_avrg(time, lat, lon) ;
>   O3S_DEP_VEL_avrg:units = "CM/S" ;
>  float H2_DEP_VEL_avrg(time, lat, lon) ;
>   H2_DEP_VEL_avrg:units = "CM/S" ;
>  float ONITR_DEP_VEL_avrg(time, lat, lon) ;
>   ONITR_DEP_VEL_avrg:units = "CM/S" ;
>  float MACROOH_DEP_VEL_avrg(time, lat, lon) ;
>   MACROOH_DEP_VEL_avrg:units = "CM/S" ;
>  float XOOH_DEP_VEL_avrg(time, lat, lon) ;
>   XOOH_DEP_VEL_avrg:units = "CM/S" ;
>  float ISOPOOH_DEP_VEL_avrg(time, lat, lon) ;
>   ISOPOOH_DEP_VEL_avrg:units = "CM/S" ;
>  float CH3CHO_DEP_VEL_avrg(time, lat, lon) ;
>   CH3CHO_DEP_VEL_avrg:units = "CM/S" ;
>  float NO_DEP_VEL_avrg(time, lat, lon) ;
>   NO_DEP_VEL_avrg:units = "CM/S" ;
>  float HO2NO2_DEP_VEL_avrg(time, lat, lon) ;
>   HO2NO2_DEP_VEL_avrg:units = "CM/S" ;
>  float GLYALD_DEP_VEL_avrg(time, lat, lon) ;
>   GLYALD_DEP_VEL_avrg:units = "CM/S" ;
>  float HYAC_DEP_VEL_avrg(time, lat, lon) ;
>   HYAC_DEP_VEL_avrg:units = "CM/S" ;
>  float CH3OH_DEP_VEL_avrg(time, lat, lon) ;
>   CH3OH_DEP_VEL_avrg:units = "CM/S" ;
>  float C2H5OH_DEP_VEL_avrg(time, lat, lon) ;
>   C2H5OH_DEP_VEL_avrg:units = "CM/S" ;
>  float HYDRALD_DEP_VEL_avrg(time, lat, lon) ;
>   HYDRALD_DEP_VEL_avrg:units = "CM/S" ;
>  float H2O2_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   H2O2_WET_DEP_RATE_avrg:units = "/S" ;
>  float HNO3_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   HNO3_WET_DEP_RATE_avrg:units = "/S" ;
>  float CH2O_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   CH2O_WET_DEP_RATE_avrg:units = "/S" ;
>  float CH3OOH_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   CH3OOH_WET_DEP_RATE_avrg:units = "/S" ;
>  float POOH_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   POOH_WET_DEP_RATE_avrg:units = "/S" ;
>  float CH3COOOH_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   CH3COOOH_WET_DEP_RATE_avrg:units = "/S" ;
>  float HO2NO2_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   HO2NO2_WET_DEP_RATE_avrg:units = "/S" ;
>  float ONIT_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   ONIT_WET_DEP_RATE_avrg:units = "/S" ;
>  float MVK_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   MVK_WET_DEP_RATE_avrg:units = "/S" ;
>  float MACR_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   MACR_WET_DEP_RATE_avrg:units = "/S" ;
>  float C2H5OOH_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   C2H5OOH_WET_DEP_RATE_avrg:units = "/S" ;
>  float C3H7OOH_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   C3H7OOH_WET_DEP_RATE_avrg:units = "/S" ;
>  float ROOH_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   ROOH_WET_DEP_RATE_avrg:units = "/S" ;
>  float CH3COCHO_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   CH3COCHO_WET_DEP_RATE_avrg:units = "/S" ;
>  float Pb_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   Pb_WET_DEP_RATE_avrg:units = "/S" ;
>  float MACROOH_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   MACROOH_WET_DEP_RATE_avrg:units = "/S" ;
>  float XOOH_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   XOOH_WET_DEP_RATE_avrg:units = "/S" ;
>  float ONITR_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   ONITR_WET_DEP_RATE_avrg:units = "/S" ;
>  float ISOPOOH_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   ISOPOOH_WET_DEP_RATE_avrg:units = "/S" ;
>  float GLYALD_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   GLYALD_WET_DEP_RATE_avrg:units = "/S" ;
>  float HYAC_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   HYAC_WET_DEP_RATE_avrg:units = "/S" ;
>  float CH3OH_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   CH3OH_WET_DEP_RATE_avrg:units = "/S" ;
>  float C2H5OH_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   C2H5OH_WET_DEP_RATE_avrg:units = "/S" ;
>  float HYDRALD_WET_DEP_RATE_avrg(time, lev, lat, lon) ;
>   HYDRALD_WET_DEP_RATE_avrg:units = "/S" ;
>  float NO_EXT_FRC_avrg(time, lev, lat, lon) ;
>   NO_EXT_FRC_avrg:units = "/CM3/S" ;
>  float CH4_EXT_FRC_avrg(time, lev, lat, lon) ;
>   CH4_EXT_FRC_avrg:units = "/CM3/S" ;
>  float CO_EXT_FRC_avrg(time, lev, lat, lon) ;
>   CO_EXT_FRC_avrg:units = "/CM3/S" ;
>  float OX_PROD_avrg(time, lev, lat, lon) ;
>   OX_PROD_avrg:units = "/CM3/S" ;
>  float OX_LOSS_avrg(time, lev, lat, lon) ;
>   OX_LOSS_avrg:units = "/CM3/S" ;
>  float OX_ADV_avrg(time, lev, lat, lon) ;
>   OX_ADV_avrg:units = "KG" ;
>  float OX_DPS_avrg(time, lev, lat, lon) ;
>   OX_DPS_avrg:units = "KG" ;
>  float OX_CNV_avrg(time, lev, lat, lon) ;
>   OX_CNV_avrg:units = "KG" ;
>  float OX_DIF_avrg(time, lev, lat, lon) ;
>   OX_DIF_avrg:units = "KG" ;
>  float OX_CHM_avrg(time, lev, lat, lon) ;
>   OX_CHM_avrg:units = "KG" ;
>  float OX_XFLX_avrg(time, lev, lat, lon) ;
>   OX_XFLX_avrg:units = "KG" ;
>  float OX_YFLX_avrg(time, lev, lat, lon) ;
>   OX_YFLX_avrg:units = "KG" ;
>  float OX_ZFLX_avrg(time, lev, lat, lon) ;
>   OX_ZFLX_avrg:units = "KG" ;
>  float OX_DRY_DEP_FLX_avrg(time, lat, lon) ;
>   OX_DRY_DEP_FLX_avrg:units = "KG" ;
>  float O3S_DRY_DEP_FLX_avrg(time, lat, lon) ;
>   O3S_DRY_DEP_FLX_avrg:units = "KG" ;
>  float CO_DRY_DEP_FLX_avrg(time, lat, lon) ;
>   CO_DRY_DEP_FLX_avrg:units = "KG" ;
>  float NO_DRY_DEP_FLX_avrg(time, lat, lon) ;
>   NO_DRY_DEP_FLX_avrg:units = "KG" ;
>  float NO2_DRY_DEP_FLX_avrg(time, lat, lon) ;
>   NO2_DRY_DEP_FLX_avrg:units = "KG" ;
>  float HNO3_DRY_DEP_FLX_avrg(time, lat, lon) ;
>   HNO3_DRY_DEP_FLX_avrg:units = "KG" ;
>  float PAN_DRY_DEP_FLX_avrg(time, lat, lon) ;
>   PAN_DRY_DEP_FLX_avrg:units = "KG" ;
>  float MPAN_DRY_DEP_FLX_avrg(time, lat, lon) ;
>   MPAN_DRY_DEP_FLX_avrg:units = "KG" ;
>
> // global attributes:
>   :Conventions = "NCAR-CSM" ;
>   :case = "debug                           " ;
>   :title = "MOZART2-v2.4
>                 " ;
> data:
>
>  ilev = 0.54, 5.4, 14.8, 21.8, 35.8, 47.8, 68.2, 88.2, 117.4, 147.8, 188.6,
>     231.6, 284.8, 340.2, 403.8, 467.6, 535.7999, 600.4, 665.4, 723.2,
>     778.3999, 824.4001, 867.1998, 900.4001, 931.3999, 953.6001, 975.1999,
>     989, 1000 ;
>
>  lev = 2.7, 10.1, 18.3, 28.8, 41.8, 58, 78.2, 102.8, 132.6, 168.2, 210.1,
>     258.2, 312.5, 372, 435.7, 501.7, 568.1, 632.9, 694.3, 750.7999, 801.4,
>     845.8, 883.8, 915.9, 942.5, 964.4, 982.1, 994.9999 ;
>
>  lat = -90, -87.14286, -84.28571, -81.42857, -78.57143, -75.71429, -72.85714,
>     -70, -67.14286, -64.28571, -61.42857, -58.57143, -55.71429, -52.85714,
>     -50, -47.14286, -44.28571, -41.42857, -38.57143, -35.71429, -32.85714,
>     -30, -27.14286, -24.28572, -21.42857, -18.57143, -15.71429, -12.85714,
>     -10, -7.142857, -4.285714, -1.428571, 1.428571, 4.285714, 7.142857, 10,
>     12.85714, 15.71429, 18.57143, 21.42857, 24.28572, 27.14286, 30, 32.85714,
>     35.71429, 38.57143, 41.42857, 44.28571, 47.14286, 50, 52.85714, 55.71429,
>     58.57143, 61.42857, 64.28571, 67.14286, 70, 72.85714, 75.71429, 78.57143,
>     81.42857, 84.28571, 87.14286, 90 ;
>
>  lon = 0, 2.8125, 5.625, 8.4375, 11.25, 14.0625, 16.875, 19.6875, 22.5,
>     25.3125, 28.125, 30.9375, 33.75, 36.5625, 39.375, 42.1875, 45, 47.8125,
>     50.625, 53.4375, 56.25, 59.0625, 61.875, 64.6875, 67.5, 70.3125, 73.125,
>     75.9375, 78.75, 81.5625, 84.375, 87.1875, 90, 92.8125, 95.625, 98.4375,
>     101.25, 104.0625, 106.875, 109.6875, 112.5, 115.3125, 118.125, 120.9375,
>     123.75, 126.5625, 129.375, 132.1875, 135, 137.8125, 140.625, 143.4375,
>     146.25, 149.0625, 151.875, 154.6875, 157.5, 160.3125, 163.125, 165.9375,
>     168.75, 171.5625, 174.375, 177.1875, 180, 182.8125, 185.625, 188.4375,
>     191.25, 194.0625, 196.875, 199.6875, 202.5, 205.3125, 208.125, 210.9375,
>     213.75, 216.5625, 219.375, 222.1875, 225, 227.8125, 230.625, 233.4375,
>     236.25, 239.0625, 241.875, 244.6875, 247.5, 250.3125, 253.125, 255.9375,
>     258.75, 261.5625, 264.375, 267.1875, 270, 272.8125, 275.625, 278.4375,
>     281.25, 284.0625, 286.875, 289.6875, 292.5, 295.3125, 298.125, 300.9375,
>     303.75, 306.5625, 309.375, 312.1875, 315, 317.8125, 320.625, 323.4375,
>     326.25, 329.0625, 331.875, 334.6875, 337.5, 340.3125, 343.125, 345.9375,
>     348.75, 351.5625, 354.375, 357.1875 ;
>
>  time = 731886.125, 731887.125, 731888.125, 731889.125, 731890.125,
>     731891.125, 731892.125, 731893.125, 731894.125, 731895.125, 731896.125,
>     731897.125, 731898.125, 731899.125, 731900.125, 731901.125, 731902.125,
>     731903.125, 731904.125, 731905.125, 731906.125, 731907.125, 731908.125,
>     731909.125, 731910.125, 731911.125, 731912.125, 731913.125, 731914.125,
>     731915.125 ;
> }


From phaines at ARL.ARMY.MIL  Mon Oct 15 11:21:21 2007
From: phaines at ARL.ARMY.MIL (Haines, Patrick (Civ, ARL/CISD))
Date: Mon, 15 Oct 2007 09:21:21 -0600
Subject: GrADS execution error (UNCLASSIFIED)
In-Reply-To: A<470F5BC1.1090203@ifm.uni-hamburg.de>
Message-ID: <MON.15.OCT.2007.092121.0600.>

Classification:  UNCLASSIFIED
Caveats: NONE

 I have set up GrADS on a Linux Networx
Advanced Technology Cluster using the SLES 9
operating system. The setup is exactly the same as
on a Linux Networx Evolocity II machine also using
the SLES 9 operating system. The GrADS installed on the
latter machine works fine, but I get the following error
when using the former machine:

*************************************************************


62 l2> ls
bin       COPYRIGHT  gradsdods  gradsnc  gribscan  gxps    INSTALL
wgrib
bufrscan  gradsc     gradshdf   gribmap  gxeps     gxtran  stnmap
63 l2> gradsc
gradsc: error while loading shared libraries: libtermcap.so.2: cannot
open shared object file: No such file or directory
64 l2>

*************************************************************

Any suggestions?  Thank you,

                                             Patrick Haines
Classification:  UNCLASSIFIED
Caveats: NONE


From theedge981 at GMAIL.COM  Mon Oct 15 13:12:18 2007
From: theedge981 at GMAIL.COM (Dan Leins)
Date: Mon, 15 Oct 2007 13:12:18 -0400
Subject: draw title options
Message-ID: <MON.15.OCT.2007.131218.0400.>

All,

Should be a pretty simple answer but I can't find it anywhere. Can anyone
tell me how I can adjust the size of the font used when drawing a title on
an image? Right now I simply draw the title but often times the title is so
long it runs off the edge of the image. I've resorted to drawing a string
instead of a title at a given x/y position and reducing the string size
using set strsiz, but I'd like to know how to shrink the font that's used in
the title.

Thanks,
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071015/526dbabf/attachment.html 

From ela at COLA.IGES.ORG  Mon Oct 15 13:19:04 2007
From: ela at COLA.IGES.ORG (Eric Altshuler)
Date: Mon, 15 Oct 2007 13:19:04 -0400
Subject: draw title options
In-Reply-To: <46e821750710151012p2579928er1b7c867efa8d5a29@mail.gmail.com>
Message-ID: <MON.15.OCT.2007.131904.0400.>

Dan,

I think your strategy of drawing a string is the only way around this problem. I've had the same question before and I don't think it's possible to control the font size in 'draw title'.

Eric

----- Original Message -----
From: "Dan Leins" <theedge981 at GMAIL.COM>
To: GRADSUSR at LIST.CINECA.IT
Sent: Monday, October 15, 2007 1:12:18 PM (GMT-0500) America/New_York
Subject: draw title options


All,
?
Should be a pretty simple answer but I can't find it anywhere. Can anyone tell me how I can adjust the size of the font used when drawing a title on an image? Right now I simply draw the title but often times the title is so long it runs off the edge of the image. I've resorted to drawing a string instead of a title at a given x/y position and reducing the string size using set strsiz, but I'd like to know how to shrink the font that's used in the title.
?
Thanks,
Dan


From rburgman at RSMAS.MIAMI.EDU  Mon Oct 15 14:07:27 2007
From: rburgman at RSMAS.MIAMI.EDU (Robert Burgman)
Date: Mon, 15 Oct 2007 14:07:27 -0400
Subject: draw title options
In-Reply-To: <46e821750710151012p2579928er1b7c867efa8d5a29@mail.gmail.com>
Message-ID: <MON.15.OCT.2007.140727.0400.>



Placing a forward slash "\" before the text will reduce the size of
the text, "\\"will reduce it further.
if you place a double forward slash "\\" in the body of the text, the
following text will be placed on 2 lines with line 2 begining after
the "\\".


 >draw title  \ first line of title \\ second line of title
        first line of title
        second line of title

--Rob

On Oct 15, 2007, at 1:12 PM, Dan Leins wrote:

> All,
>
> Should be a pretty simple answer but I can't find it anywhere. Can
> anyone tell me how I can adjust the size of the font used when
> drawing a title on an image? Right now I simply draw the title but
> often times the title is so long it runs off the edge of the image.
> I've resorted to drawing a string instead of a title at a given x/y
> position and reducing the string size using set strsiz, but I'd
> like to know how to shrink the font that's used in the title.
>
> Thanks,
> Dan

----------------------------------------------------
Dr. Robert Burgman
Division of Meteorology and Physical Oceanography
Rosenstiel School of Marine and Atmospheric Science
University of Miami MPO, MSC 237
4600 Rickenbacker Causeway
Miami, FL 33149

Tel:        (305) 421-4272
Fax:       (305) 421-4696
Email:    rburgman at rsmas.miami.edu
---------------------------------------------------



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071015/7d7fddd0/attachment.html 

From jma at COLA.IGES.ORG  Mon Oct 15 14:54:11 2007
From: jma at COLA.IGES.ORG (Jennifer Adams)
Date: Mon, 15 Oct 2007 14:54:11 -0400
Subject: draw title options
In-Reply-To: <58B3974D-F3BC-4D40-9D0C-7B05C8CD91A4@rsmas.miami.edu>
Message-ID: <MON.15.OCT.2007.145411.0400.>

I use this script instead of 'draw title'.


* title.gs
*
* This is an alternative to the 'draw title' command in GrADS.
* Font characteristics are controlled by five script variables:
* height, width, color, thickness, and font number.
* The sole argument is a string of any length which may
* contain backslashes ("\") to indicate carriage returns.
* Written by Jennifer M. Adams, January 2007
*
function title (arg)
* Set the text characteristics
height=0.20
width=0.18
color=1
thickness=1
fnum=0

* Check for backslashes
nbreaks=0
len=math_strlen(arg)
i=1
while (i<=len)
char=substr(arg,i,1)
if (char = '\')
   nbreaks=nbreaks+1
   break.nbreaks = i
endif
i=i+1
endwhile

* Figure out where the title will go
'q gxinfo'
xlims=sublin(result,3)
ylims=sublin(result,4)
ytop=subwrd(ylims,6)
xleft=subwrd(xlims,4)
xright=subwrd(xlims,6)
xmid=xleft+(xright-xleft)/2

* Set up the string characteristics
'set string 'color' bc 'thickness
'set strsiz 'width' 'height

* Draw the title
if (nbreaks)
arg.1 = substr(arg,1,break.1-1)
if (nbreaks=1)
   arg.2 = substr(arg,break.1+1,len-break.1);* two lines
   nargs=2
else
   i=2
   while (i<=nbreaks)
    s=i-1
    start = break.s
    start = start+1
    e=i
    end = break.e
    length = end-start
    arg.i = substr(arg,start,length)
    i=i+1
   endwhile
   start = break.nbreaks
   start = start+1
   length = len-start+1
   nargs=nbreaks+1
   arg.nargs = substr(arg,start,length)
endif

i=1
while (i<=nargs)
'draw string 'xmid' 'ytop+(height)+((nargs-i)*(1.5*height))'
`'fnum''arg.i
   i=i+1
endwhile

else
'draw string 'xmid' 'ytop+height' `'fnum''arg
endif


From zmumba at YAHOO.COM  Tue Oct 16 09:13:28 2007
From: zmumba at YAHOO.COM (zilore mumba)
Date: Tue, 16 Oct 2007 06:13:28 -0700
Subject: file size limit
Message-ID: <TUE.16.OCT.2007.061328.0700.>

Help needed.
I hade daily model analysis data of u and v components which is written to binary with a fortran program.
The data displays correctly in grads, but only up to day 16 out of 31. The fields displayed are exactly the same as the original data in GRIB format processed through gri2ctl and gribmap.
From day 17 the display command throws up the error as below. This is from a Windows platform). On LINUX the error indicated is slightly different ( request beyond data limits) 

The same fortran program write daily pressure data and dsiplays correctly up to day 31.
The wind data files size is of the order of 600kb for each of u and v
The pressure data file size is of the order of 200-300kB

Reading through the archive I see that 2GB seems to be the limit of the file size which grads can handle.
Could anyone  know the origin of the problem.

This is output for v component. t 1 and t 16 display correctly.
set t 30 gives the error as below

Zilore Mumba

ga-> open v925.ctl
Scanning description file:  v925.ctl
Data file v10.grb is open as file 1
LON set to -30 75
LAT set to -45 60
LEV set to 500 500
Time values set: 2007:8:1:0 2007:8:1:0
ga-> q file
File 1 : vcomp
  Descriptor: v925.ctl
  Binary: v10.grb
  Type = Gridded
  Xsize = 71  Ysize = 71  Zsize = 1  Tsize = 31
  Number of Variables = 1
    v 2 33 ** v wind [m/s]
ga-> d v
Contouring: -20 to 20 interval 5
ga-> c
ga-> set t 16
Time values set: 2007:8:16:0 2007:8:16:0
ga-> d v
Contouring: -12 to 12 interval 3
ga-> c
ga-> set t 30
Time values set: 2007:8:30:0 2007:8:30:0
ga-> d v
Low Level I/O Error:  Read error on data file
  Data file name = v10.grb
  Error reading 71 bytes at location 297348
Data Request Error:  Error for variable 'v'
  Error ocurred at column 1
DISPLAY error:  Invalid expression
  Expression = v
ga->


       
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. 
http://answers.yahoo.com/dir/?link=list&sid=396545433
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071016/9a68e210/attachment.html 

From hallak at MODEL.IAG.USP.BR  Tue Oct 16 08:53:03 2007
From: hallak at MODEL.IAG.USP.BR (Ricardo Hallak)
Date: Tue, 16 Oct 2007 10:53:03 -0200
Subject: GrADS execution error (UNCLASSIFIED)
In-Reply-To: <ED7B92904B5E834081EBD707EFB764C4CEC950@ARLWSML01.DS.ARL.ARMY.MIL>
Message-ID: <TUE.16.OCT.2007.105303.0200.>

It means that the libtermcap.so.2 library is missing in your new
machine /usr/lib directory. You have to install it in your machine. Use a
version of that library compatible with your OS. Maybe your sistem
administrator could help you.
Regards,
Ricardo

On Mon, 15 Oct 2007 09:21:21 -0600, Haines, Patrick (Civ, ARL/CISD) wrote
> Classification:  UNCLASSIFIED
> Caveats: NONE
>
>  I have set up GrADS on a Linux Networx
> Advanced Technology Cluster using the SLES 9
> operating system. The setup is exactly the same as
> on a Linux Networx Evolocity II machine also using
> the SLES 9 operating system. The GrADS installed on the
> latter machine works fine, but I get the following error
> when using the former machine:
>
> *************************************************************
>
> 62 l2> ls
> bin       COPYRIGHT  gradsdods  gradsnc  gribscan  gxps    INSTALL
> wgrib
> bufrscan  gradsc     gradshdf   gribmap  gxeps     gxtran  stnmap
> 63 l2> gradsc
> gradsc: error while loading shared libraries: libtermcap.so.2: cannot
> open shared object file: No such file or directory
> 64 l2>
>
> *************************************************************
>
> Any suggestions?  Thank you,
>
>                                              Patrick Haines
> Classification:  UNCLASSIFIED
> Caveats: NONE


From giavvns at ATH.HCMR.GR  Tue Oct 16 09:39:31 2007
From: giavvns at ATH.HCMR.GR (Ioannis A. Vamvakas)
Date: Tue, 16 Oct 2007 16:39:31 +0300
Subject: Gribbing with 2 different FORTRAN compilers
In-Reply-To: <77fcd6b20710111055r47ed618r3aeb3db5cce62fb8@mail.gmail.com>
Message-ID: <TUE.16.OCT.2007.163931.0300.>

Dear Arlindo,

I'm dealing with a fortran compiler problem you may have come across.

I'm doing some GRIB 1 packing using 'packgrib' routine by Bob Dattore at
NCAR/DSS.
When I compile my programs with the g77 (GNU vs 3.4.6) compiler everything
works fine. Yet, when I use the ifort (Intel vs 10.023) compiler the
output
GRIB file has the same size as from the g77 but tools like 'wgrib' behave
as if the file was empty.

Any suggestions on this?

Thanks again for your help.

I.A. Vamvakas


From ucfasra at UCL.AC.UK  Tue Oct 16 09:50:16 2007
From: ucfasra at UCL.AC.UK (Srivatsan Raghavan)
Date: Tue, 16 Oct 2007 14:50:16 +0100
Subject: tcorr,scorr
Message-ID: <TUE.16.OCT.2007.145016.0100.>

I am using Grads1.9b4 and unable to run the inbuilt tcorr and scorr functions as
there is an error message saying , it is an 'unknown command'.  How can I fix
this error ?


Thanks


Srivatsan


From prodicalboxer at YAHOO.COM  Tue Oct 16 12:53:41 2007
From: prodicalboxer at YAHOO.COM (Daniel Fritz)
Date: Tue, 16 Oct 2007 09:53:41 -0700
Subject: GRIB conversion
In-Reply-To: <84AAE11B-4465-4598-84A7-1474DD6E7F93@cola.iges.org>
Message-ID: <TUE.16.OCT.2007.095341.0700.>

Hello All,
      I have coverted my grib file to ctl file, however there is one problem,  the index file is not generating......here is what I type and what was responded:

             grib2ctl.pl Y48659* > Y48659*.ctl      : (everything was fine until I type the next line)
             gribmap -i Y48659*.ctl -0
              Error in the grid specification for GRIB grid type 29/30
              Grid scaling must indicate 2 2.5 x 2.5 grid
              Grid size must be 144 x 73
              Grid must go from 0 to 357.5 and -90 to 90

  could someone help me with this if I can get the index file to generate Grads will do the rest......
                                              thanks
                                                 DANNY

Jennifer Adams <jma at COLA.IGES.ORG> wrote:
  I use this script instead of 'draw title'.


* title.gs
*
* This is an alternative to the 'draw title' command in GrADS.
* Font characteristics are controlled by five script variables:
* height, width, color, thickness, and font number.
* The sole argument is a string of any length which may
* contain backslashes ("\") to indicate carriage returns.
* Written by Jennifer M. Adams, January 2007
*
function title (arg)
* Set the text characteristics
height=0.20
width=0.18
color=1
thickness=1
fnum=0

* Check for backslashes
nbreaks=0
len=math_strlen(arg)
i=1
while (i<=len)
char=substr(arg,i,1)
if (char = '\')
nbreaks=nbreaks+1
break.nbreaks = i
endif
i=i+1
endwhile

* Figure out where the title will go
'q gxinfo'
xlims=sublin(result,3)
ylims=sublin(result,4)
ytop=subwrd(ylims,6)
xleft=subwrd(xlims,4)
xright=subwrd(xlims,6)
xmid=xleft+(xright-xleft)/2

* Set up the string characteristics
'set string 'color' bc 'thickness
'set strsiz 'width' 'height

* Draw the title
if (nbreaks)
arg.1 = substr(arg,1,break.1-1)
if (nbreaks=1)
arg.2 = substr(arg,break.1+1,len-break.1);* two lines
nargs=2
else
i=2
while (i<=nbreaks)
s=i-1
start = break.s
start = start+1
e=i
end = break.e
length = end-start
arg.i = substr(arg,start,length)
i=i+1
endwhile
start = break.nbreaks
start = start+1
length = len-start+1
nargs=nbreaks+1
arg.nargs = substr(arg,start,length)
endif

i=1
while (i<=nargs)
'draw string 'xmid' 'ytop+(height)+((nargs-i)*(1.5*height))'
`'fnum''arg.i
i=i+1
endwhile

else
'draw string 'xmid' 'ytop+height' `'fnum''arg
endif



---------------------------------
Moody friends. Drama queens. Your life? Nope! - their life, your story.
 Play Sims Stories at Yahoo! Games.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071016/ac695db7/attachment.html 

From ela at COLA.IGES.ORG  Tue Oct 16 13:00:20 2007
From: ela at COLA.IGES.ORG (Eric Altshuler)
Date: Tue, 16 Oct 2007 13:00:20 -0400
Subject: GRIB conversion
In-Reply-To: <814644.10205.qm@web62211.mail.re1.yahoo.com>
Message-ID: <TUE.16.OCT.2007.130020.0400.>

Danny,

Check your ctl file for the line 'dtype grib'. If there is a number after 'grib', get rid of it, then try running gribmap again.

Eric

----- Original Message -----
From: "Daniel Fritz" <prodicalboxer at YAHOO.COM>
To: GRADSUSR at LIST.CINECA.IT
Sent: Tuesday, October 16, 2007 12:53:41 PM (GMT-0500) America/New_York
Subject: GRIB conversion


Hello All,
? ? ?  I have coverted my grib file to ctl file, however there is one problem,?  the index file is not generating......here is what I type and what was responded:
? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ?  grib2ctl.pl Y48659* > Y48659*.ctl? ? ? ? ?  : (everything was fine until I type the next line)
? ? ? ? ? ? ? ? ? ?  gribmap -i Y48659*.ctl -0
? ? ? ? ? ? ? ? ? ? ?  Error in the grid specification for GRIB grid type 29/30
? ? ? ? ? ? ? ? ? ? ?  Grid scaling must indicate 2 2.5 x 2.5 grid
? ? ? ? ? ? ? ? ? ? ? ? Grid size must be 144 x 73
? ? ? ? ? ? ? ? ? ? ? ? Grid must go from 0 to 357.5 and -90 to 90
?
could someone help me with this if I can get the index file to generate Grads will do the rest......
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  thanks
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  DANNY? ? ? ?
?
Jennifer Adams < jma at COLA.IGES.ORG > wrote:

I use this script instead of 'draw title'.


* title.gs
*
* This is an alternative to the 'draw title' command in GrADS.
* Font characteristics are controlled by five script variables:
* height, width, color, thickness, and font number.
* The sole argument is a string of any length which may
* contain backslashes ("\") to indicate carriage returns.
* Written by Jennifer M. Adams, January 2007
*
function title (arg)
* Set the text characteristics
height=0.20
width=0.18
color=1
thickness=1
fnum=0

* Check for backslashes
nbreaks=0
len=math_strlen(arg)
i=1
while (i<=len)
char=substr(arg,i,1)
if (char = '\')
nbreaks=nbreaks+1
break.nbreaks = i
endif
i=i+1
endwhile

* Figure out where the title will go
'q gxinfo'
xlims=sublin(result,3)
ylims=sublin(result,4)
ytop=subwrd(ylims,6)
xleft=subwrd(xlims,4)
xright=subwrd(xlims,6)
xmid=xleft+(xright-xleft)/2

* Set up the string characteristics
'set string 'color' bc 'thickness
'set strsiz 'width' 'height

* Draw the title
if (nbreaks)
arg.1 = substr(arg,1,break.1-1)
if (nbreaks=1)
arg.2 = substr(arg,break.1+1,len-break.1);* two lines
nargs=2
else
i=2
while (i<=nbreaks)
s=i-1
start = break.s
start = start+1
e=i
end = break.e
length = end-start
arg.i = substr(arg,start,length)
i=i+1
endwhile
start = break.nbreaks
start = start+1
length = len-start+1
nargs=nbreaks+1
arg.nargs = substr(arg,start,length)
endif

i=1
while (i<=nargs)
'draw string 'xmid' 'ytop+(height)+((nargs-i)*(1.5*height))'
`'fnum''arg.i
i=i+1
endwhile

else
'draw string 'xmid' 'ytop+height' `'fnum''arg
endif




Moody friends. Drama queens. Your life? Nope! - their life, your story.
Play Sims Stories at Yahoo! Games.


From prodicalboxer at YAHOO.COM  Tue Oct 16 13:05:30 2007
From: prodicalboxer at YAHOO.COM (Daniel Fritz)
Date: Tue, 16 Oct 2007 10:05:30 -0700
Subject: GRIB conversion
In-Reply-To: <395263638.47701192554020499.JavaMail.root@mail.iges.org>
Message-ID: <TUE.16.OCT.2007.100530.0700.>

Hey ERIC,
     what do I do???   Do I go into the file and delete??? I do see that number....
                           DANNY

Eric Altshuler <ela at COLA.IGES.ORG> wrote:
  Danny,

Check your ctl file for the line 'dtype grib'. If there is a number after 'grib', get rid of it, then try running gribmap again.

Eric

----- Original Message -----
From: "Daniel Fritz"

To: GRADSUSR at LIST.CINECA.IT
Sent: Tuesday, October 16, 2007 12:53:41 PM (GMT-0500) America/New_York
Subject: GRIB conversion


Hello All,
? ? ? I have coverted my grib file to ctl file, however there is one problem,? the index file is not generating......here is what I type and what was responded:
? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? grib2ctl.pl Y48659* > Y48659*.ctl? ? ? ? ? : (everything was fine until I type the next line)
? ? ? ? ? ? ? ? ? ? gribmap -i Y48659*.ctl -0
? ? ? ? ? ? ? ? ? ? ? Error in the grid specification for GRIB grid type 29/30
? ? ? ? ? ? ? ? ? ? ? Grid scaling must indicate 2 2.5 x 2.5 grid
? ? ? ? ? ? ? ? ? ? ? ? Grid size must be 144 x 73
? ? ? ? ? ? ? ? ? ? ? ? Grid must go from 0 to 357.5 and -90 to 90
?
could someone help me with this if I can get the index file to generate Grads will do the rest......
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? thanks
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? DANNY? ? ? ?
?
Jennifer Adams < jma at COLA.IGES.ORG > wrote:

I use this script instead of 'draw title'.


* title.gs
*
* This is an alternative to the 'draw title' command in GrADS.
* Font characteristics are controlled by five script variables:
* height, width, color, thickness, and font number.
* The sole argument is a string of any length which may
* contain backslashes ("\") to indicate carriage returns.
* Written by Jennifer M. Adams, January 2007
*
function title (arg)
* Set the text characteristics
height=0.20
width=0.18
color=1
thickness=1
fnum=0

* Check for backslashes
nbreaks=0
len=math_strlen(arg)
i=1
while (i<=len)
char=substr(arg,i,1)
if (char = '\')
nbreaks=nbreaks+1
break.nbreaks = i
endif
i=i+1
endwhile

* Figure out where the title will go
'q gxinfo'
xlims=sublin(result,3)
ylims=sublin(result,4)
ytop=subwrd(ylims,6)
xleft=subwrd(xlims,4)
xright=subwrd(xlims,6)
xmid=xleft+(xright-xleft)/2

* Set up the string characteristics
'set string 'color' bc 'thickness
'set strsiz 'width' 'height

* Draw the title
if (nbreaks)
arg.1 = substr(arg,1,break.1-1)
if (nbreaks=1)
arg.2 = substr(arg,break.1+1,len-break.1);* two lines
nargs=2
else
i=2
while (i<=nbreaks)
s=i-1
start = break.s
start = start+1
e=i
end = break.e
length = end-start
arg.i = substr(arg,start,length)
i=i+1
endwhile
start = break.nbreaks
start = start+1
length = len-start+1
nargs=nbreaks+1
arg.nargs = substr(arg,start,length)
endif

i=1
while (i<=nargs)
'draw string 'xmid' 'ytop+(height)+((nargs-i)*(1.5*height))'
`'fnum''arg.i
i=i+1
endwhile

else
'draw string 'xmid' 'ytop+height' `'fnum''arg
endif




Moody friends. Drama queens. Your life? Nope! - their life, your story.
Play Sims Stories at Yahoo! Games.



---------------------------------
Tonight's top picks. What will you watch tonight? Preview the hottest shows on Yahoo! TV.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071016/4ed8640d/attachment.html 

From ela at COLA.IGES.ORG  Tue Oct 16 13:11:04 2007
From: ela at COLA.IGES.ORG (Eric Altshuler)
Date: Tue, 16 Oct 2007 13:11:04 -0400
Subject: GRIB conversion
In-Reply-To: <35152.99576.qm@web62209.mail.re1.yahoo.com>
Message-ID: <TUE.16.OCT.2007.131104.0400.>

Danny,

Use 'vi' or some other editor and delete the number at the end of the line. The line should just be:

dtype grib

If there is a number after 'grib', and the grid dimensions are inconsistent with that particular grib type identifier, gribmap and grads may have problems. It is better in most cases not to have any number in the 'dtype grib' line.

Eric

----- Original Message -----
From: "Daniel Fritz" <prodicalboxer at YAHOO.COM>
To: GRADSUSR at LIST.CINECA.IT
Sent: Tuesday, October 16, 2007 1:05:30 PM (GMT-0500) America/New_York
Subject: Re: GRIB conversion


Hey ERIC,
? ?  what do I do???? ?  Do I go into the file and delete??? I do see that number....
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  DANNY

Eric Altshuler < ela at COLA.IGES.ORG > wrote:

Danny,

Check your ctl file for the line 'dtype grib'. If there is a number after 'grib', get rid of it, then try running gribmap again.

Eric

----- Original Message -----
From: "Daniel Fritz"
To: GRADSUSR at LIST.CINECA.IT
Sent: Tuesday, October 16, 2007 12:53:41 PM (GMT-0500) America/New_York
Subject: GRIB conversion


Hello All,
?? ?? ?? I have coverted my grib file to ctl file, however there is one problem,?? the index file is not generating......here is what I type and what was responded:
?? ?? ?? ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? grib2ctl.pl Y48659* > Y48659*.ctl?? ?? ?? ?? ?? : (everything was fine until I type the next line)
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? gribmap -i Y48659*.ctl -0
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? Error in the grid specification for GRIB grid type 29/30
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? Grid scaling must indicate 2 2.5 x 2.5 grid
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? Grid size must be 144 x 73
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? Grid must go from 0 to 357.5 and -90 to 90
??
could someone help me with this if I can get the index file to generate Grads will do the rest......
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? thanks
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? DANNY?? ?? ?? ??
??
Jennifer Adams < jma at COLA.IGES.ORG > wrote:

I use this script instead of 'draw title'.


* title.gs
*
* This is an alternative to the 'draw title' command in GrADS.
* Font characteristics are controlled by five script variables:
* height, width, color, thickness, and font number.
* The sole argument is a string of any length which may
* contain backslashes ("\") to indicate carriage returns.
* Written by Jennifer M. Adams, January 2007
*
function title (arg)
* Set the text characteristics
height=0.20
width=0.18
color=1
thickness=1
fnum=0

* Check for backslashes
nbreaks=0
len=math_strlen(arg)
i=1
while (i<=len)
char=substr(arg,i,1)
if (char = '\')
nbreaks=nbreaks+1
break.nbreaks = i
endif
i=i+1
endwhile

* Figure out where the title will go
'q gxinfo'
xlims=sublin(result,3)
ylims=sublin(result,4)
ytop=subwrd(ylims,6)
xleft=subwrd(xlims,4)
xright=subwrd(xlims,6)
xmid=xleft+(xright-xleft)/2

* Set up the string characteristics
'set string 'color' bc 'thickness
'set strsiz 'width' 'height

* Draw the title
if (nbreaks)
arg.1 = substr(arg,1,break.1-1)
if (nbreaks=1)
arg.2 = substr(arg,break.1+1,len-break.1);* two lines
nargs=2
else
i=2
while (i<=nbreaks)
s=i-1
start = break.s
start = start+1
e=i
end = break.e
length = end-start
arg.i = substr(arg,start,length)
i=i+1
endwhile
start = break.nbreaks
start = start+1
length = len-start+1
nargs=nbreaks+1
arg.nargs = substr(arg,start,length)
endif

i=1
while (i<=nargs)
'draw string 'xmid' 'ytop+(height)+((nargs-i)*(1.5*height))'
`'fnum''arg.i
i=i+1
endwhile

else
'draw string 'xmid' 'ytop+height' `'fnum''arg
endif




Moody friends. Drama queens. Your life? Nope! - their life, your story.
Play Sims Stories at Yahoo! Games.




Tonight's top picks. What will you watch tonight? Preview the hottest shows on Yahoo! TV.


From chenhuopo at 163.COM  Tue Oct 16 20:45:20 2007
From: chenhuopo at 163.COM (Huopo Chen)
Date: Wed, 17 Oct 2007 08:45:20 +0800
Subject: GRIB conversion
Message-ID: <WED.17.OCT.2007.084520.0800.>

I have the same problem as you before,but when I input the following code the problem disappeared.
You can try it.  
 gribmap -e -i Y48659*.ctl


2007-10-17 



Huopo Chen 



???? Daniel Fritz 
????? 2007-10-17  00:54:05 
???? GRADSUSR at LIST.CINECA.IT 
??? 
??? GRIB conversion 
 
Hello All,
    I have coverted my grib file to ctl file, however there is one problem,  the index file is not generating......here is what I type and what was responded:
       
           grib2ctl.pl Y48659* > Y48659*.ctl      : (everything was fine until I type the next line)
           gribmap -i Y48659*.ctl -0
            Error in the grid specification for GRIB grid type 29/30
            Grid scaling must indicate 2 2.5 x 2.5 grid
            Grid size must be 144 x 73
            Grid must go from 0 to 357.5 and -90 to 90

could someone help me with this if I can get the index file to generate Grads will do the rest......
                                            thanks 
                                               DANNY    
 
Jennifer Adams <jma at COLA.IGES.ORG> wrote:
I use this script instead of 'draw title'.


* title.gs
*
* This is an alternative to the 'draw title' command in GrADS.
* Font characteristics are controlled by five script variables:
* height, width, color, thickness, and font number.
* The sole argument is a string of any length which may
* contain backslashes ("\") to indicate carriage returns.
* Written by Jennifer M. Adams, January 2007
*
function title (arg)
* Set the text characteristics
height=0.20
width=0.18
color=1
thickness=1
fnum=0

* Check for backslashes
nbreaks=0
len=math_strlen(arg)
i=1
while (i<=len)
char=substr(arg,i,1)
if (char = '\')
nbreaks=nbreaks+1
break.nbreaks = i
endif
i=i+1
endwhile

* Figure out where the title will go
'q gxinfo'
xlims=sublin(result,3)
ylims=sublin(result,4)
ytop=subwrd(ylims,6)
xleft=subwrd(xlims,4)
xright=subwrd(xlims,6)
xmid=xleft+(xright-xleft)/2

* Set up the string characteristics
'set string 'color' bc 'thickness
'set strsiz 'width' 'height

* Draw the title
if (nbreaks)
arg.1 = substr(arg,1,break.1-1)
if (nbreaks=1)
arg.2 = substr(arg,break.1+1,len-break.1);* two lines
nargs=2
else
i=2
while (i<=nbreaks)
s=i-1
start = break.s
start = start+1
e=i
end = break.e
length = end-start
arg.i = substr(arg,start,length)
i=i+1
endwhile
start = break.nbreaks
start = start+1
length = len-start+1
nargs=nbreaks+1
arg.nargs = substr(arg,start,length)
endif

i=1
while (i<=nargs)
'draw string 'xmid' 'ytop+(height)+((nargs-i)*(1.5*height))'
`'fnum''arg.i
i=i+1
endwhile

else
'draw string 'xmid' 'ytop+height' `'fnum''arg
endif





Moody friends. Drama queens. Your life? Nope! - their life, your story.
Play Sims Stories at Yahoo! Games. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071017/084d4cc7/attachment.html 

From alexander.beck-ratzka at AEI.MPG.DE  Wed Oct 17 03:36:15 2007
From: alexander.beck-ratzka at AEI.MPG.DE (Alexander Beck-Ratzka)
Date: Wed, 17 Oct 2007 09:36:15 +0200
Subject: Is there a GRADS version for Linux 64bit available?
Message-ID: <WED.17.OCT.2007.093615.0200.>

Hello list,

I like to use GRADS on the Headnode of our cluster, kernel  2.6.16.49, and
x86_64 bit processors. The grads binaries which can be downloaded run on a
segmentation fault. I assume that is due to the fact that they were build on
a 32 bit machine.

I  would like to know whether one of you has already used GRADS on Linux
x86_64, and what is necessary for that.

Cheers

Alexander


From joy0826 at PUSAN.AC.KR  Wed Oct 17 04:53:40 2007
From: joy0826 at PUSAN.AC.KR (Ji-Yun SEO)
Date: Wed, 17 Oct 2007 10:53:40 +0200
Subject: MM5toGRIB with GRIBEX
Message-ID: <WED.17.OCT.2007.105340.0200.>

Hi~

I've been trying to encoding binary file of MM5 output to grib file with
GRIBEX
Has anyone of grads user been done??? Please HELP me !!!

When I typed "uname -a " Linux * ia64 *" appeared.
I also use intel fortran compiler instead of pgf fotran

so i changed config.linuxA64
-----------------------------------------
# Configuration file for linux (32-bit reals).
#
AR = ar
ARFLAGS = rv
LARGE_FILE = -Dlinux -DFOPEN64
DEBUG=
CC = gcc
CFLAGS = $(DEBUG) -g -DLITTLE_ENDIAN -DINTEGER_IS_INT $(LOCAL_CFLAGS)
$(LARGE_FILE) -DTABLE_PATH=\"/user1/joy/util/lib\"
FASTCFLAGS = $(CFLAGS)
FC = ifort
FFLAGS = $(DEBUG) -i4 -r8 -Dlinux -DLITTLE_ENDIAN -DINTEGER_IS_INT -
DTABLE_PATH=\"/user1/joy/util/lib\"
VECTFFLAGS = $(FFLAGS)
# |
# v
# 32-bit reals
#
RANLIB = /usr/bin/ranlib
======================================================================
I've got libgribex.a .
After ./install I tried to ./test.sh in example directory.
However, this error message occured
"forrtl: severe(174):SIGSEGV, segmentation fault occurred"

Please let me know what I have to do.
I would be grateful if you give me the answer ASAP
Have a nice day~


From pertusus at FREE.FR  Wed Oct 17 04:17:12 2007
From: pertusus at FREE.FR (Patrice Dumas)
Date: Wed, 17 Oct 2007 10:17:12 +0200
Subject: Is there a GRADS version for Linux 64bit available?
In-Reply-To: <200710170936.15716.alexander.beck-ratzka@aei.mpg.de>
Message-ID: <WED.17.OCT.2007.101712.0200.>

On Wed, Oct 17, 2007 at 09:36:15AM +0200, Alexander Beck-Ratzka wrote:
> Hello list,
>
> I like to use GRADS on the Headnode of our cluster, kernel  2.6.16.49, and
> x86_64 bit processors. The grads binaries which can be downloaded run on a
> segmentation fault. I assume that is due to the fact that they were build on
> a 32 bit machine.
>
> I  would like to know whether one of you has already used GRADS on Linux
> x86_64, and what is necessary for that.

Didn't used it, but there are packages for grads on fedora, including
for 64 bit architectures. The non free parts have been removed. I
remember vaguely a post on the mailing list by somebody saying that
there was some 64 bit issues, but so far I haven't seen a patch. Maybe
this is fixed in opengrads, but it is not sure at all.

--
Pat


From zenica3 at GMAIL.COM  Wed Oct 17 05:33:07 2007
From: zenica3 at GMAIL.COM (ibrahim Hadzismailovic)
Date: Wed, 17 Oct 2007 11:33:07 +0200
Subject: MM5toGRIB with GRIBEX
In-Reply-To: <20071017085402.07F20207BA@mx2.cineca.it>
Message-ID: <WED.17.OCT.2007.113307.0200.>

Hi,

You can use INTERPB program to convert MM5 outputs to pressure level and
then use program MM5toGRIB. Take a look on this page
http://redibericamm5.uib.es/algoritmos.htm.

Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071017/111cdfb1/attachment.html 

From massimo.aceti at METEOGIORNALE.IT  Wed Oct 17 15:38:34 2007
From: massimo.aceti at METEOGIORNALE.IT (Massimo Aceti @ mtg)
Date: Wed, 17 Oct 2007 21:38:34 +0200
Subject: problems with gens and apcpsfc field
In-Reply-To: <20071017081711.GA2719@free.fr>
Message-ID: <WED.17.OCT.2007.213834.0200.>

Hello all,

I've got some problems with gens low resolution files

Using get_grib.pl & get_inv.pl utilities I download only some fields
from all grib2 files of this dataset
http://140.90.33.30/data/nccf/com/gens/prod/gefs.$date/$run/pgrb2alr/

I convert grib2 files in grib1 format with cnvgrib using -g21 option

then I create ctl files using template option

So I obtain 21 ctl files like this

dset /home/prova/ensemble/00/gep01.%f2.grb
index /home/prova/ensemble/00/gep01.00.grb.idx
undef 9.999E+20
title /home/prova/ensemble/00/gep01.00.grb
*  produced by grib2ctl v0.9.12.5p39a
dtype grib 2
options template
options yrev
ydef 73 linear -90.000000 2.5
xdef 144 linear 0.000000 2.500000
tdef 65 linear 00Z17oct2007 6hr
*  z has 2 levels, for prs
zdef 2 levels
850 500
vars 4
APCPsfc  0 61,1,0  ** surface Total precipitation [kg/m^2]
HGTprs 2 7,100,0 ** (profile) Geopotential height [gpm]
PRMSLmsl  0 2,102,0  ** unknown level Pressure reduced to MSL [Pa]
TMPprs 2 11,100,0 ** (profile) Temp. [K]
ENDVARS


The probem is that after 258 hours step, grads don't display the apcpsfc
field, the message is "Cannot contour grid - all undefined values"

I try also to concatenate grib2 files with cat, then convert with
cnvgrib the 21 resulting files and then create ctl files without option
template

But there is ever the same problem with apcpsfc field

using wgrib I saw that up to 252 hours step the TimeU of apcp field is
set to 1 (TimeU=1) and after to 11 (TimeU=11). Is the only difference I saw

Maybe the problem is in cnvgrib. There's a problem with precipitation
field also in a single file after the 354 hours step.

I use grads 1.94 under unix machine (distro linux debian)

anyone has an idea to solve the problem?

Thanks

Massy


From theedge981 at GMAIL.COM  Wed Oct 17 15:46:16 2007
From: theedge981 at GMAIL.COM (Dan Leins)
Date: Wed, 17 Oct 2007 15:46:16 -0400
Subject: if/or statement in GrADS script
Message-ID: <WED.17.OCT.2007.154616.0400.>

All,

I'm working on a GrADS script in which I will pass a forecast hour as an
argument. I have a small section of the script that I would only like to
execute when I pass forecast hours 12,24,or 36. So far I've constructed the
statement to read as follows:

if (subwrd(hh,1)='12')
blah blah blah
endif

This is all fine and good, but I'd like to re-use this same section of code
when I pass 24 or 36 as an argument. I was wondering if the if/or
functionality existed in GrADS?  I was thinking something along the lines of


if (subwrd(hh,1)='12') || if (subwrd(hh,1)='24') || if (subwrd(hh,1)='36')

but that didn't work. I really don't want to copy and paste the code
elsewhere in the script as it's a pretty lengthy section.

Is there any way I can accomplish this?

Thanks!
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071017/bfaf79b4/attachment.html 

From ela at COLA.IGES.ORG  Wed Oct 17 15:55:17 2007
From: ela at COLA.IGES.ORG (Eric Altshuler)
Date: Wed, 17 Oct 2007 15:55:17 -0400
Subject: if/or statement in GrADS script
In-Reply-To: <46e821750710171246k25651bf0q4ad0a72830a05011@mail.gmail.com>
Message-ID: <WED.17.OCT.2007.155517.0400.>

Dan,

This should work:

if (subwrd(hh,1)='12' | subwrd(hh,1)='24' | subwrd(hh,1)='36')
...
...
endif

Put the "or" (|) constructs inside the "if" statement. You can do this with "and" (&) also.

Best regards,


Eric L. Altshuler
Assistant Research Scientist
Center for Ocean-Land-Atmosphere Studies
4041 Powder Mill Road, Suite 302
Calverton, MD 20705-3106
USA

E-mail: ela at cola.iges.org
Phone: (301) 902-1257
Fax: (301) 595-9793

----- Original Message -----
From: "Dan Leins" <theedge981 at GMAIL.COM>
To: GRADSUSR at LIST.CINECA.IT
Sent: Wednesday, October 17, 2007 3:46:16 PM (GMT-0500) America/New_York
Subject: if/or statement in GrADS script

All,

I'm working on a GrADS script in which I will pass a forecast hour as an argument. I have a small section of the script that I would only like to execute when I pass forecast hours 12,24,or 36. So far I've constructed the statement to read as follows:

if (subwrd(hh,1)='12')
blah blah blah
endif

This is all fine and good, but I'd like to re-use this same section of code when I pass 24 or 36 as an argument. I was wondering if the if/or functionality existed in GrADS??  I was thinking something along the lines of

if (subwrd(hh,1)='12') || if (subwrd(hh,1)='24') || if (subwrd(hh,1)='36')

but that didn't work. I really don't want to copy and paste the code elsewhere in the script as it's a pretty lengthy section.

Is there any way I can accomplish this?

Thanks!
Dan


From mmacleod at SCOTIAWEATHER.COM  Thu Oct 18 10:25:59 2007
From: mmacleod at SCOTIAWEATHER.COM (mmacleod)
Date: Thu, 18 Oct 2007 15:25:59 +0100
Subject: Problem with use of cbarn and user defined functions
Message-ID: <THU.18.OCT.2007.152559.0100.>

Good morning All.

I have a recurring problem with both GrADS version 1.8.11 on Windows XP
and on 1.9.4b on Red Hat E4.1 Linux version.

When I plot a 2-D map and use the cbarn.gs or the user function hilo the
draw instructions seems to loose the x position on the page and shifts
even line to the left margin.  See attached maps
"NAM_NovaS_LowLvlMoistConv-WindsH03-Cor.png" which contains the plot
without cbarn being executed within the script script section below:

------ Script lines ----------
'set font 0'
'set strsiz 0.20 0.20'
'draw string 3.5 8.20 Scotia Weather Services Inc'
'set strsiz 0.12 0.12'
'draw string 0.35 7.95 NWS NAM Model 0-30 mb Horizontal Moisture
Divergence and 0-30 mb AGL WInd Direction and Speed'
'set strsiz 0.15 0.15'
'set strsiz 0.12 0.12'


if(xx > 9)

*  This inserts the valid model output date and time for the current time
   'draw string 2.5 0.15 ' xx ' Hr Prog valid at ' time1 ' - ' time3 ' -
' time2 ' - ' time4
   'set strsiz 0.1 0.1'
   'draw string 1.95 0.5 ___ 0-30 mb Horizontal Moisture Divergence (E
-06 kg/kg/s) amd 0-30 mb wind barbs  '

*  This displays the valid date and time of the model run so one does
not get confused when several model runs are available.

   'set strsiz 0.09 0.09'
     'draw string 0.25 0.40 Model run from '
   'draw string 0.25 0.25 ' timea '-' timeb '-' timec '-' timed ' '
   'draw rec .20 .20 1.75 0.55 '

 'set gxout contour'
'cbarn 1 0 6.0 0.75 '


 'printim ' fileset  xx '.png x1000 y800 '

else


*  This inserts the valid model output date and time for the current time
   'draw string 2.5 0.15 0' xx ' Hr Prog valid at ' time1 ' - ' time3 '
- ' time2 ' - ' time4
   'set strsiz 0.1 0.1'
    'draw string 1.95 0.4 ___ 0-30 mb Horizontal Moisture Divergence (E
-06 kg/kg/s) amd 0-30 mb wind barbs  '

*  This displays the valid date and time of the model run so one does
not get confused when several model runs are available.

   'set strsiz 0.09 0.09'
   'draw string 0.25 0.40 Model run from '
   'draw string 0.25 0.25 ' timea '-' timeb '-' timec '-' timed ' '
   'draw rec .20 .20 1.75 0.55 '
 'set gxout contour'
'cbarn 1 0 6.0 0.65 '

'printim ' fileset '0' xx '.png x1000 y800 '
endif

----- End of Script Lines ------

Once cbarn is run and until I reinitialize GrADS, all script runs will
then move the draw lines tight to the left margin as shown in the
attached map "NAM_NovaS_LowLvlMoistConv-WindsH03.png"

Even if I run a scrip that does not have the "run cbarn  " line in it,
the draw statements place the margins tight to the left margin.

The same thing occurs with the use of the hilo user function for the
placement of high and low centres on the  MSL maps.

It appears to be a memory location has a setting changed by cbarn or
hilo that then overrides the x  setting  of draw.

You help to correct this problem is  much appreciated.

Sincerely

Mac MacLeod

--
M.A. (Mac) MacLeod
President and General Manager
Scotia Weather Services Inc
192 Wyse Road, Suite 8,
Dartmouth, N.S. B3A 1M9

Tele: 902-468-3866
Fax:  902-461-1768
E-mail: mmacleod at scotiaweather.com
Visit us: www.scotiaweather.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: NAM_NovaS_LowLvlMoistConv-WindsH03-Cor.png
Type: image/png
Size: 21059 bytes
Desc: not available
Url : http://gradsusr.org/pipermail/gradsusr/attachments/20071018/690648e8/attachment.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NAM_NovaS_LowLvlMoistConv-WindsH03.png
Type: image/png
Size: 22087 bytes
Desc: not available
Url : http://gradsusr.org/pipermail/gradsusr/attachments/20071018/690648e8/attachment-0001.png 

From theedge981 at GMAIL.COM  Thu Oct 18 10:44:35 2007
From: theedge981 at GMAIL.COM (Dan Leins)
Date: Thu, 18 Oct 2007 10:44:35 -0400
Subject: Problem with use of cbarn and user defined functions
In-Reply-To: <47176CF7.7020703@scotiaweather.com>
Message-ID: <THU.18.OCT.2007.104435.0400.>

Mac,

I think the proper syntax in the script would be something along the lines
of

'run cbarn 1 0 6.0 0.65 '

I don't know if it makes a difference, but is the cbarn skip called "cbarn"
or "cbarn.gs"? If it's called cbarn.gs, then you'll likely need to include
the ".gs" when you call the script.

HTH,
Dan

On 10/18/07, mmacleod <mmacleod at scotiaweather.com> wrote:
>
> Good morning All.
>
> I have a recurring problem with both GrADS version 1.8.11 on Windows XP
> and on 1.9.4b on Red Hat E4.1 Linux version.
>
> When I plot a 2-D map and use the cbarn.gs or the user function hilo the
> draw instructions seems to loose the x position on the page and shifts
> even line to the left margin.  See attached maps
> "NAM_NovaS_LowLvlMoistConv-WindsH03-Cor.png" which contains the plot
> without cbarn being executed within the script script section below:
>
> ------ Script lines ----------
> 'set font 0'
> 'set strsiz 0.20 0.20'
> 'draw string 3.5 8.20 Scotia Weather Services Inc'
> 'set strsiz 0.12 0.12'
> 'draw string 0.35 7.95 NWS NAM Model 0-30 mb Horizontal Moisture
> Divergence and 0-30 mb AGL WInd Direction and Speed'
> 'set strsiz 0.15 0.15'
> 'set strsiz 0.12 0.12'
>
>
> if(xx > 9)
>
> *  This inserts the valid model output date and time for the current time
>   'draw string 2.5 0.15 ' xx ' Hr Prog valid at ' time1 ' - ' time3 ' -
> ' time2 ' - ' time4
>   'set strsiz 0.1 0.1'
>   'draw string 1.95 0.5 ___ 0-30 mb Horizontal Moisture Divergence (E
> -06 kg/kg/s) amd 0-30 mb wind barbs  '
>
> *  This displays the valid date and time of the model run so one does
> not get confused when several model runs are available.
>
>   'set strsiz 0.09 0.09'
>     'draw string 0.25 0.40 Model run from '
>   'draw string 0.25 0.25 ' timea '-' timeb '-' timec '-' timed ' '
>   'draw rec .20 .20 1.75 0.55 '
>
> 'set gxout contour'
> 'cbarn 1 0 6.0 0.75 '
>
>
> 'printim ' fileset  xx '.png x1000 y800 '
>
> else
>
>
> *  This inserts the valid model output date and time for the current time
>   'draw string 2.5 0.15 0' xx ' Hr Prog valid at ' time1 ' - ' time3 '
> - ' time2 ' - ' time4
>   'set strsiz 0.1 0.1'
>    'draw string 1.95 0.4 ___ 0-30 mb Horizontal Moisture Divergence (E
> -06 kg/kg/s) amd 0-30 mb wind barbs  '
>
> *  This displays the valid date and time of the model run so one does
> not get confused when several model runs are available.
>
>   'set strsiz 0.09 0.09'
>   'draw string 0.25 0.40 Model run from '
>   'draw string 0.25 0.25 ' timea '-' timeb '-' timec '-' timed ' '
>   'draw rec .20 .20 1.75 0.55 '
> 'set gxout contour'
> 'cbarn 1 0 6.0 0.65 '
>
> 'printim ' fileset '0' xx '.png x1000 y800 '
> endif
>
> ----- End of Script Lines ------
>
> Once cbarn is run and until I reinitialize GrADS, all script runs will
> then move the draw lines tight to the left margin as shown in the
> attached map "NAM_NovaS_LowLvlMoistConv-WindsH03.png"
>
> Even if I run a scrip that does not have the "run cbarn  " line in it,
> the draw statements place the margins tight to the left margin.
>
> The same thing occurs with the use of the hilo user function for the
> placement of high and low centres on the  MSL maps.
>
> It appears to be a memory location has a setting changed by cbarn or
> hilo that then overrides the x  setting  of draw.
>
> You help to correct this problem is  much appreciated.
>
> Sincerely
>
> Mac MacLeod
>
> --
> M.A. (Mac) MacLeod
> President and General Manager
> Scotia Weather Services Inc
> 192 Wyse Road, Suite 8,
> Dartmouth, N.S. B3A 1M9
>
> Tele: 902-468-3866
> Fax:  902-461-1768
> E-mail: mmacleod at scotiaweather.com
> Visit us: www.scotiaweather.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071018/8990ba34/attachment.html 

From mmacleod at SCOTIAWEATHER.COM  Thu Oct 18 11:14:18 2007
From: mmacleod at SCOTIAWEATHER.COM (mmacleod)
Date: Thu, 18 Oct 2007 16:14:18 +0100
Subject: Problem with use of cbarn and user defined functions
In-Reply-To: <46e821750710180744t7c24faf1t5f3be21097d67777@mail.gmail.com>
Message-ID: <THU.18.OCT.2007.161418.0100.>

Hi Dan.

I tried 'run cbarn.gs 1 0 6.0 0.65'

It made no difference  - the draw still shifted tot he left margin.

Thanks


Mac


Dan Leins wrote:
> Mac,
>
> I think the proper syntax in the script would be something along the lines
> of
>
> 'run cbarn 1 0 6.0 0.65 '
>
> I don't know if it makes a difference, but is the cbarn skip called "cbarn"
> or "cbarn.gs"? If it's called cbarn.gs, then you'll likely need to include
> the ".gs" when you call the script.
>
> HTH,
> Dan
>
> On 10/18/07, mmacleod <mmacleod at scotiaweather.com> wrote:
>
>> Good morning All.
>>
>> I have a recurring problem with both GrADS version 1.8.11 on Windows XP
>> and on 1.9.4b on Red Hat E4.1 Linux version.
>>
>> When I plot a 2-D map and use the cbarn.gs or the user function hilo the
>> draw instructions seems to loose the x position on the page and shifts
>> even line to the left margin.  See attached maps
>> "NAM_NovaS_LowLvlMoistConv-WindsH03-Cor.png" which contains the plot
>> without cbarn being executed within the script script section below:
>>
>> ------ Script lines ----------
>> 'set font 0'
>> 'set strsiz 0.20 0.20'
>> 'draw string 3.5 8.20 Scotia Weather Services Inc'
>> 'set strsiz 0.12 0.12'
>> 'draw string 0.35 7.95 NWS NAM Model 0-30 mb Horizontal Moisture
>> Divergence and 0-30 mb AGL WInd Direction and Speed'
>> 'set strsiz 0.15 0.15'
>> 'set strsiz 0.12 0.12'
>>
>>
>> if(xx > 9)
>>
>> *  This inserts the valid model output date and time for the current time
>>   'draw string 2.5 0.15 ' xx ' Hr Prog valid at ' time1 ' - ' time3 ' -
>> ' time2 ' - ' time4
>>   'set strsiz 0.1 0.1'
>>   'draw string 1.95 0.5 ___ 0-30 mb Horizontal Moisture Divergence (E
>> -06 kg/kg/s) amd 0-30 mb wind barbs  '
>>
>> *  This displays the valid date and time of the model run so one does
>> not get confused when several model runs are available.
>>
>>   'set strsiz 0.09 0.09'
>>     'draw string 0.25 0.40 Model run from '
>>   'draw string 0.25 0.25 ' timea '-' timeb '-' timec '-' timed ' '
>>   'draw rec .20 .20 1.75 0.55 '
>>
>> 'set gxout contour'
>> 'cbarn 1 0 6.0 0.75 '
>>
>>
>> 'printim ' fileset  xx '.png x1000 y800 '
>>
>> else
>>
>>
>> *  This inserts the valid model output date and time for the current time
>>   'draw string 2.5 0.15 0' xx ' Hr Prog valid at ' time1 ' - ' time3 '
>> - ' time2 ' - ' time4
>>   'set strsiz 0.1 0.1'
>>    'draw string 1.95 0.4 ___ 0-30 mb Horizontal Moisture Divergence (E
>> -06 kg/kg/s) amd 0-30 mb wind barbs  '
>>
>> *  This displays the valid date and time of the model run so one does
>> not get confused when several model runs are available.
>>
>>   'set strsiz 0.09 0.09'
>>   'draw string 0.25 0.40 Model run from '
>>   'draw string 0.25 0.25 ' timea '-' timeb '-' timec '-' timed ' '
>>   'draw rec .20 .20 1.75 0.55 '
>> 'set gxout contour'
>> 'cbarn 1 0 6.0 0.65 '
>>
>> 'printim ' fileset '0' xx '.png x1000 y800 '
>> endif
>>
>> ----- End of Script Lines ------
>>
>> Once cbarn is run and until I reinitialize GrADS, all script runs will
>> then move the draw lines tight to the left margin as shown in the
>> attached map "NAM_NovaS_LowLvlMoistConv-WindsH03.png"
>>
>> Even if I run a scrip that does not have the "run cbarn  " line in it,
>> the draw statements place the margins tight to the left margin.
>>
>> The same thing occurs with the use of the hilo user function for the
>> placement of high and low centres on the  MSL maps.
>>
>> It appears to be a memory location has a setting changed by cbarn or
>> hilo that then overrides the x  setting  of draw.
>>
>> You help to correct this problem is  much appreciated.
>>
>> Sincerely
>>
>> Mac MacLeod
>>
>> --
>> M.A. (Mac) MacLeod
>> President and General Manager
>> Scotia Weather Services Inc
>> 192 Wyse Road, Suite 8,
>> Dartmouth, N.S. B3A 1M9
>>
>> Tele: 902-468-3866
>> Fax:  902-461-1768
>> E-mail: mmacleod at scotiaweather.com
>> Visit us: www.scotiaweather.com
>>
>>
>>
>>
>
>

--
M.A. (Mac) MacLeod
President and General Manager
Scotia Weather Services Inc
192 Wyse Road, Suite 8,
Dartmouth, N.S. B3A 1M9

Tele: 902-468-3866
Fax:  902-461-1768
E-mail: mmacleod at scotiaweather.com
Visit us: www.scotiaweather.com


From giuliani at LAMMA.RETE.TOSCANA.IT  Thu Oct 18 12:25:48 2007
From: giuliani at LAMMA.RETE.TOSCANA.IT (Graziano Giuliani)
Date: Thu, 18 Oct 2007 18:25:48 +0200
Subject: Is there a GRADS version for Linux 64bit available?
Message-ID: <THU.18.OCT.2007.182548.0200.>

Yes, in Archlinux. See
http://aur.archlinux.org/packages.php?do_Details=1&ID=7868

There is a "huge" patch to use all features and new dap++ interface. Also in
SDF the Netcdf-3 API is used, no supplibs (most shared), an "idea" on how to
use shapefiles linking shapelib.

Works (patching) at least on Debian 4 64 bit, fedora 7 64 bit, Ubuntu 7.04
64 bit and (of course) Arch.

Graziano.


From pertusus at FREE.FR  Thu Oct 18 13:18:39 2007
From: pertusus at FREE.FR (Patrice Dumas)
Date: Thu, 18 Oct 2007 19:18:39 +0200
Subject: Is there a GRADS version for Linux 64bit available?
In-Reply-To: <20071018162610.8B3F9207A7@mx2.cineca.it>
Message-ID: <THU.18.OCT.2007.191839.0200.>

On Thu, Oct 18, 2007 at 06:25:48PM +0200, Graziano Giuliani wrote:
> Yes, in Archlinux. See
> http://aur.archlinux.org/packages.php?do_Details=1&ID=7868
>
> There is a "huge" patch to use all features and new dap++ interface. Also in
> SDF the Netcdf-3 API is used, no supplibs (most shared), an "idea" on how to
> use shapefiles linking shapelib.

Your patch (maybe modified a bit) is included in opengrads, except for
the shapelib part. If it is ready for consumption, maybe you could
rebase it against the latest opengrads source at http://opengrads.org/,
and have Arlindo and people at Cola review it?

--
Pat


From pertusus at FREE.FR  Thu Oct 18 13:04:55 2007
From: pertusus at FREE.FR (Patrice Dumas)
Date: Thu, 18 Oct 2007 19:04:55 +0200
Subject: Patch request for datatype conversion in SDF code
In-Reply-To: <465F20AF.9010509@noaa.gov>
Message-ID: <THU.18.OCT.2007.190455.0200.>

On Thu, May 31, 2007 at 03:23:27PM -0400, Remik.Ziemlinski wrote:
>
> This error came up when processing the time axis of a netcdf file that
> was declared with "int".  Most often, time axes are of "double" type, so
> this casting bug was overlooked in the past.  Also, IRIX seems a bit
> more robust when casting between these types, even though they too are 4
> and 8 bytes like with IA64.  Thanks.

Does the Attached patch solve your issue?

--
Pat
-------------- next part --------------
diff -Naur grads-1.9b4/src/gacfg.c grads-1.9b4_new/src/gacfg.c
--- grads-1.9b4/src/gacfg.c   2005-05-18 14:29:17.000000000 +0000
+++ grads-1.9b4_new/src/gacfg.c 2005-11-03 13:18:45.000000000 +0000
@@ -32,6 +32,7 @@
  */

 #include <stdio.h>
+#include <string.h>
 #include "grads.h"
 #include "buildinfo.h"

diff -Naur grads-1.9b4/src/gaexpr.c grads-1.9b4_new/src/gaexpr.c
--- grads-1.9b4/src/gaexpr.c  2005-05-18 14:48:36.000000000 +0000
+++ grads-1.9b4_new/src/gaexpr.c        2005-11-03 11:22:27.000000000 +0000
@@ -13,6 +13,7 @@
 #endif

 #include <stdio.h>
+#include <string.h>
 #include <math.h>
 #include "grads.h"

diff -Naur grads-1.9b4/src/gaio.c grads-1.9b4_new/src/gaio.c
--- grads-1.9b4/src/gaio.c    2005-05-23 17:59:01.000000000 +0000
+++ grads-1.9b4_new/src/gaio.c  2005-11-03 11:37:35.000000000 +0000
@@ -22,6 +22,7 @@
 #include "grads.h"
 #include <math.h>
 #include <stdio.h>
+#include <string.h>
 #if USESDF == 1
 #include <netcdf.h>
 #if USEHDF == 1
diff -Naur grads-1.9b4/src/gasdf.c grads-1.9b4_new/src/gasdf.c
--- grads-1.9b4/src/gasdf.c   2005-05-18 14:29:17.000000000 +0000
+++ grads-1.9b4_new/src/gasdf.c 2005-11-04 10:02:05.000000000 +0000
@@ -5785,7 +5785,11 @@
   /* Turn off automatic error handling. */
   ncopts = 0;

+#if USEHDF == 1
   if (ncattname (cdfid, varid, attnum, name) == -1) {
+#else
+  if (nc_inq_attname(cdfid, varid, attnum, name) == -1) {
+#endif
     ncopts = oldncopts ;
     return Failure;
   }
@@ -5813,10 +5817,23 @@
   /* Turn off automatic error handling. */
   ncopts = 0;

+#if USEHDF == 1
   if (ncattinq (cdfid, varid, aname, atype, alen) == -1) {
     ncopts = oldncopts ;
     return Failure;
   }
+#else
+  if (nc_inq_atttype(cdfid, varid, aname, atype) != NC_NOERR) {
+    ncopts = oldncopts ;
+    return Failure;
+  }
+  size_t templen;
+  if (nc_inq_attlen(cdfid, varid, aname, &templen) != NC_NOERR) {
+    ncopts = oldncopts ;
+    return Failure;
+  }
+  *alen = (int) templen;
+#endif

   /* Allocate space for values. */
   if ((*atype == NC_BYTE) || (*atype == NC_CHAR))  {
@@ -5831,6 +5848,7 @@
     *adata = (double *) malloc (sizeof (double) * *alen);
   }  else {
     ncopts = oldncopts ;
+    printf("UNKNOWN TYPE HERE !\n");
     return Failure;
   }

@@ -5840,10 +5858,65 @@
   }

   /* Retrieve values. */
+#if USEHDF == 1
   if (ncattget (cdfid, varid, aname, (void *) (*adata)) == -1) {
     ncopts = oldncopts ;
     return Failure;
   }
+#else
+  switch (*atype)
+  {
+     case NC_BYTE:
+       if (nc_get_att_uchar(cdfid, varid, aname, (unsigned char *) *adata) != NC_NOERR)
+       {
+         ncopts = oldncopts ;
+         return Failure;
+       }
+       break;
+     case NC_CHAR:
+       if (nc_get_att_text(cdfid, varid, aname, (char *) *adata) != NC_NOERR)
+       {
+         ncopts = oldncopts ;
+         return Failure;
+       }
+       break;
+     case NC_SHORT:
+       if (nc_get_att_short(cdfid, varid, aname, (short *) *adata) != NC_NOERR)
+       {
+         ncopts = oldncopts ;
+         return Failure;
+       }
+       break;
+     case NC_LONG:
+       if (nc_get_att_int(cdfid, varid, aname, (int *) *adata) != NC_NOERR)
+       {
+         ncopts = oldncopts ;
+         return Failure;
+       }
+       break;
+     case NC_FLOAT:
+       if (nc_get_att_float(cdfid, varid, aname, (float *) *adata) != NC_NOERR)
+       {
+         ncopts = oldncopts ;
+         return Failure;
+       }
+       break;
+     case NC_DOUBLE:
+       if (nc_get_att_double(cdfid, varid, aname, (double *) *adata) != NC_NOERR)
+       {
+         ncopts = oldncopts ;
+         return Failure;
+       }
+       break;
+     default:
+       if (nc_get_att_text(cdfid, varid, aname, (char *) *adata) != NC_NOERR)
+       {
+         ncopts = oldncopts ;
+         return Failure;
+       }
+       break;
+  }
+#endif

   /* If character, set last byte to null. */
   if (*atype == NC_CHAR)  {
diff -Naur grads-1.9b4/src/gxdxwd.c grads-1.9b4_new/src/gxdxwd.c
--- grads-1.9b4/src/gxdxwd.c  2002-10-28 19:08:33.000000000 +0000
+++ grads-1.9b4_new/src/gxdxwd.c        2005-11-03 13:37:45.000000000 +0000
@@ -7,6 +7,7 @@
 #endif

 #include <stdio.h>
+#include <stdlib.h>
 #include <errno.h>

 #include <X11/Xos.h>
@@ -22,7 +23,7 @@
  *              writting.
  */

-char *calloc();
+/* char *calloc(); */

 #include "X11/XWDFile.h"

@@ -92,6 +91,7 @@
     int bw;
     Window dummywin;
     XWDFileHeader header;
+    char mytmp[64];


     /*
@@ -232,7 +232,8 @@
      * Write out the color maps, if any
      */

-    if (debug) outl("xwd: Dumping %d colors.\n", ncolors);
+    sprintf(mytmp, "xwd: Dumping %d colors.\n", ncolors);
+    if (debug) outl(mytmp);
 /*
     {
     int icineca=0;
diff -Naur grads-1.9b4/src/gxeps.c grads-1.9b4_new/src/gxeps.c
--- grads-1.9b4/src/gxeps.c   2004-02-27 14:42:11.000000000 +0000
+++ grads-1.9b4_new/src/gxeps.c 2005-11-03 14:45:16.000000000 +0000
@@ -6,6 +6,8 @@
 #include <config.h>
 #endif

+#include <stdlib.h>
+
 /***********************************************************
  * GXEPS a grads metafile to PostScript converter
  * Copyright (c) 1999 - 2001 Matthias Munnich
diff -Naur grads-1.9b4/src/gxhpng.c grads-1.9b4_new/src/gxhpng.c
--- grads-1.9b4/src/gxhpng.c  2004-03-12 16:14:04.000000000 +0000
+++ grads-1.9b4_new/src/gxhpng.c        2005-11-03 11:56:53.000000000 +0000
@@ -6,7 +6,6 @@
 #include <config.h>
 #endif

-
 /* Rasterize current metafile buffer via gd library.  Loosly based
    on the gxpng utility:

@@ -455,7 +452,7 @@
                                im->polyInts[ints++] = (y-y1) * (x2-x1) / (y2-y1) + x1;
                        }
                }
-               qsort(im->polyInts, ints, sizeof(int), gdCompareInt);
+               qsort(im->polyInts, ints, sizeof(int), (void *) gdCompareInt);

                for (i=0; (i < (ints)); i+=2) {
                        gdImageLne(im, im->polyInts[i], y,
diff -Naur grads-1.9b4/src/gxX.c grads-1.9b4_new/src/gxX.c
--- grads-1.9b4/src/gxX.c     2005-05-18 14:29:17.000000000 +0000
+++ grads-1.9b4_new/src/gxX.c   2005-11-03 11:28:15.000000000 +0000
@@ -270,7 +270,7 @@

   /* Set up icon pixmap */

-  icon_pixmap = XCreateBitmapFromData(display, win, icon_bitmap_bits,
+  icon_pixmap = XCreateBitmapFromData(display, win, (char *) icon_bitmap_bits,
                 icon_bitmap_width, icon_bitmap_height);

   /* Set standard properties */
@@ -402,7 +402,7 @@
   if (xfnam) flist = XListFonts (display, xfnam, 1, &i);
   else flist = NULL;
   if (flist==NULL) {
-    flist = XListFonts (display, "-adobe-helvetica-bold-r-normal--??-100*", 1, &i);
+    flist = XListFonts (display, "-adobe-helvetica-bold-r-normal-*-100*", 1, &i);
   }
   if (flist==NULL) {
     flist = XListFonts (display, "-adobe-helvetica-bold-r-normal-*-120*", 1, &i);
@@ -418,7 +418,7 @@
   if (xfnam) flist = XListFonts (display, xfnam, 1, &i);
   else flist = NULL;
   if (flist==NULL) {
-    flist = XListFonts (display, "-adobe-helvetica-bold-o-normal--??-100*", 1, &i);
+    flist = XListFonts (display, "-adobe-helvetica-bold-o-normal-*-100*", 1, &i);
   }
   if (flist==NULL) {
     flist = XListFonts (display, "-adobe-helvetica-bold-o-normal-*-120*", 1, &i);
@@ -3267,7 +3267,7 @@
   }

   if (typ>1) {
-    stipple_pixmap = XCreateBitmapFromData(display, win, bitmap_bits,
+    stipple_pixmap = XCreateBitmapFromData(display, win, (char *) bitmap_bits,
                     bitmap_width, bitmap_height);
     XSetStipple(display, gc, stipple_pixmap);
     XSetFillStyle(display, gc, FillStippled);
diff -u --recursive grads-1.9b4-orig/src/gauser.c grads-1.9b4-rpm/src/gauser.c
--- grads-1.9b4-orig/src/gauser.c       2005-05-18 20:51:01.000000000 +0200
+++ grads-1.9b4-rpm/src/gauser.c        2006-02-17 15:19:32.000000000 +0100
@@ -42,6 +42,7 @@
 #endif

 /* int gxhpng (char *, int, int, int, int); */
+int gxhpng (char *, int, int, int, int, char *, char *, int) ;

 /*mf 971022 --- expose Mike Fiorino's global struct to these routines for warning level setting mf*/
 extern struct gamfcmn mfcmn;
--- grads-1.9b4-orig/src/gxhpng.c       2004-03-12 17:14:04.000000000 +0100
+++ grads-1.9b4-rpm/src/gxhpng.c        2006-02-17 15:19:32.000000000 +0100
@@ -379,6 +379,11 @@

 int gdCompareInt(const void *a, const void *b);

+int gdCompareInt(const void *a, const void *b)
+{
+       return (*(const int *)a) - (*(const int *)b);
+}
+
 /* Version of gdImageFilledPolygon to invoke my local
    version of gdImageLne.  Nothing else changed... B.Doty 5/31/01 */


From hmjbarbosa at GMAIL.COM  Fri Oct 19 08:20:26 2007
From: hmjbarbosa at GMAIL.COM (Henrique Barbosa)
Date: Fri, 19 Oct 2007 09:20:26 -0300
Subject: problem to open TRMM 3B42RT 3hr binary files
Message-ID: <FRI.19.OCT.2007.092026.0300.>

Dear All,

I am trying to open the TRMM 3B42RT 3hr binary
files available from:

ftp://trmmopen.gsfc.nasa.gov/pub/merged/mergeIRMicro

Its a plain binary file, but it has a 2880 bytes header
and precipitation, error and source number are
packed as 2byte-integer, 2byte-integer and 1byte-integer
respectivelly (see file header below).

I wrote the ctl below but it is not working. Only 0 and -1
are unpacked correctly... All other values are wrong.
For instance, 76 (0.76mm/hr) is unpacked by grads
as 19456 and 162 (1.62mm/hr) is unpacked as -24064.

I can read the data correctly if I open it from a fortran
program thou. If I use it to write a new binary file
containing only the rescaled precipitation as real*4,
than I can access the data correctly from grads.

I would prefer to open the original data instead.
Any ideas how to fix the ctl?

thanks,
Henrique

=======GRADS unpacking x F90================
nx   |  ny | Grads   | F90
1261 |  40 |   -1    | -1
1261 |  41 |    0    |  0
1261 |  60 |   6656  | 26
1261 |  61 |   1264  | 44
1261 | 403 | -24064  | 162
1261 | 404 |  19456  |  76

==========GRADS VERSION==================
Config: v1.9b4 32-bit little-endian readline lats printim
Running on P4 with opensuse 10.1

===========CTL===========================
DSET ^mergeIRMicro/2002/3B42RT.2002090100.bin
UNDEF -31999
OPTIONS YREV BIG_ENDIAN
fileheader 2880
TITLE trmm data
XDEF 1440  LINEAR    0.125 0.25
YDEF  480  LINEAR  -59.875 0.25
ZDEF 1 LEVELS 1 1
TDEF 1 LINEAR 00Z01SEP2002 3HR
VARS 3
prec    0 -1,40,2,-1    prec (mm/hr)
error   0 -1,40,2,-1    error (mm/hr)
source  0 -1,40,1       source
ENDVARS

===========FILE HEADER====================
algorithm_ID=3B42RT algorithm_version=01.00
granule_ID=3B41RT.2002090100.bin header_byte_length=2880
file_byte_length=(char2880)_header+(int2)x1440x720x2_data+(int1)x1440x720_data
nominal_YYYYMMDD=20020901 nominal_HHMMSS=000000
begin_YYYYMMDD=20020831 begin_HHMMSS=223000 end_YYYYMMDD=20020901
end_HHMMSS=013000 creation_date=20020901 west_boundary=0E
east_boundary=360E north_boundary=60N south_boundary=60S
origin=northwest number_of_latitude_bins=480
number_of_longitude_bins=1440 grid=0.25x0.25_deg_lat/lon
first_box_center=59.875N,0.125E second_box_center=59.875N,0.375E
last_box_center=59.875S,359.875E number_of_variables=3
variable_name=precipitation,precipitation_error,source
variable_units=mm/hr,mm/hr,source_number variable_scale=100,100,1
variable_type=signed_integer2,signed_integer2,signed_integer1
byte_order=big_endian flag_value=-31999
flag_name=insufficient_observations contact_name=TSDIS_Helpdesk
contact_address=NASA/GSFC_Code_902_Greenbelt_MD_20771_USA
contact_telephone=301-614-5184 contact_facsimile=301-614-5575
contact_email=helpdesk at tsdis.gsfc.nasa.gov


From zliu at POP600.GSFC.NASA.GOV  Fri Oct 19 09:20:31 2007
From: zliu at POP600.GSFC.NASA.GOV (Zhong Liu)
Date: Fri, 19 Oct 2007 09:20:31 -0400
Subject: problem to open TRMM 3B42RT 3hr binary files
In-Reply-To: <e71668fa0710190520r437121f5w4f45aa90d0d07892@mail.gmail.com>
Message-ID: <FRI.19.OCT.2007.092031.0400.>

Dear Henrique Barbosa,

FYI: The NASA Goddard DISC has made those data GrADS ready,

ftp://disc2.nascom.nasa.gov/data/TRMM/Gridded/3B42RT
ftp://disc2.nascom.nasa.gov/data/TRMM/Gridded/3B40RT
ftp://disc2.nascom.nasa.gov/data/TRMM/Gridded/3B41RT

Regards,

-Zhong

Henrique Barbosa wrote:
> Dear All,
>
> I am trying to open the TRMM 3B42RT 3hr binary
> files available from:
>
> ftp://trmmopen.gsfc.nasa.gov/pub/merged/mergeIRMicro
>
> Its a plain binary file, but it has a 2880 bytes header
> and precipitation, error and source number are
> packed as 2byte-integer, 2byte-integer and 1byte-integer
> respectivelly (see file header below).
>
> I wrote the ctl below but it is not working. Only 0 and -1
> are unpacked correctly... All other values are wrong.
> For instance, 76 (0.76mm/hr) is unpacked by grads
> as 19456 and 162 (1.62mm/hr) is unpacked as -24064.
>
> I can read the data correctly if I open it from a fortran
> program thou. If I use it to write a new binary file
> containing only the rescaled precipitation as real*4,
> than I can access the data correctly from grads.
>
> I would prefer to open the original data instead.
> Any ideas how to fix the ctl?
>
> thanks,
> Henrique
>
> =======GRADS unpacking x F90================
> nx   |  ny | Grads   | F90
> 1261 |  40 |   -1    | -1
> 1261 |  41 |    0    |  0
> 1261 |  60 |   6656  | 26
> 1261 |  61 |   1264  | 44
> 1261 | 403 | -24064  | 162
> 1261 | 404 |  19456  |  76
>
> ==========GRADS VERSION==================
> Config: v1.9b4 32-bit little-endian readline lats printim
> Running on P4 with opensuse 10.1
>
> ===========CTL===========================
> DSET ^mergeIRMicro/2002/3B42RT.2002090100.bin
> UNDEF -31999
> OPTIONS YREV BIG_ENDIAN
> fileheader 2880
> TITLE trmm data
> XDEF 1440  LINEAR    0.125 0.25
> YDEF  480  LINEAR  -59.875 0.25
> ZDEF 1 LEVELS 1 1
> TDEF 1 LINEAR 00Z01SEP2002 3HR
> VARS 3
> prec    0 -1,40,2,-1    prec (mm/hr)
> error   0 -1,40,2,-1    error (mm/hr)
> source  0 -1,40,1       source
> ENDVARS
>
> ===========FILE HEADER====================
> algorithm_ID=3B42RT algorithm_version=01.00
> granule_ID=3B41RT.2002090100.bin header_byte_length=2880
> file_byte_length=(char2880)_header+(int2)x1440x720x2_data+(int1)x1440x720_data
> nominal_YYYYMMDD=20020901 nominal_HHMMSS=000000
> begin_YYYYMMDD=20020831 begin_HHMMSS=223000 end_YYYYMMDD=20020901
> end_HHMMSS=013000 creation_date=20020901 west_boundary=0E
> east_boundary=360E north_boundary=60N south_boundary=60S
> origin=northwest number_of_latitude_bins=480
> number_of_longitude_bins=1440 grid=0.25x0.25_deg_lat/lon
> first_box_center=59.875N,0.125E second_box_center=59.875N,0.375E
> last_box_center=59.875S,359.875E number_of_variables=3
> variable_name=precipitation,precipitation_error,source
> variable_units=mm/hr,mm/hr,source_number variable_scale=100,100,1
> variable_type=signed_integer2,signed_integer2,signed_integer1
> byte_order=big_endian flag_value=-31999
> flag_name=insufficient_observations contact_name=TSDIS_Helpdesk
> contact_address=NASA/GSFC_Code_902_Greenbelt_MD_20771_USA
> contact_telephone=301-614-5184 contact_facsimile=301-614-5575
> contact_email=helpdesk at tsdis.gsfc.nasa.gov
>
>


--
********************************************************************
* Zhong Liu, Ph.D.                     |  zliu at pop600.gsfc.nasa.gov*
* George Mason University and          |                           *
* NASA Goddard Earth Sciences          |  (301) 614-5764 (voice)   *
* Data and Information Services Center |  (301) 614-5268 (fax)     *
* NASA/GSFC, Code 610.2                |                           *
* Greenbelt. MD. 20771  U.S.A.         |                           *
********************************************************************
* For more information about the Goddard DISC and its services:    *
* http://disc.gsfc.nasa.gov/                                       *
********************************************************************


From giavvns at ATH.HCMR.GR  Fri Oct 19 10:40:28 2007
From: giavvns at ATH.HCMR.GR (Ioannis A. Vamvakas)
Date: Fri, 19 Oct 2007 17:40:28 +0300
Subject: Conversion between little_endian and big_endian grib files
In-Reply-To: <4718AF1F.9050804@pop600.gsfc.nasa.gov>
Message-ID: <FRI.19.OCT.2007.174028.0300.>

Dear all,

Has anybody confronted in the past the so-called NUXI problem? That is,
working in a little_endian machine to generate big_endian GRIB files?

I'd appreciate any help on how you dealt with the problem!

Thanks,

--
Ioannis A. Vamvakas
Hellenic Center for Marine Research
Institute of Oceanography
46.7 Km. Athens-Sounio Ave.
GR-193 13,ANAVYSSOS,Greece
Tel.+30-22910-7-6399, Fax: +30-22910-7-6323
Cell Phone: +30-697-580-1696


From michael.bosilovich at GMAIL.COM  Fri Oct 19 10:41:24 2007
From: michael.bosilovich at GMAIL.COM (Michael G Bosilovich)
Date: Fri, 19 Oct 2007 10:41:24 -0400
Subject: problem to open TRMM 3B42RT 3hr binary files
In-Reply-To: <e71668fa0710190520r437121f5w4f45aa90d0d07892@mail.gmail.com>
Message-ID: <FRI.19.OCT.2007.104124.0400.>

I had similar problems. I got the CTL for the original binaries to
work on an SGI, but not on a Linux PC. I ended up converting the data
to real*4 in fortran, also. (I wanted to work on the Linux machine).
Likewise, I realized this is not a long term option.

I moved to the TRMM 3b42 Version 6. The RT is real time. I notice that
you are looking at 2002 data. If you are looking at retrospective case
studies or long timeseries, then the 3b42v6 might be more what you
want. At least check it out:

http://daac.gsfc.nasa.gov/precipitation/TRMM_README/TRMM_3B42_readme.shtml

These data are in HDF. Below is a sample definition file for these.
Use "open" to open the hdfsds format data with this file.

Mike

dset 3B42/data/3B42.01%m2%d2.%h1.6.HDF
dtype hdfsds
options template
undef -9999.9
xdef 1440 linear 180 0.25
ydef 400 linear -50 0.25
zdef 1 levels 1
tdef 248 linear 00Z01jul2001 3hr
vars 2
precipitation=>p  0 t,x,y precipitation
relativeError=>re 0 t,x,y relative error
endvars


On 10/19/07, Henrique Barbosa <hmjbarbosa at gmail.com> wrote:
> Dear All,
>
> I am trying to open the TRMM 3B42RT 3hr binary
> files available from:
>
> ftp://trmmopen.gsfc.nasa.gov/pub/merged/mergeIRMicro
>
> Its a plain binary file, but it has a 2880 bytes header
> and precipitation, error and source number are
> packed as 2byte-integer, 2byte-integer and 1byte-integer
> respectivelly (see file header below).
>
> I wrote the ctl below but it is not working. Only 0 and -1
> are unpacked correctly... All other values are wrong.
> For instance, 76 (0.76mm/hr) is unpacked by grads
> as 19456 and 162 (1.62mm/hr) is unpacked as -24064.
>
> I can read the data correctly if I open it from a fortran
> program thou. If I use it to write a new binary file
> containing only the rescaled precipitation as real*4,
> than I can access the data correctly from grads.
>
> I would prefer to open the original data instead.
> Any ideas how to fix the ctl?
>
> thanks,
> Henrique
>
> =======GRADS unpacking x F90================
> nx   |  ny | Grads   | F90
> 1261 |  40 |   -1    | -1
> 1261 |  41 |    0    |  0
> 1261 |  60 |   6656  | 26
> 1261 |  61 |   1264  | 44
> 1261 | 403 | -24064  | 162
> 1261 | 404 |  19456  |  76
>
> ==========GRADS VERSION==================
> Config: v1.9b4 32-bit little-endian readline lats printim
> Running on P4 with opensuse 10.1
>
> ===========CTL===========================
> DSET ^mergeIRMicro/2002/3B42RT.2002090100.bin
> UNDEF -31999
> OPTIONS YREV BIG_ENDIAN
> fileheader 2880
> TITLE trmm data
> XDEF 1440  LINEAR    0.125 0.25
> YDEF  480  LINEAR  -59.875 0.25
> ZDEF 1 LEVELS 1 1
> TDEF 1 LINEAR 00Z01SEP2002 3HR
> VARS 3
> prec    0 -1,40,2,-1    prec (mm/hr)
> error   0 -1,40,2,-1    error (mm/hr)
> source  0 -1,40,1       source
> ENDVARS
>
> ===========FILE HEADER====================
> algorithm_ID=3B42RT algorithm_version=01.00
> granule_ID=3B41RT.2002090100.bin header_byte_length=2880
> file_byte_length=(char2880)_header+(int2)x1440x720x2_data+(int1)x1440x720_data
> nominal_YYYYMMDD=20020901 nominal_HHMMSS=000000
> begin_YYYYMMDD=20020831 begin_HHMMSS=223000 end_YYYYMMDD=20020901
> end_HHMMSS=013000 creation_date=20020901 west_boundary=0E
> east_boundary=360E north_boundary=60N south_boundary=60S
> origin=northwest number_of_latitude_bins=480
> number_of_longitude_bins=1440 grid=0.25x0.25_deg_lat/lon
> first_box_center=59.875N,0.125E second_box_center=59.875N,0.375E
> last_box_center=59.875S,359.875E number_of_variables=3
> variable_name=precipitation,precipitation_error,source
> variable_units=mm/hr,mm/hr,source_number variable_scale=100,100,1
> variable_type=signed_integer2,signed_integer2,signed_integer1
> byte_order=big_endian flag_value=-31999
> flag_name=insufficient_observations contact_name=TSDIS_Helpdesk
> contact_address=NASA/GSFC_Code_902_Greenbelt_MD_20771_USA
> contact_telephone=301-614-5184 contact_facsimile=301-614-5575
> contact_email=helpdesk at tsdis.gsfc.nasa.gov
>
> --
> This message has been scanned for viruses and dangerous
> content by GMAO's MailScanner, and is believed to be clean.
>
>


From kees at AEOLIS.NL  Fri Oct 19 11:22:20 2007
From: kees at AEOLIS.NL (Kees van Vliet)
Date: Fri, 19 Oct 2007 17:22:20 +0200
Subject: Conversion between little_endian and big_endian grib files
In-Reply-To: <36523.10.6.1.211.1192804828.squirrel@10.6.1.211>
Message-ID: <FRI.19.OCT.2007.172220.0200.>

Hi,

I had this problem with GRIB data a few years ago. I got a small  
program to perform a byteswap and this worked very good.
attached is the program and a makefile to compile it with GCC.??
Good luck,

Kees van Vliet

On Oct 19, 2007, at 4:40 PM, Ioannis A. Vamvakas wrote:

> Dear all,
>
> Has anybody confronted in the past the so-called NUXI problem? That  
> is,
> working in a little_endian machine to generate big_endian GRIB files?
>
> I'd appreciate any help on how you dealt with the problem!
>
> Thanks,
>
> --
> Ioannis A. Vamvakas
> Hellenic Center for Marine Research
> Institute of Oceanography
> 46.7 Km. Athens-Sounio Ave.
> GR-193 13,ANAVYSSOS,Greece
> Tel.+30-22910-7-6399, Fax: +30-22910-7-6323
> Cell Phone: +30-697-580-1696
>




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071019/1bf50013/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: byteswap.mk
Type: application/octet-stream
Size: 649 bytes
Desc: not available
Url : http://gradsusr.org/pipermail/gradsusr/attachments/20071019/1bf50013/attachment.obj 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071019/1bf50013/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: byteswap.c
Type: application/octet-stream
Size: 4241 bytes
Desc: not available
Url : http://gradsusr.org/pipermail/gradsusr/attachments/20071019/1bf50013/attachment-0001.obj 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071019/1bf50013/attachment-0002.html 

From giavvns at ATH.HCMR.GR  Fri Oct 19 11:47:46 2007
From: giavvns at ATH.HCMR.GR (Ioannis A. Vamvakas)
Date: Fri, 19 Oct 2007 18:47:46 +0300
Subject: Problem solved: Conversion between little_endian and big_endian
 grib files
In-Reply-To: <5D2E999C-77B9-43AD-89A0-32065ADF2FB8@aeolis.nl>
Message-ID: <FRI.19.OCT.2007.184746.0300.>

I'd like to thank all those ansered to my question. With their help I
dealt with the problem.

IAV


From prodicalboxer at YAHOO.COM  Fri Oct 19 21:20:26 2007
From: prodicalboxer at YAHOO.COM (Daniel Fritz)
Date: Fri, 19 Oct 2007 18:20:26 -0700
Subject: what is the fwrite file?
In-Reply-To: <5D2E999C-77B9-43AD-89A0-32065ADF2FB8@aeolis.nl>
Message-ID: <FRI.19.OCT.2007.182026.0700.>

Hello All,
     could someone explain to me the purpose of the Fwrite file.....and also when writing a script or a code to run....the filname is at the top to be read, tell me at the end of the path of the file...is there data written to the end of that path for example;
                                       /house/johndoe/grads/track/bean.dat
  would the bean.dat be a control file or is it a grib file????  where doesthis particular piece of information come from???
                        DANNY

Kees van Vliet <kees at AEOLIS.NL> wrote:
  Hi,

I had this problem with GRIB data a few years ago. I got a small
program to perform a byteswap and this worked very good.
attached is the program and a makefile to compile it with GCC.??????
Good luck,

Kees van Vliet

On Oct 19, 2007, at 4:40 PM, Ioannis A. Vamvakas wrote:

> Dear all,
>
> Has anybody confronted in the past the so-called NUXI problem? That
> is,
> working in a little_endian machine to generate big_endian GRIB files?
>
> I'd appreciate any help on how you dealt with the problem!
>
> Thanks,
>
> --
> Ioannis A. Vamvakas
> Hellenic Center for Marine Research
> Institute of Oceanography
> 46.7 Km. Athens-Sounio Ave.
> GR-193 13,ANAVYSSOS,Greece
> Tel.+30-22910-7-6399, Fax: +30-22910-7-6323
> Cell Phone: +30-697-580-1696
>






 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071019/58076e11/attachment.html 

From prodicalboxer at YAHOO.COM  Mon Oct 22 14:22:50 2007
From: prodicalboxer at YAHOO.COM (Daniel Fritz)
Date: Mon, 22 Oct 2007 11:22:50 -0700
Subject: the script
In-Reply-To: <5D2E999C-77B9-43AD-89A0-32065ADF2FB8@aeolis.nl>
Message-ID: <MON.22.OCT.2007.112250.0700.>

Hello all,
   I wrote this script to run as a code.....
and I keep getting a syntax error.....could someone
tell me what should be in my filnam...
here is what I wrote
filnam='/home2/fritz/script/floyd.dat'

'draw map'

while (1)
res = read(filnam)
rc = sublin(res,1)

if (rc > 0)
* Check if there is a problem reading
if (rc = 2)
say 'EOF - Finished reading 'filnam
res = close(filnam)
break
else
say rc ' Error while reading 'filnam
res = close(filnam)
break
endif
endif

* No problems
* Step 1 - read in the position

datum = sublin(res,2)
dateline = subwrd(datum,1)
longitude = subwrd(datum,2)
latitude = subwrd(datum,3)

* Step 2 - convert lat/lon to page position
'd ugrd10m.1;vgrd10m.1;mag(ugrd10m.1,vgrd10m.1)'
x0 = subwrd(result,3)
y0 = subwrd(result,6)

* Step 3 - plot the position on the page
'draw mark 2 'x0' 'y0' 0.1'
endwhile
I tried to open this and run it in grads
ga-> open_Ydata.gs
ga-> set lon 250 280
LON set to 250 280
ga-> set lat 0 30
LAT set to 0 30
ga-> d ugrd10m.1;vgrd10m.1;mag(ugrd10m.1,vgrd10m.1)
ga-> run hurricanetrack_code
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
EOF - Finished reading /home2/fritz/script/floyd.dat
ga->
this what I got...can anyone help me?
open_Ydata.gs is a script of ctl files
here is part of the filename floyd.dat
eosci5.ncat.edu{fritz}1007: cat floyd.dat
11A  19.10  -58.90 09/10/12Z   70   989 HURRICANE-1
 12  19.30  -59.20 09/10/15Z   70   989 HURRICANE-1
12A  19.90  -59.70 09/10/18Z   70   989 HURRICANE-1
 13  20.50  -60.00 09/10/21Z   70   975 HURRICANE-1
13A  20.80  -60.40 09/11/00Z   75   971 HURRICANE-1
 14  21.10  -60.80 09/11/03Z   80   971 HURRICANE-1
 15  21.70  -61.60 09/11/09Z   90   963 HURRICANE-2
 16  22.20  -62.40 09/11/15Z   95   962 HURRICANE-2
 17  22.70  -63.50 09/11/21Z   95   966 HURRICANE-2
 18  22.70  -64.50 09/12/03Z   95   967 HURRICANE-2
 19  22.80  -65.90 09/12/09Z   95   960 HURRICANE-2
 20  23.00  -66.60 09/12/15Z  105   955 HURRICANE-3
20A  23.20  -67.50 09/12/18Z  105   955 HURRICANE-3
 21  23.40  -68.20 09/12/21Z  110   940 HURRICANE-3
21A  23.50  -68.70 09/13/00Z  125   932 HURRICANE-4
 22  23.60  -69.30 09/13/03Z  125   931 HURRICANE-4
22A  23.60  -70.00 09/13/06Z  130   923 HURRICANE-4
 23  23.70  -70.60 09/13/09Z  135   922 HURRICANE-4
23A  23.90  -71.40 09/13/12Z  135   921 HURRICANE-4
 24  24.10  -72.10 09/13/15Z  135   921 HURRICANE-4
24A  24.20  -73.00 09/13/18Z  135   926 HURRICANE-4
 25  24.20  -73.70 09/13/21Z  135   923 HURRICANE-4
25A  24.40  -74.10 09/14/00Z  135   924 HURRICANE-4
 26  24.50  -74.70 09/14/03Z  135   924 HURRICANE-4
26A  24.90  -75.30 09/14/06Z  135   928 HURRICANE-4
 27  25.10  -75.90 09/14/09Z  135   927 HURRICANE-4
27A  25.40  -76.20 09/14/12Z  130   929 HURRICANE-4
 28  25.70  -76.80 09/14/15Z  125   932 HURRICANE-4
28A  26.00  -77.00 09/14/18Z  120   933 HURRICANE-4
 29  26.50  -77.40 09/14/21Z  120   929 HURRICANE-4
29A  27.10  -77.60 09/15/00Z  120   934 HURRICANE-4
 30  27.70  -77.90 09/15/03Z  120   933 HURRICANE-4
30A  28.20  -78.50 09/15/06Z  120   935 HURRICANE-4
 31  28.80  -78.80 09/15/09Z  120   938 HURRICANE-4
31A  29.30  -78.80 09/15/12Z  115   941 HURRICANE-4
 32  29.90  -79.00 09/15/15Z  110   943 HURRICANE-3
32A  30.30  -79.10 09/15/17Z  110   946 HURRICANE-3
32B  30.80  -79.10 09/15/19Z  105   947 HURRICANE-3
 33  31.30  -79.00 09/15/21Z  100   949 HURRICANE-3
33A  32.10  -78.70 09/15/23Z  100   949 HURRICANE-3
33B  32.40  -78.60 09/16/01Z  100   950 HURRICANE-3
 34  32.90  -78.30 09/16/03Z  100   952 HURRICANE-3
34A  33.30  -78.10 09/16/05Z   95   952 HURRICANE-2
34B  34.00  -77.90 09/16/07Z   95   955 HURRICANE-2
 35  34.50  -77.60 09/16/09Z   90   956 HURRICANE-2
35A  35.20  -77.10 09/16/11Z   85   960 HURRICANE-2
35B  36.00  -76.60 09/16/13Z   80   962 HURRICANE-1
 36  36.80  -76.00 09/16/15Z   70   967 HURRICANE-1
36A  37.80  -75.20 09/16/18Z   65   974
HURRICANE-1geosci5.ncat.edu{fritz}1008:
anyone with any suggestions???????







--- Kees van Vliet <kees at AEOLIS.NL> wrote:

> Hi,
>
> I had this problem with GRIB data a few years ago. I
> got a small
> program to perform a byteswap and this worked very
> good.
> attached is the program and a makefile to compile it
> with GCC.??????
> Good luck,
>
> Kees van Vliet
>
> On Oct 19, 2007, at 4:40 PM, Ioannis A. Vamvakas
> wrote:
>
> > Dear all,
> >
> > Has anybody confronted in the past the so-called
> NUXI problem? That
> > is,
> > working in a little_endian machine to generate
> big_endian GRIB files?
> >
> > I'd appreciate any help on how you dealt with the
> problem!
> >
> > Thanks,
> >
> > --
> > Ioannis A. Vamvakas
> > Hellenic Center for Marine Research
> > Institute of Oceanography
> > 46.7 Km. Athens-Sounio Ave.
> > GR-193 13,ANAVYSSOS,Greece
> > Tel.+30-22910-7-6399, Fax: +30-22910-7-6323
> > Cell Phone: +30-697-580-1696
> >
>
>
>
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


From prodicalboxer at YAHOO.COM  Mon Oct 22 20:21:13 2007
From: prodicalboxer at YAHOO.COM (Daniel Fritz)
Date: Mon, 22 Oct 2007 17:21:13 -0700
Subject: NEDIT
In-Reply-To: <5D2E999C-77B9-43AD-89A0-32065ADF2FB8@aeolis.nl>
Message-ID: <MON.22.OCT.2007.172113.0700.>

HELLO ALL,
   I have writte a script earlier, and I got some
Hurricane data from the UNISYS weather web site
I made a spreadsheet out of it and how do you cut and
paste to NEDIT???  here is my data...so that the file
name at the top of the script could read it?

Floyd 1         -58.9   19.1    09//10/12Z      70      989
Floyd 1 -59.2   19.3    09/10/15Z       70      989
Floyd 1 -59.7   19.9    09/10/18Z       70      989
Floyd 1 -60     20.5    09/10/21Z       70      975
Floyd 1 -60.4   20.8    09/11/00Z       75      971
Floyd 1 60.8    21.1    09/11/03Z       80      971
Floyd 2 -61.6   21.7    09/11/09Z       90      963
Floyd 2 -62.4   22.2    09/11/15Z       95      962
Floyd 2 -63.5   22.7    09/11/21Z       95      966
Floyd 2 -64.5   22.7    09/12/03Z       95      967
Floyd 2 -65.9   22.8    09/12/09Z       95      940
Floyd 3 -66.6   23      09//10/12Z      105     955
Floyd 3 -67.5   23.2    09/12/18Z       105     955
Floyd 3 -68.2   23.4    09/12/21Z       110     940
Floyd 4 -68.7   23.5    09/13/00Z       125     932
Floyd 4 -69.3   23.6    09/13/03Z       125     931
Floyd 4 -70     23.6    09/13/06Z       130     923
Floyd 4 -70.6   23.7    09/13/09Z       135     922
Floyd 4 -71.4   23.9    09/13/12Z       135     921
Floyd 4 -72.1   24.1    09/13/15Z       135     921
Floyd 4 -73     24.2    09/13/18Z       135     926
Floyd 4 -73.7   24.2    09/13/21Z       135     923
Floyd 4 -74.1   24.4    09/14/00Z       135     924
Floyd 4 -74.7   24.5    09/14/03Z       135     924
Floyd 4 -75.3   24.9    09/14/06Z       135     928
Floyd 4 -75.9   25.1    09/14/09Z       135     927
Floyd 4 -76.2   25.4    09/14/12Z       130     929
Floyd 4 -76.8   25.7    09//14/15Z      125     932
Floyd 4 -77     26      09/14/18Z       120     933
Floyd 4 -77.4   26.5    09/14/21Z       120     929
Floyd 4 -77.6   27.1    09/15/00Z       120     934
Floyd 4 -77.9   27.7    09/15/03Z       120     933
Floyd 4 -78.5   28.2    09/15/06Z       120     935
Floyd 4 -78.8   28.8    09/15/09Z       120     938
Floyd 4 -78.8   29.3    09/15/12Z       115     941
Floyd 3 -79     29.9    09/15/15Z       110     943
Floyd 3 -79.1   30.3    09/15/17Z       110     946
Floyd 3 -79.1   30.8    09/15/19Z       105     947
Floyd 3 -79     31.3    09/15/21Z       100     949
Floyd 3 -78.7   32.1    09/15/23Z       100     949
Floyd 3 -78.6   32.4    09/16/01Z       100     950
Floyd 3 -78.3   32.9    09/16/03Z       100     952
Floyd 2 -78.1   33.3    09//16/05Z      95      952
Floyd 2 -77.9   34      09/16/07Z       95      955
Floyd 2 -77.6   34.5    09/16/09Z       90      956
Floyd 2 -77.1   35.2    09/16/11Z       85      960
Floyd 1 -76.6   36      09/16/13Z       80      962
Floyd 1 -76     36.8    09/16/15Z       70      967
Floyd 1 -75.2   37.8    09/16/18Z       65      974
        thanks
          DANNY















--- Kees van Vliet <kees at AEOLIS.NL> wrote:

> Hi,
>
> I had this problem with GRIB data a few years ago. I
> got a small
> program to perform a byteswap and this worked very
> good.
> attached is the program and a makefile to compile it
> with GCC.??????
> Good luck,
>
> Kees van Vliet
>
> On Oct 19, 2007, at 4:40 PM, Ioannis A. Vamvakas
> wrote:
>
> > Dear all,
> >
> > Has anybody confronted in the past the so-called
> NUXI problem? That
> > is,
> > working in a little_endian machine to generate
> big_endian GRIB files?
> >
> > I'd appreciate any help on how you dealt with the
> problem!
> >
> > Thanks,
> >
> > --
> > Ioannis A. Vamvakas
> > Hellenic Center for Marine Research
> > Institute of Oceanography
> > 46.7 Km. Athens-Sounio Ave.
> > GR-193 13,ANAVYSSOS,Greece
> > Tel.+30-22910-7-6399, Fax: +30-22910-7-6323
> > Cell Phone: +30-697-580-1696
> >
>
>
>
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


From prodicalboxer at YAHOO.COM  Tue Oct 23 01:25:21 2007
From: prodicalboxer at YAHOO.COM (Daniel Fritz)
Date: Mon, 22 Oct 2007 22:25:21 -0700
Subject: the SCRIPT
In-Reply-To: <5D2E999C-77B9-43AD-89A0-32065ADF2FB8@aeolis.nl>
Message-ID: <MON.22.OCT.2007.222521.0700.>

Hello ALL,
 I am still coming up with the same error....I am
running a hurricanetrack code
here is my script

filnam='/home2/fritz/script/Floyd.dat'

'draw map'

while (1)
res = read(filnam)
rc = sublin(res,1)

if (rc > 0)
* Check if there is a problem reading
if (rc = 2)
say 'EOF - Finished reading 'filnam
res = close(filnam)
break
else
say rc ' Error while reading 'filnam
res = close(filnam)
break
endif
endif

* No problems
* Step 1 - read in the position

datum = sublin(res,2)
dateline = subwrd(datum,1)
longitude = subwrd(datum,2)
latitude = subwrd(datum,3)


* Step 2 - convert lat/lon to page position
'd ugrd10m.1;vgrd10m.1;mag(ugrd10m.1,vgrd10m.1)'
x0 = subwrd(result,3)
y0 = subwrd(result,6)

* Step 3 - plot the position on the page
'draw mark 2 'x0' 'y0' 0.1'
endwhile
 here is what I am getting:
 ga-> open_Ydata.gs
ga-> set lon 270 350
LON set to 270 350
ga-> set lat 0 50
LAT set to 0 50
ga-> draw map
ga-> run hurricanetrack_code
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
EOF - Finished reading /home2/fritz/script/Floyd.dat
ga->

Could someone help me...does anybody have any
suggestion???????
      DANNY














--- Kees van Vliet <kees at AEOLIS.NL> wrote:

> Hi,
>
> I had this problem with GRIB data a few years ago. I
> got a small
> program to perform a byteswap and this worked very
> good.
> attached is the program and a makefile to compile it
> with GCC.??????
> Good luck,
>
> Kees van Vliet
>
> On Oct 19, 2007, at 4:40 PM, Ioannis A. Vamvakas
> wrote:
>
> > Dear all,
> >
> > Has anybody confronted in the past the so-called
> NUXI problem? That
> > is,
> > working in a little_endian machine to generate
> big_endian GRIB files?
> >
> > I'd appreciate any help on how you dealt with the
> problem!
> >
> > Thanks,
> >
> > --
> > Ioannis A. Vamvakas
> > Hellenic Center for Marine Research
> > Institute of Oceanography
> > 46.7 Km. Athens-Sounio Ave.
> > GR-193 13,ANAVYSSOS,Greece
> > Tel.+30-22910-7-6399, Fax: +30-22910-7-6323
> > Cell Phone: +30-697-580-1696
> >
>
>
>
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


From viviane_silva1 at YAHOO.COM  Tue Oct 23 08:21:24 2007
From: viviane_silva1 at YAHOO.COM (Viviane Silva)
Date: Tue, 23 Oct 2007 05:21:24 -0700
Subject: NEDIT
In-Reply-To: <357881.94213.qm@web62209.mail.re1.yahoo.com>
Message-ID: <TUE.23.OCT.2007.052124.0700.>

Hi Daniel,
If you are using excel, just save the file as
"Formatted Text (space delimited)". The extension of
the file will be .prn (same as .txt), then you can
open it in nedit.

Viviane



--- Daniel Fritz <prodicalboxer at YAHOO.COM> wrote:

> HELLO ALL,
>    I have writte a script earlier, and I got some
> Hurricane data from the UNISYS weather web site
> I made a spreadsheet out of it and how do you cut
> and
> paste to NEDIT???  here is my data...so that the
> file
> name at the top of the script could read it?
>
> Floyd 1         -58.9   19.1    09//10/12Z      70
>    989
> Floyd 1 -59.2   19.3    09/10/15Z       70      989
> Floyd 1 -59.7   19.9    09/10/18Z       70      989
> Floyd 1 -60     20.5    09/10/21Z       70      975
> Floyd 1 -60.4   20.8    09/11/00Z       75      971
> Floyd 1 60.8    21.1    09/11/03Z       80      971
> Floyd 2 -61.6   21.7    09/11/09Z       90      963
> Floyd 2 -62.4   22.2    09/11/15Z       95      962
> Floyd 2 -63.5   22.7    09/11/21Z       95      966
> Floyd 2 -64.5   22.7    09/12/03Z       95      967
> Floyd 2 -65.9   22.8    09/12/09Z       95      940
> Floyd 3 -66.6   23      09//10/12Z      105     955
> Floyd 3 -67.5   23.2    09/12/18Z       105     955
> Floyd 3 -68.2   23.4    09/12/21Z       110     940
> Floyd 4 -68.7   23.5    09/13/00Z       125     932
> Floyd 4 -69.3   23.6    09/13/03Z       125     931
> Floyd 4 -70     23.6    09/13/06Z       130     923
> Floyd 4 -70.6   23.7    09/13/09Z       135     922
> Floyd 4 -71.4   23.9    09/13/12Z       135     921
> Floyd 4 -72.1   24.1    09/13/15Z       135     921
> Floyd 4 -73     24.2    09/13/18Z       135     926
> Floyd 4 -73.7   24.2    09/13/21Z       135     923
> Floyd 4 -74.1   24.4    09/14/00Z       135     924
> Floyd 4 -74.7   24.5    09/14/03Z       135     924
> Floyd 4 -75.3   24.9    09/14/06Z       135     928
> Floyd 4 -75.9   25.1    09/14/09Z       135     927
> Floyd 4 -76.2   25.4    09/14/12Z       130     929
> Floyd 4 -76.8   25.7    09//14/15Z      125     932
> Floyd 4 -77     26      09/14/18Z       120     933
> Floyd 4 -77.4   26.5    09/14/21Z       120     929
> Floyd 4 -77.6   27.1    09/15/00Z       120     934
> Floyd 4 -77.9   27.7    09/15/03Z       120     933
> Floyd 4 -78.5   28.2    09/15/06Z       120     935
> Floyd 4 -78.8   28.8    09/15/09Z       120     938
> Floyd 4 -78.8   29.3    09/15/12Z       115     941
> Floyd 3 -79     29.9    09/15/15Z       110     943
> Floyd 3 -79.1   30.3    09/15/17Z       110     946
> Floyd 3 -79.1   30.8    09/15/19Z       105     947
> Floyd 3 -79     31.3    09/15/21Z       100     949
> Floyd 3 -78.7   32.1    09/15/23Z       100     949
> Floyd 3 -78.6   32.4    09/16/01Z       100     950
> Floyd 3 -78.3   32.9    09/16/03Z       100     952
> Floyd 2 -78.1   33.3    09//16/05Z      95      952
> Floyd 2 -77.9   34      09/16/07Z       95      955
> Floyd 2 -77.6   34.5    09/16/09Z       90      956
> Floyd 2 -77.1   35.2    09/16/11Z       85      960
> Floyd 1 -76.6   36      09/16/13Z       80      962
> Floyd 1 -76     36.8    09/16/15Z       70      967
> Floyd 1 -75.2   37.8    09/16/18Z       65      974
>         thanks
>           DANNY
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --- Kees van Vliet <kees at AEOLIS.NL> wrote:
>
> > Hi,
> >
> > I had this problem with GRIB data a few years ago.
> I
> > got a small
> > program to perform a byteswap and this worked very
> > good.
> > attached is the program and a makefile to compile
> it
> > with GCC.??????
> > Good luck,
> >
> > Kees van Vliet
> >
> > On Oct 19, 2007, at 4:40 PM, Ioannis A. Vamvakas
> > wrote:
> >
> > > Dear all,
> > >
> > > Has anybody confronted in the past the so-called
> > NUXI problem? That
> > > is,
> > > working in a little_endian machine to generate
> > big_endian GRIB files?
> > >
> > > I'd appreciate any help on how you dealt with
> the
> > problem!
> > >
> > > Thanks,
> > >
> > > --
> > > Ioannis A. Vamvakas
> > > Hellenic Center for Marine Research
> > > Institute of Oceanography
> > > 46.7 Km. Athens-Sounio Ave.
> > > GR-193 13,ANAVYSSOS,Greece
> > > Tel.+30-22910-7-6399, Fax: +30-22910-7-6323
> > > Cell Phone: +30-697-580-1696
> > >
> >
> >
> >
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


From yadav_grads at YAHOO.CO.IN  Tue Oct 23 08:22:27 2007
From: yadav_grads at YAHOO.CO.IN (Ramesh Kumar Yadav)
Date: Tue, 23 Oct 2007 13:22:27 +0100
Subject: formatting
In-Reply-To: <802330.597.qm@web62207.mail.re1.yahoo.com>
Message-ID: <TUE.23.OCT.2007.132227.0100.>

Dear users,

I want to write binary file into ASCII in some predefine format using GrADS. Please let me know the format statement for creating the output file.

Thanks in advance



---------------------------------
 Why delete messages? Unlimited storage is just a click away.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071023/89ab22c6/attachment.html 

From hoot at PTPNOW.COM  Tue Oct 23 08:55:52 2007
From: hoot at PTPNOW.COM (Hoot Thompson)
Date: Tue, 23 Oct 2007 08:55:52 -0400
Subject: Grads io pattern
Message-ID: <TUE.23.OCT.2007.085552.0400.>

This may seem like a clumsy question but I'm trying to understand the grads
io pattern to/from storage and whether or not it's tunable (request size,
block size, etc.) to make use of high performance RAID devices.

Make sense?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071023/af559cc4/attachment.html 

From MrSpock29 at COMCAST.NET  Tue Oct 23 11:25:40 2007
From: MrSpock29 at COMCAST.NET (Jack Ordille)
Date: Tue, 23 Oct 2007 17:25:40 +0200
Subject: 1971-2000 gridded Normals
Message-ID: <TUE.23.OCT.2007.172540.0200.>

On Tue, 9 Oct 2007 16:18:46 +0200, Meredith Croke <mcroke at AIRDAT.COM>
wrote:

>Hi Everyone,
>
>I am looking for a gridded dataset of the 1971-2000 daily normals, or
>climatology for this period of time.  Specifically I would like to get the
>30 year average for 850 mb Tmp, Surface Tmp, and 500 mb GPH.  I know I can
>ftp each year's files, but I was wondering if anyone has a file that has
>already computed the 30 year average.
>
>Thank you.
>
>Meredith

Yes,

This is something I would be interested in as well.


From simone.marras at BSC.ES  Tue Oct 23 12:16:58 2007
From: simone.marras at BSC.ES (Simone Marras)
Date: Tue, 23 Oct 2007 18:16:58 +0200
Subject: 1971-2000 gridded Normals
In-Reply-To: <20071023152601.39E992064A@mx2.cineca.it>
Message-ID: <TUE.23.OCT.2007.181658.0200.>

I apologize for the wrong email that I've just sent by mistake.

All the best,

Simone

Jack Ordille wrote:
> On Tue, 9 Oct 2007 16:18:46 +0200, Meredith Croke <mcroke at AIRDAT.COM>
> wrote:
>
>> Hi Everyone,
>>
>> I am looking for a gridded dataset of the 1971-2000 daily normals, or
>> climatology for this period of time.  Specifically I would like to get the
>> 30 year average for 850 mb Tmp, Surface Tmp, and 500 mb GPH.  I know I can
>> ftp each year's files, but I was wondering if anyone has a file that has
>> already computed the 30 year average.
>>
>> Thank you.
>>
>> Meredith
>
> Yes,
>
> This is something I would be interested in as well.


From esertel at ENVSCI.RUTGERS.EDU  Tue Oct 23 12:07:30 2007
From: esertel at ENVSCI.RUTGERS.EDU (Elif SERTEL)
Date: Tue, 23 Oct 2007 12:07:30 -0400
Subject: conversion to txt file
In-Reply-To: <20071023152601.39E992064A@mx2.cineca.it>
Message-ID: <TUE.23.OCT.2007.120730.0400.>

Hi,

I am using the folowing script to create txt files from my model output data.

'set grads off'
'set gxout print'
'set prnopts %10.5e 1 1'
'set z 1'
'set lat 41.67'
'set lon 26.57'
'set t 1 95'
'd t2-273.16'
say result
write('tempedrn.txt',result,append)
'reinit'

However, when I took time "t" higher then 99, I had en error:

Error reading 2 bytes at location 426501748

What should I do to get values in .txt format for t>99.

Thanks,
Elif.


From simone.marras at BSC.ES  Tue Oct 23 12:15:49 2007
From: simone.marras at BSC.ES (Simone Marras)
Date: Tue, 23 Oct 2007 18:15:49 +0200
Subject: 1971-2000 gridded Normals
In-Reply-To: <20071023152601.39E992064A@mx2.cineca.it>
Message-ID: <TUE.23.OCT.2007.181549.0200.>

Hola, perdona, me paso la fecha. Si posible, me gustaria aun participar

Gracias

Simone Marras
EARTH Sciences

Jack Ordille wrote:
> On Tue, 9 Oct 2007 16:18:46 +0200, Meredith Croke <mcroke at AIRDAT.COM>
> wrote:
>
>> Hi Everyone,
>>
>> I am looking for a gridded dataset of the 1971-2000 daily normals, or
>> climatology for this period of time.  Specifically I would like to get the
>> 30 year average for 850 mb Tmp, Surface Tmp, and 500 mb GPH.  I know I can
>> ftp each year's files, but I was wondering if anyone has a file that has
>> already computed the 30 year average.
>>
>> Thank you.
>>
>> Meredith
>
> Yes,
>
> This is something I would be interested in as well.


From mapurves at YAHOO.CA  Tue Oct 23 19:01:33 2007
From: mapurves at YAHOO.CA (Michael Purves)
Date: Tue, 23 Oct 2007 16:01:33 -0700
Subject: GRADSUSR Digest - 22 Oct 2007 to 23 Oct 2007 (#2007-248)
Message-ID: <TUE.23.OCT.2007.160133.0700.>

Barbara,

   Perfect. Xeroxes are fine. As long as they all add up to $1,500 or more that's fine - I don't need them all. You're a dear, thank you.

   Mary and I will be out so you can just drop them off in the mailbox, and I will bring you a cheque for $500 in the morning.

Michael

----- Original Message ----
From: Automatic digest processor <LISTSERV at LIST.CINECA.IT>
To: Recipients of GRADSUSR digests <GRADSUSR at LIST.CINECA.IT>
Sent: Tuesday, October 23, 2007 3:00:43 PM
Subject: GRADSUSR Digest - 22 Oct 2007 to 23 Oct 2007 (#2007-248)

There are 9 messages totalling 705 lines in this issue.

Topics of the day:

  1. NEDIT (2)
  2. the SCRIPT
  3. formatting
  4. Grads io pattern
  5. 1971-2000 gridded Normals (3)
  6. conversion to txt file

----------------------------------------------------------------------

Date:    Mon, 22 Oct 2007 17:21:13 -0700
From:    Daniel Fritz <prodicalboxer at YAHOO.COM>
Subject: NEDIT

HELLO ALL,
   I have writte a script earlier, and I got some
Hurricane data from the UNISYS weather web site
I made a spreadsheet out of it and how do you cut and
paste to NEDIT???  here is my data...so that the file
name at the top of the script could read it?

Floyd 1         -58.9   19.1    09//10/12Z      70      989
Floyd 1 -59.2   19.3    09/10/15Z       70      989
Floyd 1 -59.7   19.9    09/10/18Z       70      989
Floyd 1 -60     20.5    09/10/21Z       70      975
Floyd 1 -60.4   20.8    09/11/00Z       75      971
Floyd 1 60.8    21.1    09/11/03Z       80      971
Floyd 2 -61.6   21.7    09/11/09Z       90      963
Floyd 2 -62.4   22.2    09/11/15Z       95      962
Floyd 2 -63.5   22.7    09/11/21Z       95      966
Floyd 2 -64.5   22.7    09/12/03Z       95      967
Floyd 2 -65.9   22.8    09/12/09Z       95      940
Floyd 3 -66.6   23      09//10/12Z      105     955
Floyd 3 -67.5   23.2    09/12/18Z       105     955
Floyd 3 -68.2   23.4    09/12/21Z       110     940
Floyd 4 -68.7   23.5    09/13/00Z       125     932
Floyd 4 -69.3   23.6    09/13/03Z       125     931
Floyd 4 -70     23.6    09/13/06Z       130     923
Floyd 4 -70.6   23.7    09/13/09Z       135     922
Floyd 4 -71.4   23.9    09/13/12Z       135     921
Floyd 4 -72.1   24.1    09/13/15Z       135     921
Floyd 4 -73     24.2    09/13/18Z       135     926
Floyd 4 -73.7   24.2    09/13/21Z       135     923
Floyd 4 -74.1   24.4    09/14/00Z       135     924
Floyd 4 -74.7   24.5    09/14/03Z       135     924
Floyd 4 -75.3   24.9    09/14/06Z       135     928
Floyd 4 -75.9   25.1    09/14/09Z       135     927
Floyd 4 -76.2   25.4    09/14/12Z       130     929
Floyd 4 -76.8   25.7    09//14/15Z      125     932
Floyd 4 -77     26      09/14/18Z       120     933
Floyd 4 -77.4   26.5    09/14/21Z       120     929
Floyd 4 -77.6   27.1    09/15/00Z       120     934
Floyd 4 -77.9   27.7    09/15/03Z       120     933
Floyd 4 -78.5   28.2    09/15/06Z       120     935
Floyd 4 -78.8   28.8    09/15/09Z       120     938
Floyd 4 -78.8   29.3    09/15/12Z       115     941
Floyd 3 -79     29.9    09/15/15Z       110     943
Floyd 3 -79.1   30.3    09/15/17Z       110     946
Floyd 3 -79.1   30.8    09/15/19Z       105     947
Floyd 3 -79     31.3    09/15/21Z       100     949
Floyd 3 -78.7   32.1    09/15/23Z       100     949
Floyd 3 -78.6   32.4    09/16/01Z       100     950
Floyd 3 -78.3   32.9    09/16/03Z       100     952
Floyd 2 -78.1   33.3    09//16/05Z      95      952
Floyd 2 -77.9   34      09/16/07Z       95      955
Floyd 2 -77.6   34.5    09/16/09Z       90      956
Floyd 2 -77.1   35.2    09/16/11Z       85      960
Floyd 1 -76.6   36      09/16/13Z       80      962
Floyd 1 -76     36.8    09/16/15Z       70      967
Floyd 1 -75.2   37.8    09/16/18Z       65      974
        thanks
          DANNY















--- Kees van Vliet <kees at AEOLIS.NL> wrote:

> Hi,
>
> I had this problem with GRIB data a few years ago. I
> got a small
> program to perform a byteswap and this worked very
> good.
> attached is the program and a makefile to compile it
> with GCC.??
> Good luck,
>
> Kees van Vliet
>
> On Oct 19, 2007, at 4:40 PM, Ioannis A. Vamvakas
> wrote:
>
> > Dear all,
> >
> > Has anybody confronted in the past the so-called
> NUXI problem? That
> > is,
> > working in a little_endian machine to generate
> big_endian GRIB files?
> >
> > I'd appreciate any help on how you dealt with the
> problem!
> >
> > Thanks,
> >
> > --
> > Ioannis A. Vamvakas
> > Hellenic Center for Marine Research
> > Institute of Oceanography
> > 46.7 Km. Athens-Sounio Ave.
> > GR-193 13,ANAVYSSOS,Greece
> > Tel.+30-22910-7-6399, Fax: +30-22910-7-6323
> > Cell Phone: +30-697-580-1696
> >
>
>
>
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

------------------------------

Date:    Mon, 22 Oct 2007 22:25:21 -0700
From:    Daniel Fritz <prodicalboxer at YAHOO.COM>
Subject: the SCRIPT

Hello ALL,
 I am still coming up with the same error....I am
running a hurricanetrack code
here is my script

filnam='/home2/fritz/script/Floyd.dat'

'draw map'

while (1)
res = read(filnam)
rc = sublin(res,1)

if (rc > 0)
* Check if there is a problem reading
if (rc = 2)
say 'EOF - Finished reading 'filnam
res = close(filnam)
break
else
say rc ' Error while reading 'filnam
res = close(filnam)
break
endif
endif

* No problems
* Step 1 - read in the position

datum = sublin(res,2)
dateline = subwrd(datum,1)
longitude = subwrd(datum,2)
latitude = subwrd(datum,3)


* Step 2 - convert lat/lon to page position
'd ugrd10m.1;vgrd10m.1;mag(ugrd10m.1,vgrd10m.1)'
x0 = subwrd(result,3)
y0 = subwrd(result,6)

* Step 3 - plot the position on the page
'draw mark 2 'x0' 'y0' 0.1'
endwhile
 here is what I am getting:
 ga-> open_Ydata.gs
ga-> set lon 270 350
LON set to 270 350
ga-> set lat 0 50
LAT set to 0 50
ga-> draw map
ga-> run hurricanetrack_code
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
DRAW error: Syntax is DRAW MARK marktype x y size
EOF - Finished reading /home2/fritz/script/Floyd.dat
ga->

Could someone help me...does anybody have any
suggestion???????
      DANNY














--- Kees van Vliet <kees at AEOLIS.NL> wrote:

> Hi,
>
> I had this problem with GRIB data a few years ago. I
> got a small
> program to perform a byteswap and this worked very
> good.
> attached is the program and a makefile to compile it
> with GCC.??
> Good luck,
>
> Kees van Vliet
>
> On Oct 19, 2007, at 4:40 PM, Ioannis A. Vamvakas
> wrote:
>
> > Dear all,
> >
> > Has anybody confronted in the past the so-called
> NUXI problem? That
> > is,
> > working in a little_endian machine to generate
> big_endian GRIB files?
> >
> > I'd appreciate any help on how you dealt with the
> problem!
> >
> > Thanks,
> >
> > --
> > Ioannis A. Vamvakas
> > Hellenic Center for Marine Research
> > Institute of Oceanography
> > 46.7 Km. Athens-Sounio Ave.
> > GR-193 13,ANAVYSSOS,Greece
> > Tel.+30-22910-7-6399, Fax: +30-22910-7-6323
> > Cell Phone: +30-697-580-1696
> >
>
>
>
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

------------------------------

Date:    Tue, 23 Oct 2007 05:21:24 -0700
From:    Viviane Silva <viviane_silva1 at YAHOO.COM>
Subject: Re: NEDIT

Hi Daniel,
If you are using excel, just save the file as
"Formatted Text (space delimited)". The extension of
the file will be .prn (same as .txt), then you can
open it in nedit.

Viviane



--- Daniel Fritz <prodicalboxer at YAHOO.COM> wrote:

> HELLO ALL,
>    I have writte a script earlier, and I got some
> Hurricane data from the UNISYS weather web site
> I made a spreadsheet out of it and how do you cut
> and
> paste to NEDIT???  here is my data...so that the
> file
> name at the top of the script could read it?
>
> Floyd 1         -58.9   19.1    09//10/12Z      70
>    989
> Floyd 1 -59.2   19.3    09/10/15Z       70      989
> Floyd 1 -59.7   19.9    09/10/18Z       70      989
> Floyd 1 -60     20.5    09/10/21Z       70      975
> Floyd 1 -60.4   20.8    09/11/00Z       75      971
> Floyd 1 60.8    21.1    09/11/03Z       80      971
> Floyd 2 -61.6   21.7    09/11/09Z       90      963
> Floyd 2 -62.4   22.2    09/11/15Z       95      962
> Floyd 2 -63.5   22.7    09/11/21Z       95      966
> Floyd 2 -64.5   22.7    09/12/03Z       95      967
> Floyd 2 -65.9   22.8    09/12/09Z       95      940
> Floyd 3 -66.6   23      09//10/12Z      105     955
> Floyd 3 -67.5   23.2    09/12/18Z       105     955
> Floyd 3 -68.2   23.4    09/12/21Z       110     940
> Floyd 4 -68.7   23.5    09/13/00Z       125     932
> Floyd 4 -69.3   23.6    09/13/03Z       125     931
> Floyd 4 -70     23.6    09/13/06Z       130     923
> Floyd 4 -70.6   23.7    09/13/09Z       135     922
> Floyd 4 -71.4   23.9    09/13/12Z       135     921
> Floyd 4 -72.1   24.1    09/13/15Z       135     921
> Floyd 4 -73     24.2    09/13/18Z       135     926
> Floyd 4 -73.7   24.2    09/13/21Z       135     923
> Floyd 4 -74.1   24.4    09/14/00Z       135     924
> Floyd 4 -74.7   24.5    09/14/03Z       135     924
> Floyd 4 -75.3   24.9    09/14/06Z       135     928
> Floyd 4 -75.9   25.1    09/14/09Z       135     927
> Floyd 4 -76.2   25.4    09/14/12Z       130     929
> Floyd 4 -76.8   25.7    09//14/15Z      125     932
> Floyd 4 -77     26      09/14/18Z       120     933
> Floyd 4 -77.4   26.5    09/14/21Z       120     929
> Floyd 4 -77.6   27.1    09/15/00Z       120     934
> Floyd 4 -77.9   27.7    09/15/03Z       120     933
> Floyd 4 -78.5   28.2    09/15/06Z       120     935
> Floyd 4 -78.8   28.8    09/15/09Z       120     938
> Floyd 4 -78.8   29.3    09/15/12Z       115     941
> Floyd 3 -79     29.9    09/15/15Z       110     943
> Floyd 3 -79.1   30.3    09/15/17Z       110     946
> Floyd 3 -79.1   30.8    09/15/19Z       105     947
> Floyd 3 -79     31.3    09/15/21Z       100     949
> Floyd 3 -78.7   32.1    09/15/23Z       100     949
> Floyd 3 -78.6   32.4    09/16/01Z       100     950
> Floyd 3 -78.3   32.9    09/16/03Z       100     952
> Floyd 2 -78.1   33.3    09//16/05Z      95      952
> Floyd 2 -77.9   34      09/16/07Z       95      955
> Floyd 2 -77.6   34.5    09/16/09Z       90      956
> Floyd 2 -77.1   35.2    09/16/11Z       85      960
> Floyd 1 -76.6   36      09/16/13Z       80      962
> Floyd 1 -76     36.8    09/16/15Z       70      967
> Floyd 1 -75.2   37.8    09/16/18Z       65      974
>         thanks
>           DANNY
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --- Kees van Vliet <kees at AEOLIS.NL> wrote:
>
> > Hi,
> >
> > I had this problem with GRIB data a few years ago.
> I
> > got a small
> > program to perform a byteswap and this worked very
> > good.
> > attached is the program and a makefile to compile
> it
> > with GCC.??
> > Good luck,
> >
> > Kees van Vliet
> >
> > On Oct 19, 2007, at 4:40 PM, Ioannis A. Vamvakas
> > wrote:
> >
> > > Dear all,
> > >
> > > Has anybody confronted in the past the so-called
> > NUXI problem? That
> > > is,
> > > working in a little_endian machine to generate
> > big_endian GRIB files?
> > >
> > > I'd appreciate any help on how you dealt with
> the
> > problem!
> > >
> > > Thanks,
> > >
> > > --
> > > Ioannis A. Vamvakas
> > > Hellenic Center for Marine Research
> > > Institute of Oceanography
> > > 46.7 Km. Athens-Sounio Ave.
> > > GR-193 13,ANAVYSSOS,Greece
> > > Tel.+30-22910-7-6399, Fax: +30-22910-7-6323
> > > Cell Phone: +30-697-580-1696
> > >
> >
> >
> >
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

------------------------------

Date:    Tue, 23 Oct 2007 13:22:27 +0100
From:    Ramesh Kumar Yadav <yadav_grads at YAHOO.CO.IN>
Subject: formatting

--0-476381272-1193142147=:92173
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dear users,

I want to write binary file into ASCII in some predefine format using
 GrADS. Please let me know the format statement for creating the output
 file.

Thanks in advance



---------------------------------
 Why delete messages? Unlimited storage is just a click away.
--0-476381272-1193142147=:92173
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dear users,<br><br>I want to write binary file into ASCII in some
 predefine format using GrADS. Please let me know the format statement for
 creating the output file.<br><br><b><i>Thanks in
 advance<br></i></b><br><p> 



      <!--1--><hr size=1></hr> Why delete messages? Unlimited storage
 is <a
 href="http://in.rd.yahoo.com/tagline_mail_1/*http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/">just
 a click away.</a>
--0-476381272-1193142147=:92173--

------------------------------

Date:    Tue, 23 Oct 2007 08:55:52 -0400
From:    Hoot Thompson <hoot at PTPNOW.COM>
Subject: Grads io pattern

This is a multi-part message in MIME format.

------=_NextPart_000_002E_01C81552.83E25950
Content-Type: text/plain;
        charset="US-ASCII"
Content-Transfer-Encoding: 7bit

This may seem like a clumsy question but I'm trying to understand the
 grads
io pattern to/from storage and whether or not it's tunable (request
 size,
block size, etc.) to make use of high performance RAID devices.

Make sense?

------=_NextPart_000_002E_01C81552.83E25950
Content-Type: text/html;
        charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7036.0">
<TITLE>Grads io pattern</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">This may seem like a clumsy question =
but I'm trying to understand the grads io pattern to/from storage and =
whether or not it's tunable (request size, block size, etc.) to make
 use =
of high performance RAID devices.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Make sense?</FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_002E_01C81552.83E25950--

------------------------------

Date:    Tue, 23 Oct 2007 17:25:40 +0200
From:    Jack Ordille <MrSpock29 at COMCAST.NET>
Subject: Re: 1971-2000 gridded Normals

On Tue, 9 Oct 2007 16:18:46 +0200, Meredith Croke <mcroke at AIRDAT.COM>
wrote:

>Hi Everyone,
>
>I am looking for a gridded dataset of the 1971-2000 daily normals, or
>climatology for this period of time.  Specifically I would like to get
 the
>30 year average for 850 mb Tmp, Surface Tmp, and 500 mb GPH.  I know I
 can
>ftp each year's files, but I was wondering if anyone has a file that
 has
>already computed the 30 year average.
>
>Thank you.
>
>Meredith

Yes,

This is something I would be interested in as well.

------------------------------

Date:    Tue, 23 Oct 2007 18:16:58 +0200
From:    Simone Marras <simone.marras at BSC.ES>
Subject: Re: 1971-2000 gridded Normals

I apologize for the wrong email that I've just sent by mistake.

All the best,

Simone

Jack Ordille wrote:
> On Tue, 9 Oct 2007 16:18:46 +0200, Meredith Croke <mcroke at AIRDAT.COM>
> wrote:
>
>> Hi Everyone,
>>
>> I am looking for a gridded dataset of the 1971-2000 daily normals,
 or
>> climatology for this period of time.  Specifically I would like to
 get the
>> 30 year average for 850 mb Tmp, Surface Tmp, and 500 mb GPH.  I know
 I can
>> ftp each year's files, but I was wondering if anyone has a file that
 has
>> already computed the 30 year average.
>>
>> Thank you.
>>
>> Meredith
>
> Yes,
>
> This is something I would be interested in as well.

------------------------------

Date:    Tue, 23 Oct 2007 12:07:30 -0400
From:    Elif SERTEL <esertel at ENVSCI.RUTGERS.EDU>
Subject: conversion to txt file

Hi,

I am using the folowing script to create txt files from my model output
 data.

'set grads off'
'set gxout print'
'set prnopts %10.5e 1 1'
'set z 1'
'set lat 41.67'
'set lon 26.57'
'set t 1 95'
'd t2-273.16'
say result
write('tempedrn.txt',result,append)
'reinit'

However, when I took time "t" higher then 99, I had en error:

Error reading 2 bytes at location 426501748

What should I do to get values in .txt format for t>99.

Thanks,
Elif.

------------------------------

Date:    Tue, 23 Oct 2007 18:15:49 +0200
From:    Simone Marras <simone.marras at BSC.ES>
Subject: Re: 1971-2000 gridded Normals

Hola, perdona, me paso la fecha. Si posible, me gustaria aun participar

Gracias

Simone Marras
EARTH Sciences

Jack Ordille wrote:
> On Tue, 9 Oct 2007 16:18:46 +0200, Meredith Croke <mcroke at AIRDAT.COM>
> wrote:
>
>> Hi Everyone,
>>
>> I am looking for a gridded dataset of the 1971-2000 daily normals,
 or
>> climatology for this period of time.  Specifically I would like to
 get the
>> 30 year average for 850 mb Tmp, Surface Tmp, and 500 mb GPH.  I know
 I can
>> ftp each year's files, but I was wondering if anyone has a file that
 has
>> already computed the 30 year average.
>>
>> Thank you.
>>
>> Meredith
>
> Yes,
>
> This is something I would be interested in as well.

------------------------------

End of GRADSUSR Digest - 22 Oct 2007 to 23 Oct 2007 (#2007-248)
***************************************************************






      ____________________________________________________ 
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now at
http://ca.toolbar.yahoo.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071023/f3a94b9f/attachment.html 

From sajjad_met at HOTMAIL.COM  Wed Oct 24 06:16:13 2007
From: sajjad_met at HOTMAIL.COM (sajjad saeed)
Date: Wed, 24 Oct 2007 15:16:13 +0500
Subject: BCC RegCM output data with Grads
In-Reply-To: <021801c806a1$86e4c4e0$94ae4ea0$@com>
Message-ID: <WED.24.OCT.2007.151613.0500.>

Dear all,
I am using regional climate model of Beijing Climate Centre,China. I have a problem.  When I open the file I get this kind of message
....................................................................................
ga-> open daily_ave91.ctl
Scanning description file:  daily_ave91.ctl
Data file daily_ave_1991.bin is open as file 1
LON set to 42 110.5
LAT set to 0 44.5
LEV set to 1000 1000
Time values set: 1991:5:1:0 1991:5:1:0
Notice: Implied interpolation for file daily_ave91.ctl
 Interpolation will be performed on any data displayed from this file

..................................................................................................................................
Than I used the commond to check file variables

ga-> q file
File 1 : model-output on surface
  Descriptor: daily_ave91.ctl
  Binary: daily_ave_1991.bin
  Type = Gridded
  Xsize = 138  Ysize = 90  Zsize = 1  Tsize = 153
  Number of Variables = 17
    tamxd 0 99 daily maximum surface temperature (k)
    tamnd 0 99 daily minimum surface temperature (k)
    psdnd 0 99 daily averaged surface pressure (cb)
    soldd 0 99 daily averaged direct solar fluxat the surface (W/m2)
    difdd 0 99 daily averaged diffuse solar fluxat the surface (W/m2)
    frudd 0 99 daily averaged net upward longwave fluxat the surface (W/m2)
    sswdd 0 99 daily averaged upper soil moisture (mm)
    rswdd 0 99 daily averaged root zone soil moisture (mm)
    evapd 0 99 daily averaged evaporative flux (kg/m**2/s)
    senhd 0 99 daily averaged sensible heat flux (w/m**2)
    rnosd 0 99 daily accumulated surface runoff (mm)
    rnodd 0 99 daily accumulated total runoff (mm)
    rfddd 0 99 daily accumulated rainfall (mm)
    cqvdd 0 99 daily averaged column water vapor (g/m**2)
    cqcdd 0 99 daily averaged column cloud water (g/m**2)
    cqidd 0 99 daily averaged column cloud ice (g/m**2)
    dtaud 0 99 daily averaged cloud optical depth
.....................................................................................................................................

Now I want to see a variable

ga-> d rfddd
Notice:  Automatic Grid Interpolation Taking Place
Contouring: nan to nan interval inf

I donot get any display on the screen

I than selected set clevs 0 1 2

ga-> d rfddd
Notice:  Automatic Grid Interpolation Taking Place
Contouring at clevs =  0 1 2 3

I got the display at the lower (south) of the domain. This is a very small belt.

I am unable to recoganize the problem. Any help in this regard will be highly appreciated.

With regards

Sajjad Saeed


_________________________________________________________________
Connect to the next generation of MSN Messenger
http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline


From ela at COLA.IGES.ORG  Wed Oct 24 11:37:23 2007
From: ela at COLA.IGES.ORG (Eric Altshuler)
Date: Wed, 24 Oct 2007 11:37:23 -0400
Subject: BCC RegCM output data with Grads
In-Reply-To: <BAY128-W26CFD0A6F1C576ED9ECDEBFB940@phx.gbl>
Message-ID: <WED.24.OCT.2007.113723.0400.>

Sajjad,

This problem might be happening because the data has the opposite byte ordering from what your machine has. Try adding one of these lines to your ctl file and see which one works:

options big_endian

options little_endian

One of these choices should work. If not, you have some other problem with your data, or it might have header bytes that grads does not know about (you can also specify header properties in the ctl file). See http://grads.iges.org/grads/gadoc/index.html

Best regards,


Eric L. Altshuler
Assistant Research Scientist
Center for Ocean-Land-Atmosphere Studies
4041 Powder Mill Road, Suite 302
Calverton, MD 20705-3106
USA

E-mail: ela at cola.iges.org
Phone: (301) 902-1257
Fax: (301) 595-9793

----- Original Message -----
From: "sajjad saeed" <sajjad_met at HOTMAIL.COM>
To: GRADSUSR at LIST.CINECA.IT
Sent: Wednesday, October 24, 2007 6:16:13 AM (GMT-0500) America/New_York
Subject: BCC RegCM output data with Grads

Dear all,
I am using regional climate model of Beijing Climate Centre,China. I have a problem.  When I open the file I get this kind of message
....................................................................................
ga-> open daily_ave91.ctl
Scanning description file:  daily_ave91.ctl
Data file daily_ave_1991.bin is open as file 1
LON set to 42 110.5
LAT set to 0 44.5
LEV set to 1000 1000
Time values set: 1991:5:1:0 1991:5:1:0
Notice: Implied interpolation for file daily_ave91.ctl
 Interpolation will be performed on any data displayed from this file

..................................................................................................................................
Than I used the commond to check file variables

ga-> q file
File 1 : model-output on surface
  Descriptor: daily_ave91.ctl
  Binary: daily_ave_1991.bin
  Type = Gridded
  Xsize = 138  Ysize = 90  Zsize = 1  Tsize = 153
  Number of Variables = 17
    tamxd 0 99 daily maximum surface temperature (k)
    tamnd 0 99 daily minimum surface temperature (k)
    psdnd 0 99 daily averaged surface pressure (cb)
    soldd 0 99 daily averaged direct solar fluxat the surface (W/m2)
    difdd 0 99 daily averaged diffuse solar fluxat the surface (W/m2)
    frudd 0 99 daily averaged net upward longwave fluxat the surface (W/m2)
    sswdd 0 99 daily averaged upper soil moisture (mm)
    rswdd 0 99 daily averaged root zone soil moisture (mm)
    evapd 0 99 daily averaged evaporative flux (kg/m**2/s)
    senhd 0 99 daily averaged sensible heat flux (w/m**2)
    rnosd 0 99 daily accumulated surface runoff (mm)
    rnodd 0 99 daily accumulated total runoff (mm)
    rfddd 0 99 daily accumulated rainfall (mm)
    cqvdd 0 99 daily averaged column water vapor (g/m**2)
    cqcdd 0 99 daily averaged column cloud water (g/m**2)
    cqidd 0 99 daily averaged column cloud ice (g/m**2)
    dtaud 0 99 daily averaged cloud optical depth
.....................................................................................................................................

Now I want to see a variable

ga-> d rfddd
Notice:  Automatic Grid Interpolation Taking Place
Contouring: nan to nan interval inf

I donot get any display on the screen

I than selected set clevs 0 1 2

ga-> d rfddd
Notice:  Automatic Grid Interpolation Taking Place
Contouring at clevs =  0 1 2 3

I got the display at the lower (south) of the domain. This is a very small belt.

I am unable to recoganize the problem. Any help in this regard will be highly appreciated.

With regards

Sajjad Saeed


_________________________________________________________________
Connect to the next generation of MSN Messenger
http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline


From eric192 at 163.COM  Wed Oct 24 20:59:22 2007
From: eric192 at 163.COM (lifei)
Date: Thu, 25 Oct 2007 08:59:22 +0800
Subject: about cdiff
Message-ID: <THU.25.OCT.2007.085922.0800.>

  Hi all,   I am confused when using cdiff() function, the help doc tells that "Result values at the grid boundaries are set to missing", and I have difficulties when coping with writing the .ctl file created by that function.   My initial .grd data have a horizontal resolution of 360*180,with one time and height level,that is 360*180*4=259200bytes, when I use cdiff() function, it is 260640bytes, which means 360*181*4 or 362*180*4, by the way, I made the centered difference operation along the x and y direction and created two .grd files by using the "fwrite" command. When I display the new data , it only shows the ground map, and "Contouring: nan to nan interval inf ". Please give me some help by writing "XDEF and YDEF" in the newly created .ctl file .  Thanks!                                                  Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071025/a88cdebb/attachment.html 

From sajjad_met at HOTMAIL.COM  Thu Oct 25 01:15:37 2007
From: sajjad_met at HOTMAIL.COM (sajjad saeed)
Date: Thu, 25 Oct 2007 10:15:37 +0500
Subject: BCC RegCM output data with Grads
In-Reply-To: <1552262397.57571193240243088.JavaMail.root@mail.iges.org>
Message-ID: <THU.25.OCT.2007.101537.0500.>


Dear Eric L. Altshuler,
 
Thankyou very much for your kind guidence and email. Now it works.
 
Thankyou again
 
Sajjad Saeed
******************************************************************************Meteorologist,Pakistan Meteorological Department (PMD),P.O.Box 1214, Sector H-8/2, Islamabad, Pakistan.Ph; 0092-51-9250360-3,7, Fax:0092-51-9250368Research Fellow,Global Change Impact Studies Centre (GCISC),First Floor, Saudi Pak Tower, Blue Area, Islamabad, Pakistan.Ph: +92-51-9219785, Fax: +92-51-9219787Mob:+92-334-5419962 Email: sajjad_met at hotmail.com. sajjad2pk2 at yahoo.com sajjad.saeed at gcisc.org.pk > Date: Wed, 24 Oct 2007 11:37:23 -0400> From: ela at COLA.IGES.ORG> Subject: Re: BCC RegCM output data with Grads> To: GRADSUSR at LIST.CINECA.IT> > Sajjad,> > This problem might be happening because the data has the opposite byte ordering from what your machine has. Try adding one of these lines to your ctl file and see which one works:> > options big_endian> > options little_endian> > One of these choices should work. If not, you have some other problem with your data, or it might have header bytes that grads does not know about (you can also specify header properties in the ctl file). See http://grads.iges.org/grads/gadoc/index.html> > Best regards,> > > Eric L. Altshuler> Assistant Research Scientist> Center for Ocean-Land-Atmosphere Studies> 4041 Powder Mill Road, Suite 302> Calverton, MD 20705-3106> USA> > E-mail: ela at cola.iges.org> Phone: (301) 902-1257> Fax: (301) 595-9793> > ----- Original Message -----> From: "sajjad saeed" <sajjad_met at HOTMAIL.COM>> To: GRADSUSR at LIST.CINECA.IT> Sent: Wednesday, October 24, 2007 6:16:13 AM (GMT-0500) America/New_York> Subject: BCC RegCM output data with Grads> > Dear all,> I am using regional climate model of Beijing Climate Centre,China. I have a problem. When I open the file I get this kind of message> ....................................................................................> ga-> open daily_ave91.ctl> Scanning description file: daily_ave91.ctl> Data file daily_ave_1991.bin is open as file 1> LON set to 42 110.5> LAT set to 0 44.5> LEV set to 1000 1000> Time values set: 1991:5:1:0 1991:5:1:0> Notice: Implied interpolation for file daily_ave91.ctl> Interpolation will be performed on any data displayed from this file> > ..................................................................................................................................> Than I used the commond to check file variables> > ga-> q file> File 1 : model-output on surface> Descriptor: daily_ave91.ctl> Binary: daily_ave_1991.bin> Type = Gridded> Xsize = 138 Ysize = 90 Zsize = 1 Tsize = 153> Number of Variables = 17> tamxd 0 99 daily maximum surface temperature (k)> tamnd 0 99 daily minimum surface temperature (k)> psdnd 0 99 daily averaged surface pressure (cb)> soldd 0 99 daily averaged direct solar fluxat the surface (W/m2)> difdd 0 99 daily averaged diffuse solar fluxat the surface (W/m2)> frudd 0 99 daily averaged net upward longwave fluxat the surface (W/m2)> sswdd 0 99 daily averaged upper soil moisture (mm)> rswdd 0 99 daily averaged root zone soil moisture (mm)> evapd 0 99 daily averaged evaporative flux (kg/m**2/s)> senhd 0 99 daily averaged sensible heat flux (w/m**2)> rnosd 0 99 daily accumulated surface runoff (mm)> rnodd 0 99 daily accumulated total runoff (mm)> rfddd 0 99 daily accumulated rainfall (mm)> cqvdd 0 99 daily averaged column water vapor (g/m**2)> cqcdd 0 99 daily averaged column cloud water (g/m**2)> cqidd 0 99 daily averaged column cloud ice (g/m**2)> dtaud 0 99 daily averaged cloud optical depth> .....................................................................................................................................> > Now I want to see a variable> > ga-> d rfddd> Notice: Automatic Grid Interpolation Taking Place> Contouring: nan to nan interval inf> > I donot get any display on the screen> > I than selected set clevs 0 1 2> > ga-> d rfddd> Notice: Automatic Grid Interpolation Taking Place> Contouring at clevs = 0 1 2 3> > I got the display at the lower (south) of the domain. This is a very small belt.> > I am unable to recoganize the problem. Any help in this regard will be highly appreciated.> > With regards> > Sajjad Saeed> > > _________________________________________________________________> Connect to the next generation of MSN Messenger> http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline
_________________________________________________________________
Explore the seven wonders of the world
http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071025/27499d42/attachment.html 

From vpk1 at LEICESTER.AC.UK  Thu Oct 25 07:46:28 2007
From: vpk1 at LEICESTER.AC.UK (Kanawade, V.P.)
Date: Thu, 25 Oct 2007 12:46:28 +0100
Subject: Wind vetcor plotting
Message-ID: <THU.25.OCT.2007.124628.0100.>

Dear All,
Greetings from Leicester University.
I am trying to plot mean wind vector for July 2004. Could you please
have a look at the GrADS code to generate wind vector plot and please
correct and suggest to produce nice and informative plot.

'reinit'
'set display color white'
'c'
'set mpdraw on'
'set arrowhead 0.15
'set arrlab on'
'set map 1 1 7'
'set gxout vector'
'sdfopen F:/uwnd05_1000mb.nc   (uwind file)'
'sdfopen F:/vwnd05_1000mb.nc   (vwind file)'
'set lat -90 90'
'set lon -180 180'
'set lev 1000'
'd uwnd.1;vwnd.2'
'draw title Wind Vector at 1000 hPa   July 2004'
'printim windjul04_1000mb.gif gif'

please see attached wind vector plot.

Then I tired to average u and v component of windfields using following
command but it doesn't work.

'define x =ave(uwnd.1, t=1, t=30)'
'define y=ave(vwnd.2, t=1, t=30)'
'd x;y'

Any suggestions are very much appreciated.
Thank you.


Best regards,
Vijay Kanawade

Ph D Student
Earth Observation Science Group
Space Research Centre
University of Leicester
Leicester, LE1 7RH
Tel: +44 (0) 116 252 2771
Email: vpk1 at le.ac.uk


From matt1 at CEP.RUTGERS.EDU  Thu Oct 25 09:22:25 2007
From: matt1 at CEP.RUTGERS.EDU (Matt Georgescu)
Date: Thu, 25 Oct 2007 09:22:25 -0400
Subject: Wind vetcor plotting
In-Reply-To: <1F2CE8D4B0195E488213E8B8CCF7148606FEB5DB@Saffron.cfs.le.ac.uk>
Message-ID: <THU.25.OCT.2007.092225.0400.>

Vijay,

there is no attached figure in your e-mail.

As regards your question, Eric L. Altshuler provided me with an answer to
a similar query I had some time ago.

If you'd like to take a time average over separate wind components, try
this:

*Define "skipped" version of u and v-wind separately
'define x = skip(ave(uwnd.1, t=1, t=30),5,5)'
'define y = skip(ave(vwnd.2, t=1, t=30),5,5)'
*Resulting vector of "skipped" u and v-wind.
'd x;y'

Here is more on the "skip" function from the GrADS Documentation:
http://grads.iges.org/grads/gadoc/gadocindex.html

matt

On Thu, 25 Oct 2007, Kanawade, V.P. wrote:

> Dear All,
> Greetings from Leicester University.
> I am trying to plot mean wind vector for July 2004. Could you please
> have a look at the GrADS code to generate wind vector plot and please
> correct and suggest to produce nice and informative plot.
>
> 'reinit'
> 'set display color white'
> 'c'
> 'set mpdraw on'
> 'set arrowhead 0.15
> 'set arrlab on'
> 'set map 1 1 7'
> 'set gxout vector'
> 'sdfopen F:/uwnd05_1000mb.nc   (uwind file)'
> 'sdfopen F:/vwnd05_1000mb.nc   (vwind file)'
> 'set lat -90 90'
> 'set lon -180 180'
> 'set lev 1000'
> 'd uwnd.1;vwnd.2'
> 'draw title Wind Vector at 1000 hPa   July 2004'
> 'printim windjul04_1000mb.gif gif'
>
> please see attached wind vector plot.
>
> Then I tired to average u and v component of windfields using following
> command but it doesn't work.
>
> 'define x =ave(uwnd.1, t=1, t=30)'
> 'define y=ave(vwnd.2, t=1, t=30)'
> 'd x;y'
>
> Any suggestions are very much appreciated.
> Thank you.
>
>
> Best regards,
> Vijay Kanawade
>
> Ph D Student
> Earth Observation Science Group
> Space Research Centre
> University of Leicester
> Leicester, LE1 7RH
> Tel: +44 (0) 116 252 2771
> Email: vpk1 at le.ac.uk
>


From poupkou at AUTH.GR  Thu Oct 25 10:27:32 2007
From: poupkou at AUTH.GR (Anastasia Poupkou)
Date: Thu, 25 Oct 2007 17:27:32 +0300
Subject: No subject
Message-ID: <THU.25.OCT.2007.172732.0300.>

Dear GRADS USERS,

We have gridded model results that are projected in Lambert conformal conic projection. We would like to reproject model results in a lat-lon grid of lower resolution than the original data. The main idea is not to perform interpolation in lat-lon grid points but to perform averaging over each lat-lon grid cell. Would you recommend any tool?


Thank you very much.

Kind regards,

Anastasia 




*********************************************
Dr. Anastasia Poupkou                   
Laboratory of Atmospheric Physics    
Aristotle University of Thessaloniki  
PO Box 149, 54 124 Thessaloniki,Greece            
Tel. +30 2310 99 80 09                
Fax. +30 2310 99 80 90                
http://lap.physics.auth.gr            
*********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071025/6b3278ae/attachment.html 

From mying at CITIZ.NET  Thu Oct 25 21:50:33 2007
From: mying at CITIZ.NET (Mying)
Date: Fri, 26 Oct 2007 09:50:33 +0800
Subject: what's matter with my GrADS?
Message-ID: <FRI.26.OCT.2007.095033.0800.>

Dear all,

I need help. I don't know what's the matter with my GrADS(see attached file). It worked OK last week.

ying











_______________________________________________________________________________


????? ????????????????????????????


http://www.citiz.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: error.GIF
Type: image/gif
Size: 19538 bytes
Desc: not available
Url : http://gradsusr.org/pipermail/gradsusr/attachments/20071026/cbc178a0/attachment.gif 

From hallak at MODEL.IAG.USP.BR  Fri Oct 26 01:21:28 2007
From: hallak at MODEL.IAG.USP.BR (Ricardo Hallak)
Date: Fri, 26 Oct 2007 03:21:28 -0200
Subject: what's matter with my GrADS?
In-Reply-To: <200710260950313289713@citiz.net>
Message-ID: <FRI.26.OCT.2007.032128.0200.>

Couldn't it be a virus?
Ricardo

On Fri, 26 Oct 2007 09:50:33 +0800, Mying wrote
> Dear all,
>
> I need help. I don't know what's the matter with my GrADS(see
> attached file). It worked OK last week.
>
> ying
>
>
______________________________________________________________________________
_
>
> ?????????? ????????????????????????????????????????????????????????
>
> http://www.citiz.net


From pkarora66 at GMAIL.COM  Fri Oct 26 02:29:43 2007
From: pkarora66 at GMAIL.COM (pradeep arora)
Date: Fri, 26 Oct 2007 06:29:43 +0000
Subject: grads scripts for thermodynamic indices
Message-ID: <FRI.26.OCT.2007.062943.0000.>

Dear All,

 Regards,

I require grads scripts for plotting various thermodynamic indices (e.g.,
Lifting Index, CAPE, Freezing Level Height etc), so that I can plot x-y
plots at any given time for the entire domain, generated by MM5 & WRF. I am
unable to convert existing scripts for 'plotskew.gs', which is meant to plot
skewt plot for 1-2 points.
Please offer your expertise.
Thanking You all.

Pradeep Arora
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071026/1b5ed947/attachment.html 

From Charles.Seman at NOAA.GOV  Fri Oct 26 14:44:15 2007
From: Charles.Seman at NOAA.GOV (Charles Seman)
Date: Fri, 26 Oct 2007 14:44:15 -0400
Subject: grads scripts for thermodynamic indices
In-Reply-To: <d24fc9a30710252329g2162efbex7ead8f1feb89c35@mail.gmail.com>
Message-ID: <FRI.26.OCT.2007.144415.0400.>

Dear Pradeep Arora,

I'm not sure if this would work, but perhaps in a GrADS script, you
could define a variable containing all zeros, then loop over (x,y) grid
points, run "plotskew.gs" at each grid point, and replace the each
"zero" value of your defined variable with the desired index value from
"plotskew.gs"?
ftp://grads.iges.org/grads/scripts/defval_demo.gs

Chuck

pradeep arora wrote:
> Dear All,
>
>  Regards,
>
> I require grads scripts for plotting various thermodynamic indices
> (e.g., Lifting Index, CAPE, Freezing Level Height etc), so that I can
> plot x-y plots at any given time for the entire domain, generated by
> MM5 & WRF. I am unable to convert existing scripts for ' plotskew.gs
> <http://plotskew.gs>', which is meant to plot skewt plot for 1-2 points.
> Please offer your expertise.
> Thanking You all.
>
> Pradeep Arora

--

Please note that Charles.Seman at noaa.gov should be considered my NOAA
email address, not cjs at gfdl.noaa.gov.

********************************************************************
 Charles Seman                                Charles.Seman at noaa.gov
 U.S. Department of Commerce / NOAA / OAR
 Geophysical Fluid Dynamics Laboratory         voice: (609) 452-6547
 201 Forrestal Road                              fax: (609) 987-5063
 Princeton, NJ  08540-6649            http://www.gfdl.noaa.gov/~cjs/
********************************************************************

"The contents of this message are mine personally and do not reflect
any position of the Government or NOAA."


From hmjbarbosa at GMAIL.COM  Fri Oct 26 16:48:33 2007
From: hmjbarbosa at GMAIL.COM (Henrique Barbosa)
Date: Fri, 26 Oct 2007 18:48:33 -0200
Subject: HDF-SDS Read Error for dtype FLOAT32
Message-ID: <FRI.26.OCT.2007.184833.0200.>

Dear all,

I am trying to open monthly convective/stratiform heating
from TRMM:

http://daac.gsfc.nasa.gov/data/datapool/TRMM/01_Data_Products/02_Gridded/09_Monthly_Heating_CSH/index.html

for which I wrote this simple ctl:

dset ^CSH.021001.6.HDF
dtype hdfsds
undef -9999.9
xdef 720 linear -180.0 0.5
ydef 148 linear -37.0 0.5
zdef 19 levels 0.5 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
tdef 1 linear 00Z01oct2002 1mon
vars 1
LatentHeating=>lh  19 t,x,y latent heat
endvars

Grads opens the ctl successfully but complains when
showing the data with the following message:

ga-> d lh
HDF-SDS Read Error for dtype FLOAT32
Data Request Error:  Error for variable 'lh'
  Error ocurred at column 1
DISPLAY error:  Invalid expression
  Expression = lh

Does anyony know what it means? Any clues how to
solve it? Btw, I am able to read the data with official TRMM
software and write it as a plain binary. Hence it is not
a problem with the data, but with Grads being able
to read the HDF4.

[]'s
Henrique


From zliu at POP600.GSFC.NASA.GOV  Fri Oct 26 17:34:14 2007
From: zliu at POP600.GSFC.NASA.GOV (Zhong Liu)
Date: Fri, 26 Oct 2007 17:34:14 -0400
Subject: HDF-SDS Read Error for dtype FLOAT32
In-Reply-To: <e71668fa0710261348k58936c70ldac891b866f96ea3@mail.gmail.com>
Message-ID: <FRI.26.OCT.2007.173414.0400.>

Dear Henrique Barbosa,

I think you forgot to add the z dimension in the ctl file. Try to add z,
such as,

dset ^CSH.021001.6.HDF
dtype hdfsds
undef -9999.9
xdef 720 linear -180.0 0.5
ydef 148 linear -37.0 0.5
zdef 19 levels 0.5 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
tdef 1 linear 00Z01oct2002 1mon
vars 1
LatentHeating=>lh  19 t,z,x,y latent heat
endvars

Good luck.

Regards,

-Zhong

Henrique Barbosa wrote:
> Dear all,
>
> I am trying to open monthly convective/stratiform heating
> from TRMM:
>
> http://daac.gsfc.nasa.gov/data/datapool/TRMM/01_Data_Products/02_Gridded/09_Monthly_Heating_CSH/index.html
>
> for which I wrote this simple ctl:
>
> dset ^CSH.021001.6.HDF
> dtype hdfsds
> undef -9999.9
> xdef 720 linear -180.0 0.5
> ydef 148 linear -37.0 0.5
> zdef 19 levels 0.5 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
> tdef 1 linear 00Z01oct2002 1mon
> vars 1
> LatentHeating=>lh  19 t,x,y latent heat
> endvars
>
> Grads opens the ctl successfully but complains when
> showing the data with the following message:
>
> ga-> d lh
> HDF-SDS Read Error for dtype FLOAT32
> Data Request Error:  Error for variable 'lh'
>   Error ocurred at column 1
> DISPLAY error:  Invalid expression
>   Expression = lh
>
> Does anyony know what it means? Any clues how to
> solve it? Btw, I am able to read the data with official TRMM
> software and write it as a plain binary. Hence it is not
> a problem with the data, but with Grads being able
> to read the HDF4.
>
> []'s
> Henrique
>
>


--
********************************************************************
* Zhong Liu, Ph.D.                     |  zliu at pop600.gsfc.nasa.gov*
* George Mason University and          |                           *
* NASA Goddard Earth Sciences          |  (301) 614-5764 (voice)   *
* Data and Information Services Center |  (301) 614-5268 (fax)     *
* NASA/GSFC, Code 610.2                |                           *
* Greenbelt. MD. 20771  U.S.A.         |                           *
********************************************************************
* For more information about the Goddard DISC and its services:    *
* http://disc.gsfc.nasa.gov/                                       *
********************************************************************


From jcharlery at UWICHILL.EDU.BB  Sat Oct 27 07:17:21 2007
From: jcharlery at UWICHILL.EDU.BB (John Charlery)
Date: Sat, 27 Oct 2007 13:17:21 +0200
Subject: Grads in Vista
Message-ID: <SAT.27.OCT.2007.131721.0200.>

I have two laptops and two desktop computers with Microsoft Vista Ultimate
installed on all. I installed the win32e version of Grads on each machine
and changed the compatibility property to Windows XP as was suggested by
another user. Grads works fine on one laptop, but does not start on the
other three machines. Whenever I attempt to run the program on those three
machines, it simply displays a window very briefly and nothing else
happens. Does anyone know why Grads only work sometimes with Vista? Any
suggestion to get it to work with Windows Vista will be greatly
appreciated.

Many thanks,
John


From jcharlery at UWICHILL.EDU.BB  Sat Oct 27 07:13:25 2007
From: jcharlery at UWICHILL.EDU.BB (Dr. John Charlery)
Date: Sat, 27 Oct 2007 07:13:25 -0400
Subject: Grads in Vista
In-Reply-To: <e71668fa0710261348k58936c70ldac891b866f96ea3@mail.gmail.com>
Message-ID: <SAT.27.OCT.2007.071325.0400.>

I have two laptops and two desktop computers with Microsoft Vista Ultimate
installed on all. I installed the win32e version of Grads on each machine
and changed the compatibility property to Windows XP as was suggested by
another user. Grads works fine on one laptop, but does not start on the
other three machines. Whenever I attempt to run the program on those three
machines, it simply displays a window very briefly and nothing else happens.
Does anyone know why Grads only work sometimes with Vista? Any suggestion
will be greatly appreciated.

Many thanks,
John


From msponsler at COMCAST.NET  Sat Oct 27 10:58:53 2007
From: msponsler at COMCAST.NET (Mark Sponsler)
Date: Sat, 27 Oct 2007 14:58:53 +0000
Subject: Grads in Vista
Message-ID: <SAT.27.OCT.2007.145853.0000.>

John,
Try creating a shortcut to the grads executable and put it on your desktop. Launch the app from there.
Target: "C:\XXXXXX\PCGrADS\win32e\Grads.exe"
Start in: "C:\XXXX\PCGrADS\win32e\"

I had the same problme in Win XP and then once I got a shortcut set up the window 'stuck'.
The other option is to run it in batch mode.

Also create an empty tmp directory at the root of your C drive: C:\tmp
--
Thanks,
Mark

-------------- Original message --------------
From: "Dr. John Charlery" <jcharlery at UWICHILL.EDU.BB>

> I have two laptops and two desktop computers with Microsoft Vista Ultimate
> installed on all. I installed the win32e version of Grads on each machine
> and changed the compatibility property to Windows XP as was suggested by
> another user. Grads works fine on one laptop, but does not start on the
> other three machines. Whenever I attempt to run the program on those three
> machines, it simply displays a window very briefly and nothing else happens.
> Does anyone know why Grads only work sometimes with Vista? Any suggestion
> will be greatly appreciated.
>
> Many thanks,
> John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071027/6810b46a/attachment.html 

From jcharlery at UWICHILL.EDU.BB  Sat Oct 27 17:25:54 2007
From: jcharlery at UWICHILL.EDU.BB (John Charlery)
Date: Sat, 27 Oct 2007 23:25:54 +0200
Subject: Grads in Vista
Message-ID: <SAT.27.OCT.2007.232554.0200.>

Mark,
Thanks for the suggestions. I tried all of them (even tried re-booting the
machines after the changes), but in each case, the window would vanish
very quickly after clicking the shortcut. Running a batch file with a call
to Grads did not produce anything. I guess there is probably some setting
in Vista which needs to be turned on (or off). I still need some more help!

John


From pertusus at FREE.FR  Sun Oct 28 06:15:10 2007
From: pertusus at FREE.FR (Patrice Dumas)
Date: Sun, 28 Oct 2007 11:15:10 +0100
Subject: example of hdf coards file?
Message-ID: <SUN.28.OCT.2007.111510.0100.>

Hello,

When testing grads, I'd like to use an hdf file that can be opened by
sdfopen. I browsed a bit on the web, but didn't found anything obvious.
Is there an example somewhere?

--
Pat


From donylilium22 at YAHOO.COM  Sun Oct 28 14:42:55 2007
From: donylilium22 at YAHOO.COM (Donata Giglio)
Date: Sun, 28 Oct 2007 19:42:55 +0100
Subject: sigma coordinate
Message-ID: <SUN.28.OCT.2007.194255.0100.>

Hi!

I should plot data from netcdf files (output from an
ocean model) where:

1) only sea points are stored (I could plot 2d
variables using PDF FILE option)

2) sigma coordinate is used instead of z levels
(sigma=(z-surface elevation) / (bottom depth + surface
elevation): I can't plot 3d variables!!

I would like to plot using this sigma coordinate: does
anyone know if it's possible? How should I edit the
decriptor file?

Thank you very much for your help!!

Bye,
Donata


      ___________________________________
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html


From pkarora66 at GMAIL.COM  Mon Oct 29 08:21:56 2007
From: pkarora66 at GMAIL.COM (pradeep arora)
Date: Mon, 29 Oct 2007 12:21:56 +0000
Subject: grads scripts for thermodynamic indices
In-Reply-To: <4722357F.7080301@noaa.gov>
Message-ID: <MON.29.OCT.2007.122156.0000.>

Dear Charles Seman,

 Thanks a lot for the suggestion. I will surely try out ths and come back to
you.
Thanks again.
Pradeep Arora


On 10/26/07, Charles Seman <Charles.Seman at noaa.gov> wrote:
>
> Dear Pradeep Arora,
>
> I'm not sure if this would work, but perhaps in a GrADS script, you
> could define a variable containing all zeros, then loop over (x,y) grid
> points, run "plotskew.gs" at each grid point, and replace the each
> "zero" value of your defined variable with the desired index value from
> "plotskew.gs"?
> ftp://grads.iges.org/grads/scripts/defval_demo.gs
>
> Chuck
>
> pradeep arora wrote:
> > Dear All,
> >
> >  Regards,
> >
> > I require grads scripts for plotting various thermodynamic indices
> > (e.g., Lifting Index, CAPE, Freezing Level Height etc), so that I can
> > plot x-y plots at any given time for the entire domain, generated by
> > MM5 & WRF. I am unable to convert existing scripts for ' plotskew.gs
> > <http://plotskew.gs>', which is meant to plot skewt plot for 1-2 points.
> > Please offer your expertise.
> > Thanking You all.
> >
> > Pradeep Arora
>
> --
>
> Please note that Charles.Seman at noaa.gov should be considered my NOAA
> email address, not cjs at gfdl.noaa.gov.
>
> ********************************************************************
> Charles Seman                                Charles.Seman at noaa.gov
> U.S. Department of Commerce / NOAA / OAR
> Geophysical Fluid Dynamics Laboratory         voice: (609) 452-6547
> 201 Forrestal Road                              fax: (609) 987-5063
> Princeton, NJ  08540-6649            http://www.gfdl.noaa.gov/~cjs/
> ********************************************************************
>
> "The contents of this message are mine personally and do not reflect
> any position of the Government or NOAA."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071029/8f58bb4f/attachment.html 

From jcharlery at UWICHILL.EDU.BB  Mon Oct 29 13:31:39 2007
From: jcharlery at UWICHILL.EDU.BB (John Charlery)
Date: Mon, 29 Oct 2007 18:31:39 +0100
Subject: Grads in Vista
Message-ID: <MON.29.OCT.2007.183139.0100.>

All thanks to a "Good Samaritan" who chose to write to me directly, I now
have a solution to the problem. Here it goes... If after changing the grads
program compatibility feature to WinXP Grads still does not run, then cygwin
needs to installed on the machine with Vista. As it turns out, only the bin
folder in the cygwin installation appears to be required. If you do not
intend to use cygwin for any other application, then the other sub-folders
of cygwin could be deleted. Secondly, replace the file cygwin1.dll in the
win32e folder of PCGrADS with the later version from the bin folder of
cygwin. You are now ready to go. Apparently, the earlier version of
cygwin1.dll which comes packaged with the win32e installation program of
Grads is not what Vista always wants to use.

Thanks again, Robinson!


From azer at ENVSCI.RUTGERS.EDU  Mon Oct 29 17:48:57 2007
From: azer at ENVSCI.RUTGERS.EDU (Mina Azer)
Date: Mon, 29 Oct 2007 17:48:57 -0400
Subject: grads 64bit
Message-ID: <MON.29.OCT.2007.174857.0400.>

I am very new to grads. I was asked to install it on 64bit redhat but
once i run gradsc i get the following error:

gradsc

Grid Analysis and Display System (GrADS) Version 1.8SL11
Copyright (c) 1988-2001 by Brian Doty
Center for Ocean-Land-Atmosphere Studies
Institute for Global Environment and Society
All Rights Reserved

Config: v1.8SL11 32-bit little-endian readline printim

Issue 'q config' command for more information.

Landscape mode? (no for portrait):
GX Package Initialization: Size = 11 8.5
Segmentation fault


I have google-ed grads for 64bit and read docs but nothing help. Would
you please point me to the right docs or just tell me what am I missing.
I followed the INSTALL file step to get grads installed.

Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071029/034af193/attachment.html 

From prodicalboxer at YAHOO.COM  Tue Oct 30 12:58:11 2007
From: prodicalboxer at YAHOO.COM (Daniel Fritz)
Date: Tue, 30 Oct 2007 09:58:11 -0700
Subject: wind vectors over time
In-Reply-To: <20071026051921.M15580@model.iag.usp.br>
Message-ID: <TUE.30.OCT.2007.095811.0700.>

Hello Everyone,
   I have another question......
I have couple of skips ..one does the animation of
winds just by clicking on the map.....what does these
numbers represent??? I know that they respresent time
: Time 1 ,TIme 2, and so on for each Hurricane have
values??? , however HOW DO YOU OBTAIN THESE NUMBERS
here is the script
  #!/bin/sh
#       timelapse_setup.sh
#       draws the wind vectors over time, uses q pos.
doesn't do hurricane
#       track
#

echo enter hurricane
read hurr

#____________Find last time for specific $hurr entered
at prompt____________
if [ $hurr = Bonnie ] ; then time1=2509 time2=2519
num=42
elif [ $hurr = Charley ] ; then time1=2511 time2=2525
num=42
elif [ $hurr = Dennis ] ; then time1=3181 time2=3205
num=53
elif [ $hurr = Emily ] ; then time1=3169 time2=3189
num=53
elif [ $hurr = Erika ] ; then time1=1909 time2=1919
num=32
elif [ $hurr = Isidore ] ; then time1=1241 time2=1269
num=21
elif [ $hurr = Ivan ] ; then time1=2557 time2=2603
num=43
elif [ $hurr = Katrina ] ; then time1=3267 time2=3285
num=54
elif [ $hurr = Kyle ] ; then time1=1253 time2=1301
num=21
elif [ $hurr = Lili ] ; then time1=1253 time2=1285
num=21
elif [ $hurr = Michelle ] ; then time1=601 time1=621
num=11
elif [ $hurr = Rita ] ; then time1=3319 time2=3339
num=55
elif [ $hurr = Stan ] ; then time1=3347 time2=3357
num=56
elif [ $hurr = Wilma ] ; then time1=3373 time2=3397
num=56
else
  echo "enter start and stop times (ex. 1233 1245)"
  read time1 time2
fi

echo "'set gxout vector'" > timelapse_code
echo "'set gxout contour'" >>timelapse_code
echo "'c'" >> timelapse_code
echo "'set dbuff on'" >> timelapse_code
echo "t = ${time1}" >> timelapse_code
echo "say 'winds shaded with vorticity are displayed:
click on map'" >> timelapse_code
echo "while (t <= ${time2})" >> timelapse_code
echo "  'set t 't" >> timelapse_code
echo "  'draw title u_v_mag(u,v)'" >> timelapse_code
echo "  'set clab off'" >> timelapse_code
echo "  'd
ugrd10m.${num};vgrd10m.${num};mag(ugrd10m.${num},vgrd10m.${num})'"
>> timelapse_code
echo "  'swap'" >> timelapse_code
echo "  'q pos'" >> timelapse_code
echo "  t=t+1" >> timelapse_code
echo "endwhile" >> timelapse_code

exit 0  #-------------------------------------

for example Hurricane BONNIE time1= 2509 time2= 2519
                  "  Charley  time1= 2511 time2= 2525
                    so forth and so on
HOW DO YOU OBTAIN THESE NUMBERS...because when I typed
the code fro this script....it animated but there was
no time on it....could someone help me???


--- Ricardo Hallak <hallak at MODEL.IAG.USP.BR> wrote:

> Couldn't it be a virus?
> Ricardo
>
> On Fri, 26 Oct 2007 09:50:33 +0800, Mying wrote
> > Dear all,
> >
> > I need help. I don't know what's the matter with
> my GrADS(see
> > attached file). It worked OK last week.
> >
> > ying
> >
> >
>
______________________________________________________________________________
> _
> >
> > ??????????
>
????????????????????????????????????????????????????????
> >
> > http://www.citiz.net
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


From prodicalboxer at YAHOO.COM  Tue Oct 30 13:27:26 2007
From: prodicalboxer at YAHOO.COM (Daniel Fritz)
Date: Tue, 30 Oct 2007 10:27:26 -0700
Subject: Wind Vectors over time
In-Reply-To: <01cd01c81713$2e334ab0$3d09cf9b@elassa2>
Message-ID: <TUE.30.OCT.2007.102726.0700.>

Hello all ,
  could someone tell me how are the start time and end
time (time 1 and time 2) values are obtained.....I
know they represent the wind distribution over
time...how are these value obtained???
#____________Find last time for specific $hurr entered
at prompt____________
if [ $hurr = Bonnie ] ; then time1=2509 time2=2519
num=42
elif [ $hurr = Charley ] ; then time1=2511 time2=2525
num=42
elif [ $hurr = Dennis ] ; then time1=3181 time2=3205
num=53
elif [ $hurr = Emily ] ; then time1=3169 time2=3189
num=53
elif [ $hurr = Erika ] ; then time1=1909 time2=1919
num=32
elif [ $hurr = Isidore ] ; then time1=1241 time2=1269
num=21
elif [ $hurr = Ivan ] ; then time1=2557 time2=2603
num=43
elif [ $hurr = Katrina ] ; then time1=3267 time2=3285
num=54
elif [ $hurr = Kyle ] ; then time1=1253 time2=1301
num=21
elif [ $hurr = Lili ] ; then time1=1253 time2=1285
num=21
elif [ $hurr = Michelle ] ; then time1=601 time1=621
num=11
elif [ $hurr = Rita ] ; then time1=3319 time2=3339
num=55
elif [ $hurr = Stan ] ; then time1=3347 time2=3357
num=56
elif [ $hurr = Wilma ] ; then time1=3373 time2=3397
num=56
else
  echo "enter start and stop times (ex. 1233 1245)"
  read time1 time2
              DANNY

--- Anastasia Poupkou <poupkou at AUTH.GR> wrote:

> Dear GRADS USERS,
>
> We have gridded model results that are projected in
> Lambert conformal conic projection. We would like to
> reproject model results in a lat-lon grid of lower
> resolution than the original data. The main idea is
> not to perform interpolation in lat-lon grid points
> but to perform averaging over each lat-lon grid
> cell. Would you recommend any tool?
>
>
> Thank you very much.
>
> Kind regards,
>
> Anastasia
>
>
>
>
> *********************************************
> Dr. Anastasia Poupkou
> Laboratory of Atmospheric Physics
> Aristotle University of Thessaloniki
> PO Box 149, 54 124 Thessaloniki,Greece
> Tel. +30 2310 99 80 09
> Fax. +30 2310 99 80 90
> http://lap.physics.auth.gr
> *********************************************
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


From azer at ENVSCI.RUTGERS.EDU  Tue Oct 30 15:51:34 2007
From: azer at ENVSCI.RUTGERS.EDU (Mina Azer)
Date: Tue, 30 Oct 2007 15:51:34 -0400
Subject: Segmentation fault
Message-ID: <TUE.30.OCT.2007.155134.0400.>

Hello all,
I am new to grads and when I run the gradsc i get "Segmentation fault"
anybody seen this before
my OS is Red Hat Enterprise Linux AS (v. 4 for 32-bit x86)

Config: v1.8SL11 32-bit little-endian readline printim

Issue 'q config' command for more information.

Landscape mode? (no for portrait):
GX Package Initialization: Size = 11 8.5
Segmentation fault


thanks in advance


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071030/dae1762f/attachment.html 

From jnmutemi at YAHOO.CO.UK  Wed Oct 31 15:33:21 2007
From: jnmutemi at YAHOO.CO.UK (Joseph Mutemi)
Date: Wed, 31 Oct 2007 19:33:21 +0000
Subject: Help with code to grid and dispaly data
In-Reply-To: <131639.86780.qm@web62202.mail.re1.yahoo.com>
Message-ID: <WED.31.OCT.2007.193321.0000.>

Dears,
Help needed: I need a fortran (f77) code to grid data
and dispaly in with grads.

My text file looks like:

Station 1: LON LAT pcpValue
Station 2: LON LAT pcpvalue
...
Station 80: LON LAT pcpvalue

I will use which ever-griding/interpolation method the
your code uses.I wish to interpolate the data to 50km
grids.

Include the how I will make the necessary ctl file.

My Fortran is old f77 in a windows PC!, so I will have
to compile andf execute the code/s one by one!.

Thanks in advance.

Joseph




      ___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/


From klevey at CUSTOMWEATHER.COM  Wed Oct 31 18:47:18 2007
From: klevey at CUSTOMWEATHER.COM (Kevin M Levey)
Date: Wed, 31 Oct 2007 15:47:18 -0700
Subject: GRADS successfully installed on a 64-bit LINUX machine!
Message-ID: <WED.31.OCT.2007.154718.0700.>

WED 31OCT07: 1520PDT

Dear Grads community

I?ve come across many postings regarding installing GRADS 1.9b4 on a 64-bit
LINUX machine. I?ve noted that not too many people have had success, esp.
installing from the distributable source code obtained from COLA/IGES.

As lady luck would have it, we recently acquired a new 64-bit Linux server
running CentOS (Red Hat without the cost) and I had to install GRADS on this
machine. Firstly, I am NOT a system-administrator, but I was able to install
the 32-bit GRADS successfully on a 64-bit LINUX machine in under 4 hours
today. My lucky break came in the form a GRADS 1.9b4 RPM found on the
following site:

http://rpm.pbone.net/

think of RPMs as Unix self-installing bundles easily run from the command
line (as root user).

Do a search for GRADS on http://rpm.pbone.net/ and you will see many flavors
of UNIX listed there. FYI, you CAN install the latest FEDORA core versions
on CENTOS since they both essentially come from the original red Hat Linux.

Be forewarned, you need to be patient with this, as GRADS is a greedy little
pig and really needs a LOT of dependencies (other software to be installed).
Anyway, from not knowing how to install an RPM, 4 hours later I have a
perfectly working GRADS 1.9b4 version on our new 64-bit Linux server ? and I
mean ALL the grads binaries, including GRADSDODS WORK!.

Here is a good starting place to help you install RPMS:

http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch06_:_Insta
lling_Linux_Software

Essentially here is what I learned:

1] download the GRADS RPM AND ALL the GRADS dependencies listed on the
http://rpm.pbone.net/ site once you do a search for GRADS
2] install ALL the dependencies first BEFORE installing the GRADS RPM

If you have problems installing the RPMS and you more than likely will, look
through

http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch06_:_Insta
lling_Linux_Software

and you may need to install or update more than one RPM at the SAME time.
After much back and forward, GOOGLE searching etc, GRADS finally needed one
further RPM not listed in the original list and that was the
 netcdf-3.6.2-5.fc7_92.x86_64.rpm RPM also found on http://rpm.pbone.net/

I strongly suggest asking your systems-administrator to install this for you
if you are not sure what to do since you will need to install as "root"
user.

I will not be able to help you specifically to install grads on your own
system as ALL systems are different - you may find many
libraries/dependencies/software already on your machine, or you may have to
install/upgrade them all. Like I said, I am not a system-administrator, but
a little patience, logical thinking, GOOGLE searching got the job done!

I merely wanted to share this information with you all so that you can know
that it is possible to get GRADS installed on a 64-bit LINUX system.

Good luck!

Regards

Kevin M Levey, MSc (University of Cape Town)
Director of Meteorological Operations
CustomWeather, Inc
San Francisco, CA, USA

http://www.1stweather.com
http://www.myforecast.com
http://www.customweather.com


From Javier.Corripio at UIBK.AC.AT  Wed Oct 31 18:37:20 2007
From: Javier.Corripio at UIBK.AC.AT (Javier G. Corripio)
Date: Wed, 31 Oct 2007 23:37:20 +0100
Subject: check if opendaps file exists
Message-ID: <WED.31.OCT.2007.233720.0100.>

Dear all,

I wonder if there is a way of checking whether a file exists or not
when trying 'sdfopen'

Something like a return error code that can be checked by a script
and move to another file in a list without attempt any processing on
the erroneous one.

I am trying this for some batch processing, so I would like to script
it in an automatic way.

Many thanks,

Javier
--
***********************************************
Javier G. Corripio
Faculty of Geo- and Atmospheric Sciences
University of Innsbruck
Innrain, 52
A-6020 Innsbruck
Austria
Tel.: +43 512 507 5418
Fax:  +43 512 507 2895
email: Javier.Corripio at uibk.ac.at
url: http://www.uibk.ac.at/geographie/personal/corripio/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20071031/7476ef39/attachment.html 

From pertusus at FREE.FR  Wed Oct 31 19:07:05 2007
From: pertusus at FREE.FR (Patrice Dumas)
Date: Thu, 1 Nov 2007 00:07:05 +0100
Subject: GRADS successfully installed on a 64-bit LINUX machine!
In-Reply-To: <00ca01c81c0f$ff1ce4f0$fd56aed0$@com>
Message-ID: <THU.1.NOV.2007.000705.0100.>

On Wed, Oct 31, 2007 at 03:47:18PM -0700, Kevin M Levey wrote:
> WED 31OCT07: 1520PDT
>
> Dear Grads community
>
> http://rpm.pbone.net/
>
> think of RPMs as Unix self-installing bundles easily run from the command
> line (as root user).

For rpm based distros only (RHEL/CENTOS, fedora, mandriva, suse). And
there is some work to be done by the packagers.

> Do a search for GRADS on http://rpm.pbone.net/ and you will see many flavors
> of UNIX listed there. FYI, you CAN install the latest FEDORA core versions
> on CENTOS since they both essentially come from the original red Hat Linux.

Beware that there may be incompatibilities, in the package name for
example, or binary incompatibilities.

More or less, Centos 4 comes from Fedora 3, Centos 5 from fedora 6.

> Essentially here is what I learned:
>
> 1] download the GRADS RPM AND ALL the GRADS dependencies listed on the
> http://rpm.pbone.net/ site once you do a search for GRADS
> 2] install ALL the dependencies first BEFORE installing the GRADS RPM
>
> and you may need to install or update more than one RPM at the SAME time.
> After much back and forward, GOOGLE searching etc, GRADS finally needed one
> further RPM not listed in the original list and that was the
>  netcdf-3.6.2-5.fc7_92.x86_64.rpm RPM also found on http://rpm.pbone.net/

You can also use as much as dependencies as possible from a centos
repository, like
http://fedoraproject.org/wiki/EPEL
with yum. In epel, there is at least hdf, netcdf, udunits and libdap. I plan
to have grads, libsx in epel for the next quarter release.

> I merely wanted to share this information with you all so that you can know
> that it is possible to get GRADS installed on a 64-bit LINUX system.

On fedora it is even easier that that since,

yum install grads

does the trick.

But also be warned that files with non free software licenses are not in the
fedora rpms (lats and gui, in grads 2 the gui will be available).

--
Pat


From btsuang at YAHOO.COM  Wed Oct 31 20:38:19 2007
From: btsuang at YAHOO.COM (Ben-Jei Tsuang)
Date: Thu, 1 Nov 2007 08:38:19 +0800
Subject: Help with code to grid and dispaly data
Message-ID: <THU.1.NOV.2007.083819.0800.>

Please check my web site:
http://140.120.30.2/~bjtsuang/grads/

There is a utility xy2grads, which should be able to solve your problem

Ben



------------------------
5.           xy2grads: (http://140.120.30.2/~bjtsuang/grads/xy2grads)

-----------------------------------

xy2grads ver. 0.3

convert 'x y var1 var2 .. varns' data from ascii to grads binary format
(REAL*4) (FLOAT).

copyright by Ben-Jei Tsuang, C.L. Chen, 2001, 2003, 2005

Usage: xy2grads -i ifile <-o ofile -m method -n nvar -h headers -s -u xw xe
dx ys yn dy -x missing>

Note:  Input data must be number. Each data should be seperated by

          either space, comma, tab, carrage return, + or -

Options 1) -i ifile

        2) -o ofile (default: out.bin)

        3) -h headers: number of headerlines to skip (default=1)

        4) -m 0: last one win

              1: mean (default)

              2: sum (e.g. for adding emission sources)

        5) -n nvar (default=1)

        6) -s: swap x,y order from (x y var1 var2 .. ) to (y x var1 var2
...)

        7) -u xw: leftmost coord. (default=0)

              xe: rightmost coord. (default=360)

              dx: x incr. (default=1)

              ys: southmost coord. (default=-90)

              yn: northmost coord. (default=90)

              dy: y incr. (default=1)

        8) -x missing: missing value (default=-9.99e33) [bjtsuang at bs1
grads]$





----- Original Message -----
From: "Joseph Mutemi" <jnmutemi at YAHOO.CO.UK>
To: <GRADSUSR at LIST.CINECA.IT>
Sent: Thursday, November 01, 2007 3:33 AM
Subject: Re: Help with code to grid and dispaly data


> Dears,
> Help needed: I need a fortran (f77) code to grid data
> and dispaly in with grads.
>
> My text file looks like:
>
> Station 1: LON LAT pcpValue
> Station 2: LON LAT pcpvalue
> ...
> Station 80: LON LAT pcpvalue
>
> I will use which ever-griding/interpolation method the
> your code uses.I wish to interpolate the data to 50km
> grids.
>
> Include the how I will make the necessary ctl file.
>
> My Fortran is old f77 in a windows PC!, so I will have
> to compile andf execute the code/s one by one!.
>
> Thanks in advance.
>
> Joseph
>
>
>
>
>      ___________________________________________________________
> Yahoo! Answers - Got a question? Someone out there knows the answer. Try
> it
> now.
> http://uk.answers.yahoo.com/