• GbtCcbPaper

Discussion for June 9: CcbCmbJune9

• get peak/focus filters working properly

• look into repeatability from commissioning data (use steep spectrum sources, listed at Projects.CcbCommData)
• quantify effect of wind on our data

• look into repeatability from commissioning data (use steep spectrum sources, listed at Projects.CcbCommData) -- LCW
  • determine best way to calibrate the data.
• make source lists for power law fit.
• mocks: verify new pipeline with source strategy.
• pour over The Real Data -- LCW & BSM
• verify focus working

• BSM give larry matlab scripts to analyze DCR peaks and focuses

• Goodness of Fit - BSM

• Goodness of Fit - BSM

• TP Calibration - BSM

• TP Calibration - BSM -- sort of did-- update to ACAL

• Goodness of Fit - BSM
• Distribution -> Source Count Model - LCW
• Sources in Ref Beam - BSM
• TP Calibration - BSM

• Some weather forecasting resources I use: intellicast, Ron Maddalena's detailed forecasts.

• Some weather forecasting resources I use: intellicast, Ron Maddalena's detailed forecasts.

Structure Description: CcbCmbIDLGuide

Results

• CcbCmbResults

A useful link: our Ka/CCB channel identifications summary

• do we need separate beam heights for 1 and 2?

• Remote Observing: we'll need an ssh tunnel and vnc client set up for remote observing, detailed instructions to go here later.

• Remote Observing: is done by vnc. the gbt hardware lives on the "gbt" network (as in foo.gbt.nrao.edu) which is only accessible via the gb network (as in foo.gb.nrao.edu), so two hops via ssh tunnelling or port forwarding are needed. Note that by just getting into the gb network on vnc you can run many useful things (like astrid, to validate and submit your SBs to the database ahead of time to the appropriate project code)
  • how to go about observing remotely

The exception is that the python source code for my custom-defined scanning procedure, and for autopeakfocus2, live elsewhere, but my SBs add those to the path.

Larry and Brian agreed to put SBs for individual runs there directly or in subdirectories of it as seems appropriate. These will be ASCII text files that will need then to be imported and validated into ASTRID.

A page to track individual runs is at CcbCmbRuns. The idea is to put notes from each run here. I will also add some notes on common known issues and procedures (restart turtle; archivist fix) that we can build on...

The exception is that the python source code for my custom-defined scanning procedure, and for autopeakfocus2, live elsewhere, but my SBs add those to the path. Larry and Brian agreed to put SBs for individual runs there directly or in subdirectories of it as seems appropriate. These will be ASCII text files that will need then to be imported and validated into ASTRID.

• Page to track individual runs, tabulate standard bugfixes, etc: CcbCmbRuns
• Some weather forecasting resources I use: intellicast, Ron Maddalena's detailed forecasts.
• Telescope schedule links, once again:
  • the monthly view (click "graphics" for the month you want) -- http://wwwlocal.gb.nrao.edu/GBTopsdocs/GBTschedules/schedules.html
  • the two week view, which has dynamic scheduling info -- http://gbrescal.gb.nrao.edu/webcal/webcal.dbw?view=twoweek
• Finally, Carl Bignell's alpha-version interface to list your upcoming runs: http://gbrescal.gb.nrao.edu/proposals/remoteobs.dbw

• http://www.gb.nrao.edu/~bmason/ccb/run21dec05/
• http://www.gb.nrao.edu/~bmason/ccb/run22dec05/
• http://www.gb.nrao.edu/~bmason/ccb/srcPlots/

• http://www.gb.nrao.edu/~bmason/ccb/run21dec05/ -- fits to data (raw and calibrated)
• http://www.gb.nrao.edu/~bmason/ccb/run22dec05/ -- ditto
• http://www.gb.nrao.edu/~bmason/ccb/srcPlots/ -- summary of flux density meas'ts for these 2 runs

• Time allocated -- In addition to the 51h for 4A27 and 4A38, the whole of 6A49 (~155h) was scheduled over Feb/Mar/Apr. observing schedule links go here

