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: - The contents can be reused by putting
import example
in other files. - You do not have to remember the path to
example.py
, as long as it is in sys.path
. - 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. -
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: - 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
sys.path.append(os.environ['CASAPYUTILS'])
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
:
ip.ex("sys.path.append(os.environ['CASAPYUTILS'])")
- 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.
Installation
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:
for ev in ['CASAPYUTILS', 'PYTHONPATH']:
ip.ex("sys.path.append(os.environ['" + ev + "'])")
Use
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