Update tsnr.py

[callendeprieto]

Changed nominal flux for backup and gpbbackup in var_tracer from 27.5 nMgy (r=18.9 mag star) to 397 nMgy (r=16 mag star).
We would like to change the effectime for the backup program from 60 to 90 seconds.

[schlafly]

This looks good. Two things:

1. We'll need to discuss how to apply this change to all past backup observations.
2. Somewhere there's a coefficient setting efftime = coeff * tsnr. Have you encountered that? That coefficient may need to be updated. Ultimately we measure completeness in efftime so that needs to be correctly calibrated if we want to get the right exposure times.

[callendeprieto]

On 2/8/22 13:45, Eddie Schlafly wrote: This looks good. Two things: 1. We'll need to discuss how to apply this change to all past backup observations.

I'm not sure how to handle this. Since efftime is calibrated as discussed below, we probably need to apply a different scaling depending on date (before/after the change in the reference magnitude) for the backup tiles.

1. Somewhere there's a coefficient setting efftime = coeff * tsnr. Have you encountered that? That coefficient may need to be updated. Ultimately we measure completeness in efftime so that needs to be correctly calibrated if we want to get the right exposure times.

This must be in tsnr2_to_efftime. This routine calls get_ensemble, which gets the data from the folder data/tsnr but it looks fortsnr-ensemble*fits in that location and there is none. The following comment is in generate_templates and may give usefult hints:  # NOTE THE NORMALIZATION OF MAGNITUDES DOES NOT HAVE ANY EFFECT  # AT THE END OF THE DAY, BECAUSE BOTH TSNR2 VALUES AND EFFTIME  # ARE RECALIBRATED TO VALUES OBTAINED EARLY IN THE SURVEY  # (using table sv1-exposures.csv in py/desispec/data/tsnr/)  # TO AVOID ANY ARTIFICIAL DRIFT IN THE NORMALIZATION OF THOSE  # QUANTITIES.  # See the scale factor applied to the flux in the routine get_ensemble  # and the efftime normalization in the routine tsnr2_to_efftime

— Reply to this email directly, view it on GitHub <#1815 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF6C36O2FTNAMYUFNKPMNFLVXEJ6RANCNFSM55KLRTSA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

--------------------------------------------------------------------------------------------- AVISO LEGAL: Este mensaje puede contener información confidencial y/o privilegiada. Si usted no es el destinatario final del mismo o lo ha recibido por error, por favor notifíquelo al remitente inmediatamente. Cualquier uso no autorizadas del contenido de este mensaje está estrictamente prohibida. Más información en: https://www.iac.es/es/responsabilidad-legal DISCLAIMER: This message may contain confidential and / or privileged information. If you are not the final recipient or have received it in error, please notify the sender immediately. Any unauthorized use of the content of this message is strictly prohibited. More information: https://www.iac.es/en/disclaimer

[schlafly]

We'll probably have to re-compute efftimes for all past tiles once this code goes in. That's fine; I'm just trying to make sure we don't forget to do that. I'll bring this up on the data call tomorrow, and see if @julienguy or @araichoor have any memory of how the backup program tsnr2 -> efftime relationship is established.

[weaverba137]

@schlafly, @sbailey, what would be the consequences of merging this PR now?

[sbailey]

Short version from my perspective: I don't know the impact, but given that we've been living without it for several years it can't be too urgent, and I'm inclined to not change things that aren't required when we're imminent on going back on sky after an instrument disruption. If this is an important feature to get into Jura before the final catalogs are made, we need to hear the case for that.

[schlafly]

This is not an important feature for Jura. Before we would put this in we would need to revisit the backup program tsnr -> efftime mapping, which we didn't do and so this PR got stuck.