NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Software > IDLPlanUpdate > GBTCalibrationModel

Changes | Index | Contents | Search | Statistics | Go

Discussion page for GBT Calibration Model

This is a discussion wiki page for ideas related to GBT calibration. It is expected that this will primarily be for discussions related to GBTIDL.

The problem that needs to be solved.

We currently assume that Tcal and Tsys are constant values in channel/frequency. Tcal is also assumed to be constant with time and to come from the measured values as associated with the data in the receiver FITS files. We need the freedom to allow for more variability, especially allow for Tcal and Tsys to vary across the bandpass. We need to design the infrustructure to deal with that need in such a way that it doesn't needlessly bloat the data that is stored on disk. We know that the original aips++ solution of a Tsys vector for each sampler at each integration leads to too much data bloat (at least that was the impression of users of that system - if that turns out to be the most appropriate solution we may simply have to live with it).

Calibration Use Cases

Calibration Infrustructure

These are some ideas I've had percolating in the back of my mind for some time. They are very much not complete ideas but I wanted them out here as a starting point. Feel free to reject them and suggest anything else at any time. I have no real idea how these might be implemented or what impact they might have on our current data model and data i/o.

I think we need to separate out the calibration model from the data model (where the data model is the data container and the disk files that contain several data containers). There would then need to be some way of associating a data container (or containers) with the appropriate data model.

I've been vaguely imagining a calibration model might be similar to synthesis calibration tables as found in classic AIPS (and probably aips++ if I was more familiar with how that works). Here we'd have a table with Tsys vs time where Tsys might even be sampled on it's own independent frequency axis (fewer channels) and time would typically be more than just one integration. The most appropriate choice of "solution interval" and frequency resolution here would depend on the type of data and, I suppose, the desired calibration accuracy. We would provide most appropriate guesses but the user could make other choices (possibly resulting in more data on disk). We could have a similar calibration table for Tcal or Scal (which the user could fill in via bootstrap methods - they might also fill in Tcal by bootstrap methods). What other quantities are appropriate in a calibration model? tau, apperture efficiency, ???

Essentially, I think this would be a data base that would get populated as the calibration process proceeds and used to generate the calibrated data. The ultimate design should be driven by the use cases since I think it would be easy to spend way too much time making this completely general when much of that generality might not be needed.

I think we could implement a static Tcal data base by providing direct access to the receiver Tcal tables from with GBTIDL. This would allow us to at least use Tcal as a function of frequency in a fairly short time scale. Some wide bandwidth modes on some receivers could benefit from that. Karen has contributed a few routines that essentially do that (getps_v2 and dops_v2 in the calib tree).

-- BobGarwood - 10 Jul 2006