ECHOMOP defects/issues list

Version $Revision: 1.3 $. Last updated $Date: 2002/07/16 12:31:16 $

This list contains the current list of defects and issues for ECHOMOP. As well as specific deficiencies, these `defects' include items which are merely suggestions or TODOs.

These are in no particular order, and some have a higher priority than others.

Issue groups:


1.2 -- Rounding of pixel numbers

Status: open. Noted by Orlon Petterson <>, 4-Aug-2000

ECHOMOP 3.3-4: optimal extraction, as opposed to profile extraction, seems to round pixel numbers much more often than seems plausible.

[ See email ]

1.3 -- `Hedgehog' problem

Status: open. Noted by James Bleach <>, 9-Aug-2000

Quoth James:

I have attached two ps files to illustrate the problem that I and a colleague of mine have encountered during the reduction of sets of WHT echelle spectroscopy, dubbed the `hedgehog' problem. The problem is clear in the first image and is also present on a smaller scale in the lower spectrum of the second image, seen as small regular jumps. We found that this problem is removed if the dekker extent is reduced (see the upper two spectra in the second image, the only difference between these spectra is the background definition and as a result the S/N). I am not clear on what is causing the problem and therefore why it is solved by decreasing he dekker extent.

[ See figure figure ]

1.4 -- AI option crashes!

Status: open. Noted by Rachel North <>, 12-May-2000

Rachel North managed to produce crashes using the AI toption of ech_idwave and saving scrunched object orders (option 14: RESULT_TYPE: SCROBJ).

Interface problems

2.3 -- ech_idwave, XP and IM

Status: open. Noted by Rachel North <>, 12-May-2000

Basically, I can't seem to export(XP) or import(IM) the arc orders from ech_idwave (option 10) so that the arc can be identified using the FIGARO command ECHARC. This is the error message I'm getting:

>echarc >IMAGE - (IMage) Collapsed echelle arc image to be fitted
>ARCTYPE - (ARctype) Type of arc /'thar'/ >
>.Y.LABEL above not order number

Also, the single order toggle (option 24) doesn't seem to have any effect. In addition, when I tried to use the AI option of ech_idwave, the program crashed...

Finally, when I try and save the scrunched object orders (option 14: RESULT_TYPE: SCROBJ) the program crashes out with this message:

>*** TERMINATING  /star/bin/echomop/echmenu
>*** Received signal 11 SIGSEGV
>Segmentation fault

Closed issues

Issue groups:


1.1 -- Ripple on the continuum

Status: closed. Noted by Ignacio Negueruela <>, 4-May-1999

Ripple superimposed on the continuum, possibly due to missing counts?

[ See email ]

Resolution: deferred by Norman, 10-May-1999

An expert I consulted suggested:

Hmm. A lot depends on how bright the object is. For bright objects where sky background is not a problem, I normally try to take the dekker limits well into the inter-order gap. This is wider than the limits that are normally set automatically by option 4.1. This ensures that there is sufficient background. Is he substracting sky with option 6, or fitting scattered light with option 22?

It is hard to judge whether or not this is the problem, as he doesn't mention the amplitude of the ripple. Last year, when I was dealing with obscenely high S:N ratios, I found that the interpolation routine for tdetermining the spatial profile shape for optimal extraction was giving a ripple with an amplitude about 0.003 of the signal. The cure was to ditch optimal extraction and do simple extraction over the same limits.

In a later message, Ignacio reported:

The two problems I had seem to be in part due to the fact that the data were taken with a fibre-fed spectrograph (though they also affect the UES data). The difficulties can be interpreted as follows:

  1. "One issue is with the use of flat fields. With fibre data it doesnt usually work very well if you use flat fields in the reduction as you would with conventional echelle data. I think it is better to extract the object spectrum and flat field spectrum individually and then divide the object by the flat field."

    Well, I've tried this ans it sort of works with the fibre-fed data. I am not very happy with the results for the UES data. Neither the traditional approach nor this other one seems to work. One possible explanation could be that the extent of the flat orders is limited by the dekker while the star orders are much smaller and their geometries do not much exactly. I am not sure. I keep looking into it.

  2. "The other difficulty with fibre data is that the object profile limits need to be set very carefully else pixellation introduces noise. This is probably what was responsible for the ripple pattern you found."

    This seems to work correctly if you are careful defining the extent of the object. The pixellation (ripple) effect disappears.

Interface problems

2.1 -- ech_dekker and ech_object apparently yoked together

Status: closed. Noted by Michael Albrow <>, 1-Feb-1999

Michael Albrow:

When using echmenu, options "4.1" and "4.2" (these are the tasks ech_dekker and ech_object) don't seem to be able to be invoked separately anymore. Instead, trying either option seems to do the same as option "4" (ech_spatial).

[ See email ]

Resolution: fixed by Norman, 16-Jul-2002

There was a bug in the option-parsing code, which in fact caused the same problem with all suboptions. Made much more robust in release 3.3-6.

2.2 -- Option 4.2

Status: closed. Noted by Dave James <>, 14-Sep-1999

Option 4.2 isn't `sticky'.

[ See email ]

Resolution: fixed by Norman, 26-Jul-2002

Same fix as the previous problem.