• Time allocated -- In addition to the 51h for 4A27 and 4A38, the whole of 6A49 (~155h) was scheduled over Feb/Mar/Apr. Here are useful telescope schedule links:
  • the monthly view (click "graphics" for the month you want) -- http://wwwlocal.gb.nrao.edu/GBTopsdocs/GBTschedules/schedules.html
  • the two week view, which has dynamic scheduling info -- http://gbrescal.gb.nrao.edu/webcal/webcal.dbw?view=twoweek

• How much time will we lose to the weather? -- Our constraints are that the sky emission must be stable and the wind must be low enough not to significantly bias our flux density measurements. An integrated precipitable water vapor column of 10mm or less typically will also have stable photometric conditions; and 10mph sustained winds cause 10% rms flux density errors due to excitation of feedarm vibrations (this evaluation was from "peak crossing" scans though, and I think the effect will be a bit less for our nods-- needs looking into from our own data). Taking these as our limits, archival weather data over the whole winter tells us to expect 40% of the time to be good. A shortcoming of these analyses is that they don't include the contribution of clouds to the opacity (that information isn't in the historical database). Also, they are averaged over the whole high frequency season including the best months which we've already missed-- although Fred Schwab is coming up with a month-specific breakdown. Also there is a significant annual scatter. All things considered BSM thinks it's reasonable to expect only half of the runs we actually execute to be useful for source vetoing. We will refine this when Fred comes back with month-specific answers...

• How much time will we lose to the weather? -- Our constraints are that the sky emission must be stable and the wind must be low enough not to significantly bias our flux density measurements. An integrated precipitable water vapor column of 10mm or less typically will also have stable photometric conditions; and 10mph sustained winds cause 10% rms flux density errors due to excitation of feedarm vibrations (this evaluation was from "peak crossing" scans though, and I think the effect will be a bit less for our nods-- needs looking into from our own data). Taking these as our limits, archival weather data over the whole winter tells us to expect 40% of the time to be good. This is close to the 50% assumed in the GBT scheduling process, ie, our runs are double-booked. A shortcoming of these analyses is that they don't include the contribution of clouds to the opacity (that information isn't in the historical database). Also, they are averaged over the whole high frequency season including the best months which we've already missed-- although Fred Schwab is coming up with a month-specific breakdown. Also there is a significant annual scatter. All things considered BSM thinks it's reasonable to expect only half of the runs we actually execute to be useful for source vetoing. We will refine this when Fred comes back with month-specific answers...

• GBT Pointing Stability -- This is the key issue for our veto campaign. Three main worries: wind, "routine failures", and "scan-start ringing". We log wind data during the observations and, nominally, we should toss out data where the wind was greater than 10 mph or so. We should have a good look at the pointing calibrator data and determine the precise cut threshold ourselves; and whether we need to toss the whole scan, or just flag those integrations where the wind was bad. We may even be able to push the wind cut substantially higher by say, an empirical model involving wind direction and telescope pointing location... Spring is somewhat windy, and this might gain us a good amount of extra data!!

• GBT Pointing Stability -- This is the key issue for our veto campaign. Three main worries: wind, "routine failures", and "scan-start ringing". We log wind data during the observations and, nominally, we should toss out data where the wind was greater than 10 mph or so. We should have a good look at the pointing calibrator data and determine the precise cut threshold ourselves; and whether we need to toss the whole scan, or just flag those integrations where the wind was bad; or if we need to flag the scan symmetrically in time, etc. We may even be able to push the wind cut substantially higher by say, an empirical model involving wind direction and telescope pointing location... Spring is somewhat windy, and this might gain us a good amount of extra data!!

A big worry BSM had was the scan-start ringing however this appears to be much less problematic than his earlier experience indicated. Just looking at the bright-source data from 21 and 22dec, I would say that no scans have their fitted flux densities affected by more than 10%-- and most by much less-- by being off-source or vibrating initially. For these observations 20 sec was spent in each NOD phase, and a 20 sec dwell was inserted at the start to let ringing die off. The cleanness may be due to the observing strategy: before the scan starts we have already done a slew to the beam we're going to start with, and perhaps this antenna problem just isn't invoked that way. I suggest that we cut the starting dwell to 10 sec (matching the 10 sec per NOD phase we have planned anyway) and watch this like a hawk... if the behavior continues to be good, we can probably eliminate even that 10 sec dwell on our real sources-- probably keeping it on the calibrators as a check.

