Restart Night #5 UT 2018-09-06

OSA: D.G. Huerta

Observers/ISA: B. Rothberg, J. Hill (Tucson)

Software: P. Kubanek

ISp: J. Riedl, G. Bechetti

Mtn Manager: J. Prothro

Details

UT 02:05 - Closed for clouds

UT 02:18 - LBCs powered up, taking 25 biases, LUCI software up, test darks taken

Offline work with GCS - closed dome

Petr has patched GCS (20180906) so that we are able to have GCS process old wfs images from the command line. We used the patched version of GCS all night.
gcsclient processWFSImage [left|right] left_wfscimagexxxxxx.fits

The associated .info file will be overwritten, but FITS header parameters are not modified. Take care that the path to the FITS image is one that can be seen by GCS from the tcs machines (e.g. /lbt/data/share/tcs/user.date). Operational parameters such as rotator angle and probe position come from the FITS header while configuration parameters come from the config file (e.g. LUCI_L.cfg).

gcsclient processWFSImage left /lbt/data/share/tcs/lbto.20180906/left_wfscimage000160.fits

Compare with IDL wfsc_process_file, '/lbt/data/share/tcs/lbto.20180906/left_wfscimage000160.fits' . Take note that IDL reads the GCS Zernikes from the .fits file and NOT from the .info file (which it did sometime in the past). Doug still uses the existence of the .info file in wfsc_process_file as an indicator that GCS has processed the image.

The first important closed-dome result is that changing WFScam_hotspot_sext_x,y changes the resulting Zernikes from GCS - where we previously thought that this config variable was not used. And, making WFScam_hotspot_sext_x,y be the same number as WFScam_hotspot_x,y as we had yesterday is not the correct answer. We (John, Petr, Doug) are still searching for what the correct answer is. Also, it is WFScam_hotspot_sext_x,y that is written to the wfsc FITS header as PUPXONAX which is later displayed by IDL as "On-Axis Pupil". The thing that I have not yet succeeded at is to get GCS offline to reproduce the same results it did online last night. That is because the rotation of the Zernikes is different:

Online - equivalent angle 172.22
2018-09-05T07:56:18.740904+00:00 tcs1 LBT_GCSL: AGWUnit: getRotatorAngle: from mcs.rotatorSide[0].rotators[2].actualPositionASec is 193.78 degrees
2018-09-05T07:56:18.740911+00:00 tcs1 LBT_GCSL: WFS: rotator angle mcs.rotatorSide[0].rotators[2].actualPositionASec reported to be 193.78 degrees
2018-09-05T07:56:18.740939+00:00 tcs1 LBT_GCSL: WFS: triggerWFS: rotating Zernikes by 1.000000[rotDir] * -187.778732[rotatorAngle] + 1.000000[probeRotFactor] * -0.002038[probeRot]
2018-09-05T07:56:18.740947+00:00 tcs1 LBT_GCSL: WFS: Zernike rotation by -187.78 degrees

