opengrads-devel — OpenGrADS development issues, with focus on interfaces and extensions

[Opengrads-devel] Fwd: Bug fix for the pre-projected NetCDF data support

[Arlindo da S. <da...@al...>]

Jennifer,
  Is this offset problem (1 for binary, 0 for netcdf) also true in Grads v2?
If one needs to choose one, which one would you choose? Perhaps, offset "1"
since PDEF with binary seems to be more generally used? Besides, the GrADS
x/y/z/t indices also start at 1.

      Arlindo

---------- Forwarded message ----------
From: Sergey Varlamov <vs...@ja...>
Date: Tue, May 13, 2008 at 10:32 PM
Subject: Re: Bug fix for the pre-projected NetCDF data support
To: Arlindo da Silva <da...@al...>


Arlindo,

Thank you.

In addition,

1. Testing the PDEF with the simple 3*3
binary test file, I found that for binary files
the data offset specified in the PDEF file
is assumed to start from 1, not from 0 as is for the netCDF case.
[gaio.c, gaprow function]:

//original code, wrong offset:            pos = pos0 + ioffs[j] - 1;
//vsm - replace:
          pos = pos0 + ioffs[j];

2. The code for PDEF FILE / BILIN treatment now assumes
that the NetCDF file has standard dimensions order, i.e. x varies first etc.
Need further effort to make code more universal,
at least check the NetCDF  structure on applicability
of existing PDEF interpolation. Do not have it urgent for me,
but may be I could suggest such extension some later...

Best regards,
Sergey



Arlindo da Silva wrote:

> Serguey,
>
> Thanks for the bug report. I have entered it in the opengrads tracker for
> v1.9.0 (id 1963065).
>
>    Arlindo
>
> On Wed, May 7, 2008 at 4:08 AM, Sergey Varlamov <vs...@ja...<mailto:
> vs...@ja...>> wrote:
>
>    Dear GrADS developers,
>
>    First of all thank you for supporting this nice product.
>    I am daily using it in my work and recently I met the problem
>    when I needed to visualize the NetCDF ocean data on the special
>    curvilinear grid (ORCA grid). These data could be visualized
>    in original IJ grid without problem using GrADS DDF
>    (umask_1m.ctl ), but trying to plot the re-interpolated data
>    using PDEF FILE option failed.
>    ...
>
>
>
> --
> Arlindo da Silva
> da...@al... <mailto:da...@al...>
>


-- 

Sergey Varlamov


Senior Scientist
Climate Variations Modeling Group
Climate Variations Research Program
Frontier Research Center for Global Change
JAMSTEC, 3173-25 Showa-machi, Yokohama
Kanagawa 236-0001 JAPAN
Tel: +81-45-778-5516 Fax: +81-45-778-5707
E-mail: vs...@ja...




-- 
Arlindo da Silva
da...@al...

[Opengrads-devel] the build environment

[Arlindo da S. <da...@al...>]

On Wed, May 14, 2008 at 11:47 AM, Jennifer Adams <jm...@co...> wrote:

>
>
> Why should grads.o be different for grads and gradsdap? There are no netcdf
> dependent calls in there. All the netcdf library calls are in gasdf.c,
> gaio.c and gauser.c -- these three files have:
> #include netcdf.h
> and have separate .o files when linking grads and gradsdap. The other .o
> files that are separated for the two executables are gaddes and gacfg
> because there are some netcdf dependencies there but no calls to the
> library.
>
>
Sorry, I didn't quite answer your question last time. As you stated, one
only needs a single grads.o as there is no netcdf or sdf calls in there.
What makes it confusing is that by including gasdf.h (and indirectly)
netcdf.h in grads.c you create a misleading dependency between these 2 files
(as far as the build system is concerned there is a dependency: you can't
compile grads.c without supplying a netcdf.h). Unless someone examines every
line of grads.c it appears that grads.c does depend on netcdf.h. So,
technically it is not a "bug" as it has no side effects in today's codebase,
but it would be much safer to eliminate the inclusion of netcdf.h in grads.c
altogether.

My overall point is that by slowly adopting encapsulation and other OO
constructs (as it can be done in the constraints of good old C) one could
make the grads codebase easier to extend and maintain.  At this early stage
of development, GrADS v2 still shares the same monolithic architecture o
v1. Do you you see it this way?

  Arlindo

-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] Fwd: the build environment

[Arlindo da S. <da...@al...>]

On Wed, May 14, 2008 at 12:09 PM, Jennifer Adams <jm...@co...> wrote:

> I think the opengrads-devel list needs a "Reply-To:" header when it sends
> out messages. I sent the following as a 'reply' but it only went to
> Arlindo...
>

For consistency with gradsusr, I just updated the opengrads-devel list so
that the "reply to" defaults to the list. For some reason,
sf.netdiscourages people from setting up the lists this way.

   Arlindo


-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] Fwd: the build environment

[Arlindo da S. <da...@al...>]

On Wed, May 14, 2008 at 12:09 PM, Jennifer Adams <jm...@co...> wrote:

> I think the opengrads-devel list needs a "Reply-To:" header when it sends
> out messages. I sent the following as a 'reply' but it only went to
> Arlindo...
>

This is a good idea. I need to learn how to configure mailman at sf.net.
Does anybody know?

-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] the build environment

[Arlindo da S. <da...@al...>]

On Wed, May 14, 2008 at 11:47 AM, Jennifer Adams <jm...@co...> wrote:

>
> On May 12, 2008, at 11:29 PM, Arlindo da Silva wrote:
>
> On Mon, May 12, 2008 at 6:26 PM, Jennifer Adams <jm...@co...> wrote:
>
>>
>> for v1.9 and more recently adapted it for v2. We don't claim that what is
>> on the OpenGrADS repo is perfect but it is a pretty good start.  Some of the
>> small changes we made to the v2 codebase were made to support the new build,
>> and to fix some potentially hard to find bugs (for example, "grads.h" no
>> longer includes "netcdf.h").
>>
>> Why is that a bug?
>>
>
> The problem is that both "grads" and "gradsdap" link against the same
> "grads.o". So, you end up linking "gradsdap" with something that was
> compiled with the wrong "netcdf.h" (the one from the NetCDF library, rather
> than the one from nc-dap). Since both versions of "netcdf.h" currently in
> use are very similar, I have no evidence that your v2 build has a problem.
> However, we've been bitten by this netcdf.h mismatch issue several times in
> the past that it pays to play it save.
>
>
> Why should grads.o be different for grads and gradsdap? There are no netcdf
> dependent calls in there. All the netcdf library calls are in gasdf.c,
> gaio.c and gauser.c -- these three files have:
> #include netcdf.h
> and have separate .o files when linking grads and gradsdap. The other .o
> files that are separated for the two executables are gaddes and gacfg
> because there are some netcdf dependencies there but no calls to the
> library.
>
>
Having a separate grads.o would solve this problem, but if we don't watch
soon enough we would having 2 versions of a lot of files (since grads.h is a
very popular header file). My solution was to move all the sdf prototypes
from grads.h to sdf.h, and not include sdf.h at all in grads.h (it is not
needed).

>From an architectural point of view the current approach of adding all
possible prototypes flat in grads.h is somewhat problematic as it violates
"information hiding" and get's in the way of encapsulation.  (It would also
creates a configuration management nightmare in an environment with multiple
developers all making changes to grads.h).  In principle, only the "public"
functions of a given subpackage (e.g., gasdf) would need its prototype
broadcast through "grads.h". Internal (read: private) functions and
datatypes should be kept in a separate header file and only included by the
subpackage itself (or at the top of the file as it is done in many places
throughout grads).  Even in this case, "grads.h" should *include*  the
"public" header files rather than have them all flat in the same file.

