NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Data > GbtFitsMonitorContinuumRequests > GbtFitsMonitorRegressionExamples

Changes | Index | Contents | Search | Statistics | Jump to Topic

Gfm Regression Examples

• Gfm Regression Examples
  • Where's the data??
  • Good scans for testing focus fitting
  • Scans for testing how GFM copes with "failed" scans
  • Some good Ka-band scans which should fail heuristics, but don't
  • Good test/"bad" datasets.
  • Problem scans
    • The "beam offsets" table problem.
    • Outstanding problem scans.
    • Resolved problem scans for GFM Integration Version 3; 2004 Cycle 3; 12 May 2004.

This page contains examples of peak/focus scans which are expected to provide a good test of the peak/focus fitting algorithms in GFM, and can be used to both check upgrades to the program, and provide test cases for things which are not working well. Some large data-sets which should provide useful additional checks are available at the GbtFitsMonitorBenchmarks page.

Where's the data??

If you can't find the data in /home/gbtdata, look in /home/gbtmirror.

IF you can't find the data in /home/gbtmirror, look in /home/archive/test-data or /home/archive/science-data (both only available to the 192 network).

Good scans for testing focus fitting

/home/gbtdata/TPTCSRMP_041104 Scans 15 to 27. Note, very windy for scan 23.

Scans for testing how GFM copes with "failed" scans

/home/gbtdata/TPTCSDSB041021 Scans 608 - 611. Scan 611 fails because the DCR configuration got screwed up by some unathorized parallel testing. Ideally GFM would process 610 on its own, and use this for the El correction. This works in the Nov 15th 2004 version of gfm-test!

Some good Ka-band scans which should fail heuristics, but don't

/home/gbtdata/TKABSM_23OCT04 Scans 67-70 and 72-75 c.f. scans 3-6

Good test/"bad" datasets.

We have defined two large datasets, TPTCSRMP031229 Scans 5 - 404 and TPTCSDSB040225 All scans, which provide a good workout for gfm on "good data". Benchmarking and the "correct" results for each of these have been recorded, and these should be re-run every time a new version of gfm is developed. Details are at the GbtFitsMonitorBenchmarks page.

TPTCSRMP040515 has some particularly bad RFI and weak sources, which provide a good test for the error-trapping capabilities. Many scans are bad, but particularly 1-4, 9, 22-25, 35-38, 54-57, 62, 74-77 (output messages seem wrong), 78-81 (would be a good test of relaxed limits), 93-96 (ditto), 107-110 (ditto), 111-114, 115 (good focus test) 116-119 (heuristics), 120-123, 124-127, 128 (focus heuristics) 129-132 (heuristics).

Problem scans

These is a list of scans, the majority of which are flawed in some way, which provide a good test of the exception-handling capabilities of gfm. Scans are divided into those which give unexpected results in the current version of gfm, and those which are handled as expected. All of these scans should be checked each time a new version of gfm is developed, to ensure the exception-handling capabilities have not regressed. Problems to date can be divided into four main categories:

• Problems handling bad input data in a clean manner (e.g. missing GO FITS file; Antenna FITS file errors).
• gfm getting confused over scan handling in off-line mode after encountering a bad scan.
• Not fitting data which look good;
• Correctly fitting data (as evidenced by scan summary), but claiming the fit is bad and/or not plotting it.

The "beam offsets" table problem.

Note, the GFM Integration Version 4; 2004 Cycle 3; 5 May 2004 version of gfm-test handles both of these correctly

The antenna FITS files contains a binary tables extension BEAM_OFFSETS, which specifies the cross-elevation and elevation offsets of the individual feeds. This table was introduced with FITSVER 1.3. The definitions of the beam offsets was accidentally changed in FITSVER 1.6, which corresponds (I think) to M&C versions 3.19 through 4.2. Here are some example beamswitched datafiles from FITSVERS 1.5 and FITSVERS 1.6.

FITSVER 1.5

