-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update X_FP, Y_FP for GFA pixel corners to match target_ra/dec. #150
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see your approach is to write directly a modified version of the GFA pixel coordinates saved in a separate file. Wouldn't it be better to directly apply the cheat transform in write_focal_plane_metrology ? This would have the advantage to expose clearly the parameters of the transform and would make it easier to apply modifications when we have better data.
I feel like if we have improved metrology, I'll need to refit the transform anyway, so there's no particular win there? It's not clear to me if the current approach or the approach you describe would be better behaved following updates to the metrology of things that aren't the GFA X_FP, Y_FP. But yes, the code that writes out the patch file works by applying a simplecorr object to a subset of the metrology, so it would be easy enough to do that inside write_focal_plane_metrology. I just figured this approach was more parallel to the existing code in that script. And initially I had hoped that write_focal_plane_metrology looked for a list of patches, and it would pick up mine without any additional code---though that was obviously wrong. |
Just a confirmation that this indeed improves the results. On one dither sequence (see details below):
|
This PR extends the coverage of the ray-traced tan2fp ZB fits to handle angle differences up to 360 degrees. These are seldom used in practice but are possible, and produce different distortion patterns. The PR is also slightly more careful about how ADC angles are translated into look ups into the fits. Additionally, the ray tracing code was parallelized to speed it up.
Update cheat parameters via a fit to dithers, rather than to PM. Use new ADC interpolation code.
This now fits the cheat parameters to the dithers rather than to PM. So by construction there is no mean offset with respect to the dithers. It further uses Aaron's initial GFA coadds rather than just the 10th coadd guide cube frame; this looks to improve the stability of the cheat parameters appreciably. https://data.desi.lbl.gov/desi/users/schlafly/desimeter/coadd/quivers-20200314-63159.pdf |
PS: this now has a bunch of duplicative commits with #156, so I don't know what will happen when we try to merge it. Happy to resolve the conflicts should they arise after that one goes in. |
Great. Thanks. Now the next step may be to stack the dither offsets and see if we can adjust systematic ZB coefficient correction to the ones obtained with the ray tracing code. |
This PR adds a metrology 'cheat' patch, updating the corners of the GFAs in FP coordinates according to a 6 parameter scale & offset model so that the target_ra/dec match the desimeter ra/dec.
This approach makes sense if we assume that platemaker is doing a good job with the overall 'cheat' parameters, so that the actual ra & dec are good matches for the target_ra/dec, having been placed by platemaker in the right places on average for these large scale parameters.
Some important remaining issues:
An alternative would be to say that we take the PM - desimeter comparison as evidence that a temporally constant set of cheats isn't a horrible idea, but then to fit those cheats based on the three good dither sequences. Then we would be trying to come closer to "truth" than to PM. We'd only have three sequences to use in that case, though, and I haven't yet evaluated how consistent the cheat parameters are among those sequences.
For setting dx & dy, we might also want to think harder about the field model. Currently I take a catalog from a particular guide frame to set this. But we really want to be averaging over all of the relevant guide frames.
Leaving this as a draft PR until I have a DocDB file and we discuss some of these issues.