NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Software > PlanOfRecordC72005 > ModificationRequest12C705

Changes | Index | Contents | Search | Statistics | Go

Quality Checks on Ka Band Receiver FITS Files

Modification Request #12 (C07 2005)

• 1. Introduction
• 2. Background
• 3. Requirements
• 4. Design
  • 4.1 Ka Reciever Scan Files
  • 4.2 Ka Reciever data quality rules
  • 4.3 Changes to =GFM=
• 5. Deployment Checklist
• 6. Test Plan
• Signatures
• CCC Discussion Area

1. Introduction

This MR is essentially the implementation of the rules spelled out in the previous MR, ModificationRequest1C605, for the GFM application.

Brian Mason would like GFM to check that the Ka band receiver was configured in a fashion suitable for one of the calibrations that GFM knows how to apply. If the receiver was not configured in the appropriate fashion then GFM should revert to a "raw" mode, which will still enable deriving pointing & focus offsets, which are essential GFM functions and don't depend on if or how you calibrate the data. It would be suitable to have some warning and change labels on plots & reports, as results are not actually in Kelvin. This is all for pointing, focus, & tipping.

Testing the validity of the raw data for GFM calibration is the goal. The fundamental condition to be met is: If the Ka Band receiver is configured appropriately (as determined by application of data quality rules specified below), then GFM should calibrate the data, otherwise GFM should revert to raw mode.

One Ka band receiver FITS file is produced per scan. One additional calibration FITS file should be present in the receiver directory, as is the case for all receivers. Development will use the data in /home/archive/problem-data/tape-0001/CKA_14NOV04 as a basis for developing this MR.

2. Background

One Ka band receiver FITS file is produced per scan. One additional calibration FITS file should be present in the receiver directory, as is the case for all receivers. Development will use the data in /home/archive/problem-data/tape-0001/CKA_14NOV04 as a basis for developing this MR.

3. Requirements

The main requirement for this MR is that all the data quality checks specified in Ron Duplains previous MR are implemented for the online quick look application, GFM.

Below is a table specifiying exactly how GFM should respond when the above mentioned rules are applied. Not included are the basic checks for file existense and proper generic configuration, in which case GFM should raise an appropriate error message.

If	Apply This Rule	If the Rule isn't satisfied (ie is false)
Backend is CCB	PHASSRC must equal CCB	WARN User: Receiver not configured for use with CCB
Backend is CCB	CALSRC must equal CCB	WARN User: receiver not configured for use with CCB
Backend is NOT CCB	LCALTRAK and RCALTRAK must be TRUE	GFM should calibrate your data
Backend is NOT CCB	LCALTRAK or RCALTRAK is FALSE	GFM should operate in raw mode
Backend is NOT CCB and you are Beamswitching	PHASSRC must equal EXT	WARN User: Receiver not configured for switching signals
Backend is NOT CCB and you are Beamswitching	CALSRC must equal EXT	WARN User: Receiver not configured for switching signals
Backend is NOT CCB and you are Beamswitching	D1SRTRAK and S1SRTRAK may not have the same value AND D2SRTRAK and S2SRTRAK may not have the same value, where all of these keywords have values of T or F. [Logical expression: (D1SRTRAK XOR S1SRTRAK) AND (D2SRTRAK XOR S2SRTRAK)]	WARN User: Receiver not configured for switching signals

"Beamswitching" means that SWSTATE must equal BSWITCH in GO FITS file.

- These requirements are not to be implemented this cycle, but are included in the CCB/GFM MR, where they will be implemented next cycle. This is due to the fact that the CCB is not ready yet, and all of our current code is DCR-specific.

4. Design

4.1 Ka Reciever Scan Files

• Scan Files refer to the fits files that are produced for every scan, using the same timestamp convention as other device files (as opposed to the single calibration file).
• The existence of these scan files in the same directory (/home/gbtdata/project/Rcvr26_42) as the calibration file breaks the previous used model for project device files.
• An additional complication arises from the fact that the current test data we have does not include these scan files in the ScanLog.fits file.
• Changes in both the Scan and Project classes must be made to:
  • include these scan files if they are not listed in the ScanLog.fits file.
  • open fql connections to the scan files when using the Scan class for a specific scan.
• These changes will include specific checks to see if the 'device' is 'Rcvr26_42'. Although these kind of checks are not ideal, since the Ka Rcvr is so unique, it seems unavoidable.

4.2 Ka Reciever data quality rules

• The specific rules spelled out in the previous MR must be encapsulated in a logicical location.
• We will implement these rules in a new class, 'Rcvr26_42', in the sparrow/gbt/api/receiver directory. The current code in this directory may not be in use, so perhaps it should be removed.

4.3 Changes to GFM

• The new Ka Reciever class, and will be used to guide =GFM='s correct response for pointing, focus, and tipping scans.

5. Deployment Checklist

The above changes will only affect the GFM application, more specifically, its pointing, focus and tipping plugins. No changes need to be made in the control system, other interfaces, such as CLEO, or in analysis tools, such as SDFITS, or GBTIDL.

6. Test Plan

We have test data which we will use for constructing unit tests: /home/archive/problem-data/tape-0001/CKA_14NOV04

We will use the following scans from project TKA_18MAR05 to test the gfm quality checks

we will copy the data to another place and manually tweak the keyword values to invoke error conditions, whose validity we will verify. This will not affect the real data b/c we're working on a copy.

Signatures

APPROVED: I acknowledge that my request is fully contained in this MR, and if the SDD delivers exactly what I specified, I will be happy.

ACCEPTED: I acknowledge that I have validated the completed code according to the acceptance tests, and I am happy with the results.

Written	- PaulMarganian - 20 Oct 2005
Checked
Approved by Sponsor	- BrianMason - 20 Oct 2005
Approved by CCC	symbol - name - date
Accepted/Delivered by Sponsor	symbol - name - date

Symbols:

• Use %X% if MR is not complete (will display )
• Use %Y% if MR is complete (will display )

CCC Discussion Area