ALMA Optical Pointing


TIP Last Update: JeffMangum - 29 May 2012

Useful Equation for Calculating Distance in Spherical Coordinates

Distance R between (Az1,El1) and (Az2,El2):

cos(R) = sin(El1)*sin(El2) + cos(E1)*cos(E2)*cos(Az1-Az2)

Can also be used with (RA,Dec).

-- JeffMangum - 2009-11-25

Wind Velocity Scaling Between OSF and AOS

Since it is the wind force that is the important factor in characterizing the pointing performance, we need to scale the allowable wind speed during pointing measurements. Force is pressure per unit area. The antenna performance specification relates to the AOS, so we need to scale the pressure as follows:

P(AOS)*V^2(AOS) = P(OSF)*V^2(OSF)

V(AOS) = 6.4/9.5 m/s (day/night)

P(AOS)/P(OSF) = 0.75

Scaling to the OSF:

V(OSF) = sqrt(P(AOS)/P(OSF))*V(AOS) = sqrt(0.75)*V(AOS) = 5.5/8.2 m/s day/night

-- JeffMangum - 2009-12-03

Tycho-2 Catalog Access

For checking the ALMA version of the Tycho-2 catalog positions used by our OPT measurements, use the following link:

Tycho-2 Catalog Search

Be sure to select the "mean_ra" and "mean_dec" output columns so that you can compare them directly to the positions listed in the ALMA OPT catalogs.

-- JeffMangum - 2011-10-08

Vertex Pointing and Fast Switching Acceptance Report Numbering

Static or Rolling Updated Reports:
  • 19: "ALMA Prototype Optical Pointing Telescopes Overview"
  • 06: "ALMA Vertex Antenna Pointing Calculations Description"
  • 20: "ALMA Weather Station Measurements Associated with Vertex Antenna Acceptance"
  • 39: "ALMA Production Optical Pointing Telescopes Overview"
  • 56: "ALMA Antenna DV14: Metrology System Stability Following Long Slews"

Antenna All-Sky Offset Fast Switching Seeing
DV01
00
01
02
...
DV02
00 (03)
01 (04)
02 (05)
... (06)
DV03
07
08
09
10
DV04
15
16
17
18
DV05
11
12
13
14
DV06
27
28
29
30
DV07
19
20
21
22
DV08
23
24
25
26
DV09
31
32
33
34
DV10
35
36
37
38
DV11
40
41
42
43
DV12
44
45
46
47
DV13
48
49
50
51
DV14
52
53
54
55
DV15
57
58
59
60
DV16
61
62
63
64
DV17
65
66
67
68
DV18
69
70
71
72
DV19
73
74
75
76
DV20
77
78
79
80
DV21
81
82
83
84
DV22
85
86
87
88
DV23
89
90
91
92
DV24
93
94
95
96
DV25
97
98
99
100

GPS Trouble Shooting

NickEmerson has produced a document called "GPS_Troubleshooting_tips.pdf" which lists commands for communicating with the GPS clock on the Vertex antennas. To effect this communication:
  • Log on to vtx-gns.
  • Telnet to the appropriate GPS clock IP address.
  • If you find that the GPS is not working normally use the "pstrip" command to power-cycle the GPS (the GPS is normally connected to slot 2 of the power strip).

Production OPT

Pointing Documentation

Optical Pointing System Information

Optical Pointing System Acceptance

OPT System Design Description

Based on the prototype OPT systems, JeffMangum wrote a "manual" which describes the design considerations, describes the prototype systems, and suggests areas of improvement. The 2005/06/20 version of this document is the latest.

-- JeffMangum - 21 Jan 2007

Optical Pointing Peak Finding Algorithm

OPT Crib Sheets

-- JeffMangum - 15 Feb 2007

TelCal Optical Pointing User Guide

-- JeffMangum - 15 Feb 2007

Guide to Using the ALMA OT for Optical Pointing

-- JeffMangum - 15 Feb 2007

OPT1/OPT2 Differences

  • The mounting base of OPT2 is 100mm closer to the rear of tube.
  • The shutter/solar filter mounting tube was extended by 200mm on OPT2
  • The camera cover is much smaller on OPT2
  • There is an extra bulkhead/feed through plate on OPT2 for weather protection. This should be straight forward.
  • Because of the different lengths, the cables between the rear Can and front mechanisms are a different length and pass through the bulkhead.
  • Electrically, OPT2 is much cleaner inside since it was #2.

If OPT2 is used in a VertexRSI antenna:

  • OPT2 would stick out the front of the BUS considerably and would probably violate the ICD volume.

Attached is a drawing showing some of the OPT1/OPT2 differences.

-- JeffMangum - 17 Apr 2007

Note About Difference Between Sky RMS and Popn SD

The tpoint analysis produces two statistical measures of the residual RMS from a fit:

  • Sky RMS: The standard RMS of the residuals from a pointing model fit.
  • Popn SD: The RMS weighted by the distribution of measurements over (Az,El).

The Popn SD tends to be larger than Sky RMS for data sets with a small number of points or poor sky coverage. When the number of measurements is relatively large (>100 or more) with uniform (Az,El) coverage, Popn SD approaches Sky RMS.

Population SD is definitely the most "honest" statistic, and reflects the fact that with few observations and many coefficients the residuals will be smaller than they should be if one uses Sky RMS.

Since the pointing characterization of the production antennas uses optical pointing data sets with a varying number of points and varying uniformity of sky coverage, I will quote both Sky RMS and Popn SD when describing results.

-- JeffMangum - 27 Aug 2008

Detectability of Stars Fainter Than 6th Magnitude in Daytime

As it is difficult to obtain enough stars during daytime measurements to establish a good pointing model, on 2008/08/28 Pere Planesas tested the detectability of stars fainter than magnitude 3 in daytime with both OPT1 and OPT2. Conditions were as follows:

  • The sky was clear and the rate of detections was much higher than average.
  • Wind was low (always < 3 m/s, average ~1.5 m/s, from Az~270).
  • As is normal, though, the Sun was interfering with our ability to observe a large part of sky.
  • Identical tests were carried out on OPT1 and OPT2.
  • Integration time = 5 seconds throughout.

