Friday, March 20, 2009

Eimers project

Project for Marc Eimers:
Determine velocities to molecular clouds by a variety of methods. Start with l=30

1. Find archival data, particularly from the JCMT, for each core.
2. Compare morphologically to 13CO from GRS
3. Find Vizier data

locating beams



White - "Default", OP-calculated beam-locations
Red - My code's beam locations
Yellow - Boloparams, the fiducial beam locations

Sunday, March 8, 2009

Gem OB1 comparisons

I'm running 0,1,2,3,5,7,10,16, and 19 PCA component 51 iteration maps of Gem OB1 with deconvolution. No clue when they'll be done because they're at the end of a long queue.

Next (important!) step is to re-run the simulations with linear source sizes but with different numbers of PCA components, different kernel sizes, etc..... there is a LOT of parameter space to cover.

Wednesday, March 4, 2009

A detailed look at l086

Despite a slew of alignment errors, it appears that the alignment for MOST fields turns out OK using Method 3 of the pixel-shift code; the signal to noise is VERY low in a lot of fields.

070724_o38 does not come up with a good fit, for very good reason - there appears to be no signal at all.

070907_o20 is a problem. The offset was 27 pixels, which is too large, but nonetheless correct. I had to institute the plane fitter at an earlier stage to get it to work.

However, the biggest problem: the SCUBA source aligns with 070907_o20 but not the rest of the maps. So I needed to re-fit everything. That was a BIG mistake, we need to check carefully for it in other fields.

Tuesday, March 3, 2009

Methods Paper: Figures / analysis to produce

The methods paper needs some justification of the number of PCA components used. This will require a map of some field with a range of number of PCA components.

Plan:
simulate a map of L111 (the most square field) with 0-20 PCA components x 21 iterations and a variety of source sizes and plot the recovered flux vs. number of PCA components. Ideally, do this with both deconvolution and not. Estimated processing time is ~24 hours.

Also, a plot of flux vs. iteration number will be useful.


Glitch filtering method has been modified:
"Glitches are removed by drizzling each bolometer measurement into a given pixel using the mapping M[p], but retaining each pixel as an array of measurements. Then, measurements exceeding $3\times MAD$ (Median Average Deviation) are flagged out in the timestream. In cases where there were too few ($<3$) hits per pixel, the pixel was completely flagged out. This only occurred for pixels at scan edges."



Data flagging:
Partly covered by deglitching. Many scans were flagged by hand to remove overly noisy scans and those that were observed to confuse the iterative mapper. Hand flagging is more robust than automated and can remove features caused by the filter convolved with the glitch.


Creation of astrophysical model:
Not entirely sure what this section entails. Should have a subsection on deconvolution though.

Jackknifing has not generally been done...

4.3 Relative Alignment and Mosaicing

Relative alignment was performed by finding the peak of the cross-correlation between images and a pointing master selected from the epoch with the best-constrained pointing model for that field. Each observation was initially mapped individually, then all observations of a given field were cross-correlated with a selected master image of that field. The cross-correlation peak was fit with a gaussian and the difference between the gaussian peak and the image center was used as the pixel offset. The offsets were recorded and written to the timestreams. Finally, all observations of a field were merged into a single timestream with pointing offsets applied to create the field mosaic.

Monday, March 2, 2009

a bunch of plots





I wasted a lot of time making these so I figured I might as well waste a little space showing them.

A new series of problems


  1. There are severe (~5 pixel) pointing offsets in the MOSAICs. They are caused by IRAF and I can't figure out exactly why.
  2. Deconvolution has created more artifacts at l=54, 70, 357. I don't know how to fix them.
  3. Either my earlier time estimates were way off, or the mapping has gotten slower. It now takes ~120 computer hours (72 real hours) where before it was taking closer to 48.