Milkyway /scratch disk usage

-bash-3.00$ du -h --max-depth=1 ../
16K     ../lost+found
80G     ../sliced
1.3G    ../elatov
70G     ../cleaned
58G     ../mapped
179G    ../sliced_polychrome
4.0K    ../ironsides
49G     ../coadd_mapped
2.1G    ../pca_coadd
2.8G    ../3pca_3iterations
11M     ../centroid
17M     ../lost
34M     ../ptg_maps
3.8G    ../montage
31G     ../maps_from_polychrome
93M     ../ptg_mmd
32G     ../backup_from_kilauea
31G     ../sharc
1.8M    ../distortion
6.9G    ../fake
138G    ../adam_work
136G    ../bgps_dir_from_polychrome
815G    ../

Galactic vs. RA mapping

They don't match up. This is a serious problem.

I think it's only a problem for the GC: ad2xy refuses to map things right around that transition. I think it's OK elsewhere.

Update - Pointing Model

Update - Pointing Model 7/31/08
The pointing model application "works" now, but I have a problem with our model. We don't get down to the <10" RMS offset we're looking for. The mean offsets are all zero, but the spread is more like 20".

Example plots on milkyway: [see attached PDFs too]
/scratch/adam_work/plots/models_ptgmdl_0506.ps
/scratch/adam_work/plots/models_ptgmdl_0707.ps
/scratch/adam_work/plots/models_rawcsoptg_0506.ps
/scratch/adam_work/plots/models_rawcsoptg_0707.ps

On the left side are plotted "all" of the data points, on the right I've used a two-iteration 3-sigma rejection to eliminate outliers to a small degree.

Top of these plots - as labeled - is altoff vs. alt, bottom is azoff vs. alt.

The red lines are a 2nd order polynomial fit to the data.
The cyan lines are the pointing model corrections calculated by Meredith.

The 'ptgmdl' files have had the pointing model corrections applied. Note that they are centered around offsets of zero.
The 'rawcsoptg' files DO NOT have pointing model corrections applied, and FZAO/FAZO have been REMOVED from the original pointing. Hence, these are RAW CSO TELESCOPE POINTING plots.

Things to note:

* In the 0707 'ptgmdl' set, the az is not quite centered at zero
* the 0506 'ptgmdl' set still has bulk offsets
* the ALTOFF and AZOFF are in delta-coordinate: this means that azoff should be scaled by dividing by cos(alt) to put the y-axis in consistent units. In most cases, this means that the already large spread at higher altitudes is going to INCREASE. That means the problem is going to get worse...

Questions:

1. What is the main difference between my plots and Meredith's? i.e. why is my RMS ~an order of magnitude larger?
2. Does more outlier rejection make sense? Is there any reason not to trust certain observations if they visible turn out right?



PPSes are supposed to be "absolute references" for the 1x1, 3x1 maps
OLD PROBLEM: PPS and large maps mapped with same 'pointing model' but ended up with different coordinates

Defining Pointing Terminology

There has been a lot of confusion about pointing terminology.

• CSO pointing model: the telescope pointing model used and written as a black box


• has already been corrected for aberration/nutation


• is in current epoch coordinates (e.g. J2007.34)


• Instrument-specific correction to pointing model


• ??? also referred to as 't terms'


• is offset between CSO pointing model and real locations


• should be a function of alt (and maybe az)


• is recorded in "RPC" files


• is in units of distance on the sky: delta-RA and delta-DEC, or delta-ALT and delta-AZ will be in the same units, while if they were in coordinate units delta-RA and delta-AZ would have to be scaled by 1/cos(DEC) or 1/cos(ALT) respectively
  


• FAZO and FZAO: Fixed Azimuth Offset and Fixed Zenith Angle Offset
  
  • these are ambiguously defined in the pipeline code
  
  
  • ???? FAZO/FZAO include both the functional instrument specific pointing offset and any manual changes made at the telescope [manual only relevant to 2007 observations]
  
  
  • ???? or are these JUST fixed offsets, and the instrument specific corrections are not included? Either way, how can I separate out manually-applied fixed offsets from fitted-model offsets?
  
  

New Pipeline to CVS

Open topic - what needs to be done to put the new pipeline on the CVS?

1. Under the assumption that it will be used by others, the documentation needs to be complete.
   
2. Needs to be compatible with current pipeline (no name overlap)
   
3. Have to fix / update some Goddard astrolib routines that have short integer for loops and need long integer for loops
   -which ones?
4. Probably need to add instrument specific pointing model corrections for non-BGPS observations
   

BOLOCAM PIPELINE BLOG

Guy pointed out in the CU meeting today that we need a better way to keep track of changes / problems / etc. The wiki's kind of a pain, and this will serve as something of a replacement for the e-mail-only conversations that have been going on with the Software Power Team.