The results for DV01 were:

  • Magnitude range: 2.0 to 3.0
    • OPT1:
      • ALMA-OT found 36, Frame Grabber detected 29
      • Tpoint data reduction showed 27 were acceptable.
    • OPT2:
      • ALMA-OT found 42, Frame Grabber detected 38,
      • Tpoint data reduction showed all were acceptable.
  • Magnitude range: 3 to 3.5
    • OPT1:
      • ALMA-OT found 24, Frame Grabber detected 21,
      • Tpoint data reduction showed 18 were acceptable.
    • OPT2:
      • ALMA-OT found 30, Frame Grabber detected 24,
      • Tpoint data reduction showed 23 were acceptable.
  • Magnitude range: 3.5 to 4.0
    • OPT1:
      • ALMA-OT found 72, Frame Grabber detected 38,
      • Tpoint data reduction showed 33 were acceptable.
    • OPT2:
      • ALMA-OT found 72, Frame Grabber detected 60,
      • Tpoint data reduction showed 23 were acceptable.

The percentage of stars useful for pointing as compared to the catalogs produced by ALMA-OT for OPT1/OPT2 was:

  • Magnitudes 2.0 to 3.0: 75%/90%
  • Magnitudes 3.0 to 3.5: 75%/77%
  • Magnitudes 3.5 to 4.0: 46%/32%

The reduction in efficiency of detecting the stars is worse than it appears, as the sky distribution also changes. The distribution of fainter stars is restricted to larger solar elongations, so the sky coverage that we get from them is increasingly biased as we go to fainter stars.

The conclusion from these measurements is that:
  • OPT2 works better than OPT1, giving a higher detection rate.
  • OPT2 CCD may be working at a lower temperature. This was checked later and found to be the case. Using In object explorer: CONTROL ALMA0x OpticalTelescope ccdTemperature found that OPT1 = 9.08 C and OPT2 = -1.66 C. Later checked the CCD cooling system setting and found that the "5 C" switch is indeed on, so the maximum cooling setting was active. Nevertheless, OPT1 always has a higher temperature than that in OPT2. Pere followed these differences throughout the day and night and found that the temperature difference was pretty uniformly 6-11 C.
  • However, the number of acceptable stars that contribute to sky coverage without increasing significantly the final RMS, remains small.

In summary, expanding the magnitude range for day time observing to 3.5 magnitude stars will increase the sample by around 20 stars, after removing a few outliers, BUT their distribution will be strongly biased as most of them will lie at low elevations in the region opposite to the Sun.

Perhaps the best way to have a better sky coverage is doing observing runs all day long, so data will be taken with the Sun avoidance area changing place. The combination of all data sets must give a good sky coverage. The use of fainter stars would produce a biased coverage (due to the Sun) and a larger number of outliers.

-- JeffMangum - 31 Aug 2008

Proper Star Magnitude Range for Night Time Pointing Observations

Offset pointing measurements are made using stars with magnitudes less than or about 5.2 show "multi-moding" in their residual distributions. For example, in the set of 6 offset pointing runs made 2008-10-22, two of them show bimodal residuals. Looking closer at these two aberrant runs, and using the source listing included with each run, I find that the stars with magnitude less than about 5.2 are not consistent with the other two stars, with magnitudes greater than 5.5 or so. Furthermore, the separation between the "nodes" of the bimodal distribution is about 1 arcsec, which is very close to the pixel size on the OPTs.

It appears to me that we are seeing quantization due to the use of stars which are too bright in these measurements. During the prototype evaluation we determined that the OPTs begin to saturate for night time observations around magnitude 6. We found, again during the prototype evaluation, that we could detect, with a few seconds of integration, stars down to about 9th magnitude. I believe that one should use dimmer stars, certainly m > 6.0 for all-sky pointing and m > 6.5 for offset pointing and fast switching.

-- JeffMangum - 24 Oct 2008

OPT Fast Dumping File Format Description (With Prototype OPTs)

See AIV wiki description for details. Note that this format existed only for the prototype OPTs. See below for a description of the (very similar) format for the fast dumping with the production OPTs. In summary:

  • timeStamp: [100ns]
  • exposureTime: [s]
  • posX: [pixels]
  • posY: [pixels]
  • posErrX: [pixels2]
  • posErrY: [pixels2]
  • SNR
  • actAz: [rad]
  • actEl: [rad]
  • skyFrameAz: [rad]
  • skyFrameEl: [rad]

These values are used to derive the offset Az and El as follows:

returnData->offsetAZ.value = (cmdPositionAz - actPositionAz) - skyFrameAz + pmOffsetAz;
returnData->offsetEL.value = (cmdPositionEl - actPositionEl) - skyFrameEl + pmOffsetEl; 

Definitions of variables as follows:

  • timeStamp: ACS time, which is defined as 100 ns units since Oct 15, 1582. This means that: unixTime = (timestamp/1E7) - 12219292800.0.
  • exposureTime: OPT exposure time in seconds.
  • cmdPositionAz, cmdPositionEl: This is, in SLALIB parlance, the observed position, and includes all astronomical effects (like precesion and refraction). It does not include the contribution from the pointing model implemented on the ABM.
  • actPositionAz, actPositionEl: Is the value returned by the AZ_POSN_RSP monitor point that is aligned with the the timing event. It has been converted from turns to radians and then the offsets introduced by the pointing model that are implemented on the ABM are taken out. The actPositionEl uses the EL_POSN_RSP monitor point.
  • encPositionAz, encPositionEl: Is the value returned by the GET_AZ_ENC monitor point. It has been converted to radians, using a vendor specific conversion factor and an antenna specific encoder offset. The encPositionEl uses the GET_EL_ENC monitor point.
  • skyFrameAz, skyFrameEl: Is the offset, in radians, between the position of the center of the star on the CCD and the centre pixel on the CCD. Calculation of this involves finding the centroid of the star on the CCD calculating how far it is from the centre of the CCD after taking into account the plate scale of the CCD and the rotation of the CCD axes with respect to the antenna axes.
  • pmOffsetAz, pmOffsetEl: Input pointing model offsets in Az and El.

