<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
We know that the loss of the LATS interface severely impacts many users. But our intention is to *replace* it with something better, not to eliminate the functionality completely. Consider this: <div><br class="webkit-block-placeholder"></div><div>set x; set y; set z; set t; set e<br><div>set gxout fwrite</div><div>set fwrite -nc file.nc</div><div>d var</div><div>disable fwrite</div><div><br class="webkit-block-placeholder"></div><div>You've just written out a subset in netcdf with all the necessary metadata. Other formats such as HDF could be added as a -h4 or -h5 option. When 'var' is part of an unmanageably large grib2 data set behind a remote server (several possibilities come to mind), you've just saved yourself a week (or more) of work. </div><div><br class="webkit-block-placeholder"></div><div>Jennifer</div><div><br></div><div><div><br><div><div>On Jan 30, 2008, at 8:53 AM, Mike Bosilovich wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Thanks for the prompt reply Brian,<br><br>I realize and greatly appreciate the amount of work you, Jennifer and others have done, with very little support. Grads is a great tool, 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 users need to do. Lats4d fills a very important role in my work, and I expect others as well. I wanted to pass on a point of view. Certainly, I'm not trying to tell you what you must do, only providing feedback on the capability that I find useful. <br> <br>Now, as for what Jennifer said, there was a post that says lats will not be supported. That was the impetus for my post. If I misunderstood, and there will be lats4d capability in some way, I apologize for over reacting.<br> <br>In any event, I also need to clarify my statement on the new NCEP reanalysis. They will have 1000TB of Grib1 format data at NCDC (this is still changing, as I understand). In Grib2, it comes down to 500Tb or so. For what that's worth, it's still immense. I got the sense that they are planning on grib1, because of the lack of utilities with grib2 capability.<br> <br>Again, this is merely my opinion as a user, and I hoped the opinion and the information would be useful to the developers. <br><br>Sincerely,<br><br>Mike Bosilovich<br><br><div class="gmail_quote">On Jan 29, 2008 10:02 PM, Brian Doty <<a href="mailto:doty@cola.iges.org">doty@cola.iges.org</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, 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><div><div></div><div class="Wj3C7c"><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></div></div></blockquote></div><br></blockquote></div><br><div> <span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div>--</div><div>Jennifer M. Adams</div><div>IGES/COLA</div><div>4041 Powder Mill Road, Suite 302</div><div>Calverton, MD 20705</div><div><a href="mailto:jma@cola.iges.org">jma@cola.iges.org</a></div><div><br class="khtml-block-placeholder"></div><br class="Apple-interchange-newline"></span></span></span> </div><br></div></div></div></body></html>