Subject: Re: [sloan-25mlog 2504] Re: Fwd: Re: 2.5m obslog 20150819 (SJD 57254) From: Russet McMillan Date: Fri, 21 Aug 2015 15:26:15 -0600 Are you folks still using TPOINT? There's a useful trick for finding = bad measurements in pointing data. Tpoint will tell you what the worst = outlier is, but it tells you that after trying to do a fit, so it has = actually already incorporated that outlier into the results. You can = also look at how the points are distributed without fitting them, just = comparing against the previous pointing. For the 3.5m we typically find = that there will be an offset so the cluster of data points will be off = center, but they should be in a tight group and any point outside of = that group is a possible bad measurement. Or if the group is not so = tight, before any data fitting, that's another piece of information. To get plots without fitting the data, inside TPOINT: inmod indat use fix fit (then make plots and examine them) exit (do not outmod, it would be meaningless) This method might not really work if you already did outmod with the = fitted data, unless you can inmod the previous pointing model instead of = the new one. I usually do this as a check before doing the full model = reduction. I'm onsite this weekend if I can help. On Aug 21, 2015, at 3:03 PM, kpan@apo.nmsu.edu wrote: > Hi Connie and Dan, >=20 > I looked at the instrument block, didn't find anything suspicious = there. > The largest fitting error in altitude is 40 (was 30), and 90 in AZ = (was > about 70). >=20 > -kaike >=20 >> Has anyone tried looking at the new instrument block as the possible >> culprit? That was part of the discussion when this started but I = haven't >> seen anything about that since. >>=20 >> Connie >>=20 >> Begin forwarded message: >>=20 >>> From: Dan Long >>> Date: August 21, 2015 at 7:46:02 AM PDT >>> To: Kaike Pan >>> Cc: "2.5m_log" , Dan Long >>> >>> Subject: [sloan-25mlog 2502] Re: 2.5m obslog 20150819 (SJD 57254) >>>=20 >>> Hi Kaike, >>>=20 >>> While these errors might be larger than has been seen typically, = they >>> are not large enough to explain the residuals in the pointing model. >>> If the largest error is 30 ticks, this is less than half an = arcsecond >>> for azimuth and altitude, and just over half and arcsecond for >>> rotator. Rotator error is going to be a very insensitive function = of >>> pointing, especially when near the axis of rotation where the = pointing >>> data is taken. Ten ticks in altitude is about an eighth of an >>> arcsecond on sky. Fiducial errors would only impact acquisition = since >>> they are not used in tracking or guiding. >>>=20 >>> Cheers, >>>=20 >>> Dan >>>=20 >>>=20 >>>=20 >>>> On Aug 20, 2015, at 4:47 PM, kpan@apo.nmsu.edu wrote: >>>>=20 >>>> Hi Dan and Patrick, >>>>=20 >>>> I tried to identify the cause, but could not find any smoking gun. >>>> The plots looks normal except for slightly bigger scatters, no = obvious >>>> outlier or systematic trends. >>>>=20 >>>> The only thing off my head is that I do noticed that new fiducial >>>> tables >>>> have bigger fitting errors then they had. For example, in the past, = the >>>> fitting errors for rot tables have typical errors of 3 ticks for >>>> individual ID, and biggest one at about 10. In the new table = (include >>>> the one took a few days ago) has typical error of 15, the biggest = one >>>> of >>>> 30. >>>> The latitude table has 10 ticks bigger fitting errors too. But not >>>> sure >>>> how much worse pointing this could introduces. >>>>=20 >>>> Let's try the normal MaNGA and eBOSS observations tonight, and = check >>>> how >>>> good/bad the pointings are. Please keep eyes on MaNGA plate = guiding, >>>> and >>>> notice in the log if guiding is consistently off more than 2.0". >>>> Thanks, >>>>=20 >>>> -kaike >>>>=20 >>>>>=20 >>>>> APACHE POINT OBSERVATORY SDSS 2.5M >>>>>=20 >>>>> OBSERVING LOG >>>>> Wednesday August 19, 2015 >>>>>=20 >>>>> (SJD 57254) >>>>>=20 >>>>> ---- Observing Team ---- >>>>>=20 >>>>> Olena Malanushenko >>>>> Dan Oravetz >>>>> Kaike Pan (support) >>>>>=20 >>>>> ---- Observing Summary ---- >>>>>=20 >>>>> A few passing clouds at times, seeing generally >>>>=20 >>>>> Obtained a 20-point pointing model during some intermittent clouds >>>>> that >>>>> had a >>>>> resultant Sky RMS of 3". Then we moved on to the 155-point = pointing >>>>> model, >>>>> but >>>>> did not implement it because the Sky RMS was relatively large = (>5"). >>>>> We >>>>> will >>>>> wait further instructions from Kaike. >>>>>=20 >>>>> Notes >>>>> =3D=3D=3D=3D=3D >>>>> Roughly half a dozen times during the 155-point pointing model the = Az >>>>> and/or Alt >>>>> axes went out of closed loop. Once this was due to a star in the = DIMM >>>>> avoidance >>>>> region, but the cause of other events was not clear. >>>>>=20 >>>>> Az fiducials 15 and 27 consistently reported large errors. >>>>>=20 >>>>> When we tried to restart mcp via the MCP Menu (running from = sdss-hub), >>>>> it >>>>> produced an error message (see Log body), but didn't actually = execute >>>>> the >>>>> reset, >>>>> so we went down to the lower enclosure and manually toggled the = reset >>>>> switch. We >>>>> don't recall having this misbehavior when MCP Menu was running = from >>>>> sdsshost. >>>>>=20 >>>>> ---- Observing Plan ---- >>>>=20 >>>>=20 >>>> ____________________________________________________________ >>>> Logs of Nightly APO Activities >>>> = https://trac.sdss.org/tracmailman/browser/private/sloan-25mlog/index.html >>>=20 >>> ____________________________________________________________ >>> Logs of Nightly APO Activities >>> = https://trac.sdss.org/tracmailman/browser/private/sloan-25mlog/index.html >>>=20 >>> !DSPAM:10028,55d739814651291928405! >>>=20 >> ____________________________________________________________ >> Logs of Nightly APO Activities >> = https://trac.sdss.org/tracmailman/browser/private/sloan-25mlog/index.html >=20 >=20 > ____________________________________________________________ > Logs of Nightly APO Activities > = https://trac.sdss.org/tracmailman/browser/private/sloan-25mlog/index.html