Showing posts with label discrepancy. Show all posts
Showing posts with label discrepancy. Show all posts

Thursday, July 28, 2011

STF measurement attempts, round 3?

Below are plots of the spatial transfer function for a variety of simulation parameters. Each line represents the median (i.e., mean of the center 2 of 4) spatial transfer function of 4 realizations of the listed parameters.






A few unfortunate details are apparent:
  1. The STF is background dependent, though not strongly
  2. The STF appears to never exceed 85%, and be more typically 75%. If this is not matched by point-source PSDs, an explanation for the flux discrepancy becomes possible
  3. The 50% recovery point is much closer in than previously stated, at closer to 150" than 300".
Note for comparison that the recovery fraction for point sources is much more nearly 1, at least in the calibrator type maps. We need to wait for Jared's simulations with point sources in a full size map to confirm this, but it seems pretty likely that the STF is different for point sources and extended structures.

Sunday, March 27, 2011

Trying to bootstrap

I've concluded, based on previous posts http://bolocam.blogspot.com/2011/02/downsampling-why-is-dec-2010-different.html, http://bolocam.blogspot.com/2011/03/revisiting-calibration-yet-again.html, and http://bolocam.blogspot.com/2011/03/workaround-for-individual-maps.html, that ds5 is a problem primarily for undersampled images, i.e. those taken in the normal mapping mode. This makes bootstrapping a bit tricky.

There are two options:
1. Map Uranus and AFGL 4029 both in Volts and figure out what flux density AFGL 4029 must have to lie on that curve
2. Map Uranus and compute a calibration curve, apply that calibration curve to AFGL 4029, and then compare derived flux densities.

Both have the major problem that the individual AFGL 4029 maps will forcibly be undersampled if I use ds5 data (which is normally OK, according to the first paragraph). In the second case, it is possible to co-add the images and get around the under-sampling issue, while in the first case it is not because of the dependence on total loading (MEANDC).

The real problem is that the whole goal of these observations was to compare the different observing methods and see if they agree (1x1, 3x1, pointing, etc.) since the pointing-style observations were used to calibrate the others. But if the 1x1s are just straight-up unreliable, how can we do the comparison? I think the co-added AFGL 4029 is the only option, but then how do I test if it's correct? It would be really nice to have AFGL 4029 observed with both scan types...


Alright, onto the data. After last week's fix of the bad bolos, I really hope ds1 and ds5 agree. However, first glance at the cal curves says they don't. ds1 and ds2 agree, but ds5 is different.

After checking them out with ds9 *ds[15]*13pca*_map10.fits -scale limits -1 1000 -log -cmap hsv -match colorbars -match scales -match frames wcs &, it appears that the _mask_ data is all... wrong, somehow. That's OK, I want to discard the mask data anyway, so I'm happy to NOT spend time debugging it.

Even after careful examination showing that the fits look good - and noting that the fluxes look pretty much the same - the calibration curves still look rather different. Unfortunately I had to spend 3 hours debugging IDL plotting commands; I want to show the fits each time and save them as postscripts. What does "xyouts" with "/device,/normal" do? I thought that should plot x,y text at the coordinates specified in the plot window... but no, that is JUST /normalize.

Anyway, realized that centroid_map treated NANs as zero. Added ERR keyword (with a reasonable estimate of the error) in centroid_map to ignore NANs. It looks like improper treatment of NANs is responsible for a lot of the scatter seen in the calibration plots.

There is a substantial difference between the "fitted" peak and the "measured" peak (the latter computed by taking the sum of the pixels divided by the area of the fitted gaussian). It looks like the "measured" version is more robust, at first glance. However, unfortunately, for 101208_o11, the difference between ds1 and ds5 exists in both quantities. I will have to examine timestreams now... ARGH.

Well, the timestreams show... that indeed the model is lower in ds1, but not why. The "remainder" (new_astro; the stuff that never gets incorporated into the model but DOES get incorporated into the map) appears to be the same in both. Similarly, there is little to no flux in the PCA atmosphere, so it's not simply being cleaned out. Where is the flux going or coming from?




Thursday, June 24, 2010

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.

Monday, June 21, 2010

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