How to calibrate the 19-channel array for data reduction ======================================================== File: kdata:[smt.doc]calib_bolo.doc (Michael Dumke, 17 Jan 2002) In order to correctly reduce their data, observers need to know some parameters of the 19-channel (or any other) bolometer array in use at the HHT. These parameters can be determined by planet observation, which should be performed by the observers themselves. However, in case there is no planet up during a project, and also to provide reference values for these parameters, we (the FoTs) should perform, reduce and analyse this kind of observations from time to time. The parameters to determine are: I. Offsets of the individual bolometer channels II. Relative gains of the individual bolometer channels III. Beamwidth IV. Conversion factor (counts --> mJy) V. Effective observing frequency The fact that two software packages (NIC and MOPSI) are capable to reduce bolometer data give us more than one method to estimate these parameters, but also requires some care due to different normalisations in the two packages. In the following I provide some kind of cookbook how to analyse the bolometer data in order to get the desired parameters. This information may be useful for observers, too. Usually I will take care of all this, but all FoTs should have an idea about the necessary steps ... ================================================================== I. Offsets of the individual bolometer channels. This information is required for OTF mapping, when 19 individual channels have to be averaged. Both NIC and MOPSI provide some standard procedures to calculate the offsets (and also the relative gains) from an OTF map of a planet. Even if it is only required for the relative gains, it is - since they are estimated with the same procedure - recommended to correct for the atmospheric extinction before (reduction of skydips). In NIC, use the following command sequence: > sic log BOLO_DATA: "/" > signal .asc > set opacity on > flag /reset > set gain_channel off > support > baseline /order 0 > makplan > fit > restore > fit /file sc_nic.fit new We recommend to estimate the channel parameters with NIC first, since the first fit procedure above (on the .mdb file) directly gives the beam separation you have to provide for the restoration in MOPSI. In MOPSI, use the following: > in-d "" > read t.raw no-rcp > base-ran 1 las > base-s 0 > dele rc 20 21 > taus > corr ext > init gfits > restore ! > rc-p gfits > write rc-p sc_mopsi.rcp The values contained in the output-files mean the position where the source will appear in a certain channel when the observation is centered in channel 1. While MOPSI gives the coordinates (0,0) for this channel, i.e. it shifts all values that the offsets for channel 1 are 0, NIC writes the fitted position for all channels with respect to the map center, which means that also the offsets for channel 1 are not 0. Note further that NIC writes the offsets in a system rotated ccw with elevation, and gives the values of interest only as a comment at the end of the file. When we follow the philosophy that an offset of channel 1 is due to incorrect pointing and should never occur, the NIC output should be shifted to be consistent with the MOPSI output. I have created two small tcl-scripts: * fit2rcp: Takes the output file from the FIT command in NIC, shifts the channel offsets so that channel 1 is at (0,0), and writes the offsets into a rcp-file in the format which is used by MOPSI. * rcp2nic: Takes a rcp-file created by MOPSI (or by fit2rcp) and writes the channel parameters into a NIC-Macro that can be used to update the channel-parameters within NIC. See the next section for some further notes about these rcp-files. ------------------------------------------------------------------ II. Relative gains of the individual bolometer channels The 19 channels show different gains, which has to be corrected for during data reduction. The procedure is the same as for the offsets; actually one determines (and corrects) channel offsets and gains in the same step. Here are some additional notes about the gains: * To correctly determine the channel gains, you must correct for atmospheric extinction before (i.e. reducing the skydips). * The gains are normalized differently in MOPSI and NIC. While in NIC the gain of channel 1 is set to 1.0, and all others relative to it, in MOPSI they are renormalized so that their average is about 1.0. The programs fit2rcp and rcp2nic account for that. But as a direct consequence of this normalization the conversion factor counts-->Jansky is different for both programs. How to use the rcp-files: MOPSI searches for a file named e.g. "2000s_21.rcp" or "2000a_21.rcp" (for spring and autumn, respectively) in the directory $ZYLKA_RCP - this environment variable is usually set to /home/smtop/bolo/rcp. You should have similarly named macros for NIC (e.g. "2000s_21.nic"), which can be produced by the rcp2nic program. NIC at the HHT knows a symbol called "load_rcp", which calls a macro that in turn selects the correct channel parameters according to the observing date. All these macros are/should be stored in the directory /home/smtop/bolo/rcp (and /home/smtsys/bolo/rcp for Tucson use.) Averaged channel parameters: As long as we do not know much about how these parameters change with elevation etc., we should keep averaged results from several (8 - 10) maps of different planets. It is recommended to make this average with the <...>.rcp-file and then create the NIC macro from the averaged file by calling rcp2nic. There is another tcl-script available which is called "rcpaver", which does this averaging on .rcp-files. Furthermore, the results obtained with NIC and MOPSI can also be averaged before creating the NIC macro, in order to provide the same channel parameters for both programs (except for the different normalization). Before doing this, the MOPSI-created average should be renormalized by another tcl-script, called "rcpnorm". ------------------------------------------------------------------ III. Beamwidth The beamwidth of the bolometer array can be estimated from planet maps or pointings. For the maps, follow the description in I. to estimate the channel parameters. The output-file will give you also the fitted beamwidth for each channel. Pointing scans can be reduced in NIC with the "solve" command, here you will also get the fitted beamwidth. Take this fitted beamwidth and the planet diameter (from the Astronomical Almanac) and enter it into the BEAMWIDTH program to get the instrumental beamwidth. Look at kdata:[smt.doc]beamwidth.doc for details. The HPBW of the 19channel is somwhere at 22" - 23". You need this value for the calibration (see IV.) - for extended planets a beamwidth error of 1" corresponds to about 2% in flux. ------------------------------------------------------------------ IV. Conversion factor (counts --> mJy) For an absolute calibration of the data one has to convert the measured "counts" into useful astronomical units, i.e. Jansky or Janksy/beam. The basic idea is simple: Measure the flux of a planet in counts and compare it with its flux in Jansky. Because of the different normalization of the relative channel gains in NIC and MOPSI you should use the conversion factor estimated from data in NIC to calibrate your NIC-reduced data, and that estimated from data in MOPSI for MOPSI-reduced data. An important point: You have to correct for atmopsheric extinction before reducing your planet data. a) Measured fluxes On-Offs: Reduce them as usual and write down the counts measured for channel 1 (before subtraction of adjacent channels, because planets are not point-like, and you will see them in other channels, too). b) "Theoretical" planet fluxes. To estimate the flux of a planet in Jansky, you can use the PLANETS subroutine within MOPSI. Upon entering PLANETS, you have to provide some information (that you can change later interactively) about telescope etc., but also about geocentric distance of the planet (get this from the Astronomical Almanac). Since planets are extended, the flux density [Jy] corresponds then to the integrated flux density (in a map), and the flux density/beam [Jy/beam] corresponds to the maximum in a map or the measured value at an On-Off. I think you can also estimate planet fluxes in ASTRO, but I've never done it. The conversion factor is somewhere around 0.9 - 1.0 mJy/count. ------------------------------------------------------------------ V. Effective observing frequency ... still to be done ... ==================================================================