Differences between revisions 38 and 39
Revision 38 as of 2014-03-13 11:53:10
Size: 4247
Editor: obelix
Comment:
Revision 39 as of 2014-05-05 10:20:43
Size: 4680
Editor: obelix
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
== v1.3.1 ==
 * '''kmo_illumination_flat, kmo_sci_red, easySPARK_illumination_flat.sh'''
  * Contrary to our assumption this recipe is NOT rotational independent. Until now the recipe kmo_illumination_flat just processes one rotator angle and applies it to all angles provided in kmo_sci_red. Some tests have shown that in illum_corr.fits there should be corrections for the same angles used in the corresponding master_flat.fits

SPARK Known bugs

Here you find a list of all bugs which haven't been fixed in the most actual version of the KMOS pipeline.
Check as well the Change Log to see which bugs have already been fixed, but not released yet.

v1.3.1

  • kmo_illumination_flat, kmo_sci_red, easySPARK_illumination_flat.sh

    • Contrary to our assumption this recipe is NOT rotational independent. Until now the recipe kmo_illumination_flat just processes one rotator angle and applies it to all angles provided in kmo_sci_red. Some tests have shown that in illum_corr.fits there should be corrections for the same angles used in the corresponding master_flat.fits

v1.3.0

  • kmo_wave_cal

    • Products are missing the filter extension. Recipes doing reconstruction as well as some easySPARK-scripts will fail
      (lcal.fits instead of lcal_YJYJYJ.fits and det_img_wave.fits instead of det_img_wave_YJYJYJ.fits)
      Workaround: Renaming the LCAL product manually solves the issue.

  • kmo_reconstruct, kmo_sci_red, kmo_multi_reconstruct

    • Misleading recipe output regarding xcal-interpolation: When the angle of the science frame to reconstruct lies between 30-60deg and 300-330deg the interpolation is executed correctly, but the recipe output would state that it would NOT have been executed.
      Example: angle of 40deg gives following output
      "Loading all calibration frames with angle 60deg (input: 40deg)"
      instead of:
      "Loaded calibration frames with interpolated angles between 0deg and 60deg (input: 40deg)"
      Workaround: None needed, just ignore specific messages in this case.

  • kmo_sci_red, kmo_sky_tweak

    • Crashes occasionally (rather rarely). The bug has been identified and be shown to possibly occur in any band.
      Workaround: None for kmo_sky_tweak. For kmo_sci_red: Since only specific IFUs are affected, these could be omitted by specifying the IFU or object name to process (parameters --ifus or --name). This way at least the other IFUs can be processed.

  • kmo_std_star

    • A user reported a case where the fitting of the atmospheric model failed in YJ-band. Investigation is underway.

v1.2.5

On MacOS:

Some users reported following warning in kmo_wave_cal even when the resulting XCAL, YCAL, LCAL have the same number of rotator angles with matching values:

  • [WARNING] : **********************************************************************
    [WARNING] : **********************************************************************
    [WARNING] : *** For XCAL another angle has been picked than for LCAL ***
    [WARNING] : *** (XCAL: 2.68156e+154, LCAL: 6.92925e-310) ***
    [WARNING] : *** ***
    [WARNING] : *** The recipe will be executed, but the ***
    [WARNING] : *** results should be mistrusted !!! ***
    [WARNING] : *** ***
    [WARNING] : *** Please take care to take XCAL, YCAL and LCAL frame ***
    [WARNING] : *** from the same calibration set !!! ***
    [WARNING] : **********************************************************************
    [WARNING] : **********************************************************************

One value is very large and the other very, very close to zero.
Unfortunately this effect isn't reproducible and hence not really debugable and has to stay open for the moment. The calibrations don't seem to be corrupted and can be used anyway. To be more precise: This warning is emitted after having calculated the LCAL frame and during following reconstruction of the ARC_ON frame in order to create the reconstructed detector image, which in turn is used to collect some QC parameters.

v1.2.4

  • SPARKplug with MacOS X

    • Needs as prerequisite the port p5-tk to run, but it fails to compile. The bug has been reported but not fixed yet.

v1.1.0

  • SPARKplug

    • some static calibration frames in the resulting sof-files are tagged wrong

SPARK / SPRED

MacOSX-Users with a working installation of the SPRED pipeline for SINFONI can experience difficulties using it after having installed SPARK. This happens only if they install packages needed for the SPARKplug tool which uses as well python. In this case separate working environemnts are recommended.

KMOS-SPARKwiki: Known Bugs (last edited 2014-05-05 10:20:43 by obelix)