A big worry BSM had initially was the scan-start ringing. This happens when a bug in the antenna manager or servo code caused an abrupt scan-start motion that excited vibrations in the GBT feedarm. However this appears to be much less problematic than earlier experience indicated. Just looking at the bright-source data from 21 and 22dec, I would say that no scans have their fitted flux densities affected by more than 10%-- and most by much less-- by being off-source or vibrating initially. For these observations 20 sec was spent in each NOD phase, and a 20 sec dwell was inserted at the start to let ringing die off. The cleanness may be due to the observing strategy: before the scan starts we have already done a slew to the beam we're going to start with, and perhaps this antenna problem just isn't invoked that way. I suggest that we cut the starting dwell to 10 sec (matching the 10 sec per NOD phase we have planned anyway) and watch this like a hawk... if the behavior continues to be good, we can probably eliminate even that 10 sec dwell on our real sources-- probably keeping it on the calibrators as a check.

There are two low-level, known servo issue that are visible in our data but won't significantly affect our results. One is a 1 Hz oscillation in the servo, often visible on bright sources. This will impose a percent or two multiplicative RMS to the signal. THe other is that we consistently "overshoot" when slewing in one direction of the NOD. BSM thinks this is due to a (known) stiction problem in the servo-- in one direction you are slewing w/the sky, in the other against, and go through zero velocity. Under low-wind conditions the antenna indicated positions capture this overshoot quite well (see the agreement between model and data), and it is a small fraction of the time in the nod, so it won't bias our results.

There are two low-level, known servo issue that are visible in our data but won't significantly affect our results. One is a 1 Hz oscillation in the servo, often visible on bright sources. This will impose a few percent multiplicative RMS to the signal. THe other is that we consistently "overshoot" when slewing in one direction of the NOD. BSM thinks this is due to a (known) stiction problem in the servo-- in one direction you are slewing w/the sky, in the other against, and go through zero velocity. Under low-wind conditions the antenna indicated positions capture this overshoot quite well (see the agreement between model and data), and it is a small fraction of the time in the nod, so it won't bias our results.

• • Calibration: allow 1-min slew each way to/from the calibrator. A peak scan (slew back then forth in az; back then forth in el-- 4 scans of 30 sec each) takes 3 min with overheads. A focus, with overheads, takes 2 min. The otfnod will take 1.5 min.
  • per-night inefficiencies: plan on losing 1/2 hour on average to setup the system, allowing for occasional failures (i think this is conservative). Allow a 10 min initial slew. Allow for two peaks and focuses on your primary calibrator or a total of 10 min, and 1.5 min for an otfnod.
• System Configuration:

• • Secondary/pointing Calibration: allow 1-min slew each way to/from the calibrator. A peak scan (slew back then forth in az; back then forth in el-- 4 scans of 30 sec each) takes 3 min with overheads. A focus, with overheads, takes 2 min. The otfnod will take 1.5 min.
  • Primary calibrator-- do the same observations as are done on the pointing calibrator.
  • per-night inefficiencies: plan on losing 1/2 hour on average to setup the system, allowing for occasional failures (i think this is conservative). Allow a 10 min initial slew. Allow for two peaks and focuses on your first calibrator or a total of 10 min, and 1.5 min for an otfnod.
• System Configuration: I have been running the CCB with 5ms integration time, 4 kHz beamswitch rate, 25 usec blanking; and 2 out of 20 integrations have the A cal on.

• • gbtstatus: (type "gbtstatus") This is a configurable status summary that can be run in a terminal window, which is excellent for remote observing. I haven't used it much but we should start. I think that for our observations this can quickly replace CLEO (or many CLEO windows).

• • gbtstatus: (type "gbtstatus") This is a configurable status summary that can be run in a terminal window, which is excellent for remote observing. I haven't used it much but we should start. I think that for our observations this can quickly replace CLEO (or many CLEO windows). Documentation for the GBTSTATUS display is here

Here is some GFM documentation.

• • • A good astrid overview

• • • config tool documentation
    • Astrid-valid config tool script that sets up the CCB for our observations
    • same, but sets up DCR fot point/focus observations

