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
