Determination of LDG/RDG zeropoints for MODS1/MODS2 and further MODS checkout
OSA: David Gonzalez Huerta
ISp: John Morris
Observers: Doug Miller, John Hill, Olga Kuhn
Useful work done with both MODS1 and MODS2 (the DX held out for it...). Starting in the afternoon, Kellee & Mike Lesser changed the gain from 1 to 10 in the AzCam
software (see IT #6198) and resulting guider reached up to ~65000 counts (guider). This was harder to check on the WFS images, but I did not see any bleeding as we did last week, and the images I checked reached ~28000 counts. At night, we used the StoneO
masks to confirm rotator zeropoints. In doing so, we realized that modsAlign needs to be updated to call modsCmd with the mods1/mods2 switches. The rotational offsets we measured, first on StoneO
and later checked on StoneO
, suggest new values:
left rotator zeropoint = 27.69 (vs 27.63 old)
right rotator zeropoint = 26.7 (vs 26.85 old, but the last mosAlignment suggested that 26.85 might be a better value).
For the right rotator zeropoint = 26.85 we collected a set of data to compute the PCS-AGw transform on 20160318, but did not yet analyze it. The zeropoints we determined tonight are close enough to their old values that we could, for left, revert to the old value & transform and, for right, revert to 26.85 and implement the corresponding transform. It would still be good to check these with a series of 5-dice images.
As well as the rotator zeropoints, John also edited the pointingoffsets in the PCSInstrument.conf file. When guiding, these should put the alignment stars close to the boxes.
Started night with: LUCI1 & None. We focused/collimated - but seeing was bouncing around from 1.2"...2.0"
At the start, the PCSInstrument.conf has:
LEFTZEROPOINT 29.03 (original 27.63 + the 1.4 deg offset measured last week from slitscan data)
RIGHTZEROPOINT 26.85 (we have a set of transform data for this; perhaps we need to rotate 0.4 based on slitscan data)
Seeing is not stable. With SX, they closed the loop, but it is not quite within the LUCI-AO criteria right now.
02:50: DGH reconfiguring to MODS1 & MODS2. (Doug was able to set the DX secondary, and it behaved all the while, until 07:00 when we switched to LUCI1.)
02:56, Will try MOS alignment first. Note that we think we corrected LEFTZEROPOINT based on 20161011 slitscan data, but had not had time to check last Monday. (And we saw that after entering an offset of ~1.4 deg, the slitscan data did not change much, so it really needs confirmation).
02:56, DX is alive. So we'll try binocular alignment.
03:07, Preset to bright star near first target, but cannot see it in either guidecam. Looking up IE/CA values from last time MODS was used. No star, but we see some passing by as we offset, so at least the MODS2 guide camera is working after the change made this afternoon to the gain (1->10). Spiral searching. Star found on DX 03:24. SX guide probe was at park position. (not sure why it was at park even when the preset was sent).
03:28 Resent preset. Good! Stars on both MODS1 and MODS2 guiders. Focus on 13.1 mag star. Guide images just peak around 7000 counts.
03:40 acqBinoMODS mods.36.StoneO.acq <br/>
MODS1 Offset Command:
offsetpointing -1.5546 -9.280 -0.153 detxy rel
Send the offset to the Telescope (Y|N)?: y
Sending MODS1 offset...
** ERROR: You did not specify which MODS Instrument to use
--mods1 = send command to MODS1 (alias: -m 1)
--mods2 = send command to MODS2 (alias: -m 2)
Offset command returned error - /home/MODSeng/bin/modsAlign aborting
MODS1: -1.5546 -9.280 -0.153 detxy rel (so we did the wrong thing by changing the rotator zeropoint last week)
4: stars in upper left corners
MODS2: offsetpointing 0.0725 -4.908 -1.318 detxy rel
mods2Align... 4: forgot to send offset
5 looks OK
04:05 Slitscan: No change yet to PCSInstrument.conf. Repeat slit scan to check and see whether it gives results similar to modsAlign.
1r: 5=slit 6,7,8,9,10
2r: 6=slit 7,8,9,10,11
Slit is -0.445+/-0.000 degrees CCW from the Y axis
-2.948+/-0.006 degrees should be added to the current rotator zeropoint
Currently at 29.03. Subtract 2.95 -> 26.08.
Edit PCSInstrument.conf to change LEFTZEROPOINT 26.08
MODS2: -0.35 deg. Currently 26.85. Subtract 0.35. -> 26.50
Edit PCSInstrument.conf to change RIGHTZEROPOINT 26.50
With these two changes, repeat the scripts:
execBinoMODS Stone0gs1224_slit_act.img ... this time with 0.8" slit instead of 0.6" one (but these slits overlap well).
1r: 11=slit 12,13,14,15,16
2r: 12=slit 13,14,15,16,17
Line of star centroids is -3.379+/-0.004 degrees CCW from the Y axis
Slit is -0.432+/-0.000 degrees CCW from the Y axis
-2.947+/-0.004 degrees should be added to the current rotator zeropoint
Slit is 0.141+/-0.000 degrees CCW from the Y axis
-0.710+/-0.001 degrees should be added to the current rotator zeropoint
Changes made to PCSInstrument.conf apparently are not being accepted when we restart PCS...
compare m1list.fits and m1list2.fits in /scratch/20161018/ (these are the combined field images)
But, John confirms that they are --- he sees the change in the log. So is there something wrong with the slitscan method?
Now try a MOS acquisition to see what it says:
05:15 acqBinoMODS mods.36.StoneO.acq
MODS1: offsetpointing -1.6557 -9.748 -0.455 detxy rel
needed an additional offset +1 -2 and stars appear more or less centered in boxes on 20
MODS2: offsetpointing 0.2142 -6.045 -1.595 detxy rel
confirm image is 20, however, I ran modsAlign on these two images twice:
modsAlign mods.36.StoneO.mms mods2r.20161018.0018.fits mods2r.20161018.0019.fits
John found the problem with PCSInstrument.conf --- one must be careful when making comments! Spaces between the # and the parameter name can mess things up.
We also noticed a problem with pointing origin:
For MODS1, we have to give dx -9.5" or about -5.8mm (-9.2/1.6) to move the stars to the boxes,
and for MODS2: -6" (-3.75 mm) and -1.6 (-1mm)
John is entering these new pointing offsets in PCSInstrument.conf (pointing origin) and changing
right zeropoint back to 26.85 while
left zeropoint still at 26.03
05:50 David restarting PCS and GCS.
acqBinoMODS mods.36.StoneO.acq --- no star found.
05:54 David restarting PCS again. Checking pointing.
06:01 acqBinoMODS mods.36.StoneO.acq
m1r: 21 and 22
m2r: 21 and 22
06:05: copied ~modseng/bin/modsAlign and ~modseng/bin/modsAlign_exp to my working directory and edited modsCmd lines to add --mods1 or --mods2.
lbto@obs4:51 % ./modsAlign_exp mods.36.StoneO.mms mods1r.20161018.0021.fits mods1r.20161018.0022.fits
offsetpointing -1.6282 -0.293 -0.270 detxy rel
confirm: 23 --- still stars are in upper left,
manually make an offset +1, -2 and take an exposure
lbto@obs4:52 % ./modsAlign_exp mods.36.StoneO.mms mods2r.20161018.0021.fits mods2r.20161018.0022.fits
offsetpointing -0.1451 1.515 -0.608 detxy rel
24... looks bad - stars not well aligned in boxes
give rot offset -2*dtheta = +0.29
25 --- looks better.
Blinking mods1r 21 and 22: stars need to move ccw. Need to add 1.6 to rotator zeropoint.
John adds 1.61 to 26.03 ---> 27.69 LEFT ROT ZEROPOINT
and subtracts 0.145 from 26.85 ---> 26.7 RIGHT ROT ZEROPOINT
New field: StoneA
MODS1 Offset Command:
offsetpointing -0.1520 6.361 -1.985 detxy rel (this should move stars CCW)
MODS2 Offset Command:
offsetpointing -0.1334 0.640 -0.383 detxy rel (this should move stars CCW)
John changes pointing origin for MODS1: +3.9, -1.2
m1r: 29 --- stars are now on boxes
Now we give detxy pa offset of 10 deg to both mods1 and mods2 and take a 20-sec snap:
both star fields rotate CW with +theta offset.
In detxy system: +dtheta moves stars CW. So the -dtheta indicated by modsAlign
should rotate stars CCW.
If modsAlign makes a (CCW) -dtheta offset to align stars on boxes, and the fact that a line of stars needs to rotate CCW to line up with slit implies a +dtheta offset needed to the rotator zeropoint, then the right zeropoint 26.85 is good for MODS2 and the left zeropoint 27.69 is good ... but 27.84 would even better...
In conclusion, I think if we cannot obtain data for a transform, we can restore left zeropoint to 27.63 (from 27.69) and use the existing transform, and we can revert right zeropoint to 26.85 (from 26.7) and use the transform (as yet to be computed) from the data we collected on 20160318 (albeit using mods2b and g_sdss).