• • example CCB scheduling block

• • Special tweaks: there are a number of special tweaks to our standard observing setup. 1) we turn off and reroute the system local oscillator (needed for spectral line observations) so it doesn't affect our data. This is done by the line execfile("killlo.py"). 2) We add the weather station to the "archivist", which will generate scan-synchronous weather data FITS files. This is done by execfile("addwx.py"). 3) Instead of the standard Astrid Peak() and Focus() routines, for high-frequency observing we have a new AutoPeakFocus2?() routine which has a number of desirable procedures, notably, an improved active-surface look-up-table which yields quite flat gain curves between 20 and 80 deg elevation. 4) BSM (with others) has implemented custom trajectories for the nods. The actual trajectories live in FITS files in ~bmason/gbt-dev/scanning/ptcsTraj/. The files are read into the scheduling block by a python procedure called readFitsTraj(), and executed by a custom observing procedure called dotrajectory().

• • Special tweaks: there are a number of special tweaks to our standard observing setup. 1) we turn off and reroute the system local oscillator (needed for spectral line observations) so it doesn't affect our data. This is done by the line execfile("killlo.py"). 2) We add the weather station to the "archivist", which will generate scan-synchronous weather data FITS files. This is done by execfile("addwx.py"). 3) Instead of the standard Astrid Peak() and Focus() routines, for high-frequency observing we have a new AutoPeakFocus2?() routine which has a number of desirable procedures, notably, an improved active-surface look-up-table which yields quite flat gain curves between 20 and 80 deg elevation. 4) BSM (with others) has implemented custom trajectories for the nods. The actual trajectories live in FITS files in ~bmason/gbt-obs/gbtcbiruns/. The files are read into the scheduling block by a python procedure called readFitsTraj(), and executed by a custom observing procedure called dotrajectory().
• Notes on particular procedures: or Astrid/ObservinAPI "Scan Types"...
  • Peak and Focus have been subsumed into AutoPeakFocus? which does them all... which in turn has been subsumed into AutPeakFocus2?, which implements a new active surface model and has other nice options (like allowing the automatic configuration that AutoPeakFocus? does to be overridden)
• Remote Observing: we'll need an ssh tunnel and vnc client set up for remote observing, detailed instructions to go here later.

A page to track individual runs is at CcbCmbRuns. The idea is to put scheduling blocks for individual runs here; along with the observer's notes for that run, and subsequent notes from the analysis and data inspection.

Nearly all the files referenced in my template scheduling block live in the world read-writable directory ~bmason/gbt-obs/gbtcbiruns/ The exception is that the python source code for my custom-defined scanning procedure, and for autopeakfocus2, live elsewhere, but my SBs add those to the path.

Larry and Brian agreed to put SBs for individual runs there directly or in subdirectories of it as seems appropriate. These will be ASCII text files that will need then to be imported and validated into ASTRID.

A page to track individual runs is at CcbCmbRuns. The idea is to put notes from each run here. I will also add some notes on common known issues and procedures (restart turtle; archivist fix) that we can build on...

Include known issues (restart turtle; archivist fix)

• Issues to look into carefully
  • objective, quantitative criteria for wx (photometric stability, wind)
  • antenna/rx characterization from the data (a service-to-gb type activity)... we'll have a large and uniform database
  • add in ability to analyze DCR (as opposed to CCB) peak/focus data... or use GFM?

• is done in IDL. Note this has nothing to do with GBTIDL, which is a set of IDL procedures written to analyze GBT spectral line data

RANDOM LINKS TO FIT IN http://wiki.gb.nrao.edu/bin/view/Software/ObservingTools

• finish this page! (Brian)
• review astrid calibrator catalg (Brian/Larry)
• create science target catalogs in astrid format (Larry)
• create SB's for the first observations, just by changing the source list section and referenced astrid catalogs, and giving the file an appropriate name
• extract items from above... (bsm)

• quantify effect of wind on our data
• BSM give larry matlab scripts to analyze DCR peaks and focuses

• • a series of observations of program sources: between 20 and 27 CBI-field sources observed with the CCB, and a single point/focus check (data collected with the DCR until GFM accepts CCB data, which will be soon) along with a CCB nod on the pointing calibrator.

