search

AstarVienna / irdb

A database containing instrument data for infrared telescopes
GNU General Public License v3.0
6 stars 8 forks source link

Possible changes/improvements in MICADO setup #112

Open oczoske opened 1 year ago

oczoske commented 1 year ago

Two suggestions for possible improvement of the user-friendliness of the MICADO setup:

1) As indicated in #110, the current setup with three independent FilterWheels (filter_wheel_1, filter_wheel_2 and pupil_wheel) requires some effort on the part of the user. For one thing they need to know which wheel the requested filter is in. The new narrow-band filters included in #110 must be accompanied by a broad-band filter in one of the other wheels (as defined in Table 8 of ELT-TRE-MCD-56300-0173); if that is forgotten, the simulations will be swamped by leakage flux. A more user-friendly setup could be based on a single FilterWheel effect, which includes all filters; for the narrow-band filters these would be the effective filter curves obtained by multiplying the narrow-band curve with the associated broad-band curve. In addition, a second FilterWheel would be required to hold the neutral-density filters that can be used in conjunction with the filters. Experimenting with non-default setups is still possible with the add_filter() method.

2) The spectroscopic setup with a separate mode for each slit seems somewhat awkward and inflexible. The current setup still needs updating to the new slit definitions (e.g. 16mas width instead of 20mas for the narrow filter), this currently requires renaming of the modes. The alternative would be to have a single "SPEC" mode with a SlitWheel effect. This could be included in the imaging modes as well (open by default...) and thus enable slit viewing as requested in #88.

99) Some of the effect names are unnecessarily verbose (e.g. micado_spectral_traces could be shortened to spectral_traces , also to make naming more homogeneous with other instruments).

hugobuddel commented 1 year ago

Some thoughts:

1a. Another way to resolve this is to properly support simulating a full template or observing block (https://github.com/AstarVienna/ScopeSim/issues/22). That way the user specifies the Template / OB, including the filter, but also dithering steps etc, and then ScopeSim (or ICS simulator?) translates this to the desired hardware configuration. This would be my preference, since it solves other problems like dithering as well, and it allows ScopeSim to stay close to the hardware.

1b. Agreed. Rethinking my reply, I think you are right. For now we should do as you say, and have a single filter wheel. Even having users to figure out which filter wheel should be open and which has the filter they want is already too annoying. Then, once (if ever) we implement the suggestion above, then we can (perhaps) return to two wheels, because it would be abstracted away.

1c. Note that changing the filter wheel setup will break the scripts and notebooks of users again. Perhaps we should first ensure that the versioning of the IRDB is done properly. E.g. we should be able to ask confused users "What version of the IRDB are you using?" and they should be able to answer. And they should be able to upgrade; which I think is too hard/confusing at the moment. (Make the IRDB PyPI packages?) But we should keep making progress, so maybe just go ahead.

  1. Agreed. See 1c above.

  2. Agreed. But care should be taken that the effect names have to be unique within an optical train (which I guess would be the case for spectral_traces). I personally would prefer that the effects could only be accessed in an hierarchical way, by explicitly saying which system they belong to.

teutoburg commented 1 year ago

An idea regarding 1.:

How about introducing a new "container" effect to manage multiple FilterWheels, similar in concept to some other effects that are also containers for other things? This would not require any changes to the filter curves themselves, and would still retain the current functionality (as in, older versions of the IRDB package would still be able to use the current setup with multiple FilterWheels). The new container, call it FilterWheelList (better name suggestions welcome) would then have a definition of allowed combinations, and maybe a separate method to register new combinations for experimental purposes. It would still hold the individual FilterWheel objects as attributes, so they are also accessible manually. In the end I guess MICADO is not the only instrument to use more than one filter wheel? If memory serves, some JWST instruments do that as well. So might be useful in general to have a better way of handling this.

Thoughts?? Also @astronomyk