Skip to main content


This page gives links to information and downloads for my software. If you find any of it useful and publish papers based upon it, please remember me in the acknowledgements. It is freely available to anyone who wishes to download it, but I disclaim all responsibility for any problems that might result from its use.

Documentation and download links

These links may give you a better idea of whether you want to download a given piece of software or not. They always refer to the most recent version; you will have to install the old versions if you want documentation on them. I divide up by programming language merely because the installation procedure has come to be defined by this.

F77 software

Most of my software is now written in C++ or Python, but there are a couple of well-used FORTRAN pacakges. These come with self-contained installation instructions. Although the installation is in theory not as portable as for the more recent packages, it is not normally too bad. The spectrum reduction "pamela" is now part of the starlink distribution, and since one needs starlink installed to use it, I no longer distribute it from here. Note that there is a bug in the hikianalia distribution of pamela, that will be fixed in the next release.

Package Download Version Date Changes Description
doppler doppler.tar.gz 1.0.3 Fri Aug 13 09:06:49 BST 2010 Recent All Starlink library & maximum entropy-based Doppler tomography package.
molly molly.tar.gz 1.1.8 Mon Apr 19 16:09:30 BST 2010 Recent All 1D spectrum analysis program.

C++ packages

I have moved my packages to github under user name "trmrsh". This is largely because git provides a nice platform for me to track changes and also to allow anyone else to add their own fixes, and once you get going with it, it makes updating really easy.

First steps:

  1. First ensure that all third-party software is in place. You may need some or all of the following: 'pcre' (perl-like regular expressions), 'cfitsio' (to read FITS), 'xercesc' (XML parser), 'PGPLOT' (plotting package), 'cURL' (for network requests) and 'SLALIB' (for positional astronomy). At the bottom of this page I have added diagram that explains the dependencies in more detail if you want to get them precisely right. You will also need GNU autotools (automake, autoconf, libtool) and the version control system, git. They are often installed on multi-PC systems, but may not be if you are installing on a laptop. They should be readily available under your package manager. If you don't have them, the installation will fall over, with, I hope, a fairly obvious error message. You should easily be able to find 'cURL', 'pcre', 'xercesc' and 'cfitsio' (you should look within standard repositories in the case of linux distributions), although they do not usually come by default in my experience; SLALIB, Pat Wallace's positional astronomy library, is not open source so I can't simply give a link to it I'm afraid. In order to avoid people bothering Pat for his code, he has sent me an obfusticated version which I will send to people on request. PGPLOT is almost invariably tricky if you have to install it; see below for some possible help. It comes as standard with many distributions of astronomical software such as STARLINK however, so have a look for it first before installing.
  2. Next decide on an installation directory. You might call this 'trm_software' perhaps in your top-level directory if you want to keep it separate from other packages (I will assume this below). In this directory, standard directories 'lib' and 'include' with libraries and headers will appear.
  3. If the installation directory is non-standard (you will probably find out when 'configure' fails to find header and library files when you try to install the first package dependent on 'subs'), then you will need to define the following environment variables (modify as appropriate for bash):
    setenv CPPFLAGS -I/home/username/trm_software/include
    setenv LDFLAGS  -L/home/username/trm_software/lib
    Adapt according to your configuration. If you intend also to use my Python packages (some of which use the C++ ones) you should also define
    setenv TRM_SOFTWARE /path/to/trm_software/

I will now assume that the above was successful; if not you will find out during installation and may have to return to the above section later. Here now is the procedure to follow for each C++ package, which I will assume is called 'new-package' on github (see the list of my repositories)

  1. Go to a directory in which the downloads will appear. I uuse a directory called 'github' for this, but pretty much anything will do.
  2. Type
    git clone
    This will download the software and create a sub-directory called 'new-package' (e.g. 'cpp-subs' for the standard C++ subroutines library).
  3. Then 'cd new-package'.
  4. Look at the README file. In general each package may require others to have been installed first. Thus apart from 'cpp-subs', almost all of them require 'subs' to have been installed. Make sure that the dependencies have been resolved before continuing. See below for an attempt at a visual representation of the dependencies.
  5. The C++ packages are built using the GNU autotools (automake, autoconf, libtool). These generate a script called 'configure' which does the hard work. Create this using './bootstrap'. This command can be safely re-run at any point.
  6. bootstrap should create a script called 'configure'. You run this as follows:
    ./configure --prefix=/path/to/trm_software
    (change according to your details). If you have root permission and don't mind polluting your root directories with my software, then a plain
    will do, perhaps involving a 'sudo'.
  7. You should then be able to carry out the usual
      make install
  8. Do not delete the directories downloaded from github because they will help speed later re-installs.

If you are having problems, read the troubleshooting tips, and if that does not help, contact me. In fact I recommend reading the troubleshooting tips before you start ... they could well save you some bother. Be warned, no matter how much I try, installation never seems to be smooth and I have largely lost the will to make it better. If you are trying to install the ULTRACAM pipeline, then you may want to look at this list of required software as well which summarises what can be extracted from this page, but in short order.


Suppose you have got through the above, but there is a new version (perhaps as the result of a fix for a bug you found and very nicely told me about). Then things should be much easier. You go to the relevant source directory ('cpp-subs' perhaps). You then type

git pull
make install
and should be good to go. If something more significant then a bugfix to an existing file has happened, you might need to re-run configure, but it should be easy. It might also be useful to know that 'make' can use multiple cores e.g. 'make -j4', but if you use this you should generally finish with a plain 'make' because it can get itself confused. Of course if you are trying to fix, say, 'ultracam', because of a bug in 'subs', then you will need to propagate the installations, and so will need to run 'make', 'make install' in the 'ultracam' repository directory after the above fix has been completed.

