Showing posts with label downsampling. Show all posts
Showing posts with label downsampling. Show all posts

Tuesday, April 26, 2011

ds1-ds5 comparisons

I'm comparing simulated ds1-ds5 to real ds1-ds5 comparison tests.

In the simulated tests, I compare the recovered map after 20 iterations with 13 pca components subtracted to the input map. There are figures showing this comparison for ds1 and ds5 images in addition to one showing the comparison between ds1 and ds5. The agreement is pretty much as good as you could ask for.

These simulations are the most realistic run yet. They include a simulated atmosphere that is perfectly correlated between all bolometers excepting gaussian noise, but the relative sensitivity of the bolometers is varied.




This is what a 'real' ds1-ds5 comparison looks like. The image shown is a "cross-linked" observation of Uranus with downsampling off and on. Note that downsampling clearly and blatantly smears the source flux.


The same image with "beam location correction" looks no better.



The problem is essentially the same with the individual scan directions:



What is causing this difference?
  • higher-order corrections to the atmosphere calculation?
  • inadequate sampling of the model?
  • "pointing" offsets between the model and the data (note that these are NOT pointing offsets, but they may be "distortion map" offsets)?
  • Other?
Examining the weights and scales for two individual (real) observations, ds1 followed by ds5, is not particularly telling; there is one additional outlier bolometer flagged out in the ds1 observation, but there is nothing obviously wrong with that bolometer (it may have much lower high-frequency noise than others).
The simulations actually have more discrepant weights, but that doesn't seem to cause any problems:
The timestreams both have similar artifacts:
while the simulated versions really don't:
This is true even when the relative strength of the atmosphere is higher:


I think the most viable candidate is the 'pointing offset' idea, which will take a little work to simulate properly...

Tuesday, April 19, 2011

Sampling Causes Problems: Rd 2

Proof that a well-sampled timestream / gaussian is recovered better than a poorly sampled one:




These aren't really the most convincing, since the flux loss is only 1-8% depending on how you count. The atmosphere-included ones have larger flux loss, which is important to understand... WHY does the added noise INCREASE the flux loss?


Ugh, unfortunately, there is a perfect counter-example. The first image shows a timestream in which the input map is sampled by 7.2" pixels, which is just shy of nyquist sampling the 1-sigma width of the gaussian (but is fine for the FWHM of the gaussian). The second shows 3.6" sampling of the same. No improvement. The third, very surprisingly, shows significant improvement - but this was an experiment in which the relative scales were allowed to vary.




The first two each had one high-weight bolometer rejected, the last had 12 high-weight bolos rejected. So that's problably the problem....

Monday, April 18, 2011

Sampling causes problems

One of the simplest experiments that can be run is a point-source observed in point-scan mode, i.e. with smaller step-sizes. I've done this for an Airy disk with noise added in the image plan but not atmosphere (some noise is necessary to avoid bizarre artifacts with weighting when you have truly zero signal and zero noise). At a S/N of 500, the noise is pretty minimal, though.

It turns out for the 'noiseless' images, the PCA cleaning is the issue... curiously, it varies significantly with iteration. Is it worth trying to debug the PCA cleaning for noiseless timestreams? I mean... they really shouldn't have any correlated information anyway.

There is still an outstanding issue where one bolometer gets scaled to be higher than the rest without any apparent reason for doing so.

It is also clear that we do not nyquist-sample the pixels with the timestream. However, that doesn't explain a deficiency observed in the ds1 images. Also note that the sidelobes are not picked up at this S/N, but that's not too surprising.

And here is the explanation: The peak is missed by about 10% because of finite sampling? Somehow the sampled gaussian nearly uniformly underestimates the gaussian... I think this violates theory a bit.....

Here's the problem shown again:
This is a comparison between the input image and a ds1-sampled image with perfectly correlated atmospheric noise. So there is something in the pipeline that is preventing the peaks from achieving the necessary heights.... I wonder if resampling the deconvolved image onto a higher-resolution grid, then downsampling afterwards, would fix this?

Also note that the flux loss increases from 7% to 20% from ds1 to ds5:

Tuesday, March 29, 2011

Progress, but still ds1-ds5 issues

ds1 and ds5 agree pretty well with the recent upgrades to delining and deconvolution. However, there are still counterexamples, e.g. 101208_o13, in which ds5 < ds1:




The 'fitted' values agree better than the 'measured' values now that NANs are treated properly.


Spent a few hours today trying to figure out if weighting can explain the difference between ds1 and ds5; it appears to make up for most of it so I'm doing some more experiments. Why is there so much parameter space? Why can't weighting just work? It doesn't....

also wasted a few hours trying to write a python drizzling algorithm, which unfortunately is impossible so I had to resort to an inefficient for loop.

Finally got some minor results. It really looks like there is a trend pushing up the recovered flux (i.e. higher volts/Jy) for ds5 over ds1. There is a discrepancy between map types for ds1 but not for ds5, which is actually backwards from what I would have expected, since ds1 will get better-sampled maps.



Luckily, the difference between peak fitting and "measuring" results in very small (insignificant) changes to the calibration curve (recall fitting is direct gaussian fitting; 'measuring' is using the gaussian-fit width and total flux in an ellipse to infer a peak assuming a point source):


Since this work has all been done for the 'bootstrapping' observations that are supposed to tell us if different map sizes are compatible, I have included the map sizes in the diagrams now. However, to really understand the ds1/ds5 difference, there are much better data sets, which I'm now reprocessing using the new and improved methods.

(the Whole BGPS is also processing with the new methods in the background, though since the methods are being updated live there may be more changes and it will have to be re-run.... initial looks at W5 are BAD but L030 is GOOD (bordering on amazing))

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?




Sunday, February 13, 2011

Downsampling - Why is Dec 2010 different?

As you'll recall from my previous post (and references therein...), the 2005 Orion data shows a discrepancy between ds1 and ds5 data in which the ds1 data is significantly (~10%) higher than the ds5 data. However, the 2010 Uranus observations show much larger discrepancies between ds1 and ds5 favoring the ds5 data! Because that was somewhat unbelievable to me, I ran ds1-ds5 comparisons on Uranus data from other epochs, and discovered that ds1>ds5 uniformly (also, it looks a LOT better).

So, the question remains, WHY is the Dec 2010 data brighter in ds5? More confusing to me, why do the ds5 PSFs from 2010 look so reasonable, while the ds5 PSFs from all earlier epochs look terrible?

For example, I use the observations 070727_o31 and _o32. These show clearly the blurring and flux-loss that happens when ds5 data are used for 'normal' point-sources. The disagreement is, surprisingly, worse for the co-added image, though the correlation is better... I'm not entirely clear what that means besides there being a positional offset between the individual maps that is not entirely believable.






However, the point is that these maps do not share the properties of the 2010 maps, in which the ds5 source is brighter and possibly even more peaked than the ds1 source, despite the ds1 data having lower noise (as you'd expect):





What could be boosting the flux in the Dec 2010 downsampled data? Is there something about the lines - before downsampling - that is changing the relative scaling? Perhaps I can answer this with the w5 maps... but I think that's unlikely...