NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Observing > CcbCmbCampaign

Changes | Index | Contents | Search | Go

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
  • Results
  • Current to do list

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/ -- 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

Observing Program

• 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. 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...

• 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; 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!!

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 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 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.

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: 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.

• Timing
  • 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.
  • 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.

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. Some of the programs are regrettably slow and that will take getting used to.
  • 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). Documentation for the GBTSTATUS display is here
  • 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)

[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.
    • A good astrid overview
  • 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.
    • 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
• Scheduling Blocks
  • example CCB scheduling block
  • 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.
  • 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: 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

Source Lists/Logistics

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.

• 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

Data Analysis

• Basic idea/example scripts
• 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

A useful link: our Ka/CCB channel identifications summary

Structure Description: CcbCmbIDLGuide

Discussion for June 9: CcbCmbJune9

Results

• CcbCmbResults
• GbtCcbPaper

Current to do list

• 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
• get peak/focus filters working properly
• do we need separate beam heights for 1 and 2?

• Goodness of Fit - BSM
• Distribution -> Source Count Model - LCW
• Sources in Ref Beam - BSM
• TP Calibration - BSM -- sort of did-- update to ACAL

-- BrianMason - 27 Jan 2006