Subject: Re: [infrastructure 12098] Re: [sloan-25mlog 2294] Re: 2.5m obslog 20150507 (SJD 57150) From: Paul Harding Date: Fri, 8 May 2015 18:00:20 -0400 See comments below. On May 8, 2015, at 5:00 PM, Kaike Pan wrote: >=20 >> On May 8, 2015, at 2:28 PM, John K. Parejko = wrote: >>=20 >> On 8May 2015, at 12:06, Joseph Huehnerhoff = wrote: >>=20 >>> I was also online initially for the pointing model. It was only = after midnight PDT that I logged off and was then called shortly = thereafter. As part of the pointing model work that JohnP was doing I = was giving him some backup by working on the instrument block routine. = I think I have Russell=92s programming now operational so that we can = feed it rotational and positional data and create an instrument block. = =46rom the log I cannot determine if the necessary data was taken to = verify these code. If it was not taken then it will need to be added to = the next engineering run. >>=20 >> Yes, it would have been good to have more information in the log = about the steps we were able to accomplish toward the new pointing = model, even if I didn't take a full pointing model. This was a good = portion of the night (after Tracy resolved the rotator problem), so = something more than my one sentence comment was necessary, particularly = since there were several steps that the observers performed that I = couldn't follow. >>=20 >> To that end, I'll add a few comments: >>=20 >> * Early in the morning, just after we got focused, the Az halted and = I didn't hear why or how it was resolved: >>=20 >> 10:15:43 APO.gfreischlad: az not tracking >>=20 >> * I've worked through the Pointing Model instructions, and updated = them as we went along. They're not complete yet, but many of the old = commands have been replaced with the new commands (whose names may = change again as I work on the code). >>=20 >> https://trac.sdss.org/wiki/APO/Observatory/sdssProcedures/PointModel >>=20 >> * The new guider code returns correct FWHM values of the brightest = fitted star as calculated by PyGuide, and I've adjusted Elena's = ecamFocusSweep STUI script to incorporate this information. This should = make focusing the ecam a trivial process: a large step focus sweep to = get close, then a narrow one to hit optimal focus. A little work could = probably even make it fully-automatic with a bare handful of focus = exposures, which would definitely reduce the time to focus from the = 20-30 minutes it took us, possibly to 5 minutes or less. >>=20 >> * The observers did take ecam rotation data and calculated the = average pixel positions (via what method I'm not sure). The first time = we tried to rotate, the star went off the frame: Do we know why, and = what happened to fix that? Once the images for the axis rotation were = acquired, Kaike commented: >=20 > No star was found due to AZ halt during the slew.=20 >=20 >>=20 >> 10:33:48 APO.kpan: The center change 2 pixel in X, 7 in Y. Instrument = block is edited and loaded.=20 >>=20 >> I assume this is with regard to the non-centered position that the = star was in in the first place? Do we know why the "center" position of = the ecam is actually not the center of the camera? It probably doesn't = matter to the final results (assuming we know the exact center), but it = would be good to understand. >=20 > Current imager center is at (602, 512). So X is slightly off from the = center of the chip, (512, 512). My understand is due to tilts applied = during the telescope collimation. I think that we could have the center = of the camera to be at the center of the chip by generate a new = instrument block (after telescope optical collimation). No, center off = will not affect pointing models as long as they are not off that much. = In fact, most pointing models were taken with image > centers at (590-620, 500-520).=20 Is X the axis of the engcam the aligned with the stage motion or = orthogonal to it? The endstop/home position may need adjusting if it is. 602 vs 512 is only 1.2 mm so not easy to gauge on the cartridge. Just to = be paranoid can some one double check that nothing is lose on the engcam = mounting and also do a test that homing the stage physically puts the = camera in the same place.=20 Does the physical home position repeat if the homing is done at = different Alt AZ. The mounting carts are supposed to repeatably to an arc sec or so. The center of the rotator axis should be the optical axis of the = telescope. In layman's terms the instrument block relates egncam coords = to distance from the rotator axis. >=20 >>=20 >> * Given the above time stamp, the ecam images at 90=BA rotations = should be ecam frame numbers 170-175. We did not take images on a = positional grid, sorry Joe. Can you at least use the rotation images for = an initial test of the instrument block generator? Also, Elena has a = script called "ecamGridTest" that may be useful for this in the future, = though we'll have to see exactly what the instrument block code needs, = plus update the script with the new guider commands. The wiki has = instructions about this, which I didn't touch except to replace outdated = commands: >>=20 >> = https://trac.sdss.org/wiki/APO/Observatory/sdssProcedures/PointModel#Check= OpticalAxisPositiononCCD >=20 > If I remember correctly, frame 270-173 corresponds to obj rotate angle = of 0, 90, 180, and 270. In principle, we could fit the date in the = instrument fit code as the ring data (generally ring data requires data = each 30 degrees or so instead of 90 degrees we have).=20 Its important to do the grid and rotation tests well away for the zenith = so that the tracking errors don't contribute to these measurements. >=20 >>=20 >> On to the pointing model itself, taking the last >=20 >> 11:19:41 APO.parejkoj: This would be easier if I were less dumb, and = less tired. >>=20 >> * I used Russell's Pointing Data STUI script, which was modified from = the 3.5m version, to attempt to take a 20 star pointing model. Many = thanks to Russell for being online and providing me with a function from = the 3.5m TUI that was missing in SDSS's opscore. I don't know what = interface the observers used before, but Pointing Data is quite nice: = shows a planisphere-like view of the path it will take on the sky, with = the current position marked, and allows for user-intervention if a star = isn't found. >=20 > Yes. I read the instruction for 3.5m pointing model and watched it = once. The interface is much nicer.=20 >=20 >>=20 >> * I was able to get Pointing Data to see the guider's fitted star = locations, but was not able to get the script to do all the necessary = steps for a single star. I think I just need to remove some more 3.5m = stuff from the script, since "guider findstar" does most of the things = that the 3.5m findstar + centroid did. I'll probably consult briefly = with Russell on this in the next week or two, if I can't sort it out = myself. As I said to the observers: >>=20 >> 11:42:14 APO.parejkoj_2: I'm quite sure I'd have at least gotten a 20 = point model if we hadn't had the trouble with the board. A few hours = earlier in tiredness and an hourish of debugging would have sorted this = out. >>=20 >> * Once I work out the last bugs (I should have enough ecam data to = run the simulator and fake things), Pointing Data will be included in = the next STUI release. I'm positive that we will be able to take a model = with a minimum of fuss during June engineering. >>=20 >> I will leave you with the following wise comment, just before I = turned in for the night: >>=20 >> 11:39:51 APO.parejkoj_2: As I've said before: my code always works = when I've written tests for it. Corollary: my code never works when I = haven't written tests for it. >> 11:39:57 APO.parejkoj_2: Guess which situation we're in here.. >> 11:40:04 APO.parejkoj_2: You can quote all that in the logs. >> 11:40:24 APO.gfreischlad: Haha >> 11:40:30 APO.parejkoj_2: It is absolutely true. >>=20 >> Cheers, >> John >>=20 >>>> On May 8, 2015, at 5:11 AM, viktorm@apo.nmsu.edu wrote: >>>>=20 >>>>=20 >>>> APACHE POINT OBSERVATORY SDSS 2.5M >>>>=20 >>>> OBSERVING LOG >>>> Thursday May 07, 2015 >>>>=20 >>>> (SJD 57150) >>>>=20 >>>> ---- Observing Team ---- >>>>=20 >>>> Gordon Freischlad >>>> Viktor Malanushenko >>>> Kaike Pan (pointing model support) >>>> John Parejko (pointing model support) >>>> Russell Owen =20 >>>> Joe Huehnerhoff (online for the rotator problem) >>>> Tracy Naugle (drove to the site for the rotator problem) >>>>=20 >>>>=20 >>>> ---- Observing Summary ---- >>>>=20 >>>> Clear sky all the night >>>>=20 >>>> MaNGA >>>> ----- >>>> ct=3D1, pl=3D8318; Field name: MJ196.72787+46.08353; M: 2xNSE; A: = 3xABBA; >>>> M: done; A: missing fibers 195,258,259; >>>>=20 >>>> At 4:51Z we mounted eng.camera; JohnP tested the new guider code = with new tcc. >>>> "... I was able to run the new Pointing Data STUI script, and it = moved the >>>> telescope and took images, but I still need to debug how it gets = the values from >>>> the guider." >>=20 >>=20 >> -- >> ************************* >> John Parejko >> john.parejko@yale.edu >> http://www.astro.yale.edu/~jp727/ >> 203 432-9759 >> JWG 465 >> Department of Physics >> Yale University >> New Haven, CT >> ************************** >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> ____________________________________________________________ >> Logs of Nightly APO Activities >> = https://trac.sdss.org/tracmailman/browser/private/sloan-25mlog/index.html >=20 > ____________________________________________________________ > Common APO Hardware and Software > = https://trac.sdss.org/tracmailman/browser/private/infrastructure/index.htm= l