PGPLOT installation

PGPLOT_INSTALL is a shell script which may help you overcome some of the difficulties of PGPLOT installation. Linking to PGPLOT however remains one of the trickiest aspects of the whole thing. I have recently had mixed experiences getting the PNG drivers going and sometimes just edit the attempt to install them out of the script. The only real essentials are the X display and the postscript devices.


See above re the C++ packages and github. Follow steps 1 to 4 to get the software from github and check dependencies. Once these are satisfied, its just the usual python installation procedure:

python install --prefix=your_installation_directory
where the installation directory will end up with a sub-directory or two. I use the same directory as I use for my C++ software in which lib/ and include/ appear. Just as for any python package, to use the package you may need to adjust your PYTHONPATH to point to where the package is, which could be something like
but obviously check the precise location first. You will know if it is not in your PYTHONPATH when an attempt to import the package or to access the help with 'pydoc' fails.

Troubleshooting tips

  1. Do not use the sub-directories that the git repositories unpack into for installation. You will have horrible problems if you ignore this one, believe me. To be specific, if I git clone into trm_software creating cpp-subs, I can use trm_software as the installation directory, but not trm_software/cpp-subs. Remember too that the directory that you specify will be a container for 'lib' and 'include' subdirectories.
  2. Look at the README files for what needs to be installed up front. Install it! If you are not sure whether you have it already, run 'configure' as described earlier, but make careful note if it reports that it cannot find packages listed in the README as you will need them. If it says it can't find packages which you absolutely know you have installed, then you probably have not told it where to look. If this is the case, see the next tip!
  3. If you have non-obvious problems with the C++ installation during the 'configure' stage, look at the file 'config.log' that should be generated. This looks horrendous at first sight but normally it will show a fairly simple-to-understand error if an attempt has been made to compile or link a simple test program which resulted in failure. Searching for 'error" is a good way to start. You may either find that the relevant files do not exist, in which case you need to make sure that they do (e.g. you might need to install slalib), or, more subtly, you may have failed to direct the compiler/linker to the correct location. There is a standard set of directories that get searched anyway, so presumably these files are not in those so you need to give configure some help. You do so using the 'CPPFLAGS' and 'LDFLAGS' environment variables as explained above. The first is used to identify the locations of header files (needed during compilation), the second for the locations of libraries (needed during linking). Here is how you might use these:
    setenv CPPFLAGS "-I/home/user/trm_soft/include -I/some/other/path/include"
    setenv LDFLAGS "-L/usr/local/lib -L/some/other/path/lib"
    Essentially they end up as directives which get passed to the compiler/linker. You can add any number of such directives.

    A common time to hit problems that require compiler/linker directives is when you try installing the first package that needs 'subs', because 'subs' only needs system packages which are usually to be found in standard locations, whereas you might well install 'subs' itself in a non-standard location because e.g. you are not root. You will only find out when you try installing a package that needs 'subs', at which point configure might say:

    configure: error: cannot find 'subs' headers
    If this happens, configure does not know where you put 'trm/subs.h' etc, so you need to tell it. (If you are puzzled by this, remember that different uses of 'configure', the first to install 'subs', the second to install pacakage 'X', do not communicate with each other, so unless you tell it, at the time of installing 'X', 'configure' has no idea where 'subs' is without your telling it.) To fix it, add wherever 'trm/subs.h' is located to CPPFLAGS and run configure again. Better yet, brefore re-running 'configure', you might as well direct LDFLAGS to where '' is. If you get past this stage, you are on the downhill slope ... If you expect to install others of my packages, you may want to hardwire the CPPFLAGS and LDFLAGS into your .cshrc or equivalent scripts.

    The various packages are supposed to be built so that they know where any shareable libraries that they were built with reside. However, one linux user had a problem building 'subs' which did not know where to find PGPLOT. I would interested if anyone else encounters this as I don't understand why it occurred. A fix (one I don't much like, but have no alternative to) is to direct the linker ('ld') to the right directory which can be done with the environment variable 'LD_LIBRARY_PATH'.

  4. Sometimes it helps to return to the './bootstrap' phase just to check that there really is a problem, perhaps starting off with a 'make clean' to clear out files and force re-compilation.
  5. If you get a problem like "LIBCURL_LIBCURL_CHECK_CONFIG: command not found", you might not have the libcurl development package installed.
  6. Finally, if you have not used any of my C++ programs before, I strongly advise you to look this page on user input written for the ultracam pipeline, but which is of wider applicability.

Map of C++ dependencies

The image below attempts to show what is needed for the C++ routines. If you are interested in a particular package, 'rvanal' for instance, follow the lines leading up from it, but never take a line sloping downwards. In this case you will see that you need 'observing' to be installed which requires 'subs' which in turn requires 'slalib', 'pgplot' and 'pcre'. 'pgplot' in turns needs 'png' (although see above for more about this). To install 'rvanal' therefore you would need to install first 'png', then 'pgplot, 'pcre' and 'slalib', then 'subs', 'observing' and finally 'rvanal'.

You will need many other pieces of more standard software which I don't include in the diagram as they are more usually available. A (probably incomplete) list is: autoconf, automake, libcurl, libtool ("gnu auotools"), gcc, gfortran, g++, readline, git (for getting the software in first place). ultracam comes also with some Python scripts for which there are some other dependencies. The most important is probably yo have either 'pyfits' or 'astropy' in place to allow the script '' to operate. If the package is one that is required for compilation and linking (e.g. 'readline', 'libcurl' and 'pcre', but not 'git'), you will need the development version (often called 'package-name-devel').

Dependencies map

Tom Marsh, Warwick