Two sun-safe parking changes

mhasself commented 1 month ago

don't go all the way to min_el, just go as far down as you need
don't fail because you don't have 5 extra minutes to pre-move; instead just wait until it's safe and then go to next position.

This does not address #113. It's digging more into the #111 stuff.

Please test.

kmharrington commented 1 month ago

Testing these, they very nicely caught the first day that satp1 can't stay at (180,60) and it's working for moving the parking spot during the sun break for both satp1 and satp2.

kmharrington commented 1 month ago

Ok but then I found another that I think comes from this section of the code?

platform: satp2

# yaml loads iso format automatically into datetimes
t0: 2024-10-24T20:00:00+00:00
t1: 2024-10-25T20:00:00+00:00
t0_state_file: None

elevation: 60
boresight: 0
az_speed: 0.5
az_accel: 1.0

# optional, only needed if running non-defaults
bad_smurf_slots: 
  - det-controller-c4s4
  - det-controller-c5s5
apply_boresight_rotation: True 
hwp_dir: True # True: forwards, False: backwards
home_at_end: True # Home: spin down HWP and go to (180,60)
run_relock: True # Relock detectors at the beginning of the schedule
iv_cadence: 3600 ## take lots of IVs

cal_targets:
  - source: jupiter
    # boresight: # if not specified, use scan boresight
    elevation: 50
    focus: 'ws2'
    allow_partial: True
    az_branch: 270
    az_speed: 0.8
    az_accel: 1.0
  - source: saturn
    # boresight: # if not specified, use scan boresight
    elevation: 50
    focus: 'ws4'
    allow_partial: True
    az_speed: 0.8
    az_accel: 1.0

Ends up with this block

run.wait_until('2024-10-25T13:27:24+00:00')
#run.acu.move_to(az=180.0, el=60.0) <<--- this line is not sun safe but related to issue #122 
run.acu.move_to(az=180.0, el=48.0)
run.wait_until('2024-10-25T13:32:24+00:00')
run.acu.move_to(az=180.0, el=48.0)
run.wait_until('2024-10-25T17:30:35.970000+00:00')  <<<---------These lines are not sun safe and related here I think
run.acu.move_to(az=111.483, el=48.0)
run.acu.move_to(az=111.483, el=60.0)
run.wait_until('2024-10-25T17:30:35.970000+00:00') <<<---------These lines are not sun safe and related here I think
run.acu.move_to(az=111.483, el=60.0)

mhasself commented 4 weeks ago

Ends up with this block

run.wait_until('2024-10-25T13:27:24+00:00')
#run.acu.move_to(az=180.0, el=60.0) <<--- this line is not sun safe but related to issue #122 
run.acu.move_to(az=180.0, el=48.0)
run.wait_until('2024-10-25T13:32:24+00:00')
run.acu.move_to(az=180.0, el=48.0)
run.wait_until('2024-10-25T17:30:35.970000+00:00')  <<<---------These lines are not sun safe and related here I think
run.acu.move_to(az=111.483, el=48.0)
run.acu.move_to(az=111.483, el=60.0)
run.wait_until('2024-10-25T17:30:35.970000+00:00') <<<---------These lines are not sun safe and related here I think
run.acu.move_to(az=111.483, el=60.0)

I think those are sun safe. But the lines after that:

################### Detector Setup######################
with disable_trace():
    run.initialize()
run.smurf.take_bgmap(concurrent=True)
run.smurf.take_noise(concurrent=True, tag='res_check')
run.smurf.iv_curve(concurrent=True, 
    iv_kwargs={'run_serially': False, 'cool_wait': 60*5})
run.smurf.bias_dets(concurrent=True)
time.sleep(180)
run.smurf.bias_step(concurrent=True)
run.smurf.take_noise(concurrent=True, tag='bias_check')
#################### Detector Setup Over ####################

# hwp already spinning
scan_stop = datetime.datetime(2024, 10, 25, 18, 46, 24, tzinfo=datetime.timezone.utc)
if datetime.datetime.now(tz=UTC) < scan_stop - datetime.timedelta(minutes=10):
    run.seq.scan(
        description='SOUTHERN FIELD : SE=2nd, 3rd or 4th choice',
        stop_time='2024-10-25T18:46:24+00:00',
        width=40.0, az_drift=0,
        subtype='cmb', tag='111-151',
    )
run.acu.move_to(az=111.483, el=60.0)

For me, the checker fails on run.seq.scan, which would not be sun-safe at 17:30:35... but is sun-safe 4 minutes later, i.e. after the detector setup has run.

I don't know if that's how the scheduler is actually thinking about things (i.e. to start the detector setup a few minutes before the nominal scan time), but if so it is necessary to include a wait_until before the scan, at least in the case that Sun Avoidance might trigger if you start scanning too early.

kmharrington commented 4 weeks ago

hmm, the sun safety checker failed on those exact lines for me, not the ones in the scan. So now I'm more confused. (Just to double check, you're running that for satp2 and the 49 deg. keep-out?)

mhasself commented 4 weeks ago

hmm, the sun safety checker failed on those exact lines for me, not the ones in the scan. So now I'm more confused. (Just to double check, you're running that for satp2 and the 49 deg. keep-out?)

Yes. So I think I will need to know exactly what branches you're using with that config file.

kmharrington commented 3 weeks ago

ok, going back through the sun checker, that's what was happening. the sun checker had failed on the scan because the time hadn't moved forward in the checker but the scheduler did assume detector setup took time.

I probably would be good to have a wait until there just in case the schedules get edited

simonsobs / scheduler

Two sun-safe parking changes #121