-- JeffMangum - 19 Dec 2008

OPT Fast Dumping File Format Description (With Production OPTs)

Note that the following adaptation of the original OPT fast dumping format was designed to jive with the similar PSC information and format.

  • timeStamp: [UT; ISO8601 format]
  • exposure: [s] (from StarPosition struct)
  • xPosition: [pixels] (from StarPosition struct)
  • yPosition: [pixels] (from StarPosition struct)
  • longWidth: [arcsec] (from StarPosition struct)
  • latWidth: [arcsec] (from StarPosition struct)
  • SNR: = peak/rms/(1.133*widthx*widthy) from StarPosition struct
  • azCommanded: [deg] (from MountStatusData struct)
  • elCommanded: [deg] (from MountStatusData struct)
  • azPosition: [deg] (from MountStatusData struct)
  • elPosition: [deg] (from MountStatusData struct)
  • longOffset: [deg] (from StarPosition struct)
  • latOffset: [deg] (from StarPosition struct)
  • azPointingModelCorrection: [deg] (from MountStatusData struct)
  • elPointingModelCorrection: [deg] (from MountStatusData struct)

-- JeffMangum - 2011-04-21

Tpoint File Content Definitions

First Comment Line:
  • (data.endTime + data.startTime)/2.0 (ACS time units)
  • data.SNR (unitless)
  • data.peakPositionX (pixels)
  • data.peakPositionY (pixels)

Second Comment Line:
  • data.pointingModelOffsetAz (deg)
  • data.pointingModelOffsetEl (deg)
  • data.CCDOffsetAz (deg)
  • data.CCDOffsetEl (deg)

Data Line:
  • data.sourceAZ.value (deg)
  • data.sourceEL.value (deg)
  • data.sourceAZ.value-data.offsetAZ.value (deg)
  • data.sourceEL.value-data.offsetEL.value (deg)

-- JeffMangum - 16 Oct 2008

OPT Frame Integration Position Tag

The OPT M&C assigns the position tag to an integration as follows:

In functions like PositionStreamConsumer::getActPosition(ACS::Time, double, double) there is code which returns the position at the specified time. If the specified time is between two TE's it does a linear interpolation between the two nearest values. The optical pointing observing mode (in the doExposure function in OpticalPointingImpl.cpp) asks for the antenna position at the timestamp assigned by the frame-grabber device. In the runloop function in the FrameGrabbberDeviceImpl.cpp file this timestamp is set to the middle of the exposure. There is no averaging.

This is not strictly a correct way to assign the position tag for an integration which contains N TE-based position measurements. In the case of a 5-second OPT integration there are about 100 individual TE-based positions read during this integration. Since the peak-to-peak amplitude on TE-timescales is about 0.6-0.7 arcsec, one should assign some sort of average position.

-- JeffMangum - 16 Oct 2008

OPT1 and OPT2 Plate Scales

Current to 2008/08/31:
  • OPT1 = 0.84 arcsec/pixel
  • OPT2 = 0.88 arcsec/pixel

Note that the actual settings of the plate size and rotation for OPT1 and OPT2 are (as of 2008/10/02) as follows:

  • OPT1:
    • sizeX = -8.8778
    • sizeY = +6.6584
    • rotation = +1.54935
    • As measured on 9001.
  • OPT2:
    • sizeX = -9.4288
    • sizeY = +7.0716
    • rotation = -6.67
    • As measured on 9001.

Note that the conversion from plate size to plate scale is as follows:

  • DetectorGeometryX = 0.8838 "/pxl * 640 pxl 1'/60" = 9.4288'
  • DetectorGeometryY = 0.8838 "/pxl * 480 pxl 1'/60" = 7.0716'

Why the odd use of plate size rather than the more natural plate scale? Computing IPT insistence on obscurity...

-- JeffMangum - 02 October 2008

Data Taking and On Source Criteria for Optical Pointing

Some information about tracking tolerances relevant to metrology, collected from Jeff Kern and from examination of optical pointing script and logs.

  1. Antenna calculates position for "on source" calculation as follows:
    • AzErr = (AzCommand - AzActual)*cos(ElCommand)
    • ElErr = ElCommand - ElActual
    • TotErr = sqrt(AzErr^2+ElErr^2)
  2. The antenna declares itself to be "on source" when TotErr agree to less than or equal to the tracking tolerance for 3 consecutive timing events (TEs).
  3. The tracking tolerance is set in the optical pointing script to be 1.5 arcsec (can be changed).
  4. If the antenna goes outside the tolerance for even one TE, it signals it is "off-source".
  5. After going "off source", the antenna will declare itself to be "on source" again after condition (1) above is satisfied.
  6. Any observer-input delay (such as a metrology system delay used on the Vertex antennas) is counted from the point at which the antenna is first on source and continues to count independent of whether the antenna stays on source or not. In other words, this counter is not reset if the antenna drifts off source after having gotten on source, but before an OPT integration starts.
  7. The software declares an observation to have failed (and throws away the data) if condition (3) happens anytime during the OPT integration (current value is 5 seconds, which is set in the optical pointing script).

Here is the code snippet given to me by Jorge Ibsen:

Dear Jeff,

The error is calculated as follows (in MountImpl::processCommand method):

    double azError =
        (commandedAzPosition - uncorrectedAzPosition) *
        cos(commandedElPosition);
    double elError =
        commandedElPosition - uncorrectedElPosition;

    double totalError = sqrt((azError*azError) + (elError*elError));

The error is then used to calculate the on source flag, using as
criteria ON_SOURCE_CRITERIA consecutive hits (defaulted to 3 in the
code) as follows:

    if (totalError <= tolerance_m)
        {
        targetFlagCounter_m++;

        onSource_m = (targetFlagCounter_m == ON_SOURCE_CRITERIA);
        if(onSource_m)
            {
            targetFlag_m = ACS::acsTRUE;
            ACS_LOG(LM_SOURCE_INFO,__METHOD__,
                    (LM_DEBUG,"ON_SOURCE %d totalError %lf counter %d",
                     onSource_m,
                     totalError,
                     targetFlagCounter_m));
            targetFlagCounter_m = (targetFlagCounter_m >=
ON_SOURCE_CRITERIA) ? (ON_SOURCE_CRITERIA -1) : targetFlagCounter_m;
            }
        else
            {
            targetFlag_m = ACS::acsFALSE;
            ACS_LOG(LM_SOURCE_INFO,__METHOD__,
                    (LM_DEBUG,"ON_SOURCE %d totalError %lf counter %d",
                     onSource_m,
                     totalError,
                     targetFlagCounter_m));
            }
        }
    else
        {
        onSource_m = false; // Just to be consistent
        targetFlag_m = ACS::acsFALSE;
        ACS_LOG(LM_SOURCE_INFO,__METHOD__,
                (LM_DEBUG,"ON_SOURCE %d totalError %lf",
                 onSource_m,
                 totalError));
        targetFlagCounter_m = 0;
        }

I hope this answer your question. If you have additional questions,
please send them directly to Tzu (cc me). Tzu is currently maintaining
this piece of code in the branch used  at vertex camp
(Antenna-Verification-2007-03-B, if I remember correctly).

Cheers,
Jorge

-- JeffMangum - 16 December 2008

doExposure Versus doSourceExposure in Optical Pointing Scripts

ALERT! Change to all optical pointing scripts 2009/05/14. See JIRA ticket AIVMAN-1894.

Based on discussions involving Pere and Ralph, we realized that a 1.5 second "gap" in commanded position measurements being sent to the ACU on the Antenna Verification branch was likely due to the use of "doSourceExposure", which tells the antenna to acquire a position then do an exposure, rather than "doExposure", which assumes that the antenna is already tracking a source and simply tells it to do an exposure. Ralph's recommendation was to always use doExposure rather than doSourceExposure after a sleep. Specifically, replace:

mc.setDirection(radians(ra), radians(dec), pmRA, pmDec, parallax)
time.sleep(2)
data = opmc.doSourceExposure(EXP_TIME, radians(ra), radians(dec), pmRA, pmDec, parallax)

...with...

data = opmc.doExposure(EXP_TIME)

He also noted that in order to have the shutter open following a dark frame that we need to replace:

op.getOpticalPointingModeController().getOpticalTelescope().openAperture()

...with...

op.doDarkExposure(DARK_EXP_TIME)

-- JeffMangum - 2009-05-14

Timing and Station Time Setting for OPT Measurements

System Description Up To 2009/09/27

The following is a description by Ralph Marson

The optical pointing mini-rack contains, amongst other things, a GPS and a pulse generator. The GPS has a highly stable oscillator that is locked to international time-standards when it detects enough satellites. The GPS produces two signals:
  1. A 10MHz signal that is the timebase for the pulse generator.
  2. A one pulse per minute (1PPM) signal that is used to trigger the pulse generator.

The pulse generator produces the 48ms timing event (TE) that is used by the ABM and the ACU. The 1PPM signal triggers the pulse generator to produce 1 minute's worth of TE's (1250 pulses). Assuming everything works right this should produce a continuous stream of TE's. This complicated re-triggering scheme is to ensure we have a TE exactly aligned with the start of each minute.

The clock on the ABM normally uses NTP to maintain its time. However when the ALMA software is started and the teHandler kernel module is loaded the ABM turns NTP off and counts TE's to maintain its clock. The assumption is that NTP will adjust the ABM's clock so that it is accurate to within 24ms. When the teHandler module starts it does a one time large adjustment (of 24ms or less) of the system clock to align it with the external timing events, and from then on does small adjustments of the system clock to keep it aligned with the timing events. In other words (basically restating the above in hopes of making it clear):
  • When the ALMA software is started NTP should be turned OFF on the ABM.
  • At this time the ABM loads software (the teHandler kernel module) that counts timing events (TEs) from the oscillator in the mini-rack.
  • This oscillator should be synchronised with the GPS.
  • When the ABM starts the teHandler software does a one-time adjustment of up to 24ms on the system clock.
  • This means the time on the ABM will be accurate to much better than one ms if NTP can reduce the error to less than 24ms before the ALMA software is loaded.

The ABM and NTP time synchronization can be checked with the script AllAroundntpCompare.sh.

-- JeffMangum - 17 Dec 2008

System Description Starting 2009/09/27

The following is due to Nicolas Troncoso

To remedy problems with the reliability of external NTP servers Nicolas Troncoso reconfigured the NTP server used at the SEF to use the lo-art-1 at the high site ABM which is synced to a GPS. All computers in the Vertex SEF STE are synchronized directly with the lo-art-1. The accuracy of this NTP server looked initially to be quite good.

The medium term solution is to install, in a rack in the technical building, a GPS/NTP server that will be used by all computers at the OSF. This NTP server would be the central (stratum 1) NTP server and replace all NTP servers that are off-site. This NTP server will not interact directly with the NTP at the AOS. The computers at the AOS will use as NTP server the OSF(OSF_T0). This is to avoid syncing time and glitches produced by starting up and stopping the NTP server at the AOS (lo-art-1).

Once the software is started (AOS) the ArrayTime will set the ABM time to what ever the GPS at the AOS(AOS_T0) is providing. The consequence of this setup is that the NON ABM computers and ABM will have a constant offset of AOS_T0 - OSF_T0, Which should be minimal since both times are GPS times.

This is Valid only for the AOS. The STEs at the OSF sync only against OSF_T0 so there will be no offset.

Ralph Marson points out that:

