Closed javierggt closed 1 year ago
This makes sense to me, though where in this code do you pull out which matrices to use from a reference CALDB? I didn't immediately see that and you aren't getting quite a full line-by-line code review from me on this. Thanks!
This makes sense to me, though where in this code do you pull out which matrices to use from a reference CALDB?
This is a good question. To "correct" from one reference CalDB to another, I actually subtract, because the effects of curvature will be small (these are a few arcseconds, after all). If I wanted to use the actual matrices to calculate the shift, I would use the matrices that I put in the dictionary.
If the question is where do I determine which CalDB version corresponds to a given time, that would be here (the last CalDB after removing CalDB versions after the one required, and sorting by version and start date)
Description
This PR makes it so the offsets can be adjusted to match the expectation after reprocessing using the latest alignment files in the CalDB.
The current master just plots the offsets resulting from the pipeline, but there is a time range that was processed with an earlier CalDB, and it would have smaller offsets if the observations were reprocessed. Since there will be no reprocessing soon, we need a way to display the offsets as if they had been reprocessed with the latest calalign files. This situation will happen whenever we update the calalign files.
This PR introduces the following changes:
x_ray_src
table has a newcaldb_version
field to keep track of the CalDB version used to compute the offsets. Whether this should be in theobs
table is debatable. Accordingly, theobservation.Observation
class includes methods to determine the CalDB version and it also stores the calalign information for future use.utils.calalign_from_files
which reads calalign files and produces a table of calalign matrices and offsets. This could also be in mica.utils.get_calalign_offsets
usescalalign_from_files
and thecaldb_version
in the cross-matches to shift the offsets so they match what would result from reprocessing using a reference CalDB (the latest CALALIGN files by default). This is only for display purposes, offsets on file are not changed.--use-latest-calalign
option tocalc_astrometry_rms.py
(used for quarterly inputs).Interface impacts
Adds one field to a table in astromon file. Requires a new version of the file. For testing purposes I am using the file at
/proj/sot/ska/jgonzalez/git/astromon/astromon-caldbver.h5
PROMOTION ACTIONS when this PR is promoted to production, the file needs to be promoted as well.
Testing
Unit tests
Independent check of unit tests by Jean
Functional tests
In order to produce the new
astromon.h5
file, I first had to get the caldb version for all observations, which I did using this branch and this gistFor the following tests, I use a new astromon file:
Celmon
I ran the celmon script:
and this is the output:
Documentation
Here is the updated documentation
calc_astrometry_rms
output: