Analysis Cookbook

Reference Manual

Viewer Demo

CASA Training

Beta Release Notes

CASA Beta Release Known Issues and FAQ:

Valid for Beta Patch 1 (CASA Version 2.0 Rev 4769).

Known Issues

The Beta Release is, in fact, a Beta Release, and there are a number of known issues that will be corrected in later patches and releases. These include:

  • Interface:
    • casalogger (MacOSX) ---
      • Due to a number of problems we had getting the Qt casalogger working under OSX, we have instead implemented a stripped down logger GUI. This will appear as a Console window. Sometimes an extra one appears but isnt written to - you can get rid of this if you want. This logger has the most useful functionality of the old one, and the added advantage that since its just showing the casapy.log text, you can cut and paste directly rather than using the special GUI buttons (which are broken in the Qt viewer).
  • Data Import:
    • importuvfits ---
      • There are known problems importing line data written by AIPS having to do with rest and sky frequencies. You may have to muck with the header using the ms tool. In particular, the spectral line velocities of images made from data imported with importuvfits should be checked carefully.
      • To what extent Doppler tracking corrections are made online/offline and the exact meaning of the frequency info stored in UVFITS data format vary from telescope to telescope and package to package. We are investigating how to make this more robust.
    • importvla ---
      • This task DOES support post-Modcomp VLA/EVLA data, in spite of an erroneous sentence in the Cookbook after Patch 0.5 and before 29-Apr-2008. This is handled underneath, and the scaling behavior depends on the value of applytsys in all cases.
      • Sometimes when importing post-Modcomp VLA/EVLA data (taken after June 2007), the first export records on an experiment will be confused and you will find 37 antennas (37 VLA + 10 EVLA). Usually, this can be avoided by using a timerange to skip the first couple of records from the experiment.
    • importfits ---
      • There are known problems importing line image cubes written by AIPS having to do with rest and sky frequencies. You may have to muck with the header using the imhead task.
  • Data Export:
    • exportuvfits ---
      • If you use importuvfits after an exportuvfits in the same CASA session, then it will crash unless the export was done with async=True.
  • MS Plotting and Flagging:
    • flagdata ---
      • This basic flagging task is too slow. Improvements are high on our hit-list.
    • plotxy ---
      • We have improved the averaging speed in Patch 1.0 and cleaned up some problems in incorrect display of multi-spw data. There are still some problems in the display of multi-spw averaged data. The plotting is still relatively fragile and there may be ways to excite crashes in this task.
      • Currently, plotxy requires that all the scratch columns are present in the MS. If you get an error to the effect "Invalid Table operation: Table: cannot add a column" then use clearcal() to force these columns to be made in the MS. Note that this will clear anything in all scratch columns (in case some were actually there and being used).
  • Synthesis Calibration:
    • bandpass ---
      • Polynomial bandpasses with bandtype='BPOLY' makes only a single solution vs. frequency, and spans all spectral windows and fields specified by spw and field. It will be given the field ID of the first field. The data should have been previously calibrated to the same scale with correct fluxes placed in the MODEL_DATA column (e.g. using fluxscale). A single BPOLY cal-table can handle only one solution of this type and cannot be merged with other BPOLY tables (but different ones can be applied separately).
    • fluxscale ---
      • GSPLINE solutions from gaincal cannot be used in this task.
    • gaincal ---
      • Cubic-spline gain solution with gaintype='GSPLINE' makes only a single set of solutions vs. time for all spectral windows and fields specified by spw and field. It will be given the field ID of the first field. The data should have been previously calibrated to the same scale with correct fluxes placed in the MODEL_DATA column (e.g. using fluxscale). A single GSPLINE cal-table can handle only one solution of this type and cannot be merged with other GSPLINE tables (but different ones can be applied separately).
    • hanningsmooth ---
      • This task applies simple Hanning smoothing with a fixed kernel to a MS, convolving the entire contents of the CORRECTED_DATA column and replacing it. There are no options for selection, nor to write out new MS leaving the original one undisturbed. It is best to run this on a single-source MS (after split). This will improved in upcoming patches (including the capability to apply Hanning smoothing as part of other operations).
    • polcal ---
      • You currently have to run polcal separately with poltype='X' to solve for the linear polarization angle, even if you do the D-terms on calibrator of known polarization with poltype='D+X'.
      • Polarization angle calibration poltype='X' is sensitive to any position shift in the source model relative to the phase center with respect to the phase center in intensity.
    • plotcal ---
      • This task is unable to yet plot poltype='X' solutions from polcal.
      • BPOLY solutions from bandpass must be plotted versus frequency and not channel. BPOLY and B solutions cannot yet be overlaid.
      • GSPLINE and G solutions from gaincal cannot yet be overlaid.
      • Currently, plotcal needs to know the MS from which the caltable was derived to get indexing information. It does this using the name stored inside the table, which does not include the full path, but assumes the MS is in the cwd. Thus if you are using a MS in a directory other than the current one, it will not find it. You need to change directories using cd in IPython (or os.chdir() from inside a script) to the MS location.
  • Synthesis Imaging:
    • clean ---
      • Its options are different than that for mosaic.
    • mosaic ---
      • Setting the threshold in the mosaic is tricky, as it is cleaning on an internal image including the mosaic field weights and apodized by the primary beam (not rescaled and corrected as in the final PBCOR image). It is generally correct at the mosaic centers and in regions where the mosaic is well-sampled, but tends to find less emission at the mosaic edges.
      • Its options are different than that for single-field clean.
  • Visualization:
    • viewer ---
      • There is no way to get interactive display of the pixel positions under the cursor.
      • You cannot save regions defined with the box or polygon drawing tools. This will be available in Patch 2.
      • The hardcopy of the viewer is not high-quality in Postscript mode. Its basically what you see on-screen without better fonts for labels etc. Postscript files can be large, using PNG is best.

See also the Beta Alert notices in the CASA Analysis Cookbook for more details on known problems and workarounds.

Frequently Asked Questions

Here are some Frequently Asked Questions, with answers:

  1. Q: When will the "full release" of CASA be?

    A: No earlier than November 2008.

  2. Q: Why cannot everyone get the Beta Release?

    A: We do not have the personnel resources to support a large number of Beta Users and still maintain the necessary development pace, and yet we feel we must support those users who do get the Beta. Thus, a staged release was chosen as the best compromise.


Please send any comments or questions about CASA to casa-request@nrao.edu

Copyright © 1995-2007 Associated Universities Inc., Washington, D.C.

This code is available under the terms of the GNU General Public Lincense

Modified on Wednesday, 24-Jun-2009 10:11:46 MDT