PACS
(→Notes) |
(→Other Known Issues) |
||
Line 78: | Line 78: | ||
* 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. | * 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. | ||
− | |||
− |
Revision as of 16:51, 8 December 2008
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:
Contents |
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, but now imminent (Laura))
- bldelay: baseline based (not in miriad yet, but now imminent (James))
- maxdim: new program that just displays your miriad version and the MAX parameters. MAXBUF increased.
- 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 solution is probably to run uvwide before uvsort
- The antpos uv variable is not correct.
- The freq variable is missing, listobs now works around that
- There are no linelength data (phasem1), but this is a known issue and won't be added for a while.
- 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, probably uvwide narrow=t should have been run first
- 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).
cd $MIRINC $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)
mirboss 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
and
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 make install
Notes
- uvflag:
uvwide vis=$VIS narrow=t
fixes the narrow band flags by copying them from the wide band flags. This issue will probably disappear when the SZA data filler is updated to write the narrow flags directly.
- 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.