People who have training or experience in following severe weather rarely are content to rely on the media for severe weather information. This isn’t to say anything against the TV and radio outlets, but we would just rather see the data for ourselves and make our own decisions. A number of software packages exist for analyzing weather data, of varying price and quality. For Linux and OS X users (and Windows users via Cygwin), perhaps the most powerful is GEMPAK, developed by the National Weather Service and made available by Unidata.
GEMPAK is basically what national centers, including the Storm Prediction Center and the National Hurricane Center currently use for data analysis and visualization. It is also a pretty old suite, written in pretty old Fortran, and kind of a bear to get installed sometimes. Unidata formerly provided pre-built binaries, but only source code is available for the 5.11.4 release. Since there seems to be an absence of step-by-step instructions, I thought I’d post my own. Of course, as soon as I post this, a public release of AWIPS II will be announced.
The first step is to prepare your environment. This basically consists of creating the appropriate user and/or directory structure. For simplicity and security reasons, I prefer not to create a separate GEMPAK user. I prefer to just build it in a directory that I have access to and then move it to opt when I’m done. If your account will be the only one using GEMPAK, you can just leave it in your home directory. For the sake of this demonstration, let’s assume we’re doing it my way. Then there’s no pre-work to do.
Next you’ll need to download the GEMPAK source code from Unidata’s website. Unidata requires registration to download the software, but it is free and they don’t harass you. While you’re waiting for the tarball to download, you’ll need to make sure you’ve got a few of the packages necessary for building GEMPAK. Most of them can be found in the yum repository, so you can install them with:
su -c "yum install gcc-gfortran gcc-c++ libXp-devel libX11-devel xorg-x11-fonts-ISO8859-1-75dpi"
You’ll also need OpenMotif packages, but they can’t be newer that 2.3.1. This means you cannot install the packages from the RPMFusion-nonfree repository. You’ll have to grab them manually from MotifZone. There aren’t builds for recent Fedora releases on there, but the Fedora 9 RPMs work fine with Fedora 12. Since we’ve installed these RPMs, you need to make sure yum won’t try to upgrade them, so make sure you exclude “openmotif*” in /etc/yum.conf.
By now, the tarball should be downloaded. You’ll need to unpack it just like you would any other. Let’s assume you downloaded it to ~/Download, so go to the directory you want to build GEMPAK in and run:
tar xfz ~/Download/gempak_upc5.11.4.tar.gz
Now cd into the GEMPAK5.11.4 directory you just created. The first thing you’ll need to do is edit the Gemenviron.profile (if you use the Bash shell) or Gemenviorn (for C-shell). This file sets the myriad of environment variables that GEMPAK uses. Fortunately, it is sanely built, so you only need to make a few changes. Change the NAWIPS variable to point to the directory you’re building in (for example, $HOME/GEMPAK5.11.4). USE_GFORTRAN should already be set to 1, but double-check that it is and that the references to USE_G77 and USE_PGI right below it are commented out. Eventually, you’ll also need to make sure the GEMDATA and LDMDATA variables are set correctly, but that’s beyond the scope of this how-to.
After you’ve saved the Gemenviron[.profile] file, you’ll need to make sure config/Makeinc.common is correct (it probably is) and you’ll need to edit config/Makeinc.linux_gfortran (or config/Makeinc.linux64_gfortran if you’re on an x86_64 system. You can check that with `uname -i`). Change the MOTIFINC variable to “-I/usr/include/openmotif” and change X11LIBDIR to “-L/usr/lib/openmotif” (replace “lib” with “lib64″ for x86_64 systems).
There’s one more step to get things working, which appears to be a result of Fedora 12 using a newer version of autotools than the source was prepared with. You”ll need to run the following command in both the extlibs/netCDF/v3.6.2 and extlibs/JasPer/jasper directories (return to the GEMPAK5.11.4 directory when you’re done):
autoreconf --force --install --symlink
Now that that’s done, you’ll need to load the GEMPAK environment. For the Bash shell, use `. Gemenviron.profile` and for the C-shell use `source Gemenviron`. The next step is to actually build the programs. It is a lengthy process (I timed it at about 8 minutes on my system), so you might want to go get a cup of coffee or something. Since it produces a lot of output, we want to make sure we can go back and look through it if there are any problems (it took about 5 build attempts before I got these instructions to a workable state), so we’ll save the output to a file called make.out.
make >& make.out
Once that’s completed, it’s time to install the files and clean up after ourselves:
make install; make clean
If you plan to move the built GEMPAK into somewhere like /opt, now’s the time to do that (make sure you update the NAWIPS variable in Gemenviron[.profile] appropriately). I prefer to move it to /opt and then create an /opt/gempak symbolic link to the GEMPAK5.11.4 directory so that if I install a different version, I just need to change my link and everything else works the same. For ease of use, you should set your shell configuration file to call the Gemenviron[.profile] script at login if you plan to use GEMPAK frequently.
That’s all there is, it’s ready to use now.
Edit – 7 October 2010. Instructions for Intel-based Mac OS X builds have been written by Kevin Tyle and posted to the Gembud mailing list.
Edit – 9 October 2010. Added the gcc-c++ package per Gerry Creager’s suggestion.
Pingback: Tweets that mention Building GEMPAK on Fedora « Blog Fiasco -- Topsy.com
Had my gempak workstation we use for skywarn crash, your instructions saved me a TON of time after
I pulled my hair out with these issues. THANKS!! Did you get Nsharp to run? That program seems to
segmentation fault.
I’ve replied to Ray via e-mail, but for the reference of future readers, my build of GEMPAK had a usable Nsharp. It’s still not clear what’s causing Ray’s problems.
Thanks the primer Ben; we need more clearly written instructions like these. What we don’t have though is a decent writeup on how to configure some basic scripts to access publicly-accessible data sources (for those of us that do not have the university feeds). All one can really find is snips and bits here and there, but in the end most folks have to muddle though it or pay somebody. My guess is that the folks who figure it out keep their cards close to their chest afterwards. Thanks once again.
Jack, I’m glad you found it helpful. I agree that it would be nice to see more scripts to mirror NWS data feeds for GEMPAK use. I actually considered trying to tackle this at one point, but since I have access to a university feed, it’s not been a priority for me. You’re right about the people who have such scripts keeping them hidden, and that’s probably because most of them are trying to make money off of them (which they are entitled to do, if they so choose). If I ever get around to developing one, I’ll share it publicly. It may end up waiting until after the GEMPAK to AWIPS II migration is a bit more clear. If the directory structure is considerably different, it may not be worth the effort to make something for GEMPAK.
Hi,
this might be a stupid question but how do you download the tarball? I have an account with unidata but when using wget to download the file i get a sign in form downloaded to my server and not the tarball…do i have to downnload the file to my pc than upload it to the server?
Thanks
Mary, you might be able to use the
--http-userand--http-passwdarguments to wget, but I’ve never tried it that way. I just download from the web browser and then copy it to a remote system, if necessary.This worked almost perfectly. I found 3 more packages that need to be on the system to make this work properly:
bison flex libtool
Ben, thanks for pointing that out. I install development tools when I initially install the OS, so I didn’t have to explicitly install them for the GEMPAK build. That’s probably not the case for everyone.
Your instructions have gotten me closer, but I’m still having problems getting the gui’s to build and netcdf. I’m using RHEL 5.5.
I’ve installed all the software needed including openmotif22-2.2.3 and openmotif-devel. I’m not certain though what I should use as the /usr/include because I’m not certain what include files the software is actually looking for. A rpm -q –list shows the openmotif-devel has installed files into /usr/include/Xm /usr/include/uil & /usr/include/MrM all the libs are installed in /usr/lib64 so that one was easy to setup.
The netcdf build is failing even after doing “autoreconf –force –install –symlink” in the netcdf directory. (This worked fine for jasper). I get these errors for netcdf though:
-bash-3.2$ autoreconf –force –install –symlink
man/Makefile.am:155: user target `netcdf.html’ defined here…
/usr/share/automake-1.9/am/texibuild.am: … overrides Automake target `netcdf.html’ defined here
man/Makefile.am:159: user target `netcdf-install.html’ defined here…
/usr/share/automake-1.9/am/texibuild.am: … overrides Automake target `netcdf-install.html’ defined here
man/Makefile.am:163: user target `netcdf-c.html’ defined here…
/usr/share/automake-1.9/am/texibuild.am: … overrides Automake target `netcdf-c.html’ defined here
man/Makefile.am:179: user target `netcdf-tutorial.html’ defined here…
/usr/share/automake-1.9/am/texibuild.am: … overrides Automake target `netcdf-tutorial.html’ defined here
man/Makefile.am:167: user target `netcdf-f77.html’ defined here…
/usr/share/automake-1.9/am/texibuild.am: … overrides Automake target `netcdf-f77.html’ defined here
man/Makefile.am:175: user target `netcdf-f90.html’ defined here…
/usr/share/automake-1.9/am/texibuild.am: … overrides Automake target `netcdf-f90.html’ defined here
man/Makefile.am:171: user target `netcdf-cxx.html’ defined here…
/usr/share/automake-1.9/am/texibuild.am: … overrides Automake target `netcdf-cxx.html’ defined here
man/Makefile.am:61: user variable `TEXI2DVI’ defined here…
/usr/share/automake-1.9/am/texinfos.am: … overrides Automake variable `TEXI2DVI’ defined here
man/Makefile.am:73: `doc_DATA’ is used but `docdir’ is undefined
autoreconf: automake failed with exit status: 1
I’m not so worried about the netcdf as I already have a very happy build of 3.6.2 on my machine that I figure I can use if desperate.
Any help would be really appreciated.
My issues with Nmap and Nsharp were related to fonts. Make sure The X org fonts 8859-1 and 8859-2 are installed and all will be just fine.
Ray
Ray you are the best! The fonts solved my nsharp crashing issue as well! I’ve got a Dual Core X2 4200 box here I might make another gempak box here – bringing my total to 2 Gempak boxes at my house 🙂
Hello, your guide has been a God-send! It saved me so much time tracking down the correct settings. Thank you very much!
Great content. Could I usethis on one of my sites? I would like to put it as a reference for my readers in a link pointing back here. Thanks. =) Weber (=