Another suggestion.  Right now every time a given feature is not compiled in
you get an error message trying to use it:

ga-> printim
Unknown command: printim

something which can be very confusing for a new user. A message like:

  This version of GrADS has not been built with "printim" support.

would be more user friendly. One way to achieve this, which is also more
modular and would eliminate all those USE??? scattered through the code,
would be to have each subpackage compiling in a stub when it is not being
USEd. Of course the package API would be unchanged: if the subpackage is not
being used only the subpackage needs to know about it.
The same goes for gasdf.c. If the NetCDF and nc-dap versions have the exact
same  API and public header, you only need 2 versions of gasdf.o, all the
rest of the GrADS code (except for gacfg.c) would stay exactly the same.
This kind of encapsulation would simplify the build tremendously, and
ultimately is much easier to maintain.

  I hope you don't mind my unsolicited suggestions...

  Regards,

       Arlindo


-- 
Arlindo da Silva
da...@al...

[Opengrads-devel] Fwd: the build environment

[Jennifer A. <jm...@co...>]

I think the opengrads-devel list needs a "Reply-To:" header when it  
sends out messages. I sent the following as a 'reply' but it only  
went to Arlindo...
--Jennifer


Begin forwarded message:

From: Jennifer Adams <jm...@co...>
Date: May 14, 2008 11:47:36 AM EDT
To: Arlindo da Silva <da...@al...>
Subject: Re: [Opengrads-devel] the build environment


On May 12, 2008, at 11:29 PM, Arlindo da Silva wrote:

> On Mon, May 12, 2008 at 6:26 PM, Jennifer Adams <jm...@co...>  
> wrote:
>>
>> for v1.9 and more recently adapted it for v2. We don't claim that  
>> what is on the OpenGrADS repo is perfect but it is a pretty good  
>> start.  Some of the small changes we made to the v2 codebase were  
>> made to support the new build, and to fix some potentially hard to  
>> find bugs (for example, "grads.h" no longer includes "netcdf.h").
> Why is that a bug?
>
> The problem is that both "grads" and "gradsdap" link against the  
> same "grads.o". So, you end up linking "gradsdap" with something  
> that was compiled with the wrong "netcdf.h" (the one from the  
> NetCDF library, rather than the one from nc-dap). Since both  
> versions of "netcdf.h" currently in use are very similar, I have no  
> evidence that your v2 build has a problem. However, we've been  
> bitten by this netcdf.h mismatch issue several times in the past  
> that it pays to play it save.

Why should grads.o be different for grads and gradsdap? There are no  
netcdf dependent calls in there. All the netcdf library calls are in  
gasdf.c, gaio.c and gauser.c -- these three files have:
#include netcdf.h
and have separate .o files when linking grads and gradsdap. The  
other .o files that are separated for the two executables are gaddes  
and gacfg because there are some netcdf dependencies there but no  
calls to the library.

Jennifer

Re: [Opengrads-devel] the build environment

[Arlindo da S. <da...@al...>]

On Mon, May 12, 2008 at 6:26 PM, Jennifer Adams <jm...@co...> wrote:

>
> for v1.9 and more recently adapted it for v2. We don't claim that what is
> on the OpenGrADS repo is perfect but it is a pretty good start.  Some of the
> small changes we made to the v2 codebase were made to support the new build,
> and to fix some potentially hard to find bugs (for example, "grads.h" no
> longer includes "netcdf.h").
>
> Why is that a bug?
>

The problem is that both "grads" and "gradsdap" link against the same
"grads.o". So, you end up linking "gradsdap" with something that was
compiled with the wrong "netcdf.h" (the one from the NetCDF library, rather
than the one from nc-dap). Since both versions of "netcdf.h" currently in
use are very similar, I have no evidence that your v2 build has a problem.
However, we've been bitten by this netcdf.h mismatch issue several times in
the past that it pays to play it save.



>
> I know it still needs work, but it's still in alpha, after all. There were
> a lot of nits to pick when merging gradsc, gradsnc, and gradshdf, and all of
> the flags set in config.h and the #IFDEF statements in the code do not work
> perfectly. For example, I just discovered that if you have DAP libs but not
> netcdf, it doesn't set the USESDF flag.
>
> So, keep in touch we will be glad to help out with whatever we can.
>
>
> My impression is that that working on mods to the current configure system
> is a bit like building up a house of cards -- the foundation is a bit shaky
> and not perfectly designed. Maybe GrADS should configure more like other
> packages do... something like this:
>     ./configure --with-hdf=/the/path/where/hdf/is/installed
> --with-grib2=/the/path/where/grib2/libs/are
>
> The problem with the "--with-feature" option is that features like grib2
> needs more than one library, and some of the features have overlapping
> library needs (png, jpeg, zlib, et al). And it just doesn't seem practical
> to put --with-<libname> for each and every library you need. Users can't be
> bothered with that level of detail, and even I get a little annoyed if I
> have to use a lot of options on configure. On the Mac, there are packages
> like fink and MacPorts that install libraries effortlessly in places like
> /opt/local/ (linux has yum and other similar easy ways to install stuff),
> and I'd like to take advantage of that with the -enable-dynamic-supplibs.
> But many of the library packages don't install the include files with a
> named subdirectory under include  (such as $SUPPLIBS/include/hdf/ ) so then
> I have to consider differences in configuring HDF if I'm using a non-GrADS
> customized installation or a user-configured one. Then I end up in the usual
> place -- putting the whole messy business on the back burner while I work on
> something more urgent.
>

I see Pat already answered this one.


>
> Incidentally, I found the opengrads supplibs tarball hard to use -- I
> tried it with an ubuntu build environment and it was a BIG file to download,
> and it took hours to configure/make everything, and then it didn't build
> everything flawlessly "out of the box."
>

Although I set out to do just that, I never that the supplibs build "out of
the box" on all platforms. However, once properly built, grads itself builds
"out of the box" with the pre-compiled supplibs.


> After that, it was hard to figure out how to just use some of the libs,
> and then they didn't work when trying to link with GrADS. I had to rerun
> configure with manual options on a few occasions.
>

You should have asked for help. We keep a section on the wiki for "Platform
Specific Notes". Which configure did you have to manually rerun, ours or
yours?


> Will have to get back to that problem because it will be easier to put out
> a ubuntu binary distro than walk users through building from source on that
> OS.
>

I am surprised by your experience, I build on Ubuntu all the time with the
pre-compiled supplibs, for both i686 and x86_64.  Even when the generic
GrADS binaries for these platforms do not work, building against the static
supplibs usually does the trick.  Just yesterday, I built v2.0.a2.oga.1 on
the latest Ubuntu 8.04 "out of the box" using the stock supplibs-2.0.1 for
x86_64 (which were built on Mandriva), and the binaries passed 100% of the
tests.

I have had a very good experience with the binaries for v1.9.0-rc1 (even for
Windows if you discount the initial configuration glitches). The i686
binaries seem very robust, running fine on x86_64, and even IA64. The x86_64
binaries are a bit less portable, but as I said before, building against the
pre-compiled supplibs is all that it takes. My experience building v2 with
our build scripts seems to indicate that these binaries behave similarly,
although I have not distributed my v2 binaries to a wider audience (you are
welcome to distribute these binaries if you wish.)

BTW, about half of our 1.9.0-rc1 downloads are for Windows. I suspect that a
v2 build for Win 32 would be well received. I'll be glad to contribute a
build but it would make my life a lot simpler if we could reconcile the
build scripts, and have the windows specific code maintained along with
COLA's codebase, as we used to do in the past.

    Arlindo


-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] the build environment

[Patrice D. <per...@fr...>]

On Mon, May 12, 2008 at 06:26:45PM -0400, Jennifer Adams wrote:
>
> My impression is that that working on mods to the current configure system 
> is a bit like building up a house of cards -- the foundation is a bit shaky 
> and not perfectly designed. Maybe GrADS should configure more like other 
> packages do... something like this:
>     ./configure --with-hdf=/the/path/where/hdf/is/installed 
> --with-grib2=/the/path/where/grib2/libs/are

It is already done that way with --enable-dyn-supplibs for some selected
packages (for example, in m4/hdf4.m4 you can see --with-hdf4, 
--with-hdf4-include, --with-hdf4-libdir). These could certainly be
consolidated with the --with-* options that select features (by doing
something specific when --with-hdf4=no or --without-hdf4 has been
specified).

But this is not the hard part, the hard part is automatic system library 
detection.

But what is the precise issue with the current configure system (in
opengrads, be it 1.9 or 2.0)? The 2 issues I see is that it is somewhat 
double, since there is the part that corresponds with supplibs (without
--enable-dyn-supplibs) and the part allowing for system library detection
(with --enable-dyn-supplibs), and also, as you said above, that --with-* 
should be used consistently. However, I think that the fact that it is
double is not an issue in my opinion, the supplibs part is quite simple,
I rewrote from scratch most of the part with --enable-dyn-supplibs in a 
more traditional autoconf macro style.

The consolidation of --with-* options could involve a bit of work, but
nothing problematic (read, I could do it ;-). The complex part, which is 
system library detection is already done.

> The problem with the "--with-feature" option is that features like grib2 
> needs more than one library, and some of the features have overlapping 
> library needs (png, jpeg, zlib, et al). And it just doesn't seem practical 
> to put --with-<libname> for each and every library you need. Users can't be 
> bothered with that level of detail, and even I get a little annoyed if I 
> have to use a lot of options on configure. 

It should not be useful in the default case, but allow to override what
is autodetected. And this should not be needed for all the library, only
those that are often in non system places, since it is always possible
to override LDFLAGS and CPPFLAGS (or the corresponding pkgconfig
variables).

In the current m4 macros, there is --with-hdf4, --with-hdf4-include,
--with-hdf4-libdir, --with-dods-root, --with-netcdf,
--with-netcdf-include, --with-netcdf-libdir. For most libs, LDFLAGS and
CPPFLAGS should be set. But the other libs are more traditional system
libs, and libdap which has it own config system and use pkgconfig.

> On the Mac, there are packages 
> like fink and MacPorts that install libraries effortlessly in places like 
> /opt/local/ (linux has yum and other similar easy ways to install stuff), 
> and I'd like to take advantage of that with the -enable-dynamic-supplibs. 

That are 2 different subjects. One is packaging (fink and yum). The
other is library detection (with -enable-dynamic-supplibs). The
packaging part is not really a relevant target, you should just make sure
that packaging is easy. But the library detection is clearly in the
scope of 'upstream' grads.

> But many of the library packages don't install the include files with a 
> named subdirectory under include  (such as $SUPPLIBS/include/hdf/ ) so then 
> I have to consider differences in configuring HDF if I'm using a non-GrADS 
> customized installation or a user-configured one. Then I end up in the 
> usual place -- putting the whole messy business on the back burner while I 
> work on something more urgent.

Normally I have already done all that (when --enable-dyn-supplibs is
set), that is, autoconf m4 files for library detection, that can be 
overriden with --with-* options, for some of these, and setting LDFLAGS 
and CPPFLAGS for the others. Maybe you could try this system for the most 
standard setting you use and report if it has limitations?

> Incidentally, I found the opengrads supplibs tarball hard to use -- I tried 
> it with an ubuntu build environment and it was a BIG file to download, and 
> it took hours to configure/make everything, and then it didn't build 
> everything flawlessly "out of the box." After that, it was hard to figure 
> out how to just use some of the libs, and then they didn't work when trying 
> to link with GrADS. I had to rerun configure with manual options on a few 
> occasions. Will have to get back to that problem because it will be easier 
> to put out a ubuntu binary distro than walk users through building from 
> source on that OS.

It is not surprising to me. Portability on a given platform requires trying, 
testing and adapting for that platform. Even the most general autoconf
macros need to be adapted when a software is ported to a new platform,
and it is true with static supplibs and with --enable-dyn-supplibs.

--
Pat

[Opengrads-devel] the build environment

[Jennifer A. <jm...@co...>]

On May 12, 2008, at 4:03 PM, Arlindo da Silva wrote:

> On Mon, May 12, 2008 at 2:24 PM, Jennifer Adams <jm...@co...>  
> wrote:
> Mods to the build system are on my list of important things to work  
> on, but they have been trumped by my list of urgent things to do  
> right away. I will rework the build scripts when we add geotiff and  
> shapefile output.
>
> I am sure you realize that both Pat and myself have spent a lot of  
> time reworking the GrADS build scripts
Yes, of course I have no intention of starting from scratch.

> for v1.9 and more recently adapted it for v2. We don't claim that  
> what is on the OpenGrADS repo is perfect but it is a pretty good  
> start.  Some of the small changes we made to the v2 codebase were  
> made to support the new build, and to fix some potentially hard to  
> find bugs (for example, "grads.h" no longer includes "netcdf.h").
Why is that a bug?

I know it still needs work, but it's still in alpha, after all. There  
were a lot of nits to pick when merging gradsc, gradsnc, and  
gradshdf, and all of the flags set in config.h and the #IFDEF  
statements in the code do not work perfectly. For example, I just  
discovered that if you have DAP libs but not netcdf, it doesn't set  
the USESDF flag.

> So, keep in touch we will be glad to help out with whatever we can.

My impression is that that working on mods to the current configure  
system is a bit like building up a house of cards -- the foundation  
is a bit shaky and not perfectly designed. Maybe GrADS should  
configure more like other packages do... something like this:
     ./configure --with-hdf=/the/path/where/hdf/is/installed --with- 
grib2=/the/path/where/grib2/libs/are

The problem with the "--with-feature" option is that features like  
grib2 needs more than one library, and some of the features have  
overlapping library needs (png, jpeg, zlib, et al). And it just  
doesn't seem practical to put --with-<libname> for each and every  
library you need. Users can't be bothered with that level of detail,  
and even I get a little annoyed if I have to use a lot of options on  
configure. On the Mac, there are packages like fink and MacPorts that  
install libraries effortlessly in places like /opt/local/ (linux has  
yum and other similar easy ways to install stuff), and I'd like to  
take advantage of that with the -enable-dynamic-supplibs. But many of  
the library packages don't install the include files with a named  
subdirectory under include  (such as $SUPPLIBS/include/hdf/ ) so then  
I have to consider differences in configuring HDF if I'm using a non- 
GrADS customized installation or a user-configured one. Then I end up  
in the usual place -- putting the whole messy business on the back  
burner while I work on something more urgent.

Incidentally, I found the opengrads supplibs tarball hard to use -- I  
tried it with an ubuntu build environment and it was a BIG file to  
download, and it took hours to configure/make everything, and then it  
didn't build everything flawlessly "out of the box." After that, it  
was hard to figure out how to just use some of the libs, and then  
they didn't work when trying to link with GrADS. I had to rerun  
configure with manual options on a few occasions. Will have to get  
back to that problem because it will be easier to put out a ubuntu  
binary distro than walk users through building from source on that OS.

As Hoop would say, %}
--Jennifer

Re: [Opengrads-devel] Merged and checked in GrADS 2.0.a2

[Arlindo da S. <da...@al...>]

On Mon, May 12, 2008 at 2:24 PM, Jennifer Adams <jm...@co...> wrote:

> Mods to the build system are on my list of important things to work on,
> but they have been trumped by my list of urgent things to do right away. I
> will rework the build scripts when we add geotiff and shapefile output.
>

I am sure you realize that both Pat and myself have spent a lot of time
reworking the GrADS build scripts for v1.9 and more recently adapted it for
v2. We don't claim that what is on the OpenGrADS repo is perfect but it is a
pretty good start.  Some of the small changes we made to the v2 codebase
were made to support the new build, and to fix some potentially hard to find
bugs (for example, "grads.h" no longer includes "netcdf.h").

So, keep in touch we will be glad to help out with whatever we can.

   Best Regards,

      Arlindo

-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] Merged and checked in GrADS 2.0.a2

[Jennifer A. <jm...@co...>]

Mods to the build system are on my list of important things to work  
on, but they have been trumped by my list of urgent things to do  
right away. I will rework the build scripts when we add geotiff and  
shapefile output.
Jennifer

On May 11, 2008, at 6:42 PM, Arlindo da Silva wrote:

> All,
>
>    I have just merged and checked in COLA's latest release. As  
> before, none of our patches have made to the COLA release, it is  
> does not build transparently with the supplibs-2.0.1. In addition  
> to the merge, I have implemented a couple of small enhancements to  
> "fwrite" to allow me to better interface GrADS v2 to python/perl,  
> although the patch to enable fwrite to work with named pipes  
> (FIFOs) may be of general interest. I also added a set of Grib-2  
> specific tests to pytests. See ChangeLog below for details.
>
> To check out this version:
>
> % gacvs co -P -r grads-2_0_a2-oga-1
>
>  It builds out of the box with the supplibs-2.0.1.
>
>  Jennifer, as always, you are more than welcome to incorporate  
> these patches to your codebase if you are interested.


>
>   Cheers!
>
>      Arlindo
>
> From the ChangeLog:
>
> 2008-05-10 <da...@op...>, Version GrADS 2.0.a2.oga.1
>         * merged GRADS2_DEV_BRANCH with COLA's v2.0.a2.
>         * From COLAS e-mail annoucing v2.0.a2:
>             Features:
>             * ready for use with GDS-2.0 to access 5-dimensional data
>               sets via OPeNDAP
>             * support for thinned grib2 grids
>             * gribmap has -0 option for grib2
>             * allows non-float data types for hdf coordinate axes
>             Bug Fixes:
>             * memory leak when replacing an existing defined variable
>             * multiple fixes for netcdf/hdf handling (templating,
>               zrev, %nodim%, et al.)
>             * contour interval and label handling for double  
> precision numbers
>             * changed 'query dims' output for ensembles
>             * fixed gribmap's handling of data sets templated over  
> T but not E
>             * fixed 'set annot' command and other minor bugs
>         * Added Grib-2 specific tests to pytests/
>         * src/gagx.c: Enhancements to fwrite in function gafwrt():
>             * When fwrite output file name is "-" output is sent to  
> STDOUT
>             * Now uses stat() rather fopen(...,"r") to check is the  
> file already
>                 exists. This is important for using fwrite on FIFOs  
> - a deadlock
>                 occurs if a FIFO is opened for both read/write by a  
> process.
>
> ---------- Forwarded message ----------
> From: Jennifer Adams <jm...@co...>
> Date: Fri, May 2, 2008 at 12:40 PM
> Subject: NEW RELEASE of GrADS 2.0.a2
> To: GRA...@li...
>
>
> Dear All,
> I have posted a new version of GrADS:  2.0.a2. This version has  
> several new features and important bug fixes. The GrADS downloads  
> web page (http://iges.org/grads/downloads.html) has also been  
> updated with links to the source code and two binary releases (more  
> binaries to follow as soon as possible).
>
>     Features:
>     * ready for use with GDS-2.0 to access 5-dimensional data sets  
> via OPeNDAP
>     * support for thinned grib2 grids
>     * gribmap has -0 option for grib2
>     * allows non-float data types for hdf coordinate axes
>
>     Bug Fixes:
>     * memory leak when replacing an existing defined variable
>     * multiple fixes for netcdf/hdf handling (templating, zrev, % 
> nodim%, et al.)
>     * contour interval and label handling for double precision numbers
>     * changed 'query dims' output for ensembles
>     * fixed gribmap's handling of data sets templated over T but not E
>     * fixed 'set annot' command and other minor bugs
>
> This release is a companion for GDS 2.0, which can now serve 5-D  
> data sets. COLA is running a 2nd GDS for testing on port 9191 that  
> is serving everything on the 9090 server plus GFS ensemble  
> forecasts. Check 'em out at
>      http://monsoondata.org:9191/dods/gfsens/
> A public release of GDS 2.0 is forthcoming -- we are still testing.  
> If you'd like to help, please try using the 9191 server.
>
> Please post comments and questions and bug reports here (low-tech  
> bug tracking is still in use at COLA). As always, I must be able to  
> reproduce a problem on my own systems in order to fix it, so keep  
> that in mind when reporting bugs.
>
> Jennifer
>
> --
> Jennifer M. Adams
> IGES/COLA
> 4041 Powder Mill Road, Suite 302
> Calverton, MD 20705
> jm...@co...
>
>
>
>
>
>
> -- 
> Arlindo da Silva
> da...@al...
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save  
> $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http:// 
> java.sun.com/javaone_______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel

--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jm...@co...

[Opengrads-devel] Merged and checked in GrADS 2.0.a2

[Arlindo da S. <da...@al...>]

All,
   I have just merged and checked in COLA's latest release. As before, none
of our patches have made to the COLA release, it is does not build
transparently with the supplibs-2.0.1. In addition to the merge, I have
implemented a couple of small enhancements to "fwrite" to allow me to better
interface GrADS v2 to python/perl, although the patch to enable fwrite to
work with named pipes (FIFOs) may be of general interest. I also added a set
of Grib-2 specific tests to pytests. See ChangeLog below for details.

To check out this version:

% gacvs co -P -r grads-2_0_a2-oga-1

 It builds out of the box with the supplibs-2.0.1.

 Jennifer, as always, you are more than welcome to incorporate these patches
to your codebase if you are interested.

  Cheers!

     Arlindo

>From the ChangeLog:

2008-05-10 <da...@op...>, Version GrADS 2.0.a2.oga.1
        * merged GRADS2_DEV_BRANCH with COLA's v2.0.a2.
        * From COLAS e-mail annoucing v2.0.a2:
            Features:
            * ready for use with GDS-2.0 to access 5-dimensional data
              sets via OPeNDAP
            * support for thinned grib2 grids
            * gribmap has -0 option for grib2
            * allows non-float data types for hdf coordinate axes
            Bug Fixes:
            * memory leak when replacing an existing defined variable
            * multiple fixes for netcdf/hdf handling (templating,
              zrev, %nodim%, et al.)
            * contour interval and label handling for double precision
numbers
            * changed 'query dims' output for ensembles
            * fixed gribmap's handling of data sets templated over T but not
E
            * fixed 'set annot' command and other minor bugs
        * Added Grib-2 specific tests to pytests/
        * src/gagx.c: Enhancements to fwrite in function gafwrt():
            * When fwrite output file name is "-" output is sent to STDOUT
            * Now uses stat() rather fopen(...,"r") to check is the file
already
                exists. This is important for using fwrite on FIFOs - a
deadlock
                occurs if a FIFO is opened for both read/write by a process.


---------- Forwarded message ----------
From: Jennifer Adams <jm...@co...>
Date: Fri, May 2, 2008 at 12:40 PM
Subject: NEW RELEASE of GrADS 2.0.a2
To: GRA...@li...


Dear All,I have posted a new version of GrADS:  2.0.a2. This version has
several new features and important bug fixes. The GrADS downloads web page (
http://iges.org/grads/downloads.html) has also been updated with links to
the source code and two binary releases (more binaries to follow as soon as
possible).

    Features:
    * ready for use with GDS-2.0 to access 5-dimensional data sets via
OPeNDAP
    * support for thinned grib2 grids
    * gribmap has -0 option for grib2
    * allows non-float data types for hdf coordinate axes


    Bug Fixes:
    * memory leak when replacing an existing defined variable
    * multiple fixes for netcdf/hdf handling (templating, zrev, %nodim%, et
al.)
    * contour interval and label handling for double precision numbers
    * changed 'query dims' output for ensembles
    * fixed gribmap's handling of data sets templated over T but not E
    * fixed 'set annot' command and other minor bugs

This release is a companion for GDS 2.0, which can now serve 5-D data sets.
COLA is running a 2nd GDS for testing on port 9191 that is serving
everything on the 9090 server plus GFS ensemble forecasts. Check 'em out at
     http://monsoondata.org:9191/dods/gfsens/
A public release of GDS 2.0 is forthcoming -- we are still testing. If you'd
like to help, please try using the 9191 server.

Please post comments and questions and bug reports here (low-tech bug
tracking is still in use at COLA). As always, I must be able to reproduce a
problem on my own systems in order to fix it, so keep that in mind when
reporting bugs.

Jennifer

--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jm...@co...






-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] GraDs into Matlab

[Arlindo da S. <da...@al...>]

On Fri, May 2, 2008 at 3:28 PM, Shun Jie Liu <shu...@li...> wrote:

>  Hello again.
> Meanwhile, can I take alook at whats written for the GrADs/Matlab script ?
>
>

Over the weekend I looked at extending what I had done for Octave to the
real Matlab. Alas, the standard popen2()  function that Octave (and IDL,
perl, Python,...) implements is not available in Matlab. It would be
relatively easy to implement it as a Matlab C-extension (mex). However, this
would require separate builds for each platform, something I'd like to avoid
if all possible.

Now the good news. Matlab has a very nice integration with Java and Java
integrates nicely with Python (through Jython). With a relatively small
piece of Java glue code I was able to implement the basically functionality
of the Matlab interface, reusing most of my Python code. Here is I am able
to do:

% ga = grads('gradsnc -l')
% ga.cmd('open model')
% ga.cmd('d ts')
% ga.cmd('q config')
% ver = ga.rword(1,2)  % returns 2nd word of 1st line: 1.9.0-rc1

The ga.query() and ga.open() functions will be very easy to add.  The next
step is to return a GrADS expression as a Matlab array, e.g.,

% ts = ga.expr('ts - 273')

In the other interfaces I have implemented symmetric functions to get data
*in* and *out* of GrADS. It will be much easier to implement something to
extract data from GrADS like the ga.expr() above, and I might be able to get
it working even for v2. Put data back into GrADS would require a bit more
effort. A couple of questions for you:

1) Which platform do you usually run Matlab on?

