Known Bugs

Caveat: Python Packaged with CIAO OTS

CIAO 4.0 uses the Python software packaged in the CIAO OTS directory for the Sherpa and ChIPS applications. In the window where CIAO is sourced any other Python installation is overwritten: this may interfere with other Python applications on the user's system. At present, the workaround is to run CIAO in a separate window from other Python applications. The CXC is working to resolve this issue.

Caveat: IPython Packaged with CIAO OTS

CIAO 4.0 includes IPython 0.8 in the CIAO OTS directory which is used by Sherpa and ChIPS to provide command-line user interfaces. These programs create an IPython profile in the directory $HOME/.ipython-ciao.

If IPython users want any personal customizations to be available when running CIAO, they will have to copy them from $HOME/.ipython to $HOME/.ipython-ciao.

This is a list of known bugs in the ChIPS application.

• Adding lines, polygons or curves with large ranges (on order of 10^7) to a drawing area of with a small range (on order of 10^1), may cause unexpected behaviors, including bad clipping and or positioning of the object.

• Currently clipping labels is point clipping. This means if the point is in the data range, the whole label is displayed; otherwise, the whole label is clipped.

• Joints of line segments for curves can be very visible if the lines are thick.

• Self-intersecting polygon regions are not supported.

• If the string for an axis label contains spaces, the string must be wrapped by double quotes in the add_curve command:

  add_curve(d1.data[2], d1.data[3], ['axis.y.label', '"Z offset (arcsec)"'])
  

• During an undo operation, there is a very small chance that the command will appear to miss a portion of the changes. This only occurs when the buffer is internally cleared and written to file in the middle of a sequence of commands. If this happens, simply issue another undo followed by a redo to ensure that the correct state is restored.

• Printing of pdf, jpeg, and png formats is handled via ghostscript. This is necessary because of Solaris and OS X system issues. The jpeg and png output may show slight lines between various vertices in filled polygons as a result of how the fill is triangulated by ghostscript. These lines may also appear when viewing pdf files through acroread. The lines do not appear when printed.

  In addition, opacity level support in pdfs and pngs is currently not available.

• Contours of images taken near the celestial poles, which have WCS transforms applied to them, may appear distorted as the axes are gridded uniformly in ChIPS.

• ipython included with CIAO on Mac OS X PPC and Intel has an issue when displaying the traceback from an error. As a workaround it is suggested that ipython be run as:

  ipython -xmode Plain
  

  or, while in ipython:

  import sys
  sys.tracebacklimit = 0
  

  This will minimize the traceback that is printed when errors are encountered.

• If set_contour is run on a ChipsContour object which contains small values for the intervals and levels, it will take a very long time to draw the contours. Even though the final contours may not be in interval mode, ChIPS still changes the intervals to the value specified in the object.

  The workaround is to set the intervals and levels in the ChipsContour object to None or NULL if they are not required.

• Some ATI graphics cards produce the following warning:

  libGL warning: 3D driver claims to not support visual 0x4b
  

  This does not seem to have any effect on ChIPS. A fix is supposed to be available in newer versions of mesa

• NaNs and +/-inf are currently filtered out of curve and histogram data. This filtering is not performed for other data (e.g. contours, lines)

• Turning redraw off by calling set_window_redraw(0) can be a very slow command especially if running remote. It may be faster to start with the window display off, or if grouping commands in automic units, use undo buffers.

• While inside an undo buffer block redraw will be turned off. However, to increase speed the contents of the chips window are not refreshed. So while nothing is drawn to the window, if the window is obscured by another window, the obscured pixels are lost and will not be refreshed if the obscured part is made visible again. That part of the chips window will be black.

• If an undo buffer block is nested in another undo buffer block and the inside block ends with a discard_undo_buffer, but the outside block ends with a close_undo_buffer, the discard_undo_buffer will not clear out the commands from the inside block. The inside block will be executed.

• When running ChIPS in batch mode through xvfb, multiple print_window calls to the same window may cause xvfb to crash. This happens only on large data sets, upwards of 500000 points. This is do to a limitation of Xvfb.

• The window title is not recorded by the save_state command.

• The Fedora Core 7 build of ChIPS can't load state files made on a Mac.

• After a certain number of commands, using an undo tag results in the following error:

  chips ERROR: There are no actions available to undo
  

  Alternatively, the undo tag will work correctly, but the window redraw becomes locked as "off" (i.e. it's not possible to redraw the window).

• Running ChIPS remotely from a Mac PPC to Mac Intel (or the reverse) produces an X error such as:

  The program 'ChipsServer' received an X Window System error.
  This probably reflects a bug in the program.
  The error was 'GLXUnsupportedPrivateRequest'.
     (Details: serial 72 error_code 163 request_code 150 minor_code 17)
     (Note to programmers: normally, X errors are reported asynchronously;
      that is, you will receive the error a while after causing it.
      To debug your program, run it with the --sync command line
      option to change this behavior. You can then get a meaningful
      backtrace from your debugger if you break on the gdk_x_error() function.) 
  

  The workaround is to set "setenv LIBGL_ALWAYS_INDIRECT".