I think this plan is fine for the next couple of years.

It becomes flawed when we reach the stage where we are not resetting the ARTM at the AOS very frequently. In normal operation the ARTM will only be synchronized with the GPS at start up and will then use the maser as its time source. This time source will drift slightly with respect to GPS time. I do not have the specs on the long term stability of the maser so I cannot estimate how long before this time difference becomes significant. If its years this difference may never be an issue.

One thing we did, at the ATF, to address the issue that the ARTM was often restarted was to have the GNS be a stratum 2 NTP server that used the ARTM (that was a stratum 1 server). All other computers, including the real-time computers before their kernel modules were loaded, used the GNS NTP server. The only client of the ARTM NTP server was the GNS.

-- JeffMangum - 2009-10-02

Signal-To-Noise and Dynamic Range Limitations of the OPT System

The fundamental limitation in dynamic range of the OPT system is driven by the frame grabber, which is only 16 bit (8 bit in and 8 bit out). This means that there are only 28 levels (256). This implies
  • Dynamic range = 10*log10(256) = 24 dB
  • Recall also that one magnitude = 4 dB

This, though, assumes that the noise is negligible. A couple of things to consider:
  • Integration times may change this calculation. After grabbing a frame, if there is further averaging then the dynamic range would increase without necessarily saturating the A/D. S/N should go up by roughly sqrt(n_frames).
  • The precise noise level also folds into this calculation. Assuming that the A/D in the frame grabber is set up so that random noise in the frames corresponds to a few digitization levels, then the pre-averaging dynamic range would be less than 256:1 by a factor of a few. In the absence of any other knowledge, it is usually safe to assume that the pre-sampling frame noise is equal to about 3 digitization steps - that's a compromise, being far enough away from noise=1, the point at which digitization starts losing s/n, and not too great so that you reduce dynamic range. With a post-averaging s/n of 320, that would be a pre-averaging s/n of 320/sqrt(50) or 45:1. If that corresponds exactly to onset of saturation, it implies that the frame noise level is about (256/45)=5.7 levels. That is within a factor of 2 of the optimum level assumption of 3 levels above.
  • Reasonable Rule of Thumb: If you are getting measured peak SNR of greater than 256 counts of stars while doing optical pointing measurements then you run the risk of saturating the frame grabber.

(Mis)Handling of Proper Motion

In August 2009 while characterizing the offset pointing performance of PM03 questions arose regarding the processing of the proper motion of stars used for optical pointing measurements. The problem is that most star catalogs, including Tycho2, quote proper motion on-the-sky (PmRA*, or PmRA*cos(Dec)) in mas/yr, while the SLALIB routines (specifically, SLAPM) used by the ALMA M&C software assume just PmRA (i.e. with no cos(Dec) projection onto the sky).

While characterizing the offset pointing performance of DV07 I noticed that, for several offset pointing runs, one star was consistently displaced relative to the other two in an offset pointing run. Looking at the star catalog for one of these runs:

#Group  110   Distances (deg) =  1.88  1.87  0.00
#             RAs (hour) =  12.2  12.4  12.4
#             DECs (deg) = -64.5 -65.8 -67.6
8982_04654_1              183.0031677      -64.5104033    6.58     -5.90     -0.40
8987_01671_1              186.3230515      -65.7698579    6.41    -63.5      -101.00
9227_01757_1              185.8079100      -67.6315561    6.46   -745.00    252.50

