converting binary file fw to control file ctl

Stephen R McMillan smcmillan at PLANALYTICS.COM
Fri Feb 8 00:26:42 EST 2008


Danny,
See my detailed email from earlier this evening. It explains exactly how 
to get the dimension environment that you need for your control file. It 
was the one with two files attached, including the sample control file 
with step-by-step comments. Good luck!
Stephen



Daniel Fritz <prodicalboxer at YAHOO.COM> 
Sent by: GRADSUSR at LIST.CINECA.IT
02/07/2008 11:22 PM
Please respond to
GRADSUSR at LIST.CINECA.IT


To
GRADSUSR at LIST.CINECA.IT
cc

Subject
Re: converting binary file fw to control file ctl





Hey Eric,
could you go alittle more into detail because i am
not quite understanding...do you mean my lat and lon
dimension environment.....how do i know what var is if
I am extracting data then writting the script for the
fwrite????
DANNY
--- Eric Altshuler <ela at COLA.IGES.ORG> wrote:

> Danny,
>
> You need to know how the fwrite file was written,
> i.e. what was the dimension environment when the
> 'display VAR' command was given with gxout set to
> 'fwrite', which variables were displayed, etc. There
> is no way to create a ctl file for a binary dataset
> without knowing how the dataset was written, since
> it has no metadata. If you created the file in a
> grads session or script, you need to figure out what
> is actually in that file.
>
> Eric
>
> ----- Original Message -----
> From: "Daniel Fritz" <prodicalboxer at YAHOO.COM>
> To: GRADSUSR at LIST.CINECA.IT
> Sent: Thursday, February 7, 2008 10:41:31 PM
> (GMT-0500) America/New_York
> Subject: converting binary file fw to control file
> ctl
>
> Hello Everyone,
>     from using gxout fwrite in grads
>  there come a binary file example: filename.fx , how
> do you convert the fw binary file to a control
> file?????  I don't quite understand from reading the
> Grads manual......
>     can anyone help with this???
>       It's 10:30pm here, I will be up for
> awhile..please feel free to email...
>                   DANNY
>
> --- Adam Sobel <ahs129 at COLUMBIA.EDU> wrote:
>
> > Thanks Arlindo, took a bit of redoing to get the
> ctl
> > file to work with
> > "open" but it
> > seems to have fixed the problem now!
> >
> > Adam
> >
> > Arlindo da Silva wrote:
> > > On Feb 7, 2008 12:15 AM, Adam Sobel
> > <ahs129 at columbia.edu
> > > <mailto:ahs129 at columbia.edu>> wrote:
> > >
> > >     I have a set of netcdf files, each is 1 day.
> > I have a .ctl file
> > >     so I can
> > >     view a bunch of them together in sequence
> > using xdfopen.  The ctl file
> > >     is below.
> > >
> > >
> > >
> > >     If I set t to the whole time range (in this
> > case set t 1 12) I can
> > >     view
> > >     the variables u or v just fine, e.g. make
> > animations for the whole
> > >     period, looks good.  But then if I do
> > >
> > >     define rvort=hcurl(u,v)
> > >
> > >     I get a segmentation fault
> > >
> > >
> > > This is a well known problem in the v1.8/v1.9
> > series (but not v1.7b9
> > > and new v2). There is a memory leak in the
> > sdfopen/xdfopen part of the
> > > code that causes the amount of memory to
> increase
> > with the size of the
> > > timeseries until you ran out of memory. (On a
> > linux system you can
> > > watch this happen by opening another window and
> > executing "top"). I
> > > usually experience this problem with much longer
> > data sets, but all
> > > depends on your system load and horizontal
> > resolution.
> > >
> > > I have a patched a version of GrADS for use at
> > NASA/GMAO which is
> > > built with the sdfopen/xdfopen code from  v1.7b9
> > sdf/xdfopen code,
> > > with some of the bugfixes up to v1.9b4. Since it
> > *may* not address all
> > > NetCDF files supported by v1.9b4, COLA
> recommended
> > that this patch not
> > > be included in v1.9.0-rc1. Their recommended
> > action is to prepare a
> > > ctl file with "DTYPE netcdf"  and use the "open"
> > command. Another
> > > option is the just released v2, but this version
> > is still in active
> > > development and is not as stable as v1.9 yet.
> BTW,
> > this problem is
> > > common to netcdf and hdf files alike.
> > >
> > >      Arlindo
> > >
> > >
> > > --
> > > Arlindo da Silva
> > > dasilva at alum.mit.edu
> <mailto:dasilva at alum.mit.edu>
> >
> >
> > --
> >
>
----------------------------------------------------------------
> > Adam H. Sobel
> > Department of Applied Physics and Applied
> > Mathematics
> > Department of Earth and Environmental Sciences
> > Columbia University
> > 500 W. 120th Street, Room 217
> > New York, NY 10027 USA
> > tel: 212-854-6587
> > fax: 212-854-8257
> > e-mail: ahs129 at columbia.edu
> > web: http://www.columbia.edu/~ahs129/home.html
> >
> > UNTIL AUGUST 2008, ON SABBATICAL at
> > Bureau of Meteorology Research Centre
> > GPO Box 1289
> > Melbourne VIC 3001
> > Australia
> > tel: +61-(0)3-9669-4645
> >
>
----------------------------------------------------------------
> >
>
>
>
>
>
____________________________________________________________________________________
> Looking for last minute shopping deals?
> Find them fast with Yahoo! Search.
>
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
>



____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page.
http://www.yahoo.com/r/hs




***************************************************
The information contained in this e-mail message is intended only for the use of the recipient(s) named above and may contain information that is privileged, confidential, and/or proprietary.  If you are not the intended recipient, you may not review, copy or distribute this message.  If you have received this communication in error, please notify the sender immediately by e-mail, and delete the original message.
***************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20080207/e121dee8/attachment.html 


More information about the gradsusr mailing list