NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Robert- Robert Mullenax wrote:
McIDAS would be the way we would move if something did happen to GEMPAK. It's ability to deal with model data is not anywhere nearly as good, but the new MySQL database storage of GRIB data does make it faster, and text products via the wxtlist, tafrpt, sclist, sfcrpt has always been pretty good...and of course satellite is still it's strong suit. We are heavy users of it right now for certain things.
As you note, each package has it's strength and weaknesses. Note that the next version of McIDAS (Mc-V) is being developed on top of the IDV framework and VisAD in Java. Also, work is in progress on reading McIDAS grids in the IDV using the same framework used for the GEMPAK grids.
That being said if I ever get a new machine with 4GB of RAM ee will install IDV on it since it runs on Solaris x86/x64 now. I have already played around with it quite a bit on my personal laptop.
You don't need 4GB of memory to run the IDV. We continually strive to improve the memory usage and part of the Mc-V development will address the heavy image memory usage. Feedback on where the bottlenecks are currently is always welcome. As for the underlying issue of GEMPAK moving to AWIPS2, Unidata is monitoring this closely. If you look at the job description for the GEMPAK support position, a key piece of that job will be to work with the Raytheon and NCEP developers to ensure a smooth transition away from the current GEMPAK/NAWIPS package, which as noted elsewhere will eventually go away. Don ************************************************************* Don Murray UCAR Unidata Program dmurray@xxxxxxxxxxxxxxxx P.O. Box 3000 (303) 497-8628 Boulder, CO 80307 http://www.unidata.ucar.edu/staff/donm *************************************************************
gembud
archives: