Menu
▾
▴
opengrads-devel
|
From: Arlindo da S. <da...@al...> - 2008-02-04 16:40:33
|
Jennifer,
Does the executable "grads" have any feature not covered in "gradsdap"? If
not, is "grads" really necessary? Sure, nc-dap is bloated, but nc-dap should
be considered robust enough by now. You could have gone all the way and have
a single executable called "grads", and only on those platforms where
OPeNDAP cannot be build we build it with NetCDF. What were your thoughts for
not having a single executable at this point?
Arlindo
--
Arlindo da Silva
da...@al...
|
|
From: Jennifer A. <jm...@co...> - 2008-02-04 17:08:51
|
In a couple of years the Unidate netcdf library will have swallowed up libnc-dap (see below), so gradsdap is the one that will eventually be phased out. Until then, I feel it's better to link grads with the Unidata library and gradsdap with OPeNDAP version. Then when nc4 is ready (it's waiting for hdf5 to come out of beta status), we can link grads with nc4 library and leave gradsdap alone. I am trying to keep the data formats and their supplibs and their code paths in GrADS untangled. The HDF Group is also thinking about developing an OPeNDAP client library for HDF5, so that may be another complicating factor. Here's the announcement from James Gallagher (dated October 14th, 2007): "We (OPeNDAP) are pleased to say that NSF has funded a proposal for the netCDF client library software to migrate into the Unidata code base for netCDF. This will entail rewriting the netCDF client library to use the recently developed C API for DAP 2. The effort will last two years and will take place both at OPeNDAP and Unidata." Jennifer On Feb 4, 2008, at 11:40 AM, Arlindo da Silva wrote: > Jennifer, > > Does the executable "grads" have any feature not covered in > "gradsdap"? If not, is "grads" really necessary? Sure, nc-dap is > bloated, but nc-dap should be considered robust enough by now. You > could have gone all the way and have a single executable called > "grads", and only on those platforms where OPeNDAP cannot be build > we build it with NetCDF. What were your thoughts for not having a > single executable at this point? > > Arlindo > > -- > Arlindo da Silva > da...@al... > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Opengrads-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengrads-devel > > --===============1190338742==-- -- Jennifer M. Adams IGES/COLA 4041 Powder Mill Road, Suite 302 Calverton, MD 20705 jm...@co... |
|
From: Arlindo da S. <da...@al...> - 2008-02-04 17:51:25
|
On Feb 4, 2008 12:08 PM, Jennifer Adams <jm...@co...> wrote:
> In a couple of years the Unidate netcdf library will have swallowed up
> libnc-dap (see below),
>
That would be fantastic!
> so gradsdap is the one that will eventually be phased out. Until then, I
> feel it's better to link grads with the Unidata library and gradsdap with
> OPeNDAP version. Then when nc4 is ready (it's waiting for hdf5 to come out
> of beta status), we can link grads with nc4 library and leave gradsdap
> alone.
>
I have been experimenting with the current beta of netcdf4 in the context of
v1.9 (binary name: gradsnc4) and I'd say that, pending low level hdf-5
issues which are not visible at the API level, netcdf-4 is pretty ready;
gradsnc4 already passes 100% of our tests. I have both netcdf4 beta and the
hdf-5 version it requires in the supplibs. These will be replaced with the
final versions as they become available. We have all the m4 discovery
macros for it already.
(The gradsnc4 binary is just as huge as gradsdap, as both libdap and hdf5
are bloated. Put these 2 together we will have a very heavy load, indeed. It
may be time to bring old gradsc back :-)
> I am trying to keep the data formats and their supplibs and their code
> paths in GrADS untangled. The HDF Group is also thinking about developing an
> OPeNDAP client library for HDF5, so that may be another complicating
> factor.
>
Speaking as a user, once an OPeNDAP enabled NetCDF-4 is available I see no
compeling reason for using HDF-5. I am trying to articulate this point
within NASA.
Thank you for the info!
Arlindo
> On Feb 4, 2008, at 11:40 AM, Arlindo da Silva wrote:
>
> Jennifer,
>
> Does the executable "grads" have any feature not covered in "gradsdap"?
> If not, is "grads" really necessary? Sure, nc-dap is bloated, but nc-dap
> should be considered robust enough by now. You could have gone all the way
> and have a single executable called "grads", and only on those platforms
> where OPeNDAP cannot be build we build it with NetCDF. What were your
> thoughts for not having a single executable at this point?
>
> Arlindo
>
> --
> Arlindo da Silva
> da...@al...
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
>
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>
> --===============1190338742==--
>
>
> --
> Jennifer M. Adams
> IGES/COLA
> 4041 Powder Mill Road, Suite 302
> Calverton, MD 20705
> jm...@co...
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>
>
--
Arlindo da Silva
da...@al...
|
|
From: Jennifer A. <jm...@co...> - 2008-02-04 18:22:54
|
On Feb 4, 2008, at 12:51 PM, Arlindo da Silva wrote: > On Feb 4, 2008 12:08 PM, Jennifer Adams <jm...@co...> wrote: > In a couple of years the Unidate netcdf library will have swallowed > up libnc-dap (see below), > > That would be fantastic! > > so gradsdap is the one that will eventually be phased out. Until > then, I feel it's better to link grads with the Unidata library and > gradsdap with OPeNDAP version. Then when nc4 is ready (it's waiting > for hdf5 to come out of beta status), we can link grads with nc4 > library and leave gradsdap alone. > > I have been experimenting with the current beta of netcdf4 in the > context of v1.9 (binary name: gradsnc4) and I'd say that, pending > low level hdf-5 issues which are not visible at the API level, > netcdf-4 is pretty ready; gradsnc4 already passes 100% of our > tests. I have both netcdf4 beta and the hdf-5 version it requires > in the supplibs. These will be replaced with the final versions as > they become available. We have all the m4 discovery macros for it > already. The way I see it, the whole point of moving to nc4 is to take advantage of the features that involve hdf5, so there's no point in upgrading until hdf5 is solid. I guess there are other advantages, such as the groups stuff which might be used for ensembles, but until someone steps up with a 5D netcdf file with groups that they want to read with GrADS, I'm in no rush to move to nc4. > > (The gradsnc4 binary is just as huge as gradsdap, as both libdap > and hdf5 are bloated. Put these 2 together we will have a very > heavy load, indeed. The idea is to load up your executable at configure time with all the features you want so you can make your build as bulky or lean as you like. > It may be time to bring old gradsc back :-) :-( eek! Don't even joke about it! Actually, I find it convenient that v2 and v19 have different executable names -- keeps things clear for the users migrating from one to the other. > > > I am trying to keep the data formats and their supplibs and their > code paths in GrADS untangled. The HDF Group is also thinking about > developing an OPeNDAP client library for HDF5, so that may be > another complicating factor. > > Speaking as a user, once an OPeNDAP enabled NetCDF-4 is available I > see no compeling reason for using HDF-5. I am trying to articulate > this point within NASA. I learned at the HDF5 workshop last fall that the subset of all hdf5 files that can be read by nc4 is very small. The hdf5 interface in GrADS will have to be more general and will require a descriptor file, especially as we work toward the quasi-regular data type and handling of swath data. Jennifer > > > Thank you for the info! > > Arlindo > > > > > On Feb 4, 2008, at 11:40 AM, Arlindo da Silva wrote: > >> Jennifer, >> >> Does the executable "grads" have any feature not covered in >> "gradsdap"? If not, is "grads" really necessary? Sure, nc-dap is >> bloated, but nc-dap should be considered robust enough by now. You >> could have gone all the way and have a single executable called >> "grads", and only on those platforms where OPeNDAP cannot be build >> we build it with NetCDF. What were your thoughts for not having a >> single executable at this point? >> >> Arlindo >> >> -- >> Arlindo da Silva >> da...@al... >> --------------------------------------------------------------------- >> ---- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Opengrads-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opengrads-devel >> >> --===============1190338742==-- > > -- > Jennifer M. Adams > IGES/COLA > 4041 Powder Mill Road, Suite 302 > Calverton, MD 20705 > jm...@co... > > > > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Opengrads-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengrads-devel > > > > > -- > Arlindo da Silva > da...@al... -- Jennifer M. Adams IGES/COLA 4041 Powder Mill Road, Suite 302 Calverton, MD 20705 jm...@co... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X