Given that you plan to upgrade your system for GEMPAK and LDM, it would
be a good time to also consider hardware specifications for the upcoming
migration to AWIPS-II. The minimum specifications are detailed in the
NAWIPS/GEMPAK-to-AWIPS II migration FAQ:
* The AWIPS II installation procedure has been tested on 32 bit Red Hat
4.6, Red Hat 5.0 and CentOS 4.7 Linux systems. At this time it has not
been tested on x86_64 bit Linux or Solaris platforms. Since AWIPS II is
currently under development, the recommended system specifications below
(as given by NCEP) will likely change as testing continues.
* System: 32 bit Red Hat Enterprise Linux 5
* RAM: 4 GB
* Video: 256 MB video memory, OpenGL 2.x support (CAVE appears to run
best with Nvidia)
* Disk: 10-20 GB; disk space depends on the amount of data stored.
* Network: An active network connection outside of AWIPS II is required.
The tricky bit right now is the uncertainty about AWIPS-II support in
64-bit environments. Last month Unidata received an update on possible
64-bit support from Raytheon's Omaha development team. In it, concerns
were raised about performance issues, development time invested for
testing, and the uncertain amount of time necessary for a full upgrade
to 64-bit support, though it was mentioned that these issues “/can be
overcome, and upgrading to 64 bit should remain a goal for the AWIPS
team. The critical questions are how much time will the upgrade take,
and do the benefits outweigh the risks? Due to the impending May
deadline to begin fielding and the likelihood of increased DR counts …
Raytheon Omaha recommends that we do not move CAVE to 64 bit at this time/”
There was an interim solution proposed, which was “/to upgrade the
operating systems of the workstations to 64 bit but leave CAVE with 32
bit libraries. This prepares the operating systems for a forthcoming 64
bit CAVE upgrade while removing most of the risks/.” Furthermore, the
Raytheon Omaha Special Projects team successfully upgraded to 64 bit
servers which “/provides good evidence of a 32 bit CAVE working in a 64
So it seems that if you were to purchase a new system intended for both
GEMPAK/LDM now and AWIPS-II in the near-future, a 32-bit system
architecture would be ideal, but compatibility with 64-bit systems
It's a difficult position for Unidata to be in right now - I'd really
like to be able to tell you that 64-bit is recommended and that you'll
be 100% supported down the road, but we're still somewhat unsure of how
AWIPS-II will behave on such a system. It's encouraging to hear that
Raytheon is directing attention to 64-bit support (perhaps "64-bit
compatibility" is a better term), but at this time evaluation and
testing in a 64-bit environment hasn't really taken place.
I apologize for the lengthy and slightly off-topic response, but hope it
helps clarify the near-future plans for both NAWIPS/GEMPAK and AWIPS-II.
GEMBUD readers please feel free to chime in if you have any related
questions or concerns.
On 05/09/2011 10:34 AM, Phil Birnie wrote:
We are getting ready to update our box on which our LDM and Gempak
software reside. I wanted to drop a line to see if anyone had any
hardware suggestions... I found this thread (below) from 2005, and
some of the suggestions still ring true, but wanted to get some
updated advice. Just a little more info:
• This machine also serves as as web server
(http://twister.sbs.ohio-state.edu) (we provide basic model, text,
and graphical products to the general public -- but have been held
back by hardware limitations)
• We have about 8 to 10K worth of funding for this project..
• We have used and would like to continue to use (if at all possible)
Redhat Enterprise OS unless someone has other suggestions...
Thanks in advance for any suggestions...
--- QUOTED FROM THREAD IN 2005 ----
You can get several nicely configured machines for $5K. We are
running RedHat Fedora Core 3 here, which supports 64 bit
processors in the 2.6 kernel. Redhat Fedora is free. Depending on
your campus, you could go the supported RedHat Enterprise OS route.
We generally recommend that you probably want to consider 64 bit
processors for the future, such as the Xeon or Opteron64. Dual
processor systems are quite affordable, and in the case of
an LDM server that is also doing decoding/filing, and product
generation, you will get the use out of a dual CPU machine.
User desktop systems can go either way. For running models,
the dual CPU systems are definitely going to be the way to go-
and memory should be as much as possible in your budget.
For an LDM server, it is a good idea to have as much RAM as the size of
your product queue, and your queue should be able to hold an hours
worth of data. If you were getting all IDD feeds, that would be
up to 3GB an hour at present rates. Since you are receiving a smaller
subset of data at this point, 2GB is OK for now.
For a robust LDM server, just surfing the web, a Dell dual Xeon 2.8GHz
Power Edge SC1425 with 2GB of RAM is running $1377
(my link was following the small business rack server links
That link may not get you the same page if it was using cookies etc, but
it gets you in the ballpark.
>From starting around $1377, you can ad a couple of 250GB disks for about
$400. For desktop systems where you'd need a graphics card and display,
you'll probably add $750 for a 19" flat panel and graphics card, but be
looking at tower cases, and smaller hard disks, maybe 36 or 72GB if the
data is primarily on the server. You could probably get a couple
of desktop systems with nice monitors etc for $1500.
GEMPAK will run on 128MB, but You'd probably never want to
get a new workstation with less than 512MB. You'd be happiest
planning for the future with 1GB for a desktop system. If you
plan on using the Java based IDV, I'd suggest 1GB.
If you have a specific plan for number of seats in a lab, let us know
and we may be able to get more specific, or if you are generally looking
at remote access to the server that is doing LDM and modelling, then
rack machines are a good use of space.
Unidata User Support
-- Phil Birnie --
gembud mailing list
For list information or to unsubscribe, visit: