• Installation:
  • Linux --- there is a page for known problems with Linux installation
• 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 is not written to - you can get rid of this if you want. You will also see a "console.log" that has nothing to do with CASA. 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).
  • plotter (plotxy and plotcal) (Linux 64bit) ---
    • Bug: On some Linux 64-bit systems, the plotter (e.g. from tasks plotxy and plotcal) will not work correctly. For example, the plot frame will come up but buttons like Mark or Flag will not work, and it may not refresh correctly if you move it. In this case, after starting or restarting casapy, do the following commands:
      

                    pl.ioff()
      	      pl.clf()
      	      pl.ion()
      	      

      The plotter should then work correctly.
• 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.
    • Be careful when filling data from runs that have differing characteristics, such as antenna positions or different antenna ordering. Only contiguous observations be filled into the same MS, and then calibrated separately. You can later use concat before imaging.
  • 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.
    • Data are exported in the frequency frame of the MS, so portability to other packages is subject to the same frequency-related caveats as importuvfits (see above). Also, the user should only export spws that were observed simultaneously (such as would be identified as a single FREQID in AIPS). Non-simultaneous spws will not be exported correctly in one go.
• MS Plotting and Flagging:
  • flagdata ---
    • This basic flagging task is too slow. Improvements are high on our hit-list.
  • plotxy ---
    • We have further improved the averaging operation in Patch 2.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:
  • General Calibration ---
    • The solint parameter behavior has changed in Patch 2.0, and there is now a combine parameter. Your script from Patch 1 or earlier may not work right. See the release notes for more information.
  • 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, as if the combine='field,spw,scan' option were given. The solution 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, as if the combine='spw,field,scan' option were given. The solution 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).
    • There are known "edge-effects" in GSPLINE solutions, resolution is underway (hopefully for Patch 3).
  • 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 can only be overlaid if xaxis = 'freq'.
    • GSPLINE and G solutions from gaincal can be overlaid, though this has not been extensively tested.
    • 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 same directory as the cal-table and has the same name it had when the cal-table was created.
• Synthesis Imaging:
  • clean ---
    • Now inludes the options from invert and mosaic (but with some parameter name changes).
    • 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.
    • Now produces .psf and .flux images by default. The latter means that the MS needs to be from a known telescope in order to compute the primary beam.
    • Bug: If you choose multi-Stokes image-plane Hogbom deconvolution, using psfmode='hogbom', imagermode='', and stokes='IQUV', and use interactive=T to draw a box near or beyond the size of the image, then clean will crash. This will also happen with interactive=F if you give it a mask that is too large. Choose psfmode='clark' or imagermode='csclean' to avoid this behavior (or keep clean boxes much smaller than the image size).
      Fixed: Version 2.3.0 (build #5883) 2008-08-08 (not yet released)
• Visualization:
  • viewer ---
    • You can only save the last SINGLE region defined with the box or polygon drawing tools using the Region Manager tool menu item.
    • 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.

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

   A: No earlier than November 2008.

2. Q: Why do you have to register to get user support?

   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 are committed to testing the Beta. Thus, we have implemented a registration system to track these users, and also to allow us to send emails about updates etc.

3. Q: Why does my older script now give poor calibration results in Patch 2?

   A: The behavior of some of the calibration parameters have changed in Patch 2 (e.g. solint and combine). See the release notes for more information.

4. Q: Why does the clean task fail on my VLA line dataset in my Patch 2.0 distribution installation?

   A: You need to get Patch 2.1. See the release notes for more information.

5. Q: Why does the viewer not work in my Patch 2.1 MacOSX distribution installation?

   A: You need to get the updated .dmg posted on 28-July-2008. See the release notes for more information.

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

Copyright © 2009 Associated Universities, Inc.
The National Radio Astronomy Observatory is a facility of the National Science Foundation operated under cooperative agreement by Associated Universities, Inc.

Modified on Wednesday, 24-Jun-2009 10:08:18 MDT