GBT Pointing and Focusing Implementation Notes

General

(Original text by RichardPrestage, Italics text by JoeBrandt)

If you agree, I'd like to turn this into a PTCS Project Note. But, I want to check we are on the same page before I do that. Also if you agree, I'd like to document this as "the proposed system" followed by "current departures from the proposed system", with the expectation that this won't all be implemented by Mid-November, but the remaining items will gradually dissappear.

Are we going to call this thing the "Pointing/Focus Model" (PFM)? I like the acronym, but is the name explicit enough? Should it be the pointing/collimation model? Maybe I should consult Jim Condon

I'll certainly go with whatever you decide. I'd just as soon call it PFM, since the two are treated separately, and reserve PCM for when we get a full optical model. That's my 2¢ anyway. [Aside: We should make a clear distinction between "observation control" parameters, and "pointing/focus model" parameters. Currently, subrXYZSegments is used to provide the "local focus correction". In the future, this will no longer be the case. subrXYZSegments should always be relative to the focus-tracking position, and will only be used to control scans (i.e. focus scans). To get "absolute" offsets, a pointing/focus model should be selected which has zeroes for the focus-tracking coefficients.

Currently, the xyz subreflector segment origin is relative to the focus tracking position. It becomes absolute when (a) the user disables focus tracking, or (b) zeros out the focus tracking model. I like your suggestion of using the b option.

Are there any other parameters which are currently serving double-duty in this way?]

None I am aware of.

