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

Strange sun-safe behavior #60

Closed
kmharrington opened this issue Apr 28, 2024 · 5 comments
Closed

Strange sun-safe behavior #60

kmharrington opened this issue Apr 28, 2024 · 5 comments

Comments

@kmharrington
Copy link
Member

running this script

import os
import json

import datetime as dt
from schedlib.policies.satp1 import SATP1Policy, make_cal_target
from schedlib.policies.sat import source_scan
from schedlib.policies.sat import SATPolicy, State, CalTarget
from schedlib import utils as u, core, commands as cmd, rules as ru, instrument as inst, source as src


basedir = '/so/home/kmharrin/public_html/observation_scripts/schedule_files/'
schedule_files = {
    50 : os.path.join(basedir, 'cmb_2024_el50_20240423.txt'),
    60 : os.path.join(basedir, 'cmb_2024_el60_20240423.txt'),
}

class params:
    elevation = int( 60 )
    boresight = int( 45 )
    az_speed = 0.5
    az_accel = 0.5
    hwp_dir = True

t0 = dt.datetime(2024, 5, 2, 20, 0, 0, tzinfo=dt.timezone.utc)
t1 = dt.datetime(2024, 5, 3, 20, 0, 0, tzinfo=dt.timezone.utc)

cfg = {
    'az_speed': params.az_speed, 'az_accel': params.az_accel,
    'disable_hwp': False, 'apply_boresight_rot': False,
    'hwp_dir': params.hwp_dir, 'iv_cadence': 6*u.hour,
}

#print(schedule_files[params.elevation])
policy = SATP1Policy.from_defaults(
    master_file=schedule_files[params.elevation],
    **cfg
)

policy.add_cal_target(
    source='moon', 
    boresight=params.boresight, 
    elevation=50,#params.elevation, 
    focus='right',
)
policy.add_cal_target(
    source='moon', 
    boresight=params.boresight, 
    elevation=50,#params.elevation, 
    focus='middle',
    #allow_partial=True,
)


seq = policy.init_seqs(t0, t1)
seq = policy.apply(seq)
cmds = policy.seq2cmd(seq, t0, t1)
schedule = policy.cmd2txt(cmds, t0, t1)

print("#####################################################################")
#print(schedule)


fname = f'debug_{t0.isoformat()}_{t1.isoformat()}.py'
fname = os.path.join(
    '/so/home/kmharrin/public_html/observation_scripts/debug_scripts/',
    fname
)

with open(fname, 'w') as f:
    f.write(str(schedule))

there are a bunch of scans solving to this:

run.acu.move_to(az=-89.108, el=60.0)
run.wait_until('2024-05-03T06:54:36+00:00')
# hwp already spinning
scan_stop = datetime.datetime(2024, 5, 3, 7, 54, 24, tzinfo=datetime.timezone.utc)
if datetime.datetime.now(tz=UTC) < scan_stop - datetime.timedelta(minutes=10):
    run.seq.scan(
        description='NW. First choice',
        stop_time='2024-05-03T07:54:24+00:00',
        width=40.0, az_drift=0,
        subtype='cmb', tag='271-311',
    )
    run.smurf.bias_step(concurrent=True)

There's really no reason to run straight up to the limit of our cable wrap when the sun is below the horizon (and in fact it likely increases wear & tear on the cable wrap).

@kmharrington
Copy link
Member Author

Found another example this script:

import os
import json

import datetime as dt
from schedlib.policies.satp1 import SATP1Policy, make_cal_target
from schedlib.policies.sat import source_scan
from schedlib.policies.sat import SATPolicy, State, CalTarget
from schedlib import utils as u, core, commands as cmd, rules as ru, instrument as inst, source as src


basedir = '/so/home/kmharrin/public_html/observation_scripts/schedule_files/'
schedule_files = {
    50 : os.path.join(basedir, 'cmb_2024_el50_20240423.txt'),
    60 : os.path.join(basedir, 'cmb_2024_el60_20240423.txt'),
}

class params:
    elevation = int( 60 )
    boresight = int( 0 )
    az_speed = 0.8
    az_accel = 1.5
    hwp_dir = True

t0 = dt.datetime(2024, 5, 4, 20, 0, 0, tzinfo=dt.timezone.utc)
t1 = dt.datetime(2024, 5, 5, 15, 42, 0, tzinfo=dt.timezone.utc)

cfg = {
    'az_speed': params.az_speed, 'az_accel': params.az_accel,
    'disable_hwp': False, 'apply_boresight_rot': False,
    'hwp_dir': params.hwp_dir, 'iv_cadence': 6*u.hour,
}

#print(schedule_files[params.elevation])
policy = SATP1Policy.from_defaults(
    master_file=schedule_files[params.elevation],
    **cfg
)

policy.add_cal_target(
    source='saturn', 
    boresight=params.boresight, 
    elevation=50, #params.elevation, 
    focus='middle',
    allow_partial=True,
)

#policy.add_cal_target(
#    source='saturn', 
#    boresight=params.boresight, 
#    elevation=50,#params.elevation, 
#    focus='middle',
#    allow_partial=False,
#)


seq = policy.init_seqs(t0, t1)
seq = policy.apply(seq)
cmds = policy.seq2cmd(seq, t0, t1)
schedule = policy.cmd2txt(cmds, t0, t1)

print("#####################################################################")
#print(schedule)


fname = f'debug_{t0.isoformat()}_{t1.isoformat()}.py'
fname = os.path.join(
    '/so/home/kmharrin/public_html/observation_scripts/debug_scripts/',
    fname
)

with open(fname, 'w') as f:
    f.write(str(schedule))

If I end the scan there, it gets to Saturn just fine the second time at az~300. If I try to end at 20:00 UTC the script throws an error saying it cannot solve sun safe moves are az~-59. Would love to not have to cut these into piece to get Saturn scans

@kmharrington
Copy link
Member Author

Making another note that there's really something wrong here. We managed to just straight command a non-sunsafe move right out of stow. Really no reason to wrap around here.

############# Daily Relock
for smurf in pysmurfs:
    smurf.zero_biases.start()
for smurf in pysmurfs:
    smurf.zero_biases.wait()

time.sleep(120)
run.smurf.take_noise(concurrent=True, tag='oper,take_noise,res_check')
run.smurf.uxm_relock(concurrent=True)

run.acu.set_scan_params(0.8, 1.5)
run.acu.set_boresight(target=-45)

run.wait_until('2024-05-10T20:15:00.020000+00:00')
run.acu.move_to(az=409.108, el=60.0)

@guanyilun
Copy link
Collaborator

Yeah I think this is a problem with how I set up the optimization . I didn’t disfavor any wraps, it will just tries to find the az that minimizes the overall moves necessary

@kmharrington
Copy link
Member Author

The "running to the Az limits" is definitely related to calibration scans. I'm only seeing it show up before or after a calibration target is observed

@kmharrington
Copy link
Member Author

superseded by #90

and has at least been partially fixed since then

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