Edge Case for Az then El Motions

[kmharrington]

We changed the Az / El moves to be separate, but I definitely just found an edge case on doing this (thanks sun safety checker!).

Running off this configuration:

platform: satp2

# yaml loads iso format automatically into datetimes
t0: 2024-10-22T17:30:00+00:00
t1: 2024-10-23T20:00:00+00:00
t0_state_file: None

elevation: 60
boresight: -45 
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: 'ws6'
    allow_partial: True
    az_branch: 270
  - source: saturn
    # boresight: # if not specified, use scan boresight
    elevation: 50
    focus: 'ws3'
    allow_partial: True

Ended up with

if datetime.datetime.now(tz=UTC) < scan_stop - datetime.timedelta(minutes=10):
    run.seq.scan(
        description='NW=2nd, 3rd or 4th choice',
        stop_time='2024-10-23T13:36:24+00:00',
        width=40.0, az_drift=0,
        subtype='cmb', tag='271-311',
    )
run.wait_until('2024-10-23T13:36:24+00:00')
#run.acu.move_to(az=180.0, el=60.0)   <<<------ This line is not sun safe
run.acu.move_to(az=180.0, el=52.0)
run.wait_until('2024-10-23T13:41:24+00:00')
run.acu.move_to(az=180.0, el=52.0)
run.wait_until('2024-10-23T17:39:35.970000+00:00')
run.acu.move_to(az=111.483, el=52.0)
run.acu.move_to(az=111.483, el=60.0)
run.wait_until('2024-10-23T17:39:35.970000+00:00')
run.acu.move_to(az=111.483, el=60.0)

[kmharrington]

This has happened for every schedule this week. So an important error to fix. Maybe at least start by moving in elevation first instead of azimuth?

[mhasself]

The constraint that moves should be separated into [az move; el move] would be best dealt with in the Agent, to be honest. It already does a bunch of thinking about whether az-then-el or el-then-az is better. Then the scheduler wouldn't have to worry about it so much. And it would be in effect all the time.

[mhasself]

^^ Support added in simonsobs/socs#778 - once I test and merge that I propose we simply remove the az/el sequencing from scheduler and do it through ACU agent config.

[kmharrington]

I'm still finding this error in schedule generation, would be nice to have something to fix it.

[mhasself]

Config now pending in https://github.com/simonsobs/ocs-deployment-configs/pull/297 ...