Create interface between MicadoWISE and ScopeSIM for Templates and ObservingBlocks
Templates and Observing Blocks describe everything that the telescope should do. So the information in them needs to be communicated to ScopeSim somehow.
The information send to ScopeSim can be grouped in two categories (or well, many more, but two are relevant now):
- Information about the hardware. E.g. specific dark current values, pixel scales etc.
- Information about the observation. E.g. what filter, what source, what readout mode etc. How to distinguish these is that the second type of information (about the observation) will also be send to the actual telescope, while the first (about the hardware) will only be send to ScopeSim.
But we realized that these two categories are hopelessly intertwined. This is because
- Micado-Wise shouldn't have to know anything about the hardware. E.g. it can just specify 'observation mode = wide field', it doesn't need to know what this means in terms of pixel scale.
- ScopeSim shouldn't have to know anything about observing modes etc. E.g. it just needs to know which hardware is turned on and with what settings, it doesn't need to know that these configurations have names etc.
So what is missing is the equivalent of the software that runs on the actual telescope and translates the observing block and templates to hardware commands. We need to figure out how and where to do this.
(Clarification about the difference between ESO and Micado-WISE: For ESO the template files are static, never to be changed. OB files specify which templates to use and settings for those. I've modeled the templates as classes on their own, as well as the observing blocks. The observing block instances are little more than chaining template instances together. So for each static template class/.tsf file, there will be many different template instances.)
Some issues we explored (not necessarily problematic):
- AO Mode: SCAO or MCAO: What does this change in ScopeSim again?
- Observation Mode: The template specifies an observation mode (e.g. wide and zoom), which translates to a different set of surfaces and a different pixel scale. Where / how is this translation done?
- Filter: The filter is actually just a surface with a special status. Readout Mode: This should correspond to a new effect of detector. But the properties of the detector are independent of the readout mode used for an observation. How to model this properly?
- Target / RA / Dec / observation time: this is all important for the hardware (e.g. ADC), but it is not hardware. How to mix these?
We have not yet resolved this. My first action item here is to see how this information is typically represented in observing blocks / templates. Then we can see how to propagate the information.