Frequently Asked Questions related to KMOS

• I would very much appreciate to receive (for each executed OB) a screen shot of the target allocation in the 24 KMOS IFUs. Is this possible?

Answer: Unfortunately, this cannot be implemented into standard observations. Screen shots can be taken on best effort basis, when asked for in the Readme file. We note, however, that you can reconstruct the 'acquisition' image by using the reconstruction pipeline recipe (kmo_make_image) on the archived raw acquisition files.

• Why are there so many different tools: Exposure Time Calculator, p2 Tool, KARMA?

Answer: For practical and historical reasons. The Exposure Time Calculator (ETC), for instance, is usually already required during Phase 1 when a proper evaluation of the required observation time must be made. The p2 Tool on its part is necessary only if the proposal from Phase 1 is accepted. Furthermore, the latter was initially designed to specify simple observation parameters for simple instruments only. For rather complex ones these capabilities are not sufficient anymore but must be complemented by additional utilities while the p2 Tool still represents the lowest common denominator for all instruments.

• Does the ETC take into account also the time spent on sky?

The KMOS ETC returns a realistic estimation of the integration time (on source) needed to achieve a given S/N as a function of the band selected and the atmospheric conditions. This does not include the time spent on sky in the nodding mode. In order to properly estimate the total telescope time needed for your program, you should add the overheads for time spent on sky and telescope/instrument setting, as described in section 3.5 of the KMOS User Manual.

• Is there any KARMA version for Mac OS or Windows?

Answer: At the moment there exists a single binary for Mac OS X for an i386 hardware, but without any warranty for portability. Please consult the following ESO webpage for information about the supported platforms and available binary versions:

https://www.eso.org/sci/observing/phase2/SMGuidelines/KARMA/KARMAInstall.OmegaCAM.html

• Why can’t I use the intrinsic Skycat/RTD feature XY while I’m in KARMA mode?

Answer: To avoid the possibility of getting confused by too many features in too many open windows, the RTD functionality available in KARMA mode was restricted to the absolute minimum. All you really need is available through the central KARMA control dialogue. If you want to use a certain RTD/Skycat feature, abort the KARMA session and switch back to RTD mode.

• Why isn’t it possible to optimise the total allocation efficiency over multiple KARMA cycles automatically in case the KARMA catalogue contains more than 24 targets?

Answer: In each cycle the allocation task depends on the chosen telescope pointing and the instrument rotator angle. Allowing for both of these (continuously adjustable) free parameters in an allocation algorithm would introduce too many additional degrees of freedom. But even if such a huge complexity were manageable: The sky background position complementing a certain target allocation can be obtained only interactively and hence cannot be part of an automatic algorithm.

• KARMA complains that my catalogue contains “DOS-like carriage returns”. How could this happen, and what shall I do now?

Answer: Different operating systems have different conventions of how line endings in ASCII files are represented. All Unix-like systems (including GNU/Linux and Mac OS X) use a single line feed (LF, ’\n’) only. This is also the expected line ending for catalogue files in KARMA. On Windows-like systems (including MS-DOS, Microsoft Windows, Vista etc.), however, a combination of a line feed and a carriage return (CR, ’\r’) is used. You need not necessarily have prepared your catalogue on such a system, it is sufficient to have sent it by email as an attachment via a Windows mail server and/or relay. Text files are usually converted into the format that follows the convention on the server then. If one or the other case happens to you, you can use the catalogue anyway, but you have to confirm the loading after KARMA has issued an appropriate warning. If possible, however, you should try to avoid such cases and prepare your catalogue on a native Unix-like system.

• Why isn’t it possible to define new targets by means of the image?

Answer: Since KMOS has no imaging mode, there can be no reasonable restriction regarding the source of an image to be used in KARMA. The accuracy of target positions obtained from such an image, however, would strongly depend on its astrometric properties and possibly be different from the accuracy of other catalogue entries. The positioning errors arising from such discrepancies are very difficult to detect, and therefore they shall be ruled out by design.

• Shouldn’t it be impossible to mark a single catalogue entry as science target and potential guide star at the same time?

Answer: Whether a certain catalogue entry can become a potential guide star can be decided only when the science target allocations are made and the position of the KMOS field of view with respect to the catalogue field is fixed. This happens during the KARMA session, not before. Then, of course, a guide star cannot serve as a science target anymore since guide stars must lie outside the field of view. The same applies the other way around.

• Why do you need to specify the telescope position in KARMA if this is already a p2 parameter?

Answer: The telescope pointings are specified by the target field centre and your chosen sky background

position, respectively. While the former is usually chosen with special focus on the most efficient target allocation, the latter must be determined interactively after having already assigned the pick-off arms. Since both tasks depend on the allocation process itself, they can only performed with KARMA. The initial telescope pointing (the one for acquisition), however, will be transferred to the p2 Tool automatically and must not be modified/edited in the OB.

• Why can’t I get two arms closer to each other although they don’t seem to touch yet?

Answer: To allow for additional small pick-off arm displacements (at observation time) due to corrections of differential atmospheric refraction effects each arm is surrounded by a small “safety margin” which defines the closest possible approach of 2 arms in KARMA.

• Why do I need a dedicated sky background position for the acquisition, even in case it is done by means of bright reference stars?

Answer: Reference objects need not necessarily to be as bright as it is required by data reduction to determine their centre position exactly. As a precaution for such cases the additional sky background (position) must be provided.

• Why do I get a warning that a particular bottom arm IFU is vignetted? Even with the largest possible zoom I can’t see any neighbouring upper arm shadowing it.

Answer: The IFU size as drawn by KARMA is the one related to the focal plane. The arms, however, are actually located above and below it. Therefore their tip mirrors see a somewhat diverged beam and partial vignetting can occur even in cases when it seems not to be so. In other words, the shadow of an upper arm is larger than its outline drawn by KARMA suggests. KARMA takes this effect into account.

• Does the exact position of a manually allocated arm depend on the accuracy of its manual placement in the KARMA main window and because of that possibly even on the screen resolution?

Answer: No. If you got the tip centre close enough to the envisaged target, KARMA detects a sufficient proximity at allocation time (i.e. when you press Allocate ) and gives the arm the exact target position as it appears in the catalogue. Depending on the screen resolution and the zoom settings also a slight shift of the arm outline may be visible. Either way, you recognise that an allocation was successful by means of the changed symbol colour of the assigned target.

• There is no guide star available for selection anymore although I have specified quite a few in the input catalogue. What can I do?

•Answer: In this case all your potential guide stars are located within the avoidance zone, consisting of the KMOS FoV’s at the 4 telescope positions and an additional margin allowing for the finite size of the guide probe. You can either modify the telescope pointings (large offsets between science/acquisition and sky positions increase the avoidance zone, so you can try to decrease the offsets) or you can supply additional guide stars with a modified input catalogue. In both cases, whether you like it or not, you have to go back to the corresponding preparation step.

• The telescope position that I find in the PAF file (TEL.TARG.ALPHA and TEL.TARG.DELTA) in Mosaic mode is different from my catalogue centre although I didn’t apply any offsets in KARMA. Why?

•Answer: Although an observation in Mosaic mode consists of a series of exposures at different telescope positions, only the first pointing appears in the PAF file. As the execution of a Mosaic OB always starts at the upper left corner of the mapping area, the telescope position in the PAF file is thus the one that aligns the upper left IFU of the fixed arm configuration (see figure 15) with this corner. For the large Mosaic pattern this requires an offset of about 4.05 arcsec in both directions from the centre of the mapping area.

• Why isn’t it possible to restore a previously abandoned KARMA session from the PAF file alone?

Answer: The PAF file is the one which goes into the OB. Therefore only that information is included there which is absolutely necessary to carry out the observation. The KARMA session state, however, includes much more information to store: All not yet allocated targets, for example, not used guide stars, actual settings of the user interface and much more. All this additional information would require additional keywords and pollute the PAF file unnecessarily.

• Is it possible to edit the PAF file manually after it has been generated?

Answer: According to Radio Yerevan (http://en.wikipedia.org/wiki/Radio_Yerevan_jokes): In principle, yes. But your file will be corrupted then because the automatically generated checksum doesn’t match the content anymore. Although KARMA can repair the file, you possibly run into other problems. So, don’t do that – editing the PAF file is evil!

• What happens if a certain hardware component (a pick-off arm or grating, for example) gets broken between the submission of my OB and the actual observation? Are the corresponding target allocations lost?

Answer: Shit happens. Depending on the type and number of broken components the corresponding pick-off arms will be locked and are not available for observation anymore. However, there will always be an attempt to keep the most important target allocations also in case of such a hardware failure. For this purpose the rotational position of the instrument will be optimised just before the OB execution so that a maximum of priority 1 targets can be observed with the then still available arms.