desihub / desietc

Online exposure-time calculator for DESI

desietc

Online exposure-time calculator for DESI.

The only required depenencies are: numpy, scipy, fitsio.

Python >= 3.8 is required to use the parallel processing option.

Some optional features also use: matplotlib, pandas, requests, psycopg2.

desietc's Issues

Average speed should average after the airmass correction

The 20-minute averaged speed (used by NTS for selecting the program for the next tile) applies an airmass^1.75 correction. This correction should be done before the averaging. Below is an example of the discontinuity in average speed on the night of 2021-10-08.

Account for changing sky color with sky brightness due to moon

There is a strong trend in EFFTIME_SPEC / EFFTIME_ETC with SKY_MAG_R_SPEC:

Since this is a sky color effect and we aren't measuring the sky color, any correction will be approximate. But it seems that using the sky magnitude as a proxy for the sky color would enable better BRIGHT EFFTIME estimates.

Debug (rare) invalid airmass values

@akremin has compared airmass values from the ETC json and DESI raw data header and found some (rare) examples of large discrepancies. The worst case is:

Night: 20210513, exp: 00088274, airmass etc: 1.54272, airmass data:1.104157, difference:-0.43856

Can you post your plot comparing all exposures here @akremin?

This matters for the ETC since airmass is used for its EFFTIME calculation.

Do not apply dust corrections for backup program

The backup program target selection is not extinction corrected, so the ETC effective time shouldn't be either.

Is any change needed for the backup speeds?

The ETC gets its dust extinction from the fiber-assign file associated with the current tile, calculated as the nanmedian of all targets with OBJTYPE == "TGT".

All exposures use the same Ebv coefficient, which defaults to 2.165.

The ETC currently has no notion of the DARK / BRIGHT / BACKUP programs, beyond what is implied by the SBPROF = PSF / EGL / BGS / FLT, so the first issue is how to identify backup tiles. Is there a program keyword somewhere in a fiberassign FITS header?

Update ETC absolute zero point to more closely match GFA zero point

The derived ETC transparencies are systematically offset from Aaron's GFA analysis by ~14%. This leads to slower-than-appropriate survey speeds. We should update the absolute zero point in order to compensate. The y axis is mislabeled and should be (GFA transparency) / (ETC transparency).

Update effective time calibration

From @schlafly:

There has been a fluctuation in the value of EFFTIME_SPEC / EFFTIME_ETC such that we're now averaging something like 0.95.  We stayed at 1 between the two major shutdowns but have been at ~0.95 since then.
...
Let's go ahead and boost the amount of time we get given a particular requested time by 5%.
The goal is that exposure times after this tweak will be 5% longer than they otherwise would have been.

No version string

Now that desietc is now part of the standard DESI release, it needs to be brought up to standard. For starters, there is no version string:

import desietc.__version__ as desietc_version

won't work.

Update ETC calibration to EFFTIME_SPEC

Looking at all maindark tiles observed so far, EFFTIME_SPEC / EFFTIME_ETC averages to something like 1.07. It would be good to adjust the calibration so that we don't systematically overcook dark tiles.

More robust rejection of ETC fibers with stellar contamination

Exposures 106015-8 of tile 3072 (RA 293.37 DEC 66.43) on 20211025 have sudden jumps in the sky level that appear to correlate with downward spikes in FFRAC:

This issue is to document what happened, as a starting point for possibly updating the algorithm to avoid situations like this (in case we start to see this more often).

Update airmass scaling in nts_speed to be more steep

Currently observed speeds are corrected to "zenith speeds" for use by the NTS by scaling them by the ratio of the transparency at zenith to the transparency at the observed airmass. However, brighter skies and worse seeing also contribute to slower speeds off zenith, and indeed these seem to be the dominant effect in the r band. We want to replace this with an X^1.75 scaling.

I've made the corresponding update to the SurveySpeed wiki here:
https://desi.lbl.gov/trac/wiki/SurveyOps/SurveySpeed