Check MICADO detector layout

[oczoske]

An inconsistency between the layout in irdb/MICADO and the document ELT_TRE_MCD_563000-0173_v0.5_ImagingSpectroRef has been reported.

[hugobuddel]

There doesn't seem so much to be an inconsistency, as perhaps missing information.

The 9 "X","Y","Global orientation" triples in ELT_TRE_MCD_563000-0173_v0.5 all have a match in FPA_array_layout.dat

The differences are:

• The IRDB only lists the Detector ID, which is empty in the document.
• The document lists the Location number, which is not directly a concept in the IRDB.
• The IRDB has the detectors ordered in a peculiar fashion, that makes it easy to visualize them.

Conceptually the order should not matter, because it is not guaranteed that the FITS files by the ICS software will always have the detectors in the same order either. At least, the pipeline should not depend on that.

The location number is kinda irrelevant too, because that is already given by X and Y. It might be useful to label the locations somehow, e.g. with numbers, but I don't think the IRDB or ScopeSim currently have a way to store that information.

The detector ID is maybe a bit relevant, because hypothetically, the darks and flats that are currently taken by ESO for a detector of a certain ID would, at least in theory, still be valid for that detector once it is installed. But it is probably not yet known which detector will go where.

So it seems to me that there is nothing directly wrong with the IRDB per se.

However, I'm not sure that ScopeSim takes the detector ID into account when it writes the FITS headers. The extensions are ordered in the order they are written in the IRDB, which is an order that might not match the location in the document. However, that should not matter because formally the data is not ordered anyway.

If I recall correctly, the headers currently do not store the detector ID itself. Or maybe the primary headers do? Maybe the only way to identify which extension belongs to which detector is through the EXTNAME keyword, which is currently defined as "DET§.DATA", where the § is replaced by a number. But I don't know whether § is the detector id or just the position of the detector in the IRDB table. But neither of those numbers would (necessarily) correspond to the location listed in the table in the document.

So it seems to me that nothing is wrong per se, but it could very well be that there is information missing.

What I think should happen is

• ELT_TRE_MCD_563000-0173_v0.5 should list the Detector ID, even if it is just a made up number (or string)
• The IRDB should then incorporate that detector id properly
• ScopeSim should write that detector id to the header of the extensions.

And then of course the number that belong to the detector with that ID should match. But then the ordering or location becomes irrelevant.

[hugobuddel]

If we cannot get some kind of detector ID in the document (which I assume), then we should:

• List the location number in the IRDB and in the headers
• Use the location as (part of) a pseudo-detector ID, and put that pseudo-id in the headers
• Store the actual X/Y/Orientation in the headers.

All of this should be possible now I think by putting some extra entries in https://github.com/AstarVienna/irdb/blob/dev_master/MICADO/FITS_extra_keywords.yaml , but not sure that fully works. Because you'd also need something like § for the values, and maybe that is not yet implemented.

Note that my suggestion to the MICADO team was to simulate everything through MicadoWISE, then they would have full headers from day 1. ScopeSim should support proper headers, but I didn't push for that then because we as MICADO consortium already had that part covered well enough. Essentially MicadoWISE functions as an ICS-simulator in that regard.