Adam Ginsburg's blog

Articles in the bgps category

• Some pretty neat things about delining....

  Well, I did the work, so might as well come up with some plots... I created a gaussian-fitting based delining code that saves all of the fits in a text file! That's a lot of data to play with, and allows me to draw some conclusions:

  1. For the narrow lines, the linewidth (gaussian sigma) is 0.03 Hz. For the wide lines, it is 0.05.
  2. The amplitudes from December 2010 are ENORMOUS compared to others!
  3. The width distributions of the two are similar, though the lines appear to be significantly wider in July 2009

  I've also gotten to the point that I'm satisfied with how delining with wing suppression works. Wing suppression is 0.4-2x quicker than fitting directly, depending on... not clear what exactly; it depends on epoch, but that could either be because there are more lines found or because of relative data size. Does delining have to be done on whole timestreams, or can it be done on a scan-by-scan basis? This is not entirely clear... the peaks are less suppressed when done on a scan-by-scan basis (presumably because the S/N is low and peaks are therefore not detected), but incorrect suppression (removing a line that's not there) is reduced. For short scans, the scan-by-scan approach is 10x faster; for longer scans it's ~20% faster. I think the scan-by-scan approach is going to be ideal.

  ---

  Examples from l089 (0709): Top row: non-fitted line suppression

  

  Bottom row: fitted line suppression

  

  ---

  Examples from Uranus (1012, really really liney):

  Top row: non-fitted line suppression

  

  Bottom row: fitted line suppression

  

---

• Bleh, a whole day's work dedicate to new delin...

  Bleh, a whole day's work dedicate to new delining methods and testing. Very unrewarding. However, there are results that I need to FINALLY prove and show tomorrow: 1. amplitude suppression + phase preservation is a good alternative to zeroing/scrambling or replacing with noise 2. line fitting is effective but slow 3. Assuming a line profile and suppressing is nearly as effective as line fitting 4. scan-by-scan is less effective than observation-by-observation for fitting (but it's not clear if that holds for other methods)

---

• What about the effects on the map? Unfortunately,...

  What about the effects on the map? Unfortunately, in the tests I've run, delining actually INCREASES the noise in the map! How is this possible? My only hypothesis is that PCA cleaning does an excellent job of removing the line noise, but when it is replaced with truly uncorrelated gaussian noise, the PCA cleaning no longer removes that component. But we don't want PCA cleaning to grab instrumental correlated noise; we want it to be limited to atmospheric noise. So ideally we want to completely remove the line noise without adding noise to the image... maybe the line regions should just be set to zero after all....

---

• Downsampling by a factor of 3 appears not to be an...

  Downsampling by a factor of 3 appears not to be an option because this error: % NCDF_VARGET: Requested read is larger than data in dimension 0. Reducing COUNT to 615. % REBIN: Result dimensions must be integer factor of original dimensions % Execution halted at: NCDF_VARGET_SCALE 133 /Users/adam/work/bgps_pipeline/support/ncdf_varget_scale.pro occurs.

---

• More evidence that downsampling causes problems

  The captions are pretty much the same as for the previous post, but this is a larger field and the effects are more serious.

  

---

• Downsampling has serious negative effects on the data

  Background: Downsampling is performed using Old Pipeline code called process_ncdf. All BGPS data was downsampled by a factor of 5 before mapping because of data size concerns. I did this 'blindly' (i.e., just accepted that I should) because James said I could. However, I had previously noted that the pointing files could not be done with downsampled data because the beams 'looked funny' or something along those lines; it may also have been a simple map sampling issue in which not all pixels were filled with a downsampled image. Anyway, I decided to go back and quantify the effects. The plots below are from the single "pointing-style" observation of OMC1 from 2009. The units are volts. 'ds1' indicates sampling at 0.02 seconds, 'ds5' indicates sampling every 0.1 seconds. The scan rate was 120"/s.

  ---

  

  The beam sizes were measured from the autocorrelation maps. However, because there is structure on many scales in this map, I had to use a rather ad-hoc method to remove the correlated structure. I fitted a gaussian to the elliptical northwest-southeast structure, removed it, then fitted a gaussian to the remaining circular thing in the center, which is approximately the beam. If I fit the "beam" gaussian with an ellipse, I get: Beamsize 1_1: 36.15,26.23 Beamsize 1_5: 48.39,30.21 With a circle: Beamsize 1_1: 29.51 Beamsize 1_5: 35.31

  

  The ds1 and ds5 images compared.

  

  The PSDs of the two images (on identical grids). Note that ds5 loses power at small spatial scales, 50% at 40"!

  

  The pixel-pixel plot with a fit that shows a 10% overall flux loss (best-fit).

---

• BGPS data paper published

   *[[http://irsa.ipac.caltech.edu/data/BOLOCAM_GPS/bgps_methods.pdf The Bolocam Galactic Plane Survey I. Survey Description and Data Reduction] `[`[http://arxiv.org/abs/1011.0691 arXiv]`]`  *[[http://adsabs.harvard.edu/abs/2010ApJS..188..123R The Bolocam Galactic Plane Survey II. Catalog of the Image Data] `[`[http://arxiv.org/abs/0909.2871 arXiv]`]`  *[[http://adsabs.harvard.edu/abs/2010ApJ...717.1157D The Bolocam Galactic Plane Survey III. Characterizing Physical Properties of Massive Star-Forming Regions in the Gemini OB1 Molecular Cloud ] `[`[http://arxiv.org/abs/1005.4969 arXiv]`]`  *[[http://adsabs.harvard.edu/abs/2010ApJ...721..137B The Bolocam Galactic Plane Survey IV: λ = 1.1 and 0.35 mm Dust Continuum Emission in the Galactic Center Region]

---

• v2.0 is to v1.0 as ___ is to v1.0

  

  Apparently v2.0 recovers flux better at all scales than v1.0.  However, it is noisier.  The full comparison is available here.  The trustworthy range of flux scales is 1.2-1.6ish.  The flux is increased at ALL scales in most images.  However, as was noted in comparisons with MAMBO, there may be curvature in the best-fit lines.  Also, l=35 does not appear to scale up linearly... G34 is fainter in v2.0? In the low S/N fields, the PSD is more reliable than the pixel-pixel comparison.

---

• PPS comparison completed

  The PPS scale factor seems to hold for many different (and ridiculous) aperture sizes.  The full results are here.

---

• PPS analysis: suggests a possible solution to the discrepancy

  The comparisons I mentioned in the previous post are sort of done.  They are pretty suggestive of a solution to the "flux recovery problem" we think must be true.  However, even if it is a solution, it doesn't really solve the problem completely. It looks like v1.0 should be scaled up by a factor of 1.3-1.4 (not 1.5).  v2.0 is consistent with the PPS sources to within 5%, and might even be slightly too high. The comparison was done by taking the flux in a 60" radius aperture (equivalent to bolocat 120" diameter apertures) and subtracting off the background measured in a 120" radius annulus around the source.  Without the background subtraction, these numbers would look very different: in the science fields, most of the sources sit on an extended background. Even though the "background flux" isn't recovered in the PPS fields, it should contribute to the source background because it is involved in the atmosphere subtraction (it's sort of "already subtracted" so you have to subtract from the science fields).

  

  Next step: direct comparison between v1.0 and v2.0.  Pixel by pixel, aperture, and powerspectrum

---

« Page 8 / 20 »