Offline using the FITS header rotator angle (which doesn't seem to be the only angle in the calculation)

2018-09-06T05:07:26.357280+00:00 tcs1 LBT_GCSL: AGWUnit: getRotatorAngle: from mcs.rotatorSide[0].rotators[2].actualPositionASec is 193.78 degrees
2018-09-06T05:07:26.357287+00:00 tcs1 LBT_GCSL: WFS: rotator angle mcs.rotatorSide[0].rotators[2].actualPositionASec reported to be 193.78 degrees
2018-09-06T05:07:26.357293+00:00 tcs1 LBT_GCSL: WFS: triggerWFS: rotating Zernikes by requested angle of 193.778732 deg
2018-09-06T05:07:26.357299+00:00 tcs1 LBT_GCSL: WFS: Zernike rotation by 193.78 degrees

Offline with a modified FITS header rotator angle and live rotator moved to 210 degrees. This matches the online Zermikes.

2018-09-06T05:57:43.365942+00:00 tcs1 LBT_GCSL: AGWUnit: getRotatorAngle: from mcs.rotatorSide[0].rotators[2].actualPositionASec is 209.99 degrees
2018-09-06T05:57:43.365949+00:00 tcs1 LBT_GCSL: WFS: rotator angle mcs.rotatorSide[0].rotators[2].actualPositionASec reported to be 209.99 degrees
2018-09-06T05:57:43.365956+00:00 tcs1 LBT_GCSL: WFS: triggerWFS: rotating Zernikes by requested angle of 172.220000 deg
2018-09-06T05:57:43.365962+00:00 tcs1 LBT_GCSL: WFS: Zernike rotation by 172.22 degrees

The live rotator angle is written in the .info file as ROTANGLE, while the ROTANGLE from the .fits header is written as ZERNROT. My TEMPORARY fix to the rotation issue is to manually change the ROTANGLE in the FITS header.

Open/Close

06:10 We opened for a few minutes, but then another chunk of heavy clouds forced us to close before doing anything. We are sitting just on the boundary of the outflow from a huge complex of thunderstorms in Mexico.

Wierd bug in GCS

07:18 Changing to this hotspot configuration makes GCS complain that image is saturated (in a repeatable way). (and shifting the y value does it, even -1 pixels does it, but +1 doesn't)

WFScam_hotspot_x        174.7           double  # ccd x coordinate of pixel that represents x-center of WFS spots (20170222 DLM)
WFScam_hotspot_y        214.6           double  # ccd y coordinate of pixel that represents y-center of WFS spots (20170222 DLM)
WFScam_hotspot_sext_x   170.7           double  # ccd x coordinate of pixel that represents lower leftmost x-center of WFS spots (20120204 DLM)
WFScam_hotspot_sext_y   218.6           double  # ccd y coordinate of pixel that represents lower leftmost y-center of WFS spots (20120204 DLM)

The spots are in fact mostly shifted off the subimage when you display them in ds9! This is new IT 7388.

Despite the above wierdness, both WFScam_hotspot_x,y and WFScam_hotspot_sext_x,y influence the GCS answer. Yet Doug only has one of them in IDL. ????

; AGw#4@LFBG (IDL configuration in agw_define.pro)
            agw_params[i].wfsc.pupil_x_on_axis = 170.7 ; DLM 20180904 
            agw_params[i].wfsc.pupil_y_on_axis = 218.6 ; DLM 20180904
            agw_params[i].wfsc.x_pupil_shift_direction = -1.0
 (GCS configuration in LUCI_L.cfg)
WFScam_hotspot_x        170.7           double  # ccd x coordinate of pixel that represents x-center of WFS spots (20170222 DLM)
WFScam_hotspot_y        218.6           double  # ccd y coordinate of pixel that represents y-center of WFS spots (20170222 DLM)
WFScam_hotspot_sext_x   170.7           double  # ccd x coordinate of pixel that represents lower leftmost x-center of WFS spots (20120204 DLM)
WFScam_hotspot_sext_y   218.6           double  # ccd y coordinate of pixel that represents lower leftmost y-center of WFS spots (20120204 DLM)

Here's the section of the log where subimage creation seems to go wrong. Note the 100-digit number in the log message.

2018-09-06T07:33:36.692351+00:00 tcs1 LBT_GCSL: WFS: findSpots: resulting hotspot 171.00, 12982841790010544142837397323041263358931100792016517331777003474038567211884785906890768099304040471007247522386538201999605652742460976982726289316649376964124082176.00, indices 0 -4
2018-09-06T07:33:36.692358+00:00 tcs1 LBT_GCSL: WFS: setSubAps: subAp grid rotation: 0.00 [degrees]
2018-09-06T07:33:36.692416+00:00 tcs1 LBT_GCSL: WFS: findSpots: mvSubImageXY (81, -90, 260, 89).
2018-09-06T07:33:36.692423+00:00 tcs1 LBT_GCSL: WFS: findSpots: mvSubImageXY (81, 1, 260, 180), shifted 0,-91 pix.
2018-09-06T07:33:36.692429+00:00 tcs1 LBT_GCSL: WFS: findSpots: createSubImageXY (81, 1, 260, 180).
2018-09-06T07:33:36.692434+00:00 tcs1 LBT_GCSL: CamImage: createSubImageXY(81 1 260 180)
2018-09-06T07:33:36.718606+00:00 tcs1 LBT_GCSL: WFS: findSpots: GUI subImage filename = /Repository/GCSfiles/dailyimages/left_wfscsubimage000052.fits

To see all of the cases of subimage creation, do something like this: grep createSubImageXY /lbt/log/current.log -A 1 -B 4

07:51 stop/start GCSL -- the subimage problem remains.

Open

08:20 Opening as the sky is finally clearing.

AGw4 Collimation

08:39 changed WFScam_lenslet_edge_x from 167.7 to 170.7 pixels and this changed the SH_YAVE value (seen in wfsc FITS headers); or was it a random guiding fluctuation?

08:42 changed WFScam_lenslet_edge_x,y to 167.7, 248.7 - this seems not to inlfuence SH_XAVE, SH_YAVE

08:46 changed WFScam_hotspot_sext_x from 170.7 to 173.7 pixels.

08:52 changed WFScam_hotspot_sext_x,y from 173.7 to 174.7, 218.7 to 220.7 - that seems to be too much.

08:55 changed WFScam_hotspot_sext_x,y to 173.0,218.0

gethead left_wfscimage.fits SH_XAVE SH_YAVE*

left_wfscimage000082.fits 0.049004043588216 -0.15578821310831 - the decent result, and the Zernike amplitudes look more normal.

08:56 Send Zernikes from GCSL to PSFL - it still runs away (frown). Block Zernikes again and clear active optics in order to proceed to other work.

Guide Probe Alignment to Rotator Center

SX Guiding Hotspot is 273,247 pixels

(following the procedure in BGTechProcedures, so wiki notes don't show every step)

09:02 SX wfsc image 000001 center is -30,131 ---> -60,262 ----> -15,301

correction in pixels X +288   Y -54
correction in arcsec +14.4 -2.7
correction in mm 8.64 -1.62

ssh oac@oac; cd /lbt/oacontrol/current/etc/; edit oacontrol.conf

stop /restart GCSL

09:23 ACQUIRE preset

09:34 SX wfsc image 000004 slightly elliptical 100.5,104.5 ---> 201,209 ---> 216,248

correction in pixels +57,-1
correction in arcsec +2.85 0
correction in mm 1.71 0

#homeoffset=79848,&1Q40  (previous value from 2009)
# 20180906 @ LFBG JMH   
homeoffset=79145,&1Q40    (tonight's value)

DX guiding hotspot is 275,243

09:40 DX wfsc image 000002 nice circle 130,116.5 ---> 260,233 ---> 275,272

correction in pixels  0,-29
correction in arcsec 0,-1.45
correction in mm 0,-0.87

increase RAD ooffset by 870 microns on AGW2
                       
# JMH/DLM 2015-10-27
#ooffset=418322,&1Q37
# 20180906 @RFBG JMH
ooffset=419192,&1Q37

Install the final corrections later while LUCI is doing dfithering tests. (done)

LUCI wake-up dither tests

09:48 ACQUIRE BS9105

Collimating intermittently with IDL on SX, but pupil shift direction may be wrong - this dithered data also provides wfs pupils to check the pupil shift. The wfs images have been moved to /home/lbto/data/20180906_lfbg

10:07 corrections completed to oacontrol.conf, awaiting restart of GCS.

UT 10:13 - M74 test, dithering off source and 75" dice-5 on-source

UT 10 19 - running through a few filters on both LUCIs - J. Hill is collimating LUCI-1/SX with IDL - not doing so well though

UT 10:24:30 - DX Guider jumped 3" - don't know why

UT 10:29 - LUCI-1 data is useless -pure exercise of mechanisms, but LUCI-2 data is 0.5"-0.7" seeing - can make nice mosaic

UT 10:36:24 - return from large offset - 3" jump - possibly timing problem, it starts guiding before offset complete?

UT 10:39:20 - return from large offset ~1.5" jump - seems to confirm that the mount doesn't get back to the new position before guiding resumes

M74/NGC 628 data - luci2.20180906.0003-0029 (5 pt dither, 4 offs in between, J, H, and K)

UT 10:44 - Reconfiuring for LBCs - LUCIs in safe mode

LBC Dither Wake-up Tests (NS tests)

will do another pass on 2017_WV13 - will turn off guiding LBC GUI

UT 11:16 - sending co-point for 2017_WV13 - but got co-pointing error

UT 11:19 - tried CP_2017WV13_test.xml - which worked 2 days ago (made correction to PM = 0) - still get co-pointing error

UT 11:22 - re-authorizing LBCs seem to have fixed it - running DOHYBRID

UT 11:36 - almost 2 degree difference between mirror and ambient, added +1000 Z11 to try and improve collimation (DX)

UT 11:38 - added -1000 to Z8 lots of coma on (DX)

UT 11:41 - added +1000 to Z7

UT 11:44 - backing out with "S" and going to clear active optics on DX

UT 11:45 - redoing DOHYBRID

UT 11:52 - adding +1000 Z11 to try and "unpinch" the hole DX

UT 11:54 - adding another +1000 Z11 DX

UT 12:00 - stopping DOHYBRID again, Z11 keeps going negative no matter how I try to stop it

UT 12:01 - attempting to co-point, collimation might be terrible - if this doesn't work then I will wait and take skyflats

UT 12:04 - completely out of focus on SX - giving up on this, I'm going to sit and wait for skyflats

UT 12:18 - B and z skyflats PA=0 first exposures 2k, <1k, because scale =1 not 5 (which worked)

UT 12:21 - B and z skyflats PA=0 (scale 5)

UT 12:25 - Bs probably saturated at end of 5 (last 2?) - sloan z looks good

UT 12:26 - B and z skyflats PA=180 (scale=1) - both look good

UT 12:31 - g and i skyflats PA=180 (scale=1) - g's are saturated, i's are saturated - aborting sequence

Close

UT 12:35 - closing up - will do LUCI cals (JHK imaging at least) after - powering off LBCs

UT 12:38 - luci2.20180906.0030-0031 - 2x10 sec darks (for badpixel masks)


luci1/2.20180906.

0032-0036 - J flats lights off

0037-0041 - J flats lights on

0042-0046 - H flats lights off

0047-0051 - H flats lighs on

0052-0056 - K flats lights off

Looks like the AGWs are still in their last position (blocking the field) - DO NOT USE THE ABOVE CALS


Trying this again:

luci1/2.20180906.

0057-0061 - J flats lights off

0062-0066 - J flats lights on

0067-0071 - H flats lights off

0072-0076 - H flats lighs on

0077-0081 - K flats lights off

0082-0086 - K flats lights off

UT 01:10 - Putting LUCIs in to safe state - done for night
Topic revision: r9 - 23 Jan 2019, JohnHill
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback