Sanity tests
(→Software Development) |
(→Software Development (new build)) |
||
Line 122: | Line 122: | ||
=== Software Development (new build) === | === Software Development (new build) === | ||
− | The new build system should be easier to use. After a CVS update: | + | The new build system should be easier to use and is |
+ | normally installed under '''$MIR/build'''. After a CVS update: | ||
% cd $MIR | % cd $MIR |
Revision as of 21:14, 4 June 2008
Contents |
Sanity Checks
Here we will quickly go over some commands to test basic functionality of miriad: getting the data into miriad and displaying this data using pgplot routines. We also suggest to install ds9 and the associated XPA tools. Although mostly for images and cubes, it can also be used to browse your visbility data bricks. An additional, image cube visualization package we recommend for Miriad is karma
Image Data and Display
Generating an image and displaying it in miriad:
% imgen out=map0 % hexdump -C map0/header | tail ... 000001c0 6e 61 78 69 73 00 00 00 00 00 00 00 00 00 00 08 |naxis...........| 000001d0 00 00 00 02 00 00 00 02 |........|
The important thing to note is the last line, if endianism is wrong on your machine, the last 4 bytes might read as 2,0,0,0 instead of 0,0,0,2. As in FITS files, data in miriad are stored in a big-endian fashion, which means on intel chips (little-endian) data will need to be byte swapped.
Now display the data
% implot in=map0 device=/xs % ds9 & % mirds9 map0
And to make sure your random number generator works:
% imgen out=map1 object=noise spar=1 % histo in=map1 | grep Rms Mean -3.29890E-04 Rms 9.99046E-01 Flux -2.16197E+01 Jy (65536 points)
Visibility Data and Display
Getting a Carma visibility dataset from the archive and displaying some basic properties of the data
this data is currently not available, a new dataset will be available shortly
% wget -O - http://carma-server.ncsa.uiuc.edu:8080/sciarch/data/flux.rpnt.2007may31.9.miriad.tar.gz | tar zxf - or % curl http://carma-server.ncsa.uiuc.edu:8080/sciarch/data/flux.rpnt.2007may31.9.miriad.tar.gz | tar zxf -
% itemize in=flux.rpnt.2007may31.9.miriad Itemize: Version 22-jun-02 obstype = mixed-auto-cross nwcorr = 12600 ncorr = 189000 vislen = 1048928 wflags (integer data, 407 elements) flags (integer data, 6097 elements) visdata (binary data, 1048924 elements) history (unknown data, 0 elements) vartable (text data, 650 elements)
On MacOSX (not sure intel, ppc or both) the output of nwcorr/ncorr/vislen may look different, which is related to the compiler not able to print integer*8. This seems to work fine on linux (32 and 64 bit).
% uvplt vis=flux.rpnt.2007may31.9.miriad device=/xs
% uvio flux.rpnt.2007may31.9.miriad > flux.log
WIP: a pgplot based plotting package
Give the following commands to see if you have your environment setup correctly:
% wip -d /xs WIP> box WIP> end
% wip -d /gif WIP> box WIP> end
% wip -d /ps WIP> box WIP> hardcopy WIP> end
% wip -d /xs WIP> image map0 WIP> header rd rd WIP> halftone WIP> end
Be careful with that last example, the hardcopy command would spool your pgplot.ps file to your default printer,unless you have modified your .wipinit file with something like
set "print" echo Printfile in %s
or simply
set print ignore
A final byteswapping test in from a miriad image:
% wip -d /xs WIP> image map0 WIP> header rd rd WIP> halftone WIP> end
should show just a blob in the center.
Software Development
- Assuming your Miriad is CVS enabled (i.e. you will see the $MIR/CVS directory), you should test if you can update Miriad using cvs:
% cd $MIR % cvs -nq update
If this failed with a command not found, cvs should be installed. Another failure mode is not having a ~/.cvspass entry for the anonymous access to the UMD cvs server. For this do:
% cvs login % cvs -nq update
- Testing to see if you can compile a subroutine or program, try these:
% mirboss % mir.subs fitsio % mir.prog itemize
- To update Miriad, you can update the source tree from its root:
% cd $MIR % cvs update
now carefully watch files passing by on your screen. Any preceded with ? are ok, they are not in CVS control. But anything with M (locally modified) could be suspect, the U or P are files that were updated/patched, and a C is a disaster: a CVS conflict occured. You will need to resolve this, e.g. by renaming/removing the offending file, and updating that file again.
Software Development (new build)
The new build system should be easier to use and is normally installed under $MIR/build. After a CVS update:
% cd $MIR % cvs update
you should be able to test if the new code works:
% make
and if so, install it
% make install