<commit_before>
Observing with RTS2 - Oct 2017

Normal startup: On bigobs, start 
galilserver
filter wheel gui (optional)
paddle (optional)
INDI server
xephem
from xephem > view > sky view
from sky view window, telescope > INDI panel
set telescope & dome communication, enable telescope

on gerard as bigobs:
ipython -i dataserver.py
  if this works right, it should allow the data files to be written
  on gerard and pop up a ds9 that displays each image as it is taken.

on AZCAM computer, double click Start Mont4K

RTS2 stuff:

log into rts2obs@bigpop (ssh from gerard, same pwd as bigobs)

sudo service rts2 start
rts2-queue  to check what's in each queue; "plan" is the default queue
rts2-queue --queue plan --clear   will clear it.
rts2-targetinfo <id> and rst2-targetlist are also useful.

to populate queue from the LOTIS list using Sam's script to parse LOTIS:
cd ~rts2obs/readlotis
python read_superlotis.py
Answer y to the question about populating
type rts2-queue to check what is in the queue

Bring up the control/monitor panel with:
rts2-mon
TAB to switch between panels
up and down arrows to move between lines
left and right arrows scroll the panel left/right
in the upper right panel, hit Enter to edit a line/variable
F9 to get access to the top line menu 
Esc to leave the top line menu

variables to check:
SEL:
queue_only true
selector_enabled true
plan_queing WESTEAST or HIGHEST, etc; choose something logical.
  FIFO and CIRCULAR will be confusing
C0:
scriprep 0  to keep it from repeating 
EXEC:
auto_loop false
default_auto_loop false

Note: there was something funny about the display in the SEL tab. There are
a couple of lines toward the bottom that wrap around and throw off the display 
of where your cursor is vs what variable you are editing.  This affected
"plan_queing". If in doubt, the line of descriptive text and the variable 
choices offered when you hit ENTER are correct when the cursor position is not.

To start observing:
F9 to top menu, move over to States, select On, answer Yes to question
This will move the telescope!

If you leave rts2-mon on the EXEC page it will show the current and next
target queue_id and name (eg 1026 and sn2017gup), and the observation start
time and how long it has been on the target.  This is nice for seeing
what it is doing and where it will go next.

If it slews to a target but AzCam doesn't start taking exposures, there
is a failure to communicate with the camera.  To cure this:
quit rts2-mon: F9 to top menu, System > Exit
service rts2 status
look for the PID of the rts2-camd-azcam3 process. If it's not there, find it with
ps aux | grep azcam 
on bigpop,
sudo kill -9 <PID>
sudo rts2-camd-azcam3 -i -a 10.30.1.10:2402 -n 10.30.1.2 --wheeldev W0 --focdev F0 --debug
(this is in ~rts2obs/resetcam, you don't have permission to sudo that script,
but you can copy/paste from it)
start rts2-mon again and restart the queue. 
The object that was at top of queue may disappear - RTS2 may have removed 
it from the queue once it slews to it and makes it current. You can add it 
back with:
rts2-queue --queue plan <queue_id>

If things get more wedged, or BIG61 gets hung, you can restart everything
with:
sudo service rts2 stop
sudo service rts2 start
Then restart rts2-mon. You may then need to check and reset queue_only = true,
auto_loop = false, default_auto_loop = false.

Data files seem to be winding up on gerard in ~bigobs/data with a filename
based on yyyymmdd, UT, and queue-id. Unfortunately the name in the FITS 
header is not populated with the target name. I don't know how to specify
the data destination.

plan_queing WESTEAST seemed to work mostly as expected; I'm not 100% sure that
it always observed in strict RA order, but its order was fairly sensible.  
It does understand the telescope limits. When there are objects in the queue that
appear to be skipped or sent to the end of the queue, it may be because of limits.
We had it remove objects when done, so if you run out of objects it will wind up
at the eastmost one, even if low, and may repeat it or hang out, rather than 
doing something like repeating objects that are higher up.

To stop things cleanly:

rts2-queue --queue plan --clear
in rts2-mon, States > Off, answer yes
in rts2-mon, System > Exit
sudo service rts2 stop.

While in rts2-mon, you can select the BIG61 pane and type "park" to
stow the telescope and dome.  Or you can quit and stop RTS2 and 
stow them from the INDI panel.
Finally, disable the telescope from the INDI panel.  
Make sure you quit RTS2 and disable the telescope so there's no chance
of it waking up and moving things!

rts2-targetinfo <queue_id> 
will print info about the target including the script that tells how
many exposures, what filter, etc.

The filter numbers correspond to the order in FW GUI but are 0-based.

It should be possible to change the focus in script with focpos but
this did weird things when we tried - it didn't go to the right 
values and the values reported in the rts2-mon log seemed to be two
different ones per setting.  Also, to make autofocusing easier,
it would be very nice to write telescope focus into a FITS header field
for each image.

I also have not figured out the BIG61(1m,0) offset syntax. I tried varying
the 1m to get the standard stars on both halves of the chip, but it didn't 
behave as I expected.

To add a target, you run
rts2-newtarget 
  [type stuff including RA, Dec, name, id]
rts-target -c <camera> -s "your script here" <queue_id>    
  [to make an observing script for an existing target]
rts2-queue --queue plan <queue_id>    
  [to add the target to queue named "plan"]

Example: How to add a standard star to the queue:

rts2-newtarget   [interactive, I didn't figure out the command line yet]
00:54:34 +00:41:05        [RA Dec]
s                         [save]
1100                      [queue id]
Landolt_92_249            [name]

rts2-target -c C0 -s "BIG61.OFFS=(1m,0) filter=2 E 20 filter=2 E 20 filter=3 E 10 filter=3 E 10 filter=1 E 5 filter=1 E 5 filter=4 E 10 filter=4 E 10 filter=0 E 60 filter=0 E 60" 1100

   (this order was BVRIU, I think)

rts2-queue --queue plan 1100

RTS2 will stick it into the queue according to the order option you have
in plan_queing.<commit_msg>info on lunarDistance and airmass constraint in notes<commit_after>
Observing with RTS2 - Oct 2017

Normal startup: On bigobs, start 
galilserver
filter wheel gui (optional)
paddle (optional)
INDI server
xephem
from xephem > view > sky view
from sky view window, telescope > INDI panel
set telescope & dome communication, enable telescope

on gerard as bigobs:
ipython -i dataserver.py
  if this works right, it should allow the data files to be written
  on gerard and pop up a ds9 that displays each image as it is taken.

on AZCAM computer, double click Start Mont4K

RTS2 stuff:

log into rts2obs@bigpop (ssh from gerard, same pwd as bigobs)

sudo service rts2 start
rts2-queue  to check what's in each queue; "plan" is the default queue
rts2-queue --queue plan --clear   will clear it.
rts2-targetinfo <id> and rst2-targetlist are also useful.

to populate queue from the LOTIS list using Sam's script to parse LOTIS:
cd ~rts2obs/readlotis
python read_superlotis.py
Answer y to the question about populating
type rts2-queue to check what is in the queue

Bring up the control/monitor panel with:
rts2-mon
TAB to switch between panels
up and down arrows to move between lines
left and right arrows scroll the panel left/right
in the upper right panel, hit Enter to edit a line/variable
F9 to get access to the top line menu 
Esc to leave the top line menu

variables to check:
SEL:
queue_only true
selector_enabled true
plan_queing WESTEAST or HIGHEST, etc; choose something logical.
  FIFO and CIRCULAR will be confusing
C0:
scriprep 0  to keep it from repeating 
EXEC:
auto_loop false
default_auto_loop false

Note: there was something funny about the display in the SEL tab. There are
a couple of lines toward the bottom that wrap around and throw off the display 
of where your cursor is vs what variable you are editing.  This affected
"plan_queing". If in doubt, the line of descriptive text and the variable 
choices offered when you hit ENTER are correct when the cursor position is not.

To start observing:
F9 to top menu, move over to States, select On, answer Yes to question
This will move the telescope!

If you leave rts2-mon on the EXEC page it will show the current and next
target queue_id and name (eg 1026 and sn2017gup), and the observation start
time and how long it has been on the target.  This is nice for seeing
what it is doing and where it will go next.

If it slews to a target but AzCam doesn't start taking exposures, there
is a failure to communicate with the camera.  To cure this:
quit rts2-mon: F9 to top menu, System > Exit
service rts2 status
look for the PID of the rts2-camd-azcam3 process. If it's not there, find it with
ps aux | grep azcam 
on bigpop,
sudo kill -9 <PID>
sudo rts2-camd-azcam3 -i -a 10.30.1.10:2402 -n 10.30.1.2 --wheeldev W0 --focdev F0 --debug
(this is in ~rts2obs/resetcam, you don't have permission to sudo that script,
but you can copy/paste from it)
start rts2-mon again and restart the queue. 
The object that was at top of queue may disappear - RTS2 may have removed 
it from the queue once it slews to it and makes it current. You can add it 
back with:
rts2-queue --queue plan <queue_id>

If things get more wedged, or BIG61 gets hung, you can restart everything
with:
sudo service rts2 stop
sudo service rts2 start
Then restart rts2-mon. You may then need to check and reset queue_only = true,
auto_loop = false, default_auto_loop = false.

Data files seem to be winding up on gerard in ~bigobs/data with a filename
based on yyyymmdd, UT, and queue-id. Unfortunately the name in the FITS 
header is not populated with the target name. I don't know how to specify
the data destination.

plan_queing WESTEAST seemed to work mostly as expected; I'm not 100% sure that
it always observed in strict RA order, but its order was fairly sensible.  
It does understand the telescope limits. When there are objects in the queue that
appear to be skipped or sent to the end of the queue, it may be because of limits.
We had it remove objects when done, so if you run out of objects it will wind up
at the eastmost one, even if low, and may repeat it or hang out, rather than 
doing something like repeating objects that are higher up.

To stop things cleanly:

rts2-queue --queue plan --clear
in rts2-mon, States > Off, answer yes
in rts2-mon, System > Exit
sudo service rts2 stop.

While in rts2-mon, you can select the BIG61 pane and type "park" to
stow the telescope and dome.  Or you can quit and stop RTS2 and 
stow them from the INDI panel.
Finally, disable the telescope from the INDI panel.  
Make sure you quit RTS2 and disable the telescope so there's no chance
of it waking up and moving things!

rts2-targetinfo <queue_id> 
will print info about the target including the script that tells how
many exposures, what filter, etc.

The filter numbers correspond to the order in FW GUI but are 0-based.

It should be possible to change the focus in script with focpos but
this did weird things when we tried - it didn't go to the right 
values and the values reported in the rts2-mon log seemed to be two
different ones per setting.  Also, to make autofocusing easier,
it would be very nice to write telescope focus into a FITS header field
for each image.

I also have not figured out the BIG61(1m,0) offset syntax. I tried varying
the 1m to get the standard stars on both halves of the chip, but it didn't 
behave as I expected.

To add a target, you run
rts2-newtarget 
  [type stuff including RA, Dec, name, id]
rts-target -c <camera> -s "your script here" <queue_id>    
  [to make an observing script for an existing target]
rts2-queue --queue plan <queue_id>    
  [to add the target to queue named "plan"]

Example: How to add a standard star to the queue:

rts2-newtarget   [interactive, I didn't figure out the command line yet]
00:54:34 +00:41:05        [RA Dec]
s                         [save]
1100                      [queue id]
Landolt_92_249            [name]

rts2-target -c C0 -s "BIG61.OFFS=(1m,0) filter=2 E 20 filter=2 E 20 filter=3 E 10 filter=3 E 10 filter=1 E 5 filter=1 E 5 filter=4 E 10 filter=4 E 10 filter=0 E 60 filter=0 E 60" 1100

   (this order was BVRIU, I think)

Can also try adding moon distance and airmass constraints (this is untested):

rts2-target -c C0 --lunarDistance 20: --airmass :2.2 -s "BIG61.OFFS=(1m,0) filter=2 E 20 filter=2 E 20 filter=3 E 10 filter=3 E 10 filter=1 E 5 filter=1 E 5 filter=4 E 10 filter=4 E 10 filter=0 E 60 filter=0 E 60" 1100

Add target to queue:

rts2-queue --queue plan 1100

RTS2 will stick it into the queue according to the order option you have
in plan_queing.
{'fraction_non_alphanumeric': 0.0472263284836225, 'fraction_numerical': 0.027230996654477552, 'mean_word_length': 3.7187958883994128, 'pattern_counts': {'":': 0, '<': 17, '<?xml version=': 0, '>': 29, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 4, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2338150', 'n_tokens_mistral': 4126, 'n_tokens_neox': 3801, 'n_words': 2168}