The Gnu Data Language (GDL) is a useful open-source alternative to IDL on Linux. Although for new astronomical scripting applications we prefer Python, the proprietary IDL system is widely used and there are many astronomical routines written for it that are freely available. This page is a guide to the installation of GDL on an OpenSuse Linux platform.
Download the recent source code
We assume that the base OpenSuse system has been installed with the packages that are often used to support scientific computing. There are some unusual dependencies to build a complete GDL. Additional procedures may be added after the fact since they are compiled as needed by GDL itself.
We would like to recommend installing the version in the CVS repository since is likely to have many known issues corrected. However, the version 0.9.2 released on 2012-02-20 will compile and is largely compatible with IDL and EXOFAST. These notes are based on this version and a CVS verion of 2012-07-29 which updates that release.
Go to the Sourceforge website:
and click on the "Code" link in the top menubar rather than the "Download" button that provides the last stable release. At the bottom of the new "gdl" listing there will be an option to download the GNU tar archive of the entire CVS tree. Once you have it on your system, make a copy in a permanent location, and as superuser (su), also to the /usr/local/src tree on your Linux system:
cp gnudatalanguage-gdl_20120729.tar.gz /usr/local/src
You are ready to compile the code.
Install and compile the source code
The source tree will be in /usr/local/src/ where you made a copy of the downloaded tarfile:
tar xvzf gnudatalanguage-gdl_20120729.tar.gz
This will create a "gdl" directory in /usr/local/src containing the files you will compile.
./configure --without-hdf --with-hdf5
If the configuration does not successfully complete and create "Makefile" in the top level directory, look at the list of errors generated during configuration for clues about missing packages. There will distinctive name that you will have to find in the distribution's repositories. For OpenSuse, you would use yast or yast2 as indicated, then repeat the configure command and the search for rpm's until there are no errors.
Once those issues are resolved, try building the software with
We find that during the build you may see an error such as this one:
libtool: Version mismatch error.
which is corrected by running this command
aclocal; libtoolize --force; autoconf; automake -a
in the toplevel of gdl directory, and then repeating the configure and make commands.
The GDL team notes in their CVS version that they will be using cmake instead of autoconf in the future. The software can be compiled with cmake once you install the package for your distribution. The process would be something like this:
modified to allow for variations in your installation requirements. Instructions are in the gdl INSTALL.cmake file.
After a successful make operation, install the binaries and library with
Prepare a location for the procedures that you will add:
cp -p -r /usr/local/src/gdl/src/pro ./
Add new procedures
For astronomical use, there are additional procedures to install system-wide. Download and save in your long term archive the code from these sites:
- Craig Markwardt's CMSVLIB provides SAVE and RESTORE in GDL
- NASA's astronomy library and the ftp site provides many astronomical utility procedures and handlers for FITS files
- Mark Buie's IDL libary and download site provides procedures for astrometry, photometry, and spectroscopy
- Matthew Craig's tex to IDL provides procedures to use LaTeX markup coding in graphics
Copy the .pro files from these sources into one or more separate directories under /usr/local/gdl. For example, we would use something like this:
cp /home/john/gdl/archive/astron.tar.gz ./
tar xvzf astron.tar.gz
cp *.pro /usr/local/gdl/astro/
rm -r tmp
and repeat this for each of the libraries you want to add, copying only the *.pro files into gdl. They can all go into gdl/astro, or if you anticipate updating them individually, into a separate directory for each one.
When you are done, assign the ownership of the gdl directory to root, or to a trusted user:
chown -R root.root gdl
to assure accessibility of all files and limit access for writing.
Set environment variables
In the bash shell edit the .profile directory for each user who would access gdl, or add to /etc/profile.local for everyone, to make these changes (written assuming separated directories for each added library):
We include here access to Jason Eastman's EXOFAST, assuming it may be installed in an indivdual user directory. In that case, these changes would be in that user's "hidden" .profile file.
Run EXOFAST under gdl
To run gdl you simply issue on the command line "gdl" and you will be in a command line environment for the Gnu Data Language. To exit and return to the shell, "exit". GDL commands are identical to IDL, and most are supported in the recent code.
To run a process
gdl -e 'myprocess'
is all that's needed. The myprocess.pro file must be in the current working directory or the path. Note that ".pro" is not on the command line.
To run and test EXOFAST, install it in your user home directory under your own "gdl" with the appropriate addition to your .profile as noted above. Then
Test it with this command:
gdl -e "exofast, rvpath='hat3.rv',tranpath='hat3.flux',pname='HAT-P-3b',band='Sloani',/circular,/noslope,/specpriors,minp=2.85,maxp=2.95"
There may be small modifications to the exofast procedures needed to make this work. A list of known ones as of 2012-07-30 is provided below. For help with finding solutions, a list of routines supported in GDL is available.
Running EXOFAST under GDL: problems and solutions
With stable version 0.9.2 of GDL, EXOFAST will run the fitting with the libraries given above, addition of a few missing procedures, and changes edited into specific exofast procedure files which we will note here. It will fail when trying to create a plot because of a missing routine (that is documented in GDL as present in the core code). The missing routine is said to have been added back in the CVS version as of 30 July 2012. However, the CVS version generated errors when EXOFAST reads its basic data files. This section documents our efforts to resolve this problem.
- chisqr_cvf.pro -- is not in the libraries noted above
It is available on a web search. It appears to be an ITT Visual Information Solutions routine, though it derives from code published elsewhere. It could be recoded into a gdl procedure if needed. We add it to /usr/local/gdl/extra/.
- chisqr_pdf.pro -- is not in the librarires noted above
It is available on a web search. While it appears to be an ITT Visual Information Solutions routine, it simply calls IGAMMA which is a GDL routine. We add it to /usr/local/gdl/extra/.
- bisect_pdf.pro -- is not in the librarires noted above
It is available on a web search. It appears to be an ITT Visual Information Solutions routine. We add it to /usr/local/gdl/extra/.
- USERSYM -- called by the astro library routine plotsym is not present in 0.9.2
This routine is internally coded and should be in the distribution. In this version it is annotated in plotting.ccp with the note "//for now usersym is a circle". It was introduced into the CVS source code in response to a bug report. However, the CVS version now generates errors in reading the data files used with EXOFAST, making it unusable in its current form.
USERSYM is called by plotsym.pro, an astro library routine. It is used to create distinctive point plotting in routines exofast_chi2.pro exofast_plotdist.pro. A workaround could be to comment out the call to plotsym and edit the symbol choice to a standard symbol for the following plot so that usersym (a user-defined symbol) is not requested.
- OPLOTERR -- called by exofast_chi2 and missing from GDL.
The code lines
oploterr, time, rv.rv - (rv.bjd - t0)*slope-gamma, rv.err, 8
oploterr, time, rv.rv-modelrv, rv.err, 8
could be replaced by oplot with different parameters, or a perhaps a simple ploterr procedure could be defined. There is a note in the GDL urgent needs file that oploterr should be easily derived from ploterr.