You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There should be a minimum exposure time limit in the code as well. There are thermal
restrictions on how often we can run the robots. This might have an impact on BGS.
The design minimum is 800secs but it might be possible to go faster, at 400secs the
focal plane heats up 9C (delta from ambient) and we have to keep the focal plane temp
under control so that it doesn't disrupt other factors (eg. guiding, seeing, robot lifetime,
thermal interlocks). I think you might set that time to t_min=800s and then see what
impact that has.
I expect this will impact the BRIGHT program, where the shortest exposures are now ~300s. We will need to decide what to do in the scheduler when, e.g., there is a BRIGHT tile that could reach its target SNR in 400s. Should we:
"overcook" it to exceed its target SNR,
observe a different tile that needs 800s to reach its target SNR,
temporarily exceed the 800s limit (and then allow enough time for the additional heat load to dissipate).
Another impact will be how cosmic splits are implemented. We currently split any exposure that is forecast to last 20 < texp < 40 mins into two exposures of texp/2. For 20 < texp < 27 mins, this would violate the 800s ~ 13 min constraint.
The text was updated successfully, but these errors were encountered:
The baseline design given to the focal plane systems was not to reconfigure more often than every 800 sec, so that's what we have designed to. The bright time survey isn't allowed to drive these requirements.
That said, we could reasonably expect to get a sign-off from Joe Silber to do this as frequently as every 400 sec. We could use that faster number, with the caveat that it's not guaranteed. Here's what Joe said today: "We nominally designed to 800s cycle time. At this point 400 sec is about as fast as I expect we'd want you to go. We'll be looking for power savings as we move forward (for example we believe we can run positioners about 20% lower power), but there are enough variables that I wouldn't guarantee any better than 400 sec, since there are other possible heat sources to resolve, such as if we need more power at the GFAs."
(Capturing some recent discussion in desi-data)
From Michael Levi:
I expect this will impact the BRIGHT program, where the shortest exposures are now ~300s. We will need to decide what to do in the scheduler when, e.g., there is a BRIGHT tile that could reach its target SNR in 400s. Should we:
Another impact will be how cosmic splits are implemented. We currently split any exposure that is forecast to last 20 < texp < 40 mins into two exposures of texp/2. For 20 < texp < 27 mins, this would violate the 800s ~ 13 min constraint.
The text was updated successfully, but these errors were encountered: