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.
So a new scripting language (I know IDV does not use sh or csh scripts) will have to be learned in order to write product generation scripts of the new McIDAS?
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.
Sorry, I did not mean to imply that you need that much for IDV, but it will be doing a lot of other things as the same time, in the background. We have to squeeze every ounce out of things around here I am afraid.
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.
If you read the specs about the AWIPS2 package it is daunting for someone like me who is not a programmer, not even a CS person really, it's so different from GEMPAK. Hard to see how it's going to be smooth, but I will take your word for it.
Thanks as always, Robert