• Installation:
  • Linux --- there is a page for known problems with Linux installation
• General:
  • NFS mounted disks --- It is not recommended that you run CASA (e.g. have your data) on disks that are NFS mounted. It can be done, but in some cases the files will be NFS locked and this can crash casapy or its tasks. In this case, you have to restart casapy.
• 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:In the Patch 3.0 release, in at least NRAO installations, you will find that if you change the number of subplot panels then any previous plots will not be properly cleared and mess up the axes etc. The current workaround is to do clearplot before first plotting using the new panelization.
    • Bug: On some Linux 64-bit systems (e.g. RHEL5), the plotter (e.g. from tasks plotxy and plotcal) will not work correctly. For example, the plot frame will come up behind other windows, and if you use the dismiss window (the x at the TRC of the window) when it comes back it may not have the Mark or Flag row of buttons. In this case, do not use the dismiss window if you want to get rid of the plotter. Use the Quit button instead.
    • Bug: In Patch 3.0, on some OS (mostly 64-bit), you might find that if you move another window on top of the plotter GUI window, it will not refresh or will disappear. You will have to start a new plotter.
• 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 ---
    • See also plotter issues above
    • Bug:You cannot flag data when both averaging and iteration are turned on.
    • There are modes of operation in which plotxy is known to be excessively slow.
      For data with a large number of spectral windows and/or channels, iteration (e.g. over baseline) will be very slow.
      Using the extendflag options will greatly slow down the flagging in plotxy. You will see an excessively long delay after hitting the Flag button, with lots of logger messages as it goes through each flag. Fixing this requires a refactoring of plotxy which is underway starting in Patch 4 development.
    • 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).
      Update: As of Patch 3.0 plotxy will make missing scratch columns for you.
• 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' now can make multiple solutions on different spw combinations with combine='spw' (Patch 3).
  • 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 ---
    • See also plotter issues above
    • If you use plotcal on a caltable, it will then be put into the cache of the table system. If you try to re-run a solve (e.g. gaincal, bandpass, blcal, polcal) with the same caltable name and append=F to overwrite, then when it tries to delete the original caltable it cannot due to the cache. You will see an error like:

                     SEVERE  gaincal::Calibrater::solve 
                     Caught exception: Invalid Table operation: SetupNewTable
                     ngc5921.demo.gcal is already opened 
                     (is in the table cache)
                     

      Either use a different output caltable name, or restart you casapy session (exit and start again) to free up the cache.
    • There are modes of operation in which plotcal is known to be excessively slow (this is due to the same underlying cause as for plotxy. For data with a large number of spectral windows and/or channels, iteration (e.g. over baseline or spw) will be very slow.
    • 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 ---
    • Bug: In the Patch 3.0 release the use of ftmachine = 'ft' for imagermode = 'mosaic' will lead to errors in the residual calculations and in the .flux image. For now stick to ftmachine = 'mosaic'. This will be fixed in an upcoming Patch 3.1.
    • Now includes 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 and any gridding kernel (the primary beam if ftmachine='mosaic') and this is 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.
      Update: In Patch 3.0, if the dish diameter is in the ANTENNA table of the MS, clean (with imagermode='mosaic') will be able to work out the primary beam even if from an unknown telescope.
• 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.

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: In the fullness of time :) We expect no earlier than October 2009.

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 do I get slightly (<1%) different results after calibration in Patch 3?

   A: The calibration tasks and tools do things somewhat differently underneath now, particularly for multichannel and multispw data. This should be for the better.

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

   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.

5. Q: Why am I getting slightly different or odd results for mosaic imaging in clean in Patch 3?

   A: We are improving mosaic imaging, in particular the use of the PB for imagermode='mosaic'. We are fixing known bugs for Patch 3.1.

6. Q: Why is plotting and interactive flagging in plotxy so slow and/or buggy? Why hasn't my bug been fixed?

   A: There are deep fundamental problems underneath in plotxy that cannot be robustly fixed. We are in the process of refactoring the code from the ground up, basing it on the visibility iteration engine used in calibration (which is robust and not slow). This will also allow use of different back ends such as Qt (not just matplotlib. Expect to see a basic beta version of the new plotter perhaps as early as 2.4.0 (Patch 4). In the meantime, we are curtailing further development, and limiting bug fixing, in the current plotxy.

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:02:53 MDT