2) How important is it for you to save a Matlab array as a GrADS defined
variable? Where do you usually do your plots, in GrADS or in Matlab? Do you
have the "Mapping Toolbox" available (this is a separate Matlab product)?

3) By any chance, do you know any Java? Are you familiar with Matlab
graphics?

  With just a bit more effort I shall be able to have the equivalent of the
PyGrADS "core" capabilities. As a side effect, I'll have also a Java
interface which could be useful down the line.

The advanced numerical capabilities (EOFs, least square fits, ...) and the
fancy Matplotlib graphics would be easier to implement natively in Matlab in
a m-file and I was hoping you could help me out with this.

Jennifer: Would a Java-GrADS interface be of any use for GDS? Say, to keep a
GrADS session open in association with each active connection.

  Give me a another week or so and I'll send you a prototype.

  Cheers!

     Arlindo



















-- 
Arlindo da Silva
da...@al...

[Opengrads-devel] shape.gex: almost ready for release

[Arlindo da S. <da...@al...>]

Graziano,
1)  I applied a patch this weekend and it now correctly displays shapefiles
even when the domain is [0,360]. So, I believe we have something ready for
people to try out. The code is checked in, give it a try. Preliminary
documentation is here:

    http://opengrads.org/doc/udxt/shape/

2) For the sake of completeness I'd like to prepare a suplemental
*.shapedata.tar.gz with several freely available files of interest:

admin98,shp - is there anything more recent than this?

gshhs: land, lakes, ponds and islands within lakes; these may be very useful
for people preparing navigation charts (I know of a couple of users in this
category)

3) Do you know of any shapefile for the major global rivers? Or any other
shapefile of interest. How about major world highways? Very useful for air
quality studies - pollution is usually found around major interstates)

4) Having these sample shapefiles we should be able to have a comprehensive
set of examples for the documentation.

5) Having these files installed under GADDIR, I was thinking about adding
the following UDCs:

shp_map     (same as shp_lines $GADDIR/admin98.shp)
shp_bmap   (same as shp_polyf $GADDIR/admin98.shp - replacement for
basemap.gs)
shp_land     (shp_lines $GADDIR/gshhs_land)
shp_lakes    (shp_lines $GADDIR/gshhs_lakes)
shp_pond    (shp_lines $GADDIR/gshhs_pond)
shp_isl         (shp_lines $GADDIR/gshhs_isl)

shp_rivers (???)
shp_roads (???)

The idea is to create a very easy to use package, while retaining all the
flexibility with the shp_polyf/shp_lines commands.

6) I'll save the "shp_print" command for the next release (it will remain a
stub for now).

  Let me know what you think,

     Arlindo








-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] Converter grib2 -> grib

[Arlindo da S. <da...@al...>]

Stefan,

  I did grib2.gex/grads v2 comparison on a Linux i686 box. There it makes
sense: GraDS v2 took 2:34 while grib2.gex took almost a minute longer.

1) time lats4d -2 -i gfs.t06z.ctl -format stats

141.031u 12.973s 2:34.54 99.6%

2) time lats4d -i gfs.t06z.gdf -format stats -func 'g2(@)'

179.742u 26.513s 3:24.08 101.0%

   Arlindo



On Sat, Mar 29, 2008 at 4:45 PM, Arlindo da Silva <da...@al...>
wrote:

> Stefan,
> I just did some timings on my MacBookPro G4 (1.67GHz, 1GB RAM) and I got
> some surprising results, see below. The benchmark was to cycle through the
> 180MB Grib-2 file you sent me. For reference, I converted it to Grib-1 so
> that I could have a reference. As expected, reading grib-1 is the fastest:
> it took less than 2.5 wallclock minutes for the job to finish. Using GrADS
> v2 took much longer: 10 wallclock minutes. The surprising result is that
> grib2.gex completed in less than 8.5 wallclock minutes! I was expecting it
> to be slower since for each lat-lon grid it spawns a 'wgrib2' process
> capturing its stdout in a pipe. So there is overhead costs in starting a
> process, writing/reading to/from the pipe. My only explanation is that
> wgrib2 does its decoding in single precision while GrADS v2 uses double.
>
> How does grib2.gex compares to GrADS v2 on your Linux box? I expect them
> to be in the same ballpark.
>
>     Arlindo
>
> PS: You need the attached Lats4d for GrADS v2. (You need to edit lats4d.shfor addiing the -2 option)
>
> 1) time lats4d.sh -i gfs.test.ctl -format stats:
>
>
>    36.907u 8.671s 2:23.52 31.7%    0+0k 0+9io 0pf+0w
>
>
> 2) time lats4d.sh -2 -i gfs.t06z.ctl -format stats
>
>
>    264.064u 48.255s 10:02.05 51.8% 0+0k 0+8io 0pf+0w
>
>
> 3) time lats4d.sh -i gfs.t06z.gdf -format stats -func 'g2(@)'
>
>
> 284.911u 77.193s 8:18.42 72.6%  0+0k 0+12io 0pf+0w
>
>
> --
> Arlindo da Silva
> da...@al...
>



-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] UDXT documentation

