It was found that #875 affects the long slit in MICADO, which acquires a spurious shift in the x-direction. This is because it is asymmetric in the focal-plane (or sky) coordinates, running from $-5$ arcsec to $10$ arcsec. An offset is detected in the FOV header keyword CRVAL1D, which leads to the a wrong estimate of the offset.
In fact, as stated in #875, the implementation with an offset in the detector plane is too hacky. It was necessary because the transformations in MICADO are only available for $\eta=0$ in the focal-plane, and we do not know how to map slits with $\eta\neq0$.
In view of the implementation of the MICADO IFU mode, we need to be more careful.
In fact there are three coordinate systems that play a role:
- The sky system: The slit or image slicer definition in this system describes which part of the sky is picked up by the slit or slice.
- The focal-plane system: this is the input system for the
SpectralTrace. In some cases this is identical to the sky system (the standard MICADO slits, the METIS LMS image slicer), in others it contains a pseudo-slit that results from rearranging the image slices (the MICADO IFU).
- The detector system: this is the output system for the
SpectralTrace.
Unfortunately, it also depends on the definition of the spectral mapping which coordinate systems are to be used. In principle, the METIS LMS image slicer is also rearranged into a pseudo-slit, but the available transforms go directly from the image slicer to the detector plane, thus include the rearrangement.
The first step is to correct the offsets as they are used in #875. They could be relegated to a posttransform when computing Transform2D. The MICADO IFU transform from sky/slicer to pseudoslit could use pretransform_x and pretransform_y. It remains to be seen how the transforms can be defined via the irdb yamls.
It was found that #875 affects the long slit in MICADO, which acquires a spurious shift in the x-direction. This is because it is asymmetric in the focal-plane (or sky) coordinates, running from$-5$ arcsec to $10$ arcsec. An offset is detected in the FOV header keyword
CRVAL1D, which leads to the a wrong estimate of the offset.In fact, as stated in #875, the implementation with an offset in the detector plane is too hacky. It was necessary because the transformations in MICADO are only available for$\eta=0$ in the focal-plane, and we do not know how to map slits with $\eta\neq0$ .
In view of the implementation of the MICADO IFU mode, we need to be more careful.
In fact there are three coordinate systems that play a role:
SpectralTrace. In some cases this is identical to the sky system (the standard MICADO slits, the METIS LMS image slicer), in others it contains a pseudo-slit that results from rearranging the image slices (the MICADO IFU).SpectralTrace.Unfortunately, it also depends on the definition of the spectral mapping which coordinate systems are to be used. In principle, the METIS LMS image slicer is also rearranged into a pseudo-slit, but the available transforms go directly from the image slicer to the detector plane, thus include the rearrangement.
The first step is to correct the offsets as they are used in #875. They could be relegated to a
posttransformwhen computingTransform2D. The MICADO IFU transform from sky/slicer to pseudoslit could usepretransform_xandpretransform_y. It remains to be seen how the transforms can be defined via the irdb yamls.