...we see that the third star in this list is both at a high-declination (in the south) and has a large proper motion in RA (the second-to-last number in the star's entry). When I fit the known pointing model to these measurements, I find that this third star is separated from the other two by about 7 arcsec in Az, which corresponds to 5 arcsec in RA projected onto the sky (first multiply by cos(E) = cos(50) and project to RA), while the other two are separated by about 0.5 arcsec from each other, quite systematically (for the duration of the run). Furthermore, we have used this same star field on two separate nights, getting the same result.

The error made on the sky when one does not include the cos(Dec) correction is given by:

\epsilon_{PM} = \left[1-\cos(Dec)\right]*PmRA*10.3 mas

...where the factor of 10.3 comes from the fact that the J2000 coordinated is precessed to today (April 2010). Therefore, the error made for each of the stars in the catalog above would be:

  • 8982_04654_1: \epsilon_{PM} = 0.035 arcsec
  • 8987_01671_1: \epsilon_{PM} = 0.385 arcsec
  • 9227_01757_1: \epsilon_{PM} = 4.749 arcsec

...all in good agreement with the offsets in RA measured above. Therefore, these errors are significant.

-- JeffMangum - 2010-04-07

Sky Blockage Due to the SEF

As one can see from the cumulative all-sky optical pointing measurement distribution, there is a small "divot" in the south/southwest, due to the SEF, and a wider divot in the east which is due to the Andes. For the SEF, we can calculate how much the building blocks using the following rough measurements (from Derek Harris):

  • Center of Pad 1 to Building: 30.2 m South
  • Center of Pad 2 to Building: 30.5 m South - SouthWest
  • Center of Pad 3 to Building: 25.6m SouthWest
  • Height of building: very roughly 26m

Using these measurements, and noting that the Az/El axis intersection point of the antenna is roughly 7m off of the ground, we can calculate the amount of blockage in elevation as follows:

  • \theta_1 = \tan^{-1}\left(\frac{26-7}{30.2}\right) = 32.2 degrees
  • \theta_2 = \tan^{-1}\left(\frac{26-7}{30.5}\right) = 31.9 degrees
  • \theta_3 = \tan^{-1}\left(\frac{26-7}{25.6}\right) = 36.7 degrees

Since we select only stars at E > 20 degrees, and since the azimuth range for the SEF blockage is limited to about 10 degrees or so, this blockage is not an issue for characterizing all-sky pointing.

Just to confirm these calculations, I have plotted the cumulative (as of 2010/04/13) all-sky optical pointing measurement residuals of DV07 as a function of azimuth while limiting the elevation range of the measurements to only those measurements at E < 30 degrees. Note the "divot" in the south/southwest.
DV07AllSkyBuildingBlockagePad2.jpg
SEF blockage from Pad 2

OPT Setup Information (David's wiki page)

Contains information on:
  • Installation
  • Software setup
  • Alignment
  • Hot pixels
  • Flat field frame creation

-- JeffMangum - 2012-05-29

Position Stream Client "invalid" Flag Description

For version 6.0.1 of the ALMA software the real-time command control of the antenna was changed to a buffering scheme which can be flushed as needed. This was to improve efficiency (this was one area with a known latency). The way the positioning command sequence proceeds is as follows:
  • 4 second long series (about 84 1 TE commands) of precalculated positions is sent to the ACU.
  • Before this queuing change if the antenna was commanded to a new position one would have to wait until the buffer cleared, which would be at least 4 seconds.
  • We now discard this queue immediately and start using the new source.
  • This "flush" of the queue necessarily results in a couple of TE's when we are not commanding the antenna.
  • It should be the case that any line with an "invalid" flag for a position will show-up later in the position stream output file with the same timestamp and a valid set of positions.
  • Jeff Kern expects that only one or two TEs of position information might indeed be missing from a position stream client stream.
  • This might require sorting the position stream client file in time to order the now not-necessarily-time-ordered output.
  • The important thing to remember that any position stream entry with an "invalid" position will very likely show up later in the file, with the same time stamp.

-- JeffMangum - 2009-03-24

AIV/NAOJ Weather Station Information Included with Pointing Measurements

On 2008/09/11 JeffMangum asked about the weather station both used for refraction correction and included with pointing measurements during antenna evaluation of pointing. Pere confirmed that:
  • The weather data files posted with the optical pointing measurements (MeteorologyYYMMDD.txt) look to be from the NAOJ weather station
  • The other weather data file (weather.txt) appears to be from the AIV weather station.
  • The NAOJ weather station is the one to use. It is much closer to the Vertex pads and there is no nearby power generator spoiling the temperature measurements as in the AIV weather station. Pere compared their measurements during the holography campaign and his conclusion was that the NAOJ is more reliable and more adequate for Vertex, due to its proximity, and it only fails with the solar irradiation measurements.
  • If needs reliable solar irradiation measurements the AIV weather station measurements should be used. If the AIV measurements are not available the NAOJ measurements can be used tentatively, with some scaling and offset that Pere can provide.

-- JeffMangum - 14 Sep 2008

Chajnantor Weather Station Access Points

-- JeffMangum - 05 November 2009

Scripts and Programs Used for Optical Telescope Pointing/Tracking Characterization

In the following I list the main programs and scripts used for Vertex antenna optical positioning characterization. For an outdated description of an earlier version of the programs and scripts see http://aivwiki.alma.cl/index.php/OPT_Pointing_Tests_for_DV01.

After 2010-01-01 (ALMA M&C software version 6.1): The scripts and programs are located in two areas:
  • The default location used by the OT is /alma/ACS-current/ACSSW/bin on vtx-gns.
  • An alternate location, mainly for modified versions of the scripts in the default area. This alternate location is currently /users/almaop/Scripts on vtx-gns.
Many of the observing parameters that were set with these scripts under the verification branch are now set within the OT (such as tolerance). The underlined scripts in the listing below are the main ones used for all-sky pointing, offset pointing, and fast switching characterization:
  • All Sky Pointing:
    • OpticalPointingScript.py: A script to perform all-sky pointing measurements. Details are:
      • exposure 5 secs
      • delay time 2 secs
      • random
      • metrology should be on
  • Offset Pointing :
    • OffsetOpticalPointingNoDelay.py: A script to perform the Offset Pointing test, to be used within a SB. It runs 5 sec integrations sequentially for a group of stars. The star list should be repeated as many times as required to get enough data (e.g. 40 times a triplet of stars takes about 15 minutes). Details are:
      • exposure 5 secs
      • delay time 0 seconds
      • no randomize
      • metrology on (included in script)
      • good handling of exceptions
      • Observation sequence is as follows:
        • Observation of groups of N stars
        • Each star is observed 5 times 5 seconds (5 subscans)
        • For a group of N stars the following loop is executed N times until the total observation time is more than 15 minutes:
          • Move to star #1 and run one 5-second standard pointing integrations
          • Move to star #2 and run one 5-second standard pointing integrations
          • ...
          • Move to star #N and run one 5-second standard pointing integrations
          • Move back to star #1 and run three 5-second standard pointing integrations
  • Fast Switching:
    • FastSwitchingTest_NoOpt__601.py: A script to do fast switching measurements. Details are:
      • Must command antenna to sidereal track (i.e. command in (RA,Dec) toward target (Az,El)) for these tests.
      • typical exposure time: -i 15 seconds
      • typical # of repetitions: -r 45 (--> total time of 15 minutes)
      • position angle: -p 0 (p = PA + 90; p = 0 corresponds to +Az switch)
      • offset position 1.5 deg away
      • delay time off source 8 secs
      • metrology should be on
      • usage: VertexFastSwitching.py --antenna=ALMA0x -i 15 -r 45 -p 0
  • Others:
    • 15minutes.py: A script to perform the Offset Tracking test, to be used within a SB. Observes a set of stars as follows:
      • The first star in each pair is observed 3 times 5 seconds (3 subscans).
      • The second star in each pair is observed for 15 minutes (87 subscans).
      • So, for one pair of stars it makes 3 exposures of the first star and 87 exposures of the second one. As a rule of thumb, 3 exposures correspond to the first star and the rest to the second one, that had been tracked approximately for 15 minutes.
    • VertexSeeing.py: A script to do seeing measurements. Details are:
      • typical runtime: 20 minutes, type "quit" to finish rapid position.
      • metrology should be on
      • usage: VertexSeeing.py --antenna=ALMA0x
      • old name: rapid_position2.py
    • SearchGroups: Allows one to search for groups of 2 to 9 stars located at a certain distance range (e.g. from 1.9 to 2.1 degs) and with similar magnitude. It creates a catalog that can be used as local catalog in ALMA-OT. This is needed for the offset pointing and fast switching tests. Uses the Tycho2 catalog. It is recommended to use SearchGroups in combination with Stellarium, xephem or a similar planetarium program. At the question: Sidereal time (h.frac) [-1=any] ?" type "-1" so you will get a large set of groups scattered in the sky with indication of the aprox RA,Dec position. For a given AZ,EL position the planetarium software will tell you the corresponding RA,Dec at any time of the day, so you can choose the right group. You should avoid stars too close to AZ=180, for obvious reasons. Use radec2azel to convert output (RA,Dec) to (Az,El), thus allowing for better assignment to test matrix positions. NOTE: As of 2009-11-24 the option "closure" is now the default when searching for star trios.
    • radec2azel: Routine which takes SearchGroups output and converts (RA,Dec) to (Az,El). Syntax is "radec2ael -i input-file-name -o output-file-name" (use "radec2azel -h" for full help listing).
    • AllAroundntpCompare.sh: A script which compares ABM time with NTP. Used to diagnose timing problems.
    • takeImg.py: Take a FITS image (shutter open).
    • takeDark.py: Take a FITS image (shutter closed).

Before 2010-01-01 (Verification Branch): The scripts and programs were located in /users/almaproc/POINTING/Scripts/ on vtx-gns. The underlined scripts in the listing below are the main ones used for all-sky pointing, offset pointing, and fast switching characterization:
  • All Sky Pointing:
    • VertexAllSkyPointing2sDelay.py: A script to perform all-sky pointing measurements. Details are:
      • exposure 5 secs
      • tolerance 1.5 arcsec
      • delay time 2 secs
      • random
      • metrology should be on
    • VertexAllSkyPointing5sDelay.py: A script to perform all-sky pointing measurements. Details are:
      • exposure 5 secs
      • tolerance 1.5 arcsec
      • delay time 5 secs
      • random
      • metrology should be on
      • old name: VertexAllSkyPointing.py
      • very old name: OpticalPointingScriptNoOrderWithDelay.py
    • VertexAllSkyPointing10sDelay.py: A script to perform all-sky pointing measurements. Details are:
      • exposure 5 secs
      • tolerance 1.5 arcsec
      • delay time 10 secs
      • random
      • metrology should be on
      • Used to test OPT mechanical stability on DV03
    • VertexAllSkyPointingMetroSwitch.py: A script to perform all-sky pointing measurements with metrology mode switching. Details are:
      • exposure 5 secs
      • tolerance 1.5 arcsec
      • delay time 2 secs
      • random
      • metrology switched from on (mode = 66) to off (mode = 0) every 10 measurements
      • old name: OpticalPointingScriptMetrologySwitching.py
  • Offset Pointing :
    • VertexOffsetPointingNoDelay.py: A script to perform the Offset Pointing test, to be used within a SB. It runs 5 sec integrations sequentially for a group of stars. The star list should be repeated as many times as required to get enough data (e.g. 40 times a triplet of stars takes about 15 minutes). Details are:
      • exposure 5 secs
      • tolerance 1.5 arcsec
      • delay time 0 seconds
      • no randomize
      • metrology on (included in script)
      • good handling of exceptions
      • Observation sequence is as follows:
        • Observation of groups of N stars
        • Each star is observed 5 times 5 seconds (5 subscans)
        • For a group of N stars the following loop is executed N times until the total observation time is more than 15 minutes:
          • Move to star #1 and run one 5-second standard pointing integrations
          • Move to star #2 and run one 5-second standard pointing integrations
          • ...
          • Move to star #N and run one 5-second standard pointing integrations
          • Move back to star #1 and run three 5-second standard pointing integrations
    • VertexOffsetPointing.py: Same as VertexOffsetPointingNoDelay.py but with a 2 second delay before each star integration.
    • VertexOffsetPointing10sDelay.py: Same as VertexOffsetPointingNoDelay.py but with a 10 second delay before each star integration.
  • Fast Switching:
    • VertexFastSwitching.py: A script to do fast switching measurements. Details are:
      • Must command antenna to sidereal track (i.e. command in (RA,Dec) toward target (Az,El)) for these tests.
      • typical exposure time: -i 15 seconds
      • typical # of repetitions: -r 45 (--> total time of 15 minutes)
      • position angle: -p 0 (p = PA + 90; p = 0 corresponds to +Az switch)
      • offset position 1.5 deg away
      • delay time off source 8 secs
      • metrology should be on
      • usage: VertexFastSwitching.py --antenna=ALMA0x -i 15 -r 45 -p 0
      • old name: FastSwitching3.py
      • NOTE: Modified 2009-08-19 by Ruben to do proper projection of azimuth coordinate on the sky (1/cos(El))
      • NOTE: VertexFastSwitchingNoOpticalTelescope.py is equivalent to this script (and had proper projection of azimuth coordinate on the sky made 2009/08/20)
  • Others:
    • 15minutes.py: A script to perform the Offset Tracking test, to be used within a SB. Observes a set of stars as follows:
      • The first star in each pair is observed 3 times 5 seconds (3 subscans).
      • The second star in each pair is observed for 15 minutes (87 subscans).
      • So, for one pair of stars it makes 3 exposures of the first star and 87 exposures of the second one. As a rule of thumb, 3 exposures correspond to the first star and the rest to the second one, that had been tracked approximately for 15 minutes.
    • VertexSeeing.py: A script to do seeing measurements. Details are:
      • typical runtime: 20 minutes, type "quit" to finish rapid position.
      • metrology should be on
      • usage: VertexSeeing.py --antenna=ALMA0x
      • old name: rapid_position2.py
    • SearchGroups: Allows one to search for groups of 2 to 9 stars located at a certain distance range (e.g. from 1.9 to 2.1 degs) and with similar magnitude. It creates a catalog that can be used as local catalog in ALMA-OT. This is needed for the offset pointing and fast switching tests. Uses the Tycho2 catalog. It is recommended to use SearchGroups in combination with Stellarium, xephem or a similar planetarium program. At the question: Sidereal time (h.frac) [-1=any] ?" type "-1" so you will get a large set of groups scattered in the sky with indication of the aprox RA,Dec position. For a given AZ,EL position the planetarium software will tell you the corresponding RA,Dec at any time of the day, so you can choose the right group. You should avoid stars too close to AZ=180, for obvious reasons. Use radec2azel to convert output (RA,Dec) to (Az,El), thus allowing for better assignment to test matrix positions. NOTE: As of 2009-11-24 the option "closure" is now the default when searching for star trios.
    • radec2azel: Routine which takes SearchGroups output and converts (RA,Dec) to (Az,El). Syntax is "radec2ael -i input-file-name -o output-file-name" (use "radec2azel -h" for full help listing).
    • AllAroundntpCompare.sh: A script which compares ABM time with NTP. Used to diagnose timing problems.
    • takeImg.py: Take a FITS image (shutter open).
    • takeDark.py: Take a FITS image (shutter closed).

Some additional handy little programs:

  • timestamp: It allows direct and inverse conversion of the time stamp tags (e.g. those in acuReport) and human readable UTC time. To get the inverse conversion just type: 0 or anything silly.
  • get_meteo: A program to get the NAOJ weather station numerical data from. Usage: get_meteo 081011. A password is required.
  • Rotation Test: This measurement is used to measure the calibration terms for the tiltmeter and linear sensors:
    • Move from -190 to +190 at 0.2 degrees/s at an elevation of 60.
    • If you do not have a script to do a slow 360 scan, you could do it manually with MountEngineeringInterface:
      • First move to AZ,EL = -190,60, then shutdown, and start an acuReport with 1s sampling.
      • Use metrology mode 66.
      • Then from MountEngineeringInterface, use the following commands:
        • VERTEX ACU> acu_mode_cmd 1,1 (to go to standby}
        • VERTEX ACU> acu_mode_cmd 3,3 (to go to autonomous mode)
        • VERTEX ACU> az_traj_cmd -1133394148,1193046 (to start the slew from -190 at 0.2deg/s)
      • Once it reaches +190 you can stop the antenna from MountPanel.
      • The mode change to autonomous should be done from MountEngineeringInterface to avoid conflicts with MountPanel.

-- JeffMangum - 2009-11-17

VertexRSI Antenna 1 Optical Pointing Acceptance

Vertex Antenna Metrology Calibration Constants and NPAE Values

Vertex Antenna Offset Pointing and FS Verification Testing Discussion

DV02 Issues

DV03 Issues

Additional Information

AIV Optical Pointing Wiki Pages

-- JeffMangum - 16 Sep 2008

AIV Optical Pointing Test Reporting Procedure

Some instructions for the current OPT campaign in Vx1 (acceptance) and Vx2 (OPT work) from Pere 2008/09/14:

On every individual pointing run:
  • fill in the text-based observing log (template in ~/DV0x/OPOINT/)
  • create a subdirectory for each observation, holding all auxiliary files (e.g. 2008-09-14/seeing01/)
  • when finished, save the NAOJ and the AIV weather station web pages in the data subdirectory.

During every daytime observing session:
  • do a seeing measurement with a star of magnitude dimmer than magnitude 2.5 if possible, i.e. do not use a far too bright star that saturates the image.

During every nighttime observing session:
  • do a seeing measurement with a star of magnitude 6 or dimmer.

After each observing session:
  • create a weather subdirectory (e.g. 2008-09-14/weather/)
  • save the numerical data from the two weather stations.
    • For NAOJ use the get_meteo command (passw required)
    • For AIV use the Data Query Tool and request All parameters.

Use always UTC date and time, also for the subdirectory structure.

Metrology mode setting:

  • Metrology ON: currently
    • for DV01 is:
      • set_metr_mode: 2 or 66 (or 67 for ACU model)
      • coeff 13: AN0 = 3.3
      • coeff 14: AW0 = 9.7
    • for DV02 is:
      • set_metr_mode: 2
      • coeff 13: AN0 = -8.68
      • coeff 14: AW0 = 33.6

These values may change after new inclinometer characterization.

Remember you must also set the metrology pointing model.

SetPointingModel --name=ALMA0X --file=metrologyXXX.mod

Some pointing runs (seeing, offset tracking, fast switching, metrology ON tests) require the acuReport and/or the PositionStreamClient to be running:
  • for DV01 is:
    • acuReport --antenna=ALMA01 -t1 -v > acureport.dat (for optical pointing is -t60)
    • PositionStreamClient ALMA01 positions.dat
    • MountEngineeringInterface -a ABM001 -n 0 -i C5; ACU> get_metr_deltas()
  • for DV02 is:
    • acuReport --antenna=ALMA02 -t1 -v > acureport.dat (for optical pointing is -t60)
    • PositionStreamClient ALMA02 positions.dat
    • MountEngineeringInterface -a ABM002 -n 0 -i C2; ACU> get_metr_deltas()

Seeing measurements:

Start the AcuReport and the PositionStreamClient as explained before. Use the code:

from CCL.OpticalPointing import OpticalPointing
op=OpticalPointing("ALMA01")
op.initializeHardware()
op.setSignalToNoiseThreshold(10.0)
op.doDarkExposure(0.07)
op.startRapidPosition(0.07, "/users/almaproc/rapid_0p07_2008mmdd_nn.csv")
op.stopRapidPosition()
op.shutdownHardware()
del(op)

More information in: http://aivwiki.alma.cl/index.php/Optical_Pointing_Rapid_Position_Mode

-- JeffMangum - 16 Sep 2008

This topic: Main > TWikiUsers > JeffMangum > AlmaOpticalPointing
Topic revision: 2012-05-29, JeffMangum
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 NRAO Public Wiki? Send feedback