[Ben-Jei T. <bt...@ya...>]

Dear Arlindo:

 

Thank you for your all effort, especially to make some documents for my
code. Could you send me the file "libbjt.c"? I forgot how to use cvs to
check out the file. 

 

In fact, all my function provides a help itself. Simply type 

 

 

d function_name

 

The user should be able to find the help. For example

 

d lw

 

ga-> d lw

Error from LW:  12-15 arguments expected 

lw(pl,ta,wa,taucl,fcld,ps,tg,eg,tb,wb,tauclb,fcldb
[,'binfile','ctlfile',-r-c-h-l]) 

usage:

Function returns: thermal infrared fluxes

Following the NASA Technical Memorandum (NASA/TM-2001-104606,

Vol. 19) of Chou, Suarez, Liang, and Yan (2001). This NASA TM

has been revised a few timessince. It computes thermal infrared

fluxes due to emission by water vapor, ozone, co2, o2, minor

trace gases, clouds, and aerosols and due to scattering by

clouds and aerosols.

 

Arguments:

   pl = level pressure (hPa)

   ta = layer temperature (K)

   wa = layer specific humidity (kg/kg)

   taucl= cloud optical thickness (dimensionless)

   fcld= cloud amount (fraction)

         (low cloud >700 hPa >= middle cloud > 400 hPa >= high cloud 

   ps = surface pressure (hPa)

   tg = land or ocean surface temperature (K)

   eg = land or ocean surface emissivity (fraction)

   tb = surface air temperature (K)

   wb = surface air specific humidity (kg/kg)

   tauclb= surface cloud optical thickness (dimensionless)

   fcldb= surface cloud amount (fraction)

   binfile = binary file name ('null' or blank for no output)

   ctlfile = ctl file name ('null' or blank for no output)

   -r = using Roberts et al. (1976) water vaopr continuum

   -c = using Clough et al. (1989) water vaopr continuum (default)

   -h = using look-up table (high acc but slow) (default)

   -l = using k-dist method (low acc but fast)

Operation Error:  Error from lw function

  Error ocurred at column 1

DISPLAY error:  Invalid expression 

  Expression = lw

 

ga-> d line

 

line(exp,x0,y0,x1,y1[,-l|-m|-r]) 

usage:

Function returns: draw line from (x0,y0) to (x1,y1)

  Set the line at the value val (default 1)

  using the template of exp

Arguments:

   (x0,y0),(x1,y1): coordindates in (lon, lat)

   -l: return the length [km] in each grid

   -m: return the logics (1:pass, 0: non-passing)

   -r: return the length ratio of each segment (fraction)

 

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

 

Perhaps, we can just provide this kind of documentation meanwhile. 

 

 

 

Ben

 

 

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

  _____  

From: ope...@li...
[mailto:ope...@li...] On Behalf Of Arlindo
da Silva
Sent: Monday, March 24, 2008 12:07 PM
To: ope...@li...
Subject: [Opengrads-devel] UDXT documentation

 

All,

 

  I spent sometime this weekend updating the documentation of the UDXTs. The
revised man pages are here

 

       http://opengrads.org/doc/

 

  These have been derived from source code using pod2html, and uses a new
pod.css I introduced to match the OpenGrADS general layout. For the first
time I have documentation for the environment variable extension (env) and
gsudf, a device for writing GrADS UDFs as script functions (these used to be
entirely separate, now the line is blurred). 

 

   B.-J.: I have add a very rough skeleton for the libbjt documentation,
based on what I could derive from your example script. There is still a lot
of gaps that I need your help with. The documentation is stored within the
sources. To get to it, checkout 

 

% gacvs co -P Grads   (notice capital "G")

% cd extensions/libbjt

 

and edit file libbjt.c. To see the formatted documentation on the screen
type

 

% perldoc libbjt.c

 

which should give you a man page kind of output. Type

 

% make html

 

to create libbjt.html, the same as this page:

 

    http://opengrads.org/doc/udxt/libbjt/

 

(You may need to install packages named something like perl-doc or
perl-pod.) If you don't know POD do not worry about getting the perfect
format, I can fix that later. Just type in the arguments and general
description for the function in the "FUNCTIONS PROVIDED" section. I already
entered the examples I got from you for some of the functions. You have a
great collection of very useful functions; with a bit of documentation
others may be able to take advantage of all your hard work. Thanks.

 

 My plan is to work with Mike to make some adjustments to fish, some touch
ups in shape, complete the documentation and then release a new version of
the UDXTs, including the grib2 capability for v1.9.

 

 Any comment greatly appreciated.

 

 Cheers!

 

  Arlindo.

 

 

 

 

 

 


-- 
Arlindo da Silva
da...@al... 

[Opengrads-devel] Grib2 extension

[Arlindo da S. <da...@al...>]

All,
  I have put together a very simple extension for providing Grib-2 support
in GrADS v1.9. My main motivation is to be able to use lats4d to convert
Grib-2 files to HDF. Right now, the implementation is limited to lat/lon
grids, and there is no PDEF support. I suspect it is a bit slower than grads
v2, but it is quite usable. There is no caching, and since this is v1.9, all
is float32 which is good for older, less powerful boxes. It works something
like this:

% g2gdf gfs.t00z.pgrb2bf00
% grads
...
ga-> g2_open gfs.t00z.pgrb2bf00.gdf
ga-> d g2(hgtprs)

You have to go though function g2() to get a variable, other than that you
can plot cross sections and time-series just the same. Templating is also
supported. Gribmap is not used. Documentation is here:

   http://opengrads.org/doc/udxt/grib2/


You will need both g2ctl.pl and wgrib2 v1.7.2 or later. You can get wgrib2
builds here:



http://sourceforge.net/project/showfiles.php?group_id=161773&package_id=263736


  If you have a chance to play with it I'd appreciate hearing from you. I
don't have grib2.gex binaries, but coulld provide some if you would like to
give it a try. Otherwise, it builds trivially:


% gacvs co -P Grads

% cd Grads/extensions/ams

% gmake


I'd like to release grib2.gex with the next UDXT bundle. Any comments
greatly appreciated.


  Cheers!


     Arlindo




-- 
Arlindo da Silva
da...@al...

[Opengrads-devel] UDXT documentation

[Arlindo da S. <da...@al...>]

All,
  I spent sometime this weekend updating the documentation of the UDXTs. The
revised man pages are here

       http://opengrads.org/doc/

  These have been derived from source code using pod2html, and uses a new
pod.css I introduced to match the OpenGrADS general layout. For the first
time I have documentation for the environment variable extension (env) and
gsudf, a device for writing GrADS UDFs as script functions (these used to be
entirely separate, now the line is blurred).

   B.-J.: I have add a very rough skeleton for the libbjt documentation,
based on what I could derive from your example script. There is still a lot
of gaps that I need your help with. The documentation is stored within the
sources. To get to it, checkout

% gacvs co -P Grads   (notice capital "G")
% cd extensions/libbjt

and edit file libbjt.c. To see the formatted documentation on the screen
type

% perldoc libbjt.c

which should give you a man page kind of output. Type

% make html

to create libbjt.html, the same as this page:

    http://opengrads.org/doc/udxt/libbjt/


(You may need to install packages named something like perl-doc or
perl-pod.) If you don't know POD do not worry about getting the perfect
format, I can fix that later. Just type in the arguments and general
description for the function in the "FUNCTIONS PROVIDED" section. I already
entered the examples I got from you for some of the functions. You have a
great collection of very useful functions; with a bit of documentation
others may be able to take advantage of all your hard work. Thanks.


 My plan is to work with Mike to make some adjustments to fish, some touch
ups in shape, complete the documentation and then release a new version of
the UDXTs, including the grib2 capability for v1.9.


 Any comment greatly appreciated.


 Cheers!


  Arlindo.







-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] Wgrib2 and autotools

