Problem with (MICADO) spectroscopy

[oczoske]

From Slack:

(1): In the newest version of ScopeSim spectroscopy seems to be brocken. As a comb spectrum with lines spaced 2nm apart with equal Intensities across the whole wavelength range got turned into a continuous white light spectrum by ScopeSim. By accident we discovered that using an older version of Scopesim (0.8.4) and ScopeSim_templates version 0.5.3 would produce the expected result.
(2): We found that the rectified 2D spectrum is slightly tilted to shorter wavelengths for higher slit-positions xi, for Order 3_1. I used the "spec_HK" filter with the "SPEC_15000x20" slit. I suppose this possibly comes from sub-pixel errors/variations in the detector spectrum that are not properly accounted for in the rectification, as this Order is quite slanted especially compared to the other Order where no real tilt is apparent.

[teutoburg]

Do you have the code for the source object that is mentioned in (1)? That would make it easier for me to exactly reproduce the issue.

[oczoske]

An observation: the fov cube corresponding to the flatlamp has spatial slices that are not flat in the across-slit direction:

There are four layers in the across-slit direction (16 mas slit with 4 mas pixels). Here are layers 0 and 3 (wavelength vertical, along-slice horizontal):

[oczoske]

I have traced the original problem to

src_linelist = flatlamp()
src_linelist.spectra[0] = ll

Replacing the second line with

src_linelist.fields[0].spectra[0] = ll

produces a correct result.
The reason is of course that Source.spectra is a @property, which only returns the value of the spectra attributes in Source.fields but does not allow to set them. Maybe we overuse @property, causing unnecessary confusion?

[hugobuddel]

I think that change is due to #405. The old way of keeping track of which spectrum belonged to which field was not maintainable and lead to several bugs.

In the new way, the specrum is always kept with the field it belongs. But that did make it impossible (or at least hard) to make the top level spectra attribute settable, so the read-only property is a compromise.

But I cannot find that code you quote anywhere.

[hugobuddel]

Ah this code? irdb/METIS/docs/example_notebooks/demos/demo_rectify_traces.ipynb

[hugobuddel]

There is also one in demo_grating_efficiency.ipynb, but that is all I think:

 rg '\.spectra\[\d\] ='
irdb/METIS/docs/example_notebooks/demos/demo_rectify_traces.ipynb
114:    "src_linelamp.spectra[0] = spec"

irdb/METIS/docs/example_notebooks/demos/demo_grating_efficiency.ipynb
98:    "src.spectra[0] = spec"

I'll leave it to @teutoburg to tell you how to deal with this.

I suggest adding some tests somewhere to prevent a similar regression in the future. And/or visually/automatically checking the notebooks before such a big change as #405 . (I could have done those myself as well, so this is not a complaint.)

[oczoske]

The quote came from example code of the user who reported the issue on slack, I should have mentioned that. Thanks for pointing out the demo notebooks, I'll change those.

[oczoske]

Fixed the notebooks in dev_master of irdb. That takes care of issue (1). I'll define a clearer user interface to flatlamp() to avoid confusion on the user side.

[oczoske]

I'll close here and move the second item to a separate issue.

[hugobuddel]

To reiterate: I was on board with your changes in AstarVienna/ScopeSim_Templates#124 and had approved the PR, so I think we should still merge that.