NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Data > TWikiUsers > RonMaddalena > SpecLineCalibration > CalibrationStatus
   Changes | Index | Contents | Search | Statistics | Jump to Topic

Status of the Calibration Project for the GBT

The following outlines where we currently are in the development of calibration memos, software, documentation, etc. Plus descriptions of the steps that are in progress or are yet to begin.

Astronomical SCAL

Actually there are two aspects of this project. Determining SCAL over the full band of a receiver and the determining of SCAL over a narrower, single band. The first is more complicated and should be done by a staff member. The latter should be something we should make easy for the observer.

Full Receiver passband

Status:

To Do

Observer's passband

To Do:

Engineer's TCAL values

These are still necessary if we want to determine telescope efficiencies. But, we now only need a handful of values across the passband of a receiver instead of a fully-sampled data set. However, the trade off is that these few engineer's values must have a high degree of accuracy.

My draft memo with Chelen describes how one goes from astronomical determined SCAL values, and the handful of engineer TCAL values to a high frequency resolution, high accuracy table of astronomically determined TCAL values.

Weather Information

Air Mass

1/sin(el) approximation starts to break down below 20 deg for high accuracy calibration. I have developed a better approximation than 1/sin(el) that is good to 5 deg. But, this used only 6 months of my archived weather data.

To Do:

Opacity

The current AIps++, GBTIDL calibration algorithms already accept scalar opacities. This isn't sufficient for high frequencies where opacity can double across our wide bandpasses. We thus need to alter our algorithms to use opacity vectors/tables/function (see vector data bases below).

I now have an alpha version of a GUI frontend for my opacity forecasts that anyone can now use to determine opacities within the last year at frequencies of 5 to 110 GHz. But, we need a way to get the output of this program into a opacity vector that GBTIDL can use.

Users may want to measure opacities using the GBT. We need the tipping plugin for GFM for low frequency, narrow band observers. Wide band, high frequency spectral-line observers should use multiple DCR-AFR samplers for their tippings so as to sample multiple narrow band frequencies that are scattered across their full spectral-line observing bandwidth. Line tippings aren't practical due to the limited dynamic range of our backends.

I've pretty much given up on the concept of using the 86 GHz tipper as a way to reliably determine opacities.

To Do :

Extended opacity modeling to 230 GHz - RJM 3/5/06

Tatmosphere

Values for the effective temperature of the atmosphere are needed before one can fit a tipping curve. My CLEO forecast application can now provide users with a value suitable for their observing frequency, date, etc.

Found a way to use a lookup table to provide Tatm to an accuracy of 5 K, better than that required for 1% calibration accuracy - RJM 3/5/06

To Do:

Non linearities & Calibration

The assumption that Pout = B * Pin fails for the GBT for high accuracy calibration. We've been exploring the Taylor expansion of Pout = f(Pin) where f is an arbitrary function. Using On-off data of a known calibrator, and using the noise diode, we can determine up to the second-order terms in the Taylor expansion. [Note: This work is orthogonal to Toney's efforts on baseline shapes in the presence of non-linearities.]

Although one can very reliably measure the existence of non-linearities, and even estimate their affects on data that's been processed as if the system were linear, it's not clear that one should actually correct the data for non linearities. We've had mixed results doing this and more work is needed.

A draft memo exists explaining the measurements and data reduction.

To Do :

Aperture Efficiencies

Two aspects of this project. Yuri/Frank's efforts are meant to determine efficiencies as a function of elevation at a single frequency within a receiver's band. The absolute accuracy of their results are compromised since they are using the engineer's TCAL that have an accuracy of ~10%. Since the inaccuracy of Tcal and efficiencies wash out in their analysis, their results don't compromise the quality of an observer's calibration if the same Tcal tables, exact observing frequencies, etc. are used.

My efforts with Chelen of combining high accuracy engineer TCAL values with astronomical measurements provide efficiencies (frequency-dependent at the higher frequencies) that have a higher absolute accuracy but only for a single elevation.

To Do:

Beam Efficiencies

Every pointing measurement we do has the unexploited benefit of providing the conversion factor to derive beam from aperture efficiency. This is discussed in my calibration memo.

Other calibration factors

Except for some theoretical prediction, many that uses an optical setup that's different from the final telescope, we do not have measurements of eta_l, eta_fss and Tspill(elevation). We may never be able to measure these directly. The accuracy of our calibration, the accuracy of opacities from tippings, ... are somewhat compromised by this lack of good measurements.

To Do:

Calibration Algorithms

The current state of the calibration memo has been sufficient for us to implement the rudimentary, scalar calibration now done in GBTIDL. The GBTIDL algorithms are robust for some classes of experiments and are typical of what one finds in all single-dish analysis packages.

We've built into GBTIDL the concept that our calibration routines will always act as templates for people who want to go beyond what we've developed so far. Although our GBTIDL algorithms will be useful for the majority of our users, there's a number of classes of GBT experiments where we can do better and will need to go beyond what has, up to now, been typically provided by observatories.

To Do:

Pipelining/E2E/UFO

Once the above infrastructure exists, the next step will be how one can specify the desired calibration when pipeline processing data. The number of options to specify the desired calibration is large so the UI problem will be interesting to solve. The above mentioned decision tree will be critical for helping the user decide.

Since calibration involves compromises, we can expect that a user may want to specify multiple calibration options and methods, implying that the pipeline will fork producing multiple calibrated data sets. Forking pipelines will also add interest to the E2E efforts.

Topic CalibrationStatus . { Edit | Attach | Ref-By | Printable | Diffs | r1.6 | > | r1.5 | > | r1.4 | More }
Revision r1.6 - 07 Mar 2006 - 16:40 GMT - RonMaddalena
Parents: TWikiUsers > RonMaddalena > SpecLineCalibration
Content copyright © 1999-2007 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors.