Miscellaneous Utilities

Things to run inside CASA

Many of RobReid's utilities are listed below, but there is a semiautomatically generated list here, which is naturally more complete.


I snipped this out of almasimmos to make and CLEAN an image from a measurement set. Comes in handy after adding noise.


The FITS files written by IDL often don't include header information that CASA expects. This function (based on what Kumar Golap suggested) tries to get an IDL 'fits' file into casa so it can be used as an input image for almasimmos. It is a work in progress, and you may need to massage its input using miriad and/or karma (including kvis).


Given a list of pointings, make a kvis annotation file for them.


Recommends an ALMA configuration for nearly any occasion. It requires a set of summarized beam properties (like this one ). Unfortunately it does not know about the ACA yet, but it should not be too hard to add.

Notes on running third party software in CASA

There are two ways to load in a python file example.py: execfile and import.

  • execfile('example.py') execfile is fine when you are not concerned with reusing the contents in another file, or namespace pollution. It is the only option when the file is a script that should run commands by itself, as opposed to merely defining functions, classes, and/or variables.

  • import example Imports example.py as a module, which has four advantages:
    1. The contents can be reused by putting import example in other files.
    2. You do not have to remember the path to example.py, as long as it is in sys.path.
    3. The namespace is protected by prefixing the contents with example., i.e. func1 becomes example.func1. This is of course a dubious advantage, so you can get an unadorned func1 with from example import func1 or from example import *. The as keyword can also be useful.
    4. example.py gets byte-compiled to example.pyc the first time it is imported, and example.pyc is used thereafter. This advantage can be at least as annoying as #3.
    In practice you need two more bits of python knowledge to reap these benefits:
    1. Your sys.path likely does not yet include a directory you can write to without being root. Create a directory for keeping your personal CASA python libraries, keeping in mind whether you want it to be visible from more than one computer (i.e. via NFS). You will be using it for eons to come, so make it an environment variable in your .profile, .tcshrc, or et cetera. E.g. for bash or zsh,
               export CASAPYUTILS="~/src/python_mods"           (bash, zsh)
      Source your .profile, .tcshrc, or et cetera, and in your shell run
               mkdir -p $CASAPYUTILS
               mv example.py $CASAPYUTILS
      Then you have to add $CASAPYUTILS to sys.path. In a casapy session that knows about $CASAPYUTILS,
               import os, sys
      Don't try
               sys.path += os.environ['CASAPYUTILS']
      unless you are as easily amused as I am. To avoid having to do this in future casapy sessions, put the following in the main() function of your ~/.ipython/ipy_user_conf.py:
    2. Python's import is a bit smarter than cpp='s =#include: it only imports things once, which is great when example.py is set in stone, but potentially frustrating while example.py is being debugged. Unfortunately reload example does not always seem to work. You can also try to "unimport" example.py so it can be read again, by running sys.modules.pop('example'). That may not free all of example='s         attached resources, though, or even have the intended effect.  Check =sys.getrefcount() if you are concerned. del example does not produce an error, but does not seem to help, either.

The files here can be either definition-containing "libraries", or "scripts" that run commands when execfiled, so read them before you load them! For a couple of reasons, including a lack of demand, none of them have been converted into tasks yet. It is good practice to at least partially taskify them (see taskutil.py) in order to properly handle the global namespace (i.e. use tools). Feel free to send taskification requests or other feedback.

They have all been tested to work at least once, but some of them depend on other files. If one does not work for you, a likely error is not having the file it is looking for in your sys.path, or not having execfiled that file. Please note these in the wiki if you come across them.

HOWTO: run pychecker inside CASA

pychecker tries to point out basic problems in python files, much like lint does for C.


It tends to be already installed with Debian and its derivatives, but for most CASA boxes you will have to install it yourself. Go get it and follow the directions.

...without being root

No problem, you just have to tell CASA where you put it. I put it in ~/src/local_py/, and have my own python modules in ~/src/python_mods/ so I set environment variables PYTHONPATH and CASAPYUTILS in my ~/.profile, and in my ~/.ipython/ipy_user_conf.py placed this in the main() function definition:

        ip.ex("sys.path.append(os.environ['" + ev + "'])")


Normally it is run as a standalone program, but usually you will want to check your CASA scripts from inside the CASA environment, so the right libraries can be found. Read the "Importing PyChecker" part of the pychecker page and import pychecker.checker. That adds checking to import, but unfortunately not reload. To check a file you were going to execfile, simulate running pychecker from the command line:
CASA <44>: pychecker.checker.main(['pychecker', '/users/rreid/src/python_mods/radplot.py'])
The first element in the input list is arbitrary; it acts as sys.argv[0], the name that pychecker thinks it is being called as.

Many of the tasks take a lot of arguments, so you will likely want to put
maxArgs = 32
into either ~/.pycheckrc or ./.pycheckrc. The PYCHECKER environment variable does not work.

You will have to reload pychecker.checker for each new check.

Things to run outside CASA


A perl script for calculating the average baseline length of a configuration in almasimmos format.


A perl script to produce antenna configurations in almasimmos format from a schedule of pad occupations.


A version of prepconfigs that relabels Mark Holdaway's Y+ ALMA configurations to match the spiral numbering system.


Mozex is an extension for mozilla (and Firefox) which, among other things, lets you use your favorite editor for editing text areas in web pages. So no excuses, get wikiing.


erin is an emacs mode for semiWYSIWYG syntax highlighting of TWiki pages.

-- RobReid - 21 Sep 2007
Topic revision: r10 - 2008-10-22, RobReid

This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback