• 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:
  • Python task interface ---
    • Due to a recent change in the task generation system, there can be a marked difference in what happens if you use the parameter-setting interface (using inp and go or <taskname>()) versus the functional interface (using <taskname>(arg1=val1,...)). This occurs when you let parameters default in the latter. To be safe, explictly specify values for key parameters even if you think their defaults are ok.
  • casalogger (MacOSX) ---
    • In some OSs the casalogger output cannot be copied. As a workaround, one can use the casapy.log file that is created with the same input in the working directory.
  • plotter (plotxy and plotcal) (Linux 64bit) ---
    • 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.
• Data Handling:
  • importasdm ---
    • Some EVLA SDM data was taken with a trial version of the SysCal table being written. In this case, you will see "extra" spectral windows in the data corresponding to those Tsys measurements. You can split the data for the actual data spectral windows off if you like.
  • 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.
    • The convention in miriad is to maintain velocities through various data transformations, while CASA maintains frequency integrity; given that UVFITS does not always contain detailed information about the reference frame, it is recommended to check frequencies and velocities carefully after an import from miriad via UVFITS.
  • 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.
  • exportuvfits ---
    • 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).
  • concat ---
    • Bug:If you concatenate a number of MS together where they each contain a different SPW, then be warned that subsequent task may lose track of the rest frequency (particularly after you run split). You can now set restfreq explicitly in some tasks like clean and plotxy.
• MS Plotting and Flagging:
  • flagdata ---
    • This basic flagging task is too slow. Improvements are high on our hit-list.
  • plotxy ---
    • Feature:The plotxy task is being replaced by plotms. So we recommend using plotms. However, a few plotxy features are not implemented yet in plotms (mainly scripted output, iterations) so plotms is still useful for this release.
    • 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.
    • 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, however...
    • Bug: ... if any column is missing then it will reset the values in any of the existng scratch columns, possibly wiping out what is there (like a model).
• Synthesis Calibration:
  • fluxscale ---
    • GSPLINE solutions from gaincal cannot be used in this task.
  • gaincal ---
    • Cubic-spline gain solutions now obey the combine parameter
    • There are known "edge-effects" in GSPLINE solutions, resolution is underway
  • 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 ---
    • 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. Update: As of Patch 4, you can use the rmtables task to delete tables.
    • 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 ---
    • Do not set table.tsm.option in your ~/.aipsrc or ~/.casarc file (i.e. use the default table.tsm.option). Changing this parameter can lead to unwanted results in the imaging process.
    • The use of ftmachine = 'ft' for imagermode = 'mosaic' is not as robust or efficient or fast as using ftmachine = 'mosaic'. Use the latter if possible (e.g. if you have more than a few fields in your mosaic.)
• Visualization:
  • viewer ---
    • Shapes are currently not compatible with regions and boxes. In future releases we will likely provide a uniform, single file format.
    • The image statistics on a region on a cube provides statistics for all planes rather than for the visible plane only.
    • Due to the addition of "overplotting" capabilities (plotting more than one spectral profile in the spectral profile tool (SPT)), some undesirable behavior is present in the current release: (1) contour images are "overplotted" in the SPT, as are continuum images, thus the velocity and frequency range shown in the SPT will be the union of that of all open images, contour or not, "cube" or not. (2) changing the position of the spectral cross hair, or region tool(s) in the viewer display panel undoes any zoom applied in the SPT. (3) The SPT cannot be used with more than one fits cube; the Viewer will crash immediately with a memory allocation problem. For a single fits cube and a single plane contour image (i.e. continuum) the SPT can be used with the cross hair tool, but will crash if you use either region tool.
• Analysis:
  • The msmoments task only accepts MS data (not Scantable). The input MS have a few limitations to work with msmoments task: 1. MS must have FLOAT_DATA column 2. Number of polarizations (correlations) must be same in all rows
• Simulation:
  • simdata -- corruption of simulated MS by an atmospheric phase screen is only available from the toolkit. simdata and sm: Under some circumstances, running sm.setnoise and sm.corrupt, or simdata with thermal noise, twice using the same project name, the noise can be applied a second time, doubling the noise level. Be sure to use different project names for creating different simulations with noise. see casaguides.nrao.edu for the latest simulation information

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

Copyright © 1995-2010 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.