Subject: 51630 26Mar00 SDSS nightlog Date: Mon, 27 Mar 2000 06:11:22 -0700 (MST) From: sjnk@apo.nmsu.edu (Scot Kleinman) Subject: 51630 26Mar00 SDSS nightlog APACHE POINT OBSERVATORY SDSS 2.5M OBSERVING LOG Sunday March 26 2000 (MJD 51630) OBSERVING TEAM: =============== Ellyne K. Kinney 1st shift (APO) PI tonight. Jeffrey Hayes 1st shift (APO) Scot Kleinman 2nd shift (APO) Atsuko Kleinman 2nd shift (APO) Visitors: Robert Lupton (PU) Jim Gunn (PU) THE PLAN: ========= For the first part of the night, 2 spectro plates. In the second half, if the weather co-operates, put the imager back on and try testing the auto- lskip code fixes. (A repeat of last night.) SYNOPSIS FOR NIGHT: =================== During the afternoon, Ellyne and Robert tested the MCP and TCC. (Encore!) When requesting new plates to be plugged, we are to prioritize for plates of numbers greater than 260. One plate (266) finished; one plate exposed after its prime and with moon. One sd1 crash. Imager exercised. TELESCOPE STATUS: ================= Imager mounted. Corrector on cartridge in "dome". DIMM: ----- 22-24:00 ~1/5" thereafter ~1" INTERLOCKS: ----------- None bypassed. SOFTWARE USED: -------------- IOP/SOP: v3_12_2 Watcher: v2_8_2 MCP: v4_1_4 TPM: v1_0_4 WEATHER SYNOPSIS (see below for hourly data): ============================================= Fair to partly cloudy and cool at 17:00. Nicely clear by 20:00, but still some scattered clouds, increasing as the night progressed. GENERAL COMMENTS (see Problems below for details): ================================================== We took the imager off starting at 16:30, and had the corrector and cartridge on by 17:15. We were fiducialized and did the LN2 refill for the spectrographs by 19:30 or so. At 23:00, we had a problem with trying to get the spectrographs to take spectra -- it appears that the sd1 crate died in a weird way. We called Ron R., and he was puzzled but happy for a new and unusual problem. We rebooted the crate and soldiered on. After we finally got an exposure, the "Flavor of this image" question kept scrolling by a few zillion times until we hit ctrl-C. Once we ctrl-C'd though, the exposure never read out. We then did an endStare -abort which reported success, but a subsequent goStare -init failed due to a supposed exposure still in progress. A cameraAttachLog revealed an exposure still present from much earlier in the night (the previous plate). We then stopped the guider, exited out of sop completely and started them up again, with a new initNight and -init bias frame. All worked well, but we had to do a new starPattern of course and guiderFlat. We started a new 900s exposure at 01:15. Since the DIMM was reading ~1", we thought this would be a good chance to do some imager tests in good seeing. (The 3.5m however, was getting ~2" seeing - as were we with our last spectro plate). We had the imager mounted and ready to roll around 02:30. We had previously started a bias and found id5-2 couldn't read the ID or something, so it stopped archiving. id5-1, however, worked fine, so we kept going with the bias and archiving. Once we got the camera mounted, however, we put in a new tape in id5-2 and followed the sdsshost da procedures to enable id5-2 for the star drifts. This worked fine, but at the end of the night, we got new errors for id5-2. At 02:45 we started the drift on 36N lambda 6, and didn't see many stars, so we opened the flatFieldScreen via SOP and saw stars for about 5 minutes until the screen closed itself. We then reopened it with SOP and this time, it stayed. (At the end of the night, we issued a SOP flatFieldScreen close command which was accepted, but we later noticed the screens were still open. We don't know if the screens first closed, then opened again, or it they never closed the first time.) Only one of the several needed corrections got added to autoLskip in 3_12_2, so we sourced ~sjnk/finder.tcl to play with autoLskip a bit. During one autoLskip, we got the following: im> autoLskip doing the lskip now nPeaks=374 at thresh= 1568 Continue? [y]: nPairs: 72 CAMERA: FAILURE on ftelnet: connection error in ftelnet: connection refused I cannot get the current linestart rate (Telnet to camera failed: connection error in ftelnet: connection refused while executing "ftelnet $cameraConnectTime $retryDelay $tries $latNode $portNum" invoked from within "set camera($cameraName) [ftelnet $cameraConnectTime $retryDelay $tries $latNode $portNum]..."); using old rotator move: degrees = -0.027 +- 0.036 linestart multiplier at 16 skips: 0.9998 old: 26322 # microseconds new: 26316 +- 45 im> After a few autoLskips, the clouds started getting worse. Incidentally, we did an offset rotator (in the TCC) of -0.020 then new autoLskips which indicated a rotator error of -0.061, then -0.047, both +/- 0.007. An offset rotator -0.05 then resulted in an indicated error of -0.004 +- 0.005. Repeated attempts gave similar results except for one which said +0.018 +- 0.004. It looks like the TCC offset rotator command takes a while to complete - or maybe it's we have to wait a minute or two longer to make sure that part of the chip has read out already - so we need to wait a while after an offset rotator before issuing a new lskip. This probably explains our triple lskips we had seen earlier. After all this fun, we wanted to do some more tests (focus scan and short drifts in lots of stripes), but we were told all these required good or better seeing and we were still only getting 2" fwhm images, even though the DIMM was still reading 1". (Yes, the focus loop was on and looking good; we were at an alt of 60deg and an HA ~1.) The clouds were also getting thicker. We decided to go to an HA of closer to 0 on the same stripe, so went to 36N startLambda=29. This resulted in an alt of 70 deg and HA of ~0. Seeing was the same; needed offset rotator was about -0.08. To experiment with eqToSurvey, stripeNumberFromEta, etc., we found a new stripe to go to: 39N startLambda 23. This resulted in an HA of 4deg and an alt of ~62deg. This stripe also wanted a -0.080 rotator offset. So, it looks like we can make these offsets calib offsets and be more or less OK for at least other nearby stripes. We ran endNight 51630 -doSpectro from IOP without any problems. The imager tapes were sent to recycling. DATA ACQUISITION (see IOP/SOP output below): =========================================== IMAGING: -------- Run Frames Flavor Notes ... ...... ...... ..... 1291 bias 1292 engineering 36N startLambda=6 1293 engineering 36N startLambda=29 1294 engineering 39N startLambda=23 SPECTROSCOPY: ------------- Cartridge 5, plate 266 Best Focus = 1300 -- Declared done. ---------------------- Frame Notes expTime Flavor ..... ...... ....... ..... 3235 def bias 3236 okay def FF 3237 okay def HgCdNe 3238 okay 900 science 3239 okay 900 science 3240 okay 900 science 3241 okay 900 science 3242 okay 60 az DP+ 3243 okay 60 az DP- 3244 okay 60 alt DP+ 3245 okay 60 alt DP- 3246 okay def FF 3247 okay def HgCdNe Cartridge 7, plate 282 ---------------------- Frame flavor expTime Notes ..... ...... ....... ..... 3248 def FF 3249 def HgCdNe 3250 bias 3251 flat 3252 science 900 2 hours past "ideal time" 3253 science 900 2 hours past "ideal time" 3254-3247 diamondPoints 3258 flat 3259 arc science exposures not entered in log due to being observed past prime. Is this the proper procedure here? How much past prime time can/should we go? In this case, we had already done the setup stuff when things went wrong and we didn't think there'd be a whole lot of moonless night left if we mounted a new plate and did all the setup. MIRROR NUMBERS ============== Primary: setmir( cmd ): n/a galil( act ): 4850., -2350., 100., -9500., 50., -100. linear gauges Tonight Nominal 1 = Axial A = 1.9314 1.9315 2 = Axial B = 0.5564 0.5570 3 = Axial C = 0.5564 0.5570 4 = Transverse = 0.4089 0.4075 5 = East Lateral = 1.8985 1.8980 6 = West Lateral = 0.3989 0.3990 Secondary: ( inst=spectro focus=1300 alt=55.8 deg T=4.7 C) setmir( act ): 1331933., 1319032., 1308821., -700., -5350. galil ( act ): 1047.66, 4.98, -5.00, 50.24, -56.66 linear gauges 1 = Axial A = -1.1209 2 = Axial B = -1.0809 3 = Axial C = -1.0909 4 = Transverse = 0.0249 LN2 SCHEDULE: ============= Spectro dewars filled around 19:30 and 05:45. WEATHER DATA: ============= Wind Time Temp F Dewp F MPH Direction Dust Sky Precip. 16:01 51 7 23 301 (WNW) 376 pcl 17:01 49 5 10 281 (W) 341 " 18:01 49 7 13 277 (W) 455 " 19:01 46 9 19 292 (WNW) 461 " 20:01 46 10 16 308 (NW) 462 " 22:01 45 11 9 301 (WNW) 501 " 23:01 44 11 9 308 (NW) 523 " 00:01 44 11 16 353 (N) 539 " 01:01 43 14 19 1 (N) 553 " 02:01 43 14 12 4 (N) 595 " 03:01 43 12 18 15 (NNE) 589 " 04:01 42 11 11 20 (NNE) 594 " 05:01 42 11 12 359 (N) 651 " pcl=partly cloudy, mcl=mostly cloudy, tcl=totally cloudy PROBLEMS IN DETAIL =================== sop issues ---------- When trying to go a "guiderFocus" on the 2nd plate of the night, we obtained the following message: sp1> guiderFocus 1300 5 50 .2 2 Setting focus to 1150.0 Waiting for secondary to arrive Waiting 12500 msec for secondary to arrive (press cntrl-C to abort) /data/spectro/guider/gimg0784.fits Error: Star 7 won't fit in an 392*392 region, scaled 150 The traceback gave: sp1> tb Star 7 won't fit in an 392*392 region, scaled 150 while executing "error "Star $i won't fit in an $ysize*$xsize region, scaled $scale"" invoked from within "if [catch { set sreg [subRegNew $reg $star_ysize $star_xsize [expr $yc - $star_ysize/2] [expr $xc - $star_xsize/2]] }] { regD ..." ("loop" body line 24) invoked from within "loop i 1 12 { if {![info exists guiderData($i,reg)] || $guiderData($i,reg) == "NULL" || ![info exists gFiber(gprobe,$i,xpos)]} { ..." (procedure "mosaic_rotated_fibers" line 8) invoked from within "mosaic_rotated_fibers $reg $scale 0 0 5" invoked from within "return [mosaic_rotated_fibers $reg $scale 0 0 5]..." (procedure "show_rotated_fibers" line 7) invoked from within "show_rotated_fibers $scale $size $size $bkgd" invoked from within "set reg [show_rotated_fibers $scale $size $size $bkgd]..." (procedure "showGuideStars" line 45) invoked from within "showGuideStars 150 350 75 1 1" invoked from within "if {![info exists guiderInfo(simple)]} { showSimpleFrame } elseif {$guiderInfo(simple) == 1} { showSimpleFrame } else { showGu ..." (procedure "showGuiderFrame" line 4) invoked from within "showGuiderFrame" invoked from within "if $display { showGuiderFrame }" invoked from within "if [catch {set imageName [lastGuiderFile]} msg] { echo $msg return "" } elseif {$imageName == $guiderInfo(lastImage)} { return "" ..." (procedure "checkForNewImage" line 10) invoked from within "checkForNewImage 1 0" invoked from within "if {[checkForNewImage 1 0] != ""} { break; }" ("loop" body line 3) invoked from within "loop i 0 [expr $expTime * 1000 / $dTime + 15 ] { # wait for data after $dTime; if {[checkForNewImage 1 0] != ""} { break; ..." (procedure "exposeAndWait" line 8) invoked from within "exposeAndWait $expt " ("foreach" body line 28) invoked from within "foreach focus $focusList { echo "Setting focus to $focus" tccPut set focus=$focus # here we need to wait until TCC arrives ..." (procedure "guiderFocus" line 38) invoked from within "guiderFocus 1300 5 50 .2 2" It looked like the guider was hosed; we got a similar error last night when we tried to use the "fancy" guider. We also weren't getting the usual adornments to the guider image like the FWHM, counts, or the beloved efficiency meter. Already existing exposure: -------------------------- sp1> goStare 0 -init -bias PlateId [-9999]: 282 Mon Mar 27 00:51:19 MST 2000: There is an ongoing exposure on sp1. Error: There is an ongoing exposure on sp1 sp1> Modu="mir_Adjust"; Text="Cannot compute PrimOrient" sp1> endStare -abort Error: No exposure is in progress There might have been a nicer way out of this, but we wanted to get going, so we rebooted sd1 and did a new initNight and goStare -init and proceeded happily. DATA LOGS FROM IOP/SOP: ======================= Not available as this time.