Revision as of 16:37, 8 December 2008 by Teuben (Talk | contribs)

Jump to: navigation, search

PACS notes for Miriad, in particular for those maintaining their own MIRIAD version:

Peter will normally update the OVRO and CARMA machines, as well as the 32 bit version ('astroload miriad') and 64 bit version ('astroload -v 64 miriad') on the UMD machines. For anybody else, check the procedure below if that is what you do:


New/modified software

A summary of the software components modified for PACS:

  • gpbuddy: writes out (unwrapped) phaseatm from a gain solution (that came from selfcal) [V1.7 and up]
  • gplist: handle 23 ants (SZA files now use 23, CARMA still uses nants=15)
  • uvcal: has new options=atmcal to apply the atmphase to a dataset. Make sure you have a good freqatm value in your dataset (for now)
  • uvwide: SZA data do not have narrow flags, this program was updated for this.
  • panda: baseline based (not in miriad yet)
  • bldelay: baseline based (not in miriad yet)
  • maxdim: new program that just displays your miriad version and the MAX parameters.
  • selfcal/mselfcal/mfcal: to handle the large number (around 10,000) integrations. maxdim.h also updated, see below.
  • listobs: handle SZA data [V1.25 and up]

MIRIAD/SZA data issues

The procedure to convert SZA data into miriad format is still changing, here are some known issues:

  • There are some issues if the data are not time sorted, the uvsort might fix that, but it seems to mess up (not copy?) the wide band data.
  • The antpos uv variable is not correct.
  • The freq variable is missing, listobs now works around that
  • Only wide band data are flagged, you must run
      uvwide vis=SZA narrow=t
  • 3QSO track (zrct015.3QSO_3C273.3mm.1.mir)
 * no wide band data (this may be a result of running uvsort
 * first few integrations after a source change are bad. this may actually be a result of uvsort, To Be Resolved

Reminder on updating MIRIAD (old style)

It is assumed you have a CVS enabled release of MIRIAD (i.e. you have files such as $MIR/CVS)

  • MAXDIM: two header files describing maximum sizes were updated: $MIRINC/maxdim.h and $MIRINC/maxdimc.h. Edit this files and modify the MAXBUF parameter in both files to at least 10000000 (4 times the amount is the memory used by programs that use MAXBUF).
 $EDITOR maxdim.h  maxdimc.h

and if to properly update the CVS status of these files (they changed on Dec 4, 2008) a one time is needed to old MIRIAD installs:

 mkdir tmp
 mv maxdim.h  maxdimc.h tmp
 cvs update
 mv tmp/max*h .
  • CVS: always query your source tree first and look for C (conflicts) and M (locally modified) files. The U (to be updated) files will be new ones you will get:
 cvs -nq update

and if happy with this, issue the real update

 cvs update
  • Old style updates: (you can give these commands from any directory and it assumed you have write permission in $MIR)
 mir.install subs prog

for a blanket re-install of the library and programs. You need this if e.g. maxdim.h was changed, and/or your miriad does not use shared libraries. This is also the safest way to update. On most computers this will only take 2-3 minutes. If however you know exactly what the impact of a new file is, you can pick any of the following examples, which will take 2-3 seconds:

 mir.subs fitsio.for uvio


 mir.prog itemize gpbuddy

Notice a file extension is optional, and multiple arguments can be given. Watch the output carefully for fatal compile or link errors.

Either way, a quick way to check if you had no disastrous compile issues, count the number of binaries in $MIRBIN, there should be about 400:

 ls $MIRBIN | wc

The output of a single mir.prog cgdisp command should be clean, and not give any compile or linking problems. If so, you may have either corrupt miriad library, or a misconfigured system to begin with.

  • New style updates: (these can take 10 minutes)
 cd $MIR
 make install


  • uvflag:
   uvwide vis=$VIS narrow=t

fixes the narrow band flags this

  • puthd: manually need to put freqatm in the dataset that came out of gpbuddy (phaseatm needs it in uvcal). Ideally selfcal would write the freq0 variable. E.g.
   puthd vis=$VIS/freqatm value=30.1 type=double
  • gpbuddy time ranges: if carma data (vis=) and sza data (vis2=) do not share the same time range, erroneous phases can be applied. Sampling can be slighly different, but there are caveats to using a long interval for phaseatm: UV variables only remember the past, selfcal gains are interpolated.

Known Issues

  • SZA data:
 * antpos(3,nants) is not written correctly, this will impact gpbuddy's automatic nearest neighbor search
Personal tools