• • a series of observations of program sources: with the timing described below (1.5min total per source) we can observe between 20 and 27 CBI-field sources with the CCB; followed by a single point/focus check (that data will collected with the DCR until GFM accepts CCB data, which will be soon) along with a CCB nod on the pointing calibrator.

• System Configuration

• System Configuration:

• Programs the user sees: Before starting any of these programs you need to source /home/gbt/gbt.{c,ba}sh depending on your shell.

• Programs the user sees: Before starting any of these programs you need to source /home/gbt/gbt.{c,ba}sh depending on your shell. Some of the programs are regrettably slow and that will take getting used to.

• • GFM -- GBT FITS Monitor. (type "gfm") This is the online FITS monitor and the program that derives pointing and focus offsets from your data that are applied to the telescope. It has been subsumed into Astrid (below) but is sometimes useful to run offline, after your observing run, to review pointing and focus data. GFM does not yet analyze CCB data so until it does, we will use the DCR for peak and focus scans. Also, the Ka Tcals are incorrect and its most robust to have GFM fit your raw counts, for which you must have the following in your ~/.sparrow file

• • GFM -- GBT FITS Monitor. (type "gfm") This is the online FITS monitor and the program that derives pointing and focus offsets from your data that are applied to the telescope. It has been subsumed into Astrid (below) but is sometimes useful to run offline, after your observing run, to review pointing and focus data. GFM does not yet analyze CCB data so until it does, we will use the DCR for peak and focus scans. Also, the Ka Tcals are incorrect and its most robust to have GFM fit your raw counts, for which you must have the following in your ~/.sparrow file (which controls astrid and GFM defaults)

• • philosophy. put numbers in logfiles/fits files so we can easily restart if pointing was bad. is there a bell command??
  • examples

• • philosophy: Scheduling blocks (SB's) should be reasonably compact (say 30-45 min of observations) and serve a single purpose. I have one SB for the primary calibrator observation; and one for each set of veto sources that will fit between pointing checks. For the calibrator SBs I have flow-control variables at the top of the file, as you often need to rerun certain observations but not others within it (redo only the focus say). Some examples are attached below.

Current to do list

RANDOM LINKS TO FIT IN http://wiki.gb.nrao.edu/bin/view/Software/ObservingTools

• extract items from above...

Current to do list

• finish this page! (Brian)
• review astrid calibrator catalg (Brian/Larry)
• create science target catalogs in astrid format (Larry)
• create SB's for the first observations, just by changing the source list section and referenced astrid catalogs, and giving the file an appropriate name
• extract items from above... (bsm)

• Time allocated

• Time allocated -- In addition to the 51h for 4A27 and 4A38, the whole of 6A49 (~155h) was scheduled over Feb/Mar/Apr. observing schedule links go here

In addition to the 51h for 4A27 and 4A38, the whole of 6A49 (~155h) was scheduled over Feb/Mar/Apr.

• How much time will we lose to the weather? -- Our constraints are that the sky emission must be stable and the wind must be low enough not to significantly bias our flux density measurements. An integrated precipitable water vapor column of 10mm or less typically will also have stable photometric conditions; and 10mph sustained winds cause 10% rms flux density errors due to excitation of feedarm vibrations (this evaluation was from "peak crossing" scans though, and I think the effect will be a bit less for our nods-- needs looking into from our own data). Taking these as our limits, archival weather data over the whole winter tells us to expect 40% of the time to be good. A shortcoming of these analyses is that they don't include the contribution of clouds to the opacity (that information isn't in the historical database). Also, they are averaged over the whole high frequency season including the best months which we've already missed-- although Fred Schwab is coming up with a month-specific breakdown. Also there is a significant annual scatter. All things considered BSM thinks it's reasonable to expect only half of the runs we actually execute to be useful for source vetoing. We will refine this when Fred comes back with month-specific answers...

• How much time will we lose to the weather?

Our constraints are that the sky emission must be stable and the wind must be low enough not to significantly bias our flux density measurements. An integrated precipitable water vapor column of 10mm or less typically will also have stable photometric conditions; and 10mph sustained winds cause 10% rms flux density errors due to excitation of feedarm vibrations (this evaluation was from "peak crossing" scans though, and I think the effect will be a bit less for our nods-- needs looking into from our own data). Taking these as our limits, archival weather data over the whole winter tells us to expect 40% of the time to be good. A shortcoming of these analyses is that they don't include the contribution of clouds to the opacity (that information isn't in the historical database). Also, they are averaged over the whole high frequency season including the best months which we've already missed-- although Fred Schwab is coming up with a month-specific breakdown. Also there is a significant annual scatter. All things considered BSM thinks it's reasonable to expect only half of the runs we actually execute to be useful for source vetoing. We will refine this when Fred comes back with month-specific answers...

• Source Selection

Start with the faintest NVSS sources, and sources in the areas where CBI is deepest... though we definitely do want to get some spread over the whole mosaic region...

• Source Selection -- Start with the faintest NVSS sources, and sources in the areas where CBI is deepest... though we definitely do want to get some spread over the whole mosaic region...

• GBT Pointing Stability

This is the key issue for our veto campaign. Three main worries: wind, "routine failures", and "scan-start ringing". We log wind data during the observations and, nominally, we should toss out data where the wind was greater than 10 mph or so. We should have a good look at the pointing calibrator data and determine the precise cut threshold ourselves; and whether we need to toss the whole scan, or just flag those integrations where the wind was bad. We may even be able to push the wind cut substantially higher by say, an empirical model involving wind direction and telescope pointing location... Spring is somewhat windy, and this might gain us a good amount of extra data!!

• GBT Pointing Stability -- This is the key issue for our veto campaign. Three main worries: wind, "routine failures", and "scan-start ringing". We log wind data during the observations and, nominally, we should toss out data where the wind was greater than 10 mph or so. We should have a good look at the pointing calibrator data and determine the precise cut threshold ourselves; and whether we need to toss the whole scan, or just flag those integrations where the wind was bad. We may even be able to push the wind cut substantially higher by say, an empirical model involving wind direction and telescope pointing location... Spring is somewhat windy, and this might gain us a good amount of extra data!!

• Basic Approach

GBT staff have characterized long-term deviations from the pointing model in great detail. A writeup of recommended procedures for pointing (and the active surface as well) is here. In summary, at 30 GHz we should rederive peak and focus offsets every 30 minutes during the day; in my experience we can expect 45 minutes to be safe at night.

• Basic Approach-- a night's observation will comprise
  • a single primary calibrator observation-- 3c48, 3c147, or 3c286. Some notes on appropriate calibrators are at Projects.CcbCommData
  • a series of observations of program sources: between 20 and 27 CBI-field sources observed with the CCB, and a single point/focus check (data collected with the DCR until GFM accepts CCB data, which will be soon) along with a CCB nod on the pointing calibrator.

• • program sources: we'll do A/B/B/A observations with 10 sec on each phase and a 10sec slew between positions. We'll initially retain a 10-sec pause before the first A section starts.
  • Calibration: allow 1-min slew each way to/from the calibrator. A peak scan (slew back then forth in az; back then forth in el-- 4 scans of 30 sec each) takes 3 min with overheads. A focus, with overheads, takes 2 min. The otfnod will take 1.5 min.
  • per-night inefficiencies: plan on losing 1/2 hour on average to setup the system, allowing for occasional failures (i think this is conservative). Allow a 10 min initial slew. Allow for two peaks and focuses on your primary calibrator or a total of 10 min, and 1.5 min for an otfnod.

• • config tool -- an application underlying astrid which translates high level configuration scripts into actual hardware settings. We won't have to use it directly very often. Astrid reads configuration scripts and passes them to config tool via Config() commands. There are slight syntactical differences between the config scripts astrid reads and those that config tool would take directly if we ever had to do that.

Link out here to example table with obs notes etc

A page to track individual runs is at CcbCmbRuns. The idea is to put scheduling blocks for individual runs here; along with the observer's notes for that run, and subsequent notes from the analysis and data inspection.

Current to do list

• extract items from above...
• look into repeatability from commissioning data (use steep spectrum sources, listed at Projects.CcbCommData)

%META:TOPICINFO{author="BrianMason" date="1138375680" format="1.0" version="1.1"}%

Ccb CMB Foreground Point Source Observing Campaign

This is an area to organize our CCB effort for Spring 2006, program codes

• 4A27 -- 16 hour deep-source observations
• 4A38 -- 35 hour veto pilot program
• 6A49 -- 150 hour complete veto program

Here is an index to what follows

• Ccb CMB Foreground Point Source Observing Campaign
  • Observing Program
  • Observing Strategy
  • Observing Details
  • Source Lists/Logistics
  • Data Analysis

At various points in this writeup I refer to existing data, and here is where you can find it

• http://www.gb.nrao.edu/~bmason/ccb/run21dec05/
• http://www.gb.nrao.edu/~bmason/ccb/run22dec05/
• http://www.gb.nrao.edu/~bmason/ccb/srcPlots/

Observing Program

• Time allocated

In addition to the 51h for 4A27 and 4A38, the whole of 6A49 (~155h) was scheduled over Feb/Mar/Apr.

• How much time will we lose to the weather?

Our constraints are that the sky emission must be stable and the wind must be low enough not to significantly bias our flux density measurements. An integrated precipitable water vapor column of 10mm or less typically will also have stable photometric conditions; and 10mph sustained winds cause 10% rms flux density errors due to excitation of feedarm vibrations (this evaluation was from "peak crossing" scans though, and I think the effect will be a bit less for our nods-- needs looking into from our own data). Taking these as our limits, archival weather data over the whole winter tells us to expect 40% of the time to be good. A shortcoming of these analyses is that they don't include the contribution of clouds to the opacity (that information isn't in the historical database). Also, they are averaged over the whole high frequency season including the best months which we've already missed-- although Fred Schwab is coming up with a month-specific breakdown. Also there is a significant annual scatter. All things considered BSM thinks it's reasonable to expect only half of the runs we actually execute to be useful for source vetoing. We will refine this when Fred comes back with month-specific answers...

• Source Selection

Start with the faintest NVSS sources, and sources in the areas where CBI is deepest... though we definitely do want to get some spread over the whole mosaic region...

• An open question: the deep source project. Larry and Brian talked about this offline Wed and felt that the deep bit is pretty crucial-- it will strongly limit our statements about the excess if we don't pull it off-- and the feasibility needs to be looked into at very high priority. Basically we'd like to know, if we just consider the middle two frequency channels, how well channels combine to give us sensitive flux density measurements in spite of the known issues. Larry is looking into this; as well, Brian will prototype Main/Trail observations on the GBT for the deeps... unfortunately the GBT simulator has been offline this week which hampered the effort.

Observing Strategy

• GBT Pointing Stability

This is the key issue for our veto campaign. Three main worries: wind, "routine failures", and "scan-start ringing". We log wind data during the observations and, nominally, we should toss out data where the wind was greater than 10 mph or so. We should have a good look at the pointing calibrator data and determine the precise cut threshold ourselves; and whether we need to toss the whole scan, or just flag those integrations where the wind was bad. We may even be able to push the wind cut substantially higher by say, an empirical model involving wind direction and telescope pointing location... Spring is somewhat windy, and this might gain us a good amount of extra data!!

Occasionally some component of the system will fail and your pointing will fail. Some things I've had trouble with are the dynamic (temperature-based) corrections software; the online pointing analysis software (GFM); and the subreflector being in a wacky state (say a slew rate was left in the z-axis from the previous observer somehow). Usually this will be reflected in trouble with your initial peak and focus; however to guard against this we should probably monitor all our observations. Things to watch are: peak/focus solutions are obtained and updated; solutions are reasonable (<10" at night, perhaps up to 20 or 30" during the day); subreflector slew rates are zero; and that nod amplitudes are consistent on the pointing sources.

A big worry BSM had was the scan-start ringing however this appears to be much less problematic than his earlier experience indicated. Just looking at the bright-source data from 21 and 22dec, I would say that no scans have their fitted flux densities affected by more than 10%-- and most by much less-- by being off-source or vibrating initially. For these observations 20 sec was spent in each NOD phase, and a 20 sec dwell was inserted at the start to let ringing die off. The cleanness may be due to the observing strategy: before the scan starts we have already done a slew to the beam we're going to start with, and perhaps this antenna problem just isn't invoked that way. I suggest that we cut the starting dwell to 10 sec (matching the 10 sec per NOD phase we have planned anyway) and watch this like a hawk... if the behavior continues to be good, we can probably eliminate even that 10 sec dwell on our real sources-- probably keeping it on the calibrators as a check.

