<br>Hi Wesley,<br><br>Apologies for not being more clear. The example below would be a way of using lats4d on reanalysis data behind a GDS.<br><br>lats4d -dods -i <a href="http://nomads.ncdc.noaa.gov:9091/dods/NCEP_GFS_ANALYSIS/analysis">http://nomads.ncdc.noaa.gov:9091/dods/NCEP_GFS_ANALYSIS/analysis</a><br>
_complete -o test1 -format grads_grib -lat 15 50 -lon -100 -70 -time 00Z01SEP2004 18Z01SEP2004 -vars tmpsfc tmp2m<br><br>The result is a grib file for 6 hourly subsetted temperatures.<br><br>It's possible that this works for me because of the local grads installation. The q config from my workstation is appended below.<br>
<br>The NARR grid throws a curve, some things may work, for example I'm not sure if regrid works on NARR. I put the following data set into the same command as above:<br><br><a href="http://nomads.ncdc.noaa.gov:9091/dods/NCEP_NARR_DAILY/200409/200409/narr-a_221_200409dd_hh00_000">http://nomads.ncdc.noaa.gov:9091/dods/NCEP_NARR_DAILY/200409/200409/narr-a_221_200409dd_hh00_000</a><br>
<br>I don't recall encountering grib2 data yet, so I cannot comment on that. We like serving up HDF data which is likely the anti-fun compared to grib2.<br><br>Mike<br><br><br>Config: OpenGrADS-1.9.8-m3 32-bit little-endian readline sdf/xdf hdf-sds netcdf lats athena printim<br>
<br>Grid Analysis and Display System (GrADS) Version OpenGrADS-1.9.8-m3<br>Copyright (c) 1988-2005 by Brian Doty and IGES<br>Center for Ocean-Land-Atmosphere Studies (COLA)<br>Institute for Global Environment and Society (IGES)<br>
This program is distributed WITHOUT ANY WARRANTY<br>See file COPYRIGHT for more information.<br><br>Built Fri Jul 6 00:20:28 EDT 2007 for i686-pc-linux-gnu<br><br>This version of GrADS has been configured with the following options:<br>
<br> o This is a 32-bit LITTLE ENDIAN machine version.<br> o Command line editing (readline) ENABLED.<br> o CIRES/CDC (<a href="http://www.cdc.noaa.gov">http://www.cdc.noaa.gov</a>) SDF/XDF interface ENABLED.<br> Use sdfopen or xdfopen to read both NetCDF and HDF-SDS files.<br>
o DTYPE netcdf and DTYPE hdfsds are ENABLED.<br> o OPeNDAP (a.k.a. DODS) gridded data interface DISABLED.<br> o OPeNDAP (a.k.a. DODS) station data interface DISABLED.<br> o PCMDI (<a href="http://www-pcmdi.llnl.gov">http://www-pcmdi.llnl.gov</a>) LATS interface ENABLED.<br>
This version is configured to write GRIB and HDF-SDS files.<br> o DAO (<a href="http://dao.gsfc.nasa.gov">http://dao.gsfc.nasa.gov</a>) Athena Widget GUI ENABLED.<br> o NRL/DAO/PCMDI XA or ImageMagick Image Output DISABLED.<br>
o printim command for direct png/gif output ENABLED.<br> (via the GD Library -- <a href="http://www.boutell.com/gd">http://www.boutell.com/gd</a>)<br><br>For additional information please consult <a href="http://grads.iges.org/grads/">http://grads.iges.org/grads/</a><br>
<br><br><br><div class="gmail_quote">On Jan 30, 2008 11:10 AM, Wesley Ebisuzaki <<a href="mailto:Wesley.Ebisuzaki@noaa.gov">Wesley.Ebisuzaki@noaa.gov</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Mike,<br><br> I hate to disappoint you but the NOMADS sites (NCEP, NCDC) don't<br>use lats4d for the distribution of NARR, global reanalyses and<br>other model products. With the recent release of GrADS v2.0a, all the<br>
building blocks are in place for NOMADS to support grib-2.<br>For many users, grib-2 will be more fun than grib-1.<br><font color="#888888"><br> Wesley Ebisuzaki<br></font><div><div></div><div class="Wj3C7c"><br><br>Mike Bosilovich wrote:<br>
> Thanks for the prompt reply Brian,<br>><br>> I realize and greatly appreciate the amount of work you, Jennifer and<br>> others have done, with very little support. Grads is a great tool,<br>> hands down. And I tell that to anyone who will listen.<br>
><br>> I assumed that you all, as developers, would like feedback on what<br>> users need to do. Lats4d fills a very important role in my work, and I<br>> expect others as well. I wanted to pass on a point of view. Certainly,<br>
> I'm not trying to tell you what you must do, only providing feedback<br>> on the capability that I find useful.<br>><br>> Now, as for what Jennifer said, there was a post that says lats will<br>> not be supported. That was the impetus for my post. If I<br>
> misunderstood, and there will be lats4d capability in some way, I<br>> apologize for over reacting.<br>><br>> In any event, I also need to clarify my statement on the new NCEP<br>> reanalysis. They will have 1000TB of Grib1 format data at NCDC (this<br>
> is still changing, as I understand). In Grib2, it comes down to 500Tb<br>> or so. For what that's worth, it's still immense. I got the sense that<br>> they are planning on grib1, because of the lack of utilities with<br>
> grib2 capability.<br>><br>> Again, this is merely my opinion as a user, and I hoped the opinion<br>> and the information would be useful to the developers.<br>><br>> Sincerely,<br>><br>> Mike Bosilovich<br>
><br>> On Jan 29, 2008 10:02 PM, Brian Doty <<a href="mailto:doty@cola.iges.org">doty@cola.iges.org</a><br></div></div><div><div></div><div class="Wj3C7c">> <mailto:<a href="mailto:doty@cola.iges.org">doty@cola.iges.org</a>>> wrote:<br>
><br>> Mike, the new Version 2 of GrADS is being released in alpha version<br>> and incomplete so that people would have access to the new GRIB2<br>> support. With no funding for many years and key personnel working<br>
> limited part time hours we do not have the resources to support old<br>> code and also move forward to provide essential new functionality for<br>> present and future research needs. GrADS development first started<br>
> in the late 1980s and it has taken us several years of work to clean<br>> up the 15 years of accumulated mods and patches on top of the<br>> original code base in order to come out with a new code base so we<br>
> could move forward. I have made every effort over the years to<br>> ensure upward compatibility and maintain stability. There is no way<br>> that a 20 year old code base can be patched and hacked for another 20<br>
> years or even 5 years and maintain stability and still support the<br>> 100TB data sets you talk about and the other projects probably in the<br>> pipeline. As new versions of data formats appear -- grib2, hdf5,<br>
> new netcdf on the way, etc --- we have no choice. We cannot keep<br>> using old libraries and maintain them ourselves. We cannot patch and<br>> hack old code that we didn't write to begin with and which in some<br>
> cases has restrictive copyrights.<br>><br>> As I say, version 2 as it stands now is incomplete. Key areas of<br>> functionality which need to be re-implemented have not yet been<br>> done. Other major parts of grads have not yet been upgraded, such as<br>
> the graphics package. As Jennifer said in her original email, the<br>> output of various data formats is high on the list of things yet to<br>> be done... Brian<br>><br>> On Jan 29, 2008, at 4:34 PM, Mike Bosilovich wrote:<br>
><br>> ><br>> > I have to admit an ignorance to some of the inner workings of Grads<br>> > development. But I am quite surprised to hear that lats4d is not<br>> > presently supported in Grads 2.<br>
> ><br>> > I have been using Grads for 10 years now (I can still recall the<br>> > relief after years of ncargf77 programming :-) Of course, I still<br>> > write code when appropriate, but grads and lats4d have been the<br>
> > main tools in my work. Lats4d fills a critical void. By pointing it<br>> > at any grads formatted file (netcdf, hdf, binary or grib), I can<br>> > reformat the data to what ever a colleague may need. I can also,<br>
> > easily, no, effortlessly subset variables space or time. Coupled<br>> > with a call to regrid, this subsetting utility is beyond compare.<br>> > In a c shell, it can rip through huge data files with simplicity. I<br>
> > hope this does not sound like exaggeration, lats4d is the strongest<br>> > data tool I have used.<br>> ><br>> > In our office, we have just begun production of a new reanalysis<br>
> > data product. While it will take some time to complete, we are<br>> > beginning to develop examples on how users can access and analyze<br>> > the data. Comparison with other reanalyses is obvious and will be<br>
> > in high demand. To accomplish that, they will need to regrid our<br>> > data sets to the existing coarser reanalysis data sets. Or, they<br>> > may need to change the format out of our native HDF. The easiest<br>
> > way to explain to others how to do this is with lats4d.<br>> ><br>> > There will be 100Tb of reanalysis data available through a GDS.<br>> > With Lats4d and gradsdods (or gradsdap), this would be much more<br>
> > accessible. Users, with some examples, will access the data through<br>> > online capabilities, rather than bulk downloading of the native HDF<br>> > files (a throttle may be needed for access if that is the preferred<br>
> > by users). In addition, a plan is being prepared to develop a DVD,<br>> > similar to the NCEP reanalyses CD and NARR DVD. Personally, I would<br>> > like to see a flavor of grads and lats4d included therein<br>
> > (admittedly, I have not gotten to discuss this with the grads<br>> > developers yet).<br>> ><br>> > It doesn't stop there. At AMS last week, NCEP and NCDC held a town<br>> > hall meeting to discuss their plans for the next reanalyses. They<br>
> > expect to have nearly 1000Tb of data from three different<br>> > reanalyses, and their production has also started. I don't see<br>> > storage as a barrier, but bandwidth is. Too many users making too<br>
> > many big requests will limit accessibility. Lats4d access to their<br>> > GDS will become an important function.<br>> ><br>> > Again, I have to admit I do not know the extent of the issues here.<br>
> > By necessity, I will have to use versions of grads that include<br>> > lats4d not only in my work, but as I show other how to use our<br>> > data. I felt the need to speak up and I hope that these issues will<br>
> > be considered.<br>> ><br>> > A sincere grads and lats4d user,<br>> ><br>> > Mike Bosilovich<br>> ><br>><br>><br></div></div></blockquote></div><br>