We divide pointing/focus-tracking terms into three categories: "static", "scan", and "dynamic" (can you think of better names than these?").

I initially called the "dynamic" corrections "external", but I think "dynamic" is a more appropriate term.

Static Corrections

"Static" terms are stored in the database; new values are only enabled by reloading (or doing what?) to the Antenna Manager, are only changed by commissioning scientists/software engineers, and typically are fixed for an observing session (although they might be changed during the course of a commissioning session). Examples include the coefficients of the traditional pointing model.

Static terms are read from the PFM database, and recorded for the observer in the PFM fits file.

I agree. The current implementation has the new static terms as control parameters in the antenna manager. These hidden parameters are set by the antenna coordinator when a new configuration is selected. The antenna coordinator performs the database queries and sets the antenna manager static correction parameters. The AC also writes a FITS file analogous to the Measurements manager, containing the information.

Scan Corrections

"Scan" terms may be changed during observing on a scan by scan basis, under the explicit control of the observer (through the observing interface) or by the device under control. Examples include whether the active surface FEM corrections are enabled or disabled, local pointing corrections, and the polar motion corrections for the beginning of the scan (or could polar motion in fact become a static term?).

Polar motion and UT1-UTC are treated essentially as static terms, and the begining of scan values are written to the current FITS header.

"scan" terms are recorded for the observer in the FITS file of the relevant device (e.g. active surface manager, antenna manager).

Dynamic Corrections

"dynamic" terms are changed by the system in response to changing environmental conditions, asynchronously to running scans. Examples are the external Y-focus correction generated automatically from antenna temperature sensing system.

"dynamic" terms are set by the relevant PTCS component, and are recorded in separate Archivist FITS files from the relevant samplers (either in the device, or, as a service, in the Antenna Manager). Representative (i.e. at the mid-point of the scan) values of the dynamic terms are also stored in the Antenna FITS file.

Finally, note that pointing/focus is affected by the implementation of algorithms, e.g. subreflector actuator calibration. This can be tracked via the M&C build date written into the FITS file of each device, and the M&C CVS repository. Does this actually catch everything?

Pointing/Focus Model

(I can't decide whether it is better to present this as primary/ subreflector /main drives, etc, then static/ scan/ dynamic, or vice-versa. I prefer the order below; would the other be more useful?)

The complete Pointing/Focus Model and associated corrections consist of:

PointingFocusCorrections =
  ObservatoryTerms
  Primary Corrections +
  Subreflector Corrections +
  MainDrives Corrections +        <= is there a better name for this?
  Receiver Corrections

[*** N.B. Receiver Corrections includes per-receiver pointing and focus corrections. I guess this is a standard database problem; how is it handled? * ]

Yes many receiver focus and beam offset entries will reference a single configuration id in the configuration table. This many to one and one to many relationship is what databases do well.

I've taken a shot at a schema for this, and it is Here:

As noted, each of these have potentially a static, per-scan and dynamic terms. Each is discussed in more detail below.

Observatory Terms

These are the basic parameters of the Observatory, and are all static terms.

ObservatoryTerms =
   SiteLatitude +
   SiteLongitude +
   SiteElevation +
   SiteSystem +
   SiteType +
   Anything else

Where do quantities like the UT1-UTC correction come from, and where do we want to store these? Are these static terms or scan terms? Ideally, the UT1-UTC correction would simply be updated in the database as needed, and would then flow down to all other devices which required it. The values are extracted from a mark3.out file, which is updated by a cron job every Friday afternoon, just after it's release from the EROS (Earth Rotation and Orientation Service's??) web site.

The system re-reads this file periodically, so it is picked up by the antenna manager seamlessly. The values are given once a day, so just prior to the scan, values are linearly interpolated for the scan midpoint.

This information is currently recorded in the antenna FITS file:

DELTAUTC=  -3.5814E-01 / UT1 - UTC offset for beginning of scan
IERSPMX =   7.1020E-05 / X Polar motion correction for beginning of scan
IERSPMY =   8.4064E-05 / Y Polar motion correction for beginning of scan

Note the comments are incorrect, it should say scan midpoint.

Primary Corrections

Currently, these have no obvious effect on pointing, although they must have at some level. At this stage, these quantities are primarily simply to document the configuration of the system as used. This section is likely to be the subject of considerable refinement in the Spring.

Static terms:

PrimaryTerms =
  PhotogrammetryZeroPointFile + (eventually, the *contents* of the file
                                 should move to the database!)
  FemModelName                

I agree, both the FEM and the zero points should reside in the database.

Scan terms:

  ActiveSurfaceEnabled
  FemScaleFactor

Dynamic terms:

None

Subreflector Corrections

StaticTerms:

   
SubreflectorTerms =
   FocusTrackingCoefficients +
   FocusTrackingLUT +
  [ReceiverFocusOffset from Receiver table]
   EncoderCalibration
   Do we need anything like LDVT "home" positions???

The LDVT home position ends up becoming part of the calibration information. The actuator end points are not known beyond what the designers calculated.

FocusTrackingCoefficients =
   the 18 terms

FocusTrackingLut = up to six LUTs, one per d.o.f., on the basis of MNT_EL

This is one item I mistakenly omitted. If you feel strongly about having this, I should put this in.

EncoderCalibration = J.B. to provide details....

Scan terms LocalFocusCorrection (potentially six, one per d.o.f.) anything else?

Dynamic terms DynamicFocusCorrection (potentially six, one per d.o.f.)

Main Drive Corrections

Static Terms:

MainDrivesTerms =
   TraditionalPMCoefficients +  [Need one of these for Prime Focus!!]
   PMLut +
   EncoderOffsets +
   Anything else?

Scan Terms:

   DIABMODE   ] - I really think we should move these into the static
   POLARMTN   ]   terms, and disable CLEO control of them.
   LPCs

Agreed.

Dynamic Terms: Dynamic Pointing Corrections [Now want a SOAP interface to these!!]

Although not documented (yet), this is already part of the dynamic interface addition.

Receiver Corrections

Static Terms:

ReceiverTerms =
   ReceiverBeamOffsets +
   ReceiverFocusOffsets

Scan Terms: Currently none?

Dynamic Terms: Currently none?

-- JoeBrandt - 01 Oct 2003