Project /home/archive/test-data/tape-0001/TPTCSDSB031107, Scans 5-8. K-band data. BEAM_OFFSETS table for scan 5:

   NAME        BEAMXELOFFSET         BEAMELOFFSET        SRFEED1      SRFEED2
    32A                   1D                   1D             1J           1J
   none                  deg                  deg           none         none
      1   0.000000000000E+00   0.000000000000E+00              1            2
      2   4.966666666667E-02   0.000000000000E+00              1            2
   MR12   2.483333333333E-02   0.000000000000E+00              0            0
      C   2.483333333333E-02   2.483333333333E-02              0            0

FITSVER 1.6

Project /home/archive/test-data/tape-0001/TPTCSRMP031222, Scans 170-173. Ku-band data. BEAM_OFFSETS table for scan 170:

   NAME        BEAMXELOFFSET         BEAMELOFFSET      SRFEED1      SRFEED2
    32A                   1D                   1D           1J           1J
   none                  deg                  deg         none         none
      1   4.583333333333E-02   0.000000000000E+00            1            2
      2  -4.583333333333E-02   0.000000000000E+00            1            2
      C   0.000000000000E+00   0.000000000000E+00            0            0
   MR12   0.000000000000E+00   0.000000000000E+00            0            0

Outstanding problem scans.

None!

Resolved problem scans for GFM Integration Version 3; 2004 Cycle 3; 12 May 2004.

TPTCSDSB031002 Scans 23 through 26 (in /home/archive/test-data/tape-0001). TPTCSRMP031115 Scan 71 Baselines looks completely wrong in earlier versions.

AGBT04A_022_05 Scan 285: This scan highlights a bug in Numeric.exp under Linux. The same scan processes fine under Windows. Switched to numarray.exp.

TPTCSRMP031211 Scan 365 (focus scan) and others in /home/archive/test-data/tape-0001. After processing some of the DCR corrupted scans (may be coincidence) gives: Error processing scan 365 : error reading keyword FTRKYDA: keyword not found in header

TPTCSDSB040221 Scans114/115. These were the start of peak accidentally done in C beam. 115 was aborted. 114 processes fine (no signal there), 115 results in the error messages:

Scan 115 : Gaussian fit failed for data after baseline removed.
Error processing scan 115 : exceptions.TypeError

but after this, the plot stops updating.

TPTCSRMP031211 Scans 460 - 463 (in /home/archive/test-data/tape-0001). No obvious signal present (can't remember why). 461 produced a stack dump in earlier versions of gfm. Produces:

Scan 461 : Gaussian fit failed for data after baseline removed.
Error processing scan 461 : exceptions.TypeError

but after this plotting stops updating

TPTCSDSB040225 Scan 171. This scan was aborted, so do not expect a fit.

TPTCSRMP031229 Scan 1 (in /home/archive/test-data/tape-0001). No GO FITS file.

TPTCSRMP031211 Scan 349, 367, 417, 459 (in /home/archive/test-data/tape-0001). The DCR data was corrupted (perhaps a missed tick)? These caused a stack dump in earlier versions of gfm.

AGBT02C_012_03 Scans 3625-3628. Antenna FITS file corrupt for 3625? Produced a stack dump in earlier versions of gfm.

From previous data, and scans 3627 and 3628, scans 3625 and 3626 are expected to be ok. gfm-test (04/13/04) fails with a stack dump on 3625. It will plot 3626, but produces an obviously incorrect fit (fits to a noise bump).

TPTCSDSB040408 Scans 1-4, 6-9. SRFEED information in IF Manager FITS file was incorrect (due to a bad Q-band receiver config file). This was cured by having gfm look in the Antenna FITS file for the SRFEED information.

TPTCSRMP031229 Scans 607-610 (in /home/archive/test-data/tape-0001). Same as above.

AGBT02A_025_02 Scans 1003-1006. This is an example of K-band data taken in the "fourth" beam, so that the reference beam is at lower azimuth rather than higher. This gave problems for earlier versions of gfm.

PCO2C17_01 Scans 20-23 In earlier versions of gfm Scan 20 processed normally. Scan 21 reports "gaussian fit of data failed", and fit is not plotted. But, at the end of four scans, the printout reveals that Scan 21 was indeed fitted (and in on-line mode, the LPCs were updated). Same problem occurs on scans 47 and 48 in set 47-50

TPTCSRMP040406 Scans 99-102. Same problem as above.

-- AmyShelton - 05 May 2004