Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement minimum exposure time constraint #78

Open
dkirkby opened this issue Nov 29, 2017 · 1 comment
Open

Implement minimum exposure time constraint #78

dkirkby opened this issue Nov 29, 2017 · 1 comment

Comments

@dkirkby
Copy link
Member

dkirkby commented Nov 29, 2017

(Capturing some recent discussion in desi-data)

From Michael Levi:

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.

@djschlegel
Copy link

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."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants