Two success stories, one failure story.
Successes: L111, L024. On the left is the aligned map, on the right the unaligned map.
Failure: L024. What's going on here? Is it an issue of that noisy observation, or the fact that we're using a 5x1 (I think?) as a reference?
Alignment: I did a more thorough test of the aligner, and found an error that was getting me the wrong results. I'm still getting distinctly different results than I got with imalign, but I'm not convinced they're wrong. One problem I have to deal with is the ambiguity between pointing model applied / no pointing model applied. In retrospect, I should have done ALL of the maps with no pointing model: it would be simpler to maintain a self-consistent set of alignment corrections. However, since that isn't what I did - and there isn't enough memory to host both data sets at the moment - I've dealt with the problem by adding all of the offsets to the header. Hopefully now it will be obvious if and what offsets have been applied, both pointing model and 'manual', from header keywords. Sadly, it was a pain to get that to work - IDL's _extra does not work the same way as normal keyword passing, which is disappointing and frustrating because it made me rename a lot of variables that should not have been renamed. IF this alignment fails to produce perfect results (which I don't really expect to happen - it will just take time to debug), it is still a good first step, and all we'd really need to do is use bolocat to pull out sources from the reference image and then match those in the others, doing the same thing imalign does. It wouldn't be difficult but it would be time consuming to program. Had a bunch of ideas during my insomnia last night, but I'm afraid I forgot most of them... One idea was related to the use of MAD as opposed to STDDEV: it may allow for a more robust sigma-rejection for automated flagging. But that's difficult. Another thought was using the maps to auto-identify glitches. To do this, I'd make a combined map and an individual map, hastrom them, and subtract the combined from the individual. We could then probably pretty easily spot any glitches; they should be the only outliers left, in principle. I'll test that idea, but it actually looks less promising than I'd hoped. Things are not coming out right in preliminary tests - huge residuals.
Except for l057, there is no guarantee that the whole observation is bad, BUT the code failed on ncdf_open, so it possible the observation turned bad during downsampling/preprocessing. fixed: 30, 26, 55, 35, 28, 31, 38, 54, 57 so far all observations on 060605 are bad.
DS9 does something intuitive: cd0_0 and cd1_1 multiplied by the x,y pixel difference gets you the new l,b coordinate. I think this is very likely to be correct on the galactic plane. IDL does something different. I don't know why different, or really how - it's buried somewhere in wcsxy2sph - but it's definitely different. Which is right?
I have to echo James in saying how remarkable it is than anything I ever did worked at all! I'm growing more and more certain that I've been double-correcting rotation for the past 2 months, and my maps don't look all that bad! .. image:: http://4.bp.blogspot.com/_lsgW26mWZnU/SMW4oOPcLaI/AAAAAAAADXw/1ARG8iyVXDQ/s400/070717_o15_rotations.png Image caption: Top left - both PA and rotang Top right - neither Bottom left - rotang only Bottom right - PA only I'm running the same sort of comparison on all of the GC and L=24 data. Check out /scratch/adam_work/ROT_TEST for the results. I'll be updating this when I've completed that analysis. Update 6:35 PM: !@#$, etc. New problem child: .. image:: http://1.bp.blogspot.com/_lsgW26mWZnU/SMXFUjLjRGI/AAAAAAAADX4/aynvuycRzGM/s400/060603_o16_rotations.png Image caption (same as above, luckily): Top left - both PA and rotang Top right - neither Bottom left - rotang only Bottom right - PA only So, can anyone tell me which one of THESE is right? Because I can't. Top left is 'correct' except that it's not. Update 7:10 PM: I compared adding/subtracting PA and RA, and I can say this: subtracting PA never works. Adding/subtracting RA works variably. I think I'm done testing parameter space. I haven't had very good luck doing parameter space tests in the past; it usually is more beneficial to take a step back and try to think through the problem. Update 7:30 PM: Fixed. Much as this looks like a short-lived, easily solved problem, it was one of the most subtle and insidious errors I've made. I got extremely lucky that plotting PA and ROTANGLE happened to spark off warning sirens in my mind about the positioning of the variable names. I wouldn't normally look for that.
hate to put it this way, but probably true - bolocam will eat us all. Cara and Marc have both agreed to help out with alignment work. This is good news! Next post will be bad news, just to compensate.
a few items...
Done for the day after this (observing tonight) two new procedures:
alignment_offsets_to_ncdf.pro calcoeffs_to_ncdf.pro
they're really easy, very nearly one-liners. Once they've been used once, you can just use ncdf_varput_scale Modified keyword parameters in do_the_pointing: offsets will always be applied unless the keyword 'no_offsets' is passed into the code (or the top-level wrapper). Since offsets default to zero, this should be OK.
To make .* in VIM be non-greedy (i.e. match just <a href=x> out of "<a href=x> </a>"), use:
.\{-}
/scratch/adam_work/plots/models_myptgmdl_0707.ps Look at the left plots in #1 and #4, and ignore the red lines. The RMS is 4.87 in alt, 3.51 in az, using all pointing observations in 0707 (i.e. not splitting it into part1/part2 or refining heavily). Total is 6.003", not bad. I'm calling it quits on pointing refinement for the moment; I'm satisfied using Meredith's pointing models to get science maps co-aligned, then we'll use my model on the PPSes to get the pointing to maximum precision. Also, in the galactic center, the mapping works happily now. No more silly problems with that. It's time for a real Next Step. I think that means mapping nearly everything. Well, here goes!