There are two low-level, known servo issue that are visible in our data but won't significantly affect our results. One is a 1 Hz oscillation in the servo, often visible on bright sources. This will impose a percent or two multiplicative RMS to the signal. THe other is that we consistently "overshoot" when slewing in one direction of the NOD. BSM thinks this is due to a (known) stiction problem in the servo-- in one direction you are slewing w/the sky, in the other against, and go through zero velocity. Under low-wind conditions the antenna indicated positions capture this overshoot quite well (see the agreement between model and data), and it is a small fraction of the time in the nod, so it won't bias our results.

• Basic Approach
• Timing
• System Configuration

Observing Details

• Programs the user sees: Before starting any of these programs you need to source /home/gbt/gbt.{c,ba}sh depending on your shell.
  • CLEO: (type "cleo") This is a low-level GUI interface to the individual bits of hardware in the system. It is meant for staff only (primarily engineers) but unfortunately everyone tends to use it. The windows probably regularly useful to us are: Rcvr26_40, CCB26_40, DCR, IF Rack (for DCR), scan coordinator, message window, Antenna. A very useful feature is that if you double right-click on any BLUE widget, for example the CCB port 12 readout (or a DCR port readout), it will bring up a stripchart.
  • gbtstatus: (type "gbtstatus") This is a configurable status summary that can be run in a terminal window, which is excellent for remote observing. I haven't used it much but we should start. I think that for our observations this can quickly replace CLEO (or many CLEO windows).
  • GFM -- GBT FITS Monitor. (type "gfm") This is the online FITS monitor and the program that derives pointing and focus offsets from your data that are applied to the telescope. It has been subsumed into Astrid (below) but is sometimes useful to run offline, after your observing run, to review pointing and focus data. GFM does not yet analyze CCB data so until it does, we will use the DCR for peak and focus scans. Also, the Ka Tcals are incorrect and its most robust to have GFM fit your raw counts, for which you must have the following in your ~/.sparrow file

[GfmDataProcessingDefaults]
BeamSwitched: Raw

• • Astrid -- this is the top-level observing interface program. Basically it manages the telescope run queue. You can import ascii-text observing files into it (called "scheduling blocks"), validate them for syntactic correctness, save them to an internal database, and edit them subsequently. I always make a policy of editing as little as possible within astrid, and keeping my external ascii SB's up to date. Scheduling blocks are written in python, which allows great flexibility.

• Scheduling Blocks
  • philosophy. put numbers in logfiles/fits files so we can easily restart if pointing was bad. is there a bell command??
  • examples
  • Special tweaks: there are a number of special tweaks to our standard observing setup. 1) we turn off and reroute the system local oscillator (needed for spectral line observations) so it doesn't affect our data. This is done by the line execfile("killlo.py"). 2) We add the weather station to the "archivist", which will generate scan-synchronous weather data FITS files. This is done by execfile("addwx.py"). 3) Instead of the standard Astrid Peak() and Focus() routines, for high-frequency observing we have a new AutoPeakFocus2?() routine which has a number of desirable procedures, notably, an improved active-surface look-up-table which yields quite flat gain curves between 20 and 80 deg elevation. 4) BSM (with others) has implemented custom trajectories for the nods. The actual trajectories live in FITS files in ~bmason/gbt-dev/scanning/ptcsTraj/. The files are read into the scheduling block by a python procedure called readFitsTraj(), and executed by a custom observing procedure called dotrajectory().

Source Lists/Logistics

Link out here to example table with obs notes etc

Include known issues (restart turtle; archivist fix)

Data Analysis

• Basic idea/example scripts
• Issues to look into carefully
  • objective, quantitative criteria for wx (photometric stability, wind)
  • antenna/rx characterization from the data (a service-to-gb type activity)... we'll have a large and uniform database
  • add in ability to analyze DCR (as opposed to CCB) peak/focus data... or use GFM?

-- BrianMason - 27 Jan 2006