[Don H. <ho...@Co...>]

Arlindo,

ftp://ftp.cdc.noaa.gov/Public/dhooper/ has two builds:
wgrib2_v015f wgrib2_v1.7.1

They are named for the version, and only have dynamic dependencies
on the math library and the C library.

-Hoop

Re: [Opengrads-devel] Wgrib2 and autotools

[Arlindo da S. <da...@al...>]

Wes et al,
  I just added a very rudimentary test suite, using PyUnit to organize the
tests. This is similar to what I did for GrADS; I have some notes here:

  http://opengrads.org/wiki/index.php?title=PyTests:_GrADS_Test_Suite

 The wgrib2 implementation is simpler than the one in grads as we only have
one executable (wgrib2) and only one type of input file (grib 2).

 After you build wgrib2, just type

% make check

and it will run all tests.

We need more test cases!!! In principle, each command line option should
have its own unit test.  Right now I have a single test data file (under
data/model_25.grb2) something the Mike Fiorino prepared for me for testing
grads v2. This single file could be used for most if not all test cases.

To add a new test, just add a new python function that starts with "test_"
in file pytests/TestModelFile.py - no other change is required. For example,
to test the -min/-max options I added the function:

    def test_opt_minmax(self):
        result = self.g2('-d 1 -min -max ')
        self.assertEqual(result[0],'1:0:min=10664.5:max=12531.1\n')
        result = self.g2('-d 33 -min -max ')
        self.assertEqual(result[0],'33:322100:min=95073.8:max=104675\n')
        result = self.g2('-d 67 -min -max')
        self.assertEqual(result[0],'67:676013:min=94670.3:max=104569\n')

The statement

        result = self.g2('-d 1 -min -max ')

runs

 ../src/wgrib2 -d 1 -min -max data/model_25.grb2

and captures the result in 'result'. The statement:

        self.assertEqual(result[0],'1:0:min=10664.5:max=12531.1\n')

compares the result with an expected (hard coded) outcome. This receipt can
be used for all the options producing simple ASCII output. For binary files,
one could produce the binary file and check the md5sum against a hardcoded
value, this way keeping the distribution tarball small enough. I can help
with the python wiring of the test cases, but it would be better for people
familiar with wgrib2 (i.e., developers) to come up with the actual tests.

  Take my word for it: a test suite is worth its weight in gold, specially
when porting to a new platform.

  To get the latest wgrib2 sources:

% gacvs co -P Wgrib2

and you should get the new pytests/ directory, including the test data.

   Arlindo

-- 
Arlindo da Silva
da...@al...

[Opengrads-devel] Wgrib2 and autotools

[Arlindo da S. <da...@al...>]

Wes,
   I am waiting for Pat to double check my instrumentation of wgrib2 with
the GNU autotools. I want to make sure it has all the necessary elements for
Pat to include it as a Fedora package. In the meantime, here are a few
guidelines for developing wgrib2 under autotools:

0) Here are the links for autoconf/automake in case you want to learn more
about these:

http://www.gnu.org/software/autoconf/manual/autoconf.html

http://www.gnu.org/software/automake/manual/automake.html


1) If you do not add any new file, just update the existing C sources, and
eventually update the package version. This is done in the top file "
configure.ac". Just edit the line near the top:

    AC_INIT(wgrib2, [0.1.7])

  replacing the 0.1.7 with whatever new version you would like. Once you do
that, type

  % autoreconf

  to regenerate configure/Makefile.in/Config.h.in. Then check back in the
modfied sources. The version appearing in the sources and tarballs will be
derived from this, no need to update the version elsewhere.

2) If you add a new Function, regular C source, or any *.dat or *.table file
run this script

  % cd src/
  % ./am_sources.sh

  which will recreate "am_sources.mk". (Automake restricts the use of *.c in
Makefile.am) Then do a "autoreconf" from the top dir as in 1).

3) If you need to customize the build, you usually edit file "Makefile.am"
and sometimes "configure.ac". Never edit configure, configure.h,
configure.h.in, Makefile, Makefile.in: these are automatically created from
"configure.ac", "Makefile.am". The actual "Makefile" is not meant to be
readable by humans.

4) I added the standard AUTHORS, ChangeLog, COPYING, INSTALL, NEWS, etc
files at the top per the GNU coding standards. You can read more about these
here:

  http://www.gnu.org/prep/standards/standards.html#NEWS-File

  and have used content from original sources/website to populate these.
Please check if this is adequate.



BTW, what is the current wgrib2 version: "0.1.7" or "1.7.0" ?

 Are the sources in the repo ready for a round of builds? Here are the
platforms I have in mind: Windows, Darwin Intel, Darwin PPC, i686, x86_64,
Altix ia64, IRIX64, FreeBSD. I can post the binaries on sf.net or else make
them available for you to post them on your site. Let me know what you would
like to do.

Hoop: would you be able to produce a solaris build? It should build out of
the box if you have the supplibs.

      Arlindo

-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] New Win32 GrADS build

[<smc...@pl...>]

Hi Arlindo,
I was able to uninstall the previous version (one without gex files), no 
problem, then installed the updated version (rc1, not rc; assume it 
doesn't matter since they were the same size and date stamp). It started 
without a hitch and was able to use gxyat, re, etc. although I'm brand new 
to those utilities. I'm also looking forward to your response on the 
read-file issue I mentioned the other day (Feb 22nd, subject "Re: Win32 
Binaries in v1.9.0-rc1").

Although I've never used Python, down the road I may download the newly 
available pygrads you mentioned. Thanks for making it and the grads19 
available for win32 users!

Stephen Mc



"Arlindo da Silva" <da...@al...> 
Sent by: arl...@gm...
02/24/2008 08:51 AM

To
smc...@pl...
cc
"See Hai Ooi" <ax...@ya...>, "Bill Reilly" 
<Bil...@co...>, "Eric Altshuler" <el...@co...>, "Maat, 
Herbert ter" <Her...@wu...>, "Michael G Bosilovich" 
<Mic...@na...>, ope...@li...
Subject
Re: New Win32 GrADS build





On Sun, Feb 24, 2008 at 12:42 AM, <smc...@pl...> wrote:

Thanks Arlindo! I removed the .zip version and replaced with this one. 
Installation was quick and simple. This time, unlike with .zip version, I 
was able to launch right away. However, when I tried to use gxyat it 
didn't work, even after I added GAUDXT as an env variable and updated the 
path. But then I noticed the \win32\gex folder was empty, although the 
gxyat application is in \win32. Were they intentially left out?
 
 
Oops! My mistake, I did a fresh build in the end and forgot to include the 
extensions. I just refresh the .exe file. Would you try it again? I'd 
recommend:
 
- Stop Xming (right click on the little X at lower right hand corner & 
select "Exit")
- Uninstall from [Start]/[GrADS 1.9] menu (you would help me test if this 
is working)
- Reinstall
 
  The extensions should be there this time. This is good beta testing at 
work!
 
  Thanks,
 
      Arlindo
 
 
 
 
 

Stephen Mc



"Arlindo da Silva" <da...@al...> 
Sent by: arl...@gm... 

02/23/2008 06:34 PM


To
"Michael G Bosilovich" <Mic...@na...>, "Maat, Herbert ter" 
<Her...@wu...>, "Bill Reilly" <Bil...@co...>, "See 
Hai Ooi" <ax...@ya...>, "Stephen R McMillan" <
smc...@pl...>, "Eric Altshuler" <el...@co...> 
cc
ope...@li... 
Subject
New Win32 GrADS build










Hi,
 
  I have a new Win32 build at
 
http://opengrads.org/pre-rel/win32/grads-1.9.0-rc.win32_superpack.exe
 
that I hope fixes several of the issues some of you have reported:
 
1) Xmin should now start automatically (meaning some of the mods I made 
could solve this problem that some of you had).
 
2) The "!" command in grads should work
 
3) The "^" as in "DSET ^filename" in ctl files should work now
 
4) Other niceties: Setup.exe type of installation, PATH is now set 
automatically, can be uninstalled from control pannel.
 
A main change is that the suggested default installation directory is 
"C:\GrADS19", so that v2 could later be installed under C:\GrADS20. I plan 
to post this new build on sf.netin the next couple of days, unless I hear 
from you of major problems. 

 
BTW, despite the Setup.exe installation, the whole package should still be 
relocatable to mem stick or whatever.
 
  Let me know of any problems.
 
  Thank you,
 
     Arlindo
 
 
 
 
 
 
 


-- 
Arlindo da Silva
da...@al...


***************************************************
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.
***************************************************



-- 
Arlindo da Silva
da...@al... 



***************************************************
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.
***************************************************

Re: [Opengrads-devel] New PyGrADS 1.0.8, works on Win32

[Arlindo da S. <da...@al...>]

Hi,

   I am not sure if any of you are into Python, but I have a new version of
PyGrADS that now, after a week of frustrating debugging with Mike
Bosilovich, seems to work reliably on win32. For all of this you need the
latest Win32 GrADS using the installer (.exe), not the ZIP file:

 http://opengrads.org/pre-rel/win32/grads-1.9.0-rc1.win32_superpack.exe

Here are your options:

1) If you have no Python whatsoever installed on your Windows box and would
like to give it a try, then you may want to start with the PyGrADS
win32_superpack:

  http://opengrads.org/pre-rel/win32/pygrads-1.0.8.win32_superpack.exe

This has all you need.

2) Now, if you have Python 2.5 already installed on your windows box, you
can install  "PyGrADS only" with this:

   http://opengrads.org/pre-rel/win32/pygrads-1.0.8.win32.exe

You willl have the download the dependencies individually; see the wiki:

   http://opengrads.org/wiki/index.php?title=Python_Interface_to_GrADS

Or else, you can use the superpack in 1) and only install the dependencies
you need. Notice that the superpack is specific for Python 2.5.

*Important:*  If you install "*basemaps*" be sure to install "*httplib2*",
also included in the superpack.

3)  Or else, get the tarball and do a standard python install.

  http://opengrads.org/pre-rel/win32/pygrads-1.0.8.tar.gz

Note that PyGrADS is 100% pure Python, so no compilation is necessary.
Again, you will need
the dependencies for full functionality, though. See the Wiki.

4) If you would like to try some examples, download the tarball in 3) [no
need to install it if have already done 1) or 2)], then open a cmd.exewindow nd

cd \some\path\pygrads-1.0.8\examples
c:\python25\python ganum_examples.py
c:\python25\python galab_examples.py
etc

and take a look at the output PNG files. As Mike Bosilovich reports, you can
also open the "examples" folder with the Windows Explorer and click on
"galab_examples" to run it --- I am too much of a command liner for that
:-).

  Let me know of any problems if you have a chance to try this out. I am
planning to post it on sf.net early in the week after I have a chance to
touch up the wiki documentation. And that I'll be glad to fold up my old and
slow Windows laptop and go back to my Mac :-).

   Arlindo

-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] New Win32 GrADS build

[Arlindo da S. <da...@al...>]

On Sun, Feb 24, 2008 at 4:09 AM, See Hai Ooi <ax...@ya...> wrote:

> Dear Mr Arlindo,
>
>     Thank you.
>
>     The outcome of my testing your
> grads-1.9.0-rc.win32_superpack.exe is as follows:-
>
>    (1) as compared with you zip package, I have to
> select grads classic or grads netCDF-3 or netCDF-4 in
> order to run .grb or .nc file appropriately.  [In your
> zip package, I just type grads in the command window
> and run either .grb or .nc file easily.]



Why? Just start a cmd.exe and type "grads", it should work the same way as
before. The
"GrADS 1.9" menu under [Start]/[All Programs] is just an extra convenience.


>
>    (2) q udft shows no listing of the table at all.
>    (3) your gex folder in win32 is empty.
>    (4) when I run your utFish.gs,  'psi', 'chi',
> 'fish' are shown as not a variable or function name.
>    (5) when I tried you re() function, re is shown to
> be not a variable or function name.  Also, gxyat is an
> unknown command.
>

See previous message, I forgot to include the extensions the first time
around. Download a fresh copy and reinstall. It should be there now.


>
>      Lastly, yesterday I emailed you that I am
> puzzled by the streamfunction output by using fish().
> The pattern, as compared with an example from an
> article, looks similar but the signs and magnitudes
> are vastly different.  I am pleased to reproduce below
> my email text with the attached example for your
> consideration and help.
>

I'll answer that separately.

    Arlindo


-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] New Win32 GrADS build

[Arlindo da S. <da...@al...>]

On Sun, Feb 24, 2008 at 12:42 AM, <smc...@pl...> wrote:

>
> Thanks Arlindo! I removed the .zip version and replaced with this one.
> Installation was quick and simple. This time, unlike with .zip version, I
> was able to launch right away. However, when I tried to use gxyat it didn't
> work, even after I added GAUDXT as an env variable and updated the path. But
> then I noticed the \win32\gex folder was empty, although the gxyat
> application is in \win32. Were they intentially left out?
>


Oops! My mistake, I did a fresh build in the end and forgot to include the
extensions. I just refresh the .exe file. Would you try it again? I'd
recommend:

- Stop Xming (right click on the little X at lower right hand corner &
select "Exit")
- Uninstall from [Start]/[GrADS 1.9] menu (you would help me test if this is
working)
- Reinstall

  The extensions should be there this time. This is good beta testing at
work!

  Thanks,

      Arlindo






>
> Stephen Mc
>
>
>   *"Arlindo da Silva" <da...@al...>*
> Sent by: arl...@gm...
>
> 02/23/2008 06:34 PM
>    To
> "Michael G Bosilovich" <Mic...@na...>, "Maat, Herbert ter"
> <Her...@wu...>, "Bill Reilly" <Bil...@co...>, "See
> Hai Ooi" <ax...@ya...>, "Stephen R McMillan" <
> smc...@pl...>, "Eric Altshuler" <el...@co...>  cc
> ope...@li...  Subject
> New Win32 GrADS build
>
>
>
> Hi,
>
>   I have a new Win32 build at
>
> *http://opengrads.org/pre-rel/win32/grads-1.9.0-rc.win32_superpack.exe*<http://opengrads.org/pre-rel/win32/grads-1.9.0-rc.win32_superpack.exe>
>
> that I hope fixes several of the issues some of you have reported:
>
> 1) Xmin should now start automatically (meaning some of the mods I made
> could solve this problem that some of you had).
>
> 2) The "!" command in grads should work
>
> 3) The "^" as in "DSET ^filename" in ctl files should work now
>
> 4) Other niceties: Setup.exe type of installation, PATH is now set
> automatically, can be uninstalled from control pannel.
>
> A main change is that the suggested default installation directory is
> "C:\GrADS19", so that v2 could later be installed under C:\GrADS20. I plan
> to post this new build on *sf.net* <http://sf.net/>in the next couple of
> days, unless I hear from you of major problems.
>
> BTW, despite the Setup.exe installation, the whole package should still be
> relocatable to mem stick or whatever.
>
>   Let me know of any problems.
>
>   Thank you,
>
>      Arlindo
>
>
>
>
>
>
>
>
>
> --
> Arlindo da Silva
> *da...@al...* <da...@al...>
>
>
> ***************************************************
> 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.
> ***************************************************
>



-- 
Arlindo da Silva
da...@al...