-
Notifications
You must be signed in to change notification settings - Fork 1
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
DM-25450: Add Rowe statistics to SQuaSH #60
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.
Only looked at the
0aa731a
to
c3cbdf7
Compare
c3cbdf7
to
04b6b3c
Compare
------- | ||
xy : `treecorr.KKCorrelation` | ||
A treecorr.KKCorrelation object containing the correlation function | ||
""" |
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.
Here and throughout, all descriptions above need backticks for referenced parameters and should end with a period. It would be nice to include valid values for ra/decUnits
(and a check on them to provide a useful error message, unless treecore
can be trusted to provide that).
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.
Value checking is done by treecorr
and is actually less strict than it appears to be (e.g., 'deg', 'degrees' etc. are all acceptable values by treecorr
)
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.
Sounds good, but please use double ticks for strings throughout to be consistent.
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.
You mean double quotes for strings? I believe double ticks is for internal parameters.
@@ -1161,6 +1165,29 @@ def plotRhoStatistics(self, description, plotInfoDict, log, treecorrParams, stat | |||
rhoStats = rhoStatsFunc(good_catalog) | |||
plotRhoStats(axes, rhoStats) | |||
|
|||
if verifyJob is not None: | |||
verifyJob.meta.update({"shapeAlgorithm": "HSM"}) |
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.
Since you are adding this to the metadata, I think you should leave the "HSM" out of the metric name so that it is not misleading if you were to compute the same metric but using a different shape algorithm.
Also, for consistency, you could use the updateVerifyJob(job, metaDict=None, specsList=None)
utility function in utils.py
to do the updating here.
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.
As mentioned here, the HSM name should probably stay.
8460819
to
b426c7e
Compare
@@ -516,6 +517,13 @@ def runDataRef(self, patchRefList, subdir="", cosmos=None): | |||
self.allStats, self.allStatsHigh = savePlots(plotList, "plotCoadd", repoInfo.dataId, | |||
repoInfo.butler, subdir=subdir) | |||
|
|||
metaDict = {kk: plotInfoDict[kk] for kk in ("cameraName","filter","tract","visit","patch","rerun")} |
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.
Spaces after commas in list.
Since this is a per-tract metric, it does not make sense to include "patch" or "visit" in the metadata (I suppose one could imagine adding a "patches" or "patchList" entry that lists all the patches in the dataset, but as is, you'd only get a single one listed). Also, the camera name has been referred to as "camera" (not "cameraName") in colorAnalysis.py
. If you feel strongly about "cameraName", please also change it in colorAnalysis.py
(and, if you do go that route, you could also add the "rerun" entry there 😉 )
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.
Well, this can also be called in visitAnalysis
and it runs through this implementation. I include it in the metaDict
only if it is not None, so that only relevant info is passed whether it is called from visitAnalysis
or coaddAnalysis
. And I modified it to include patchList
.
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.
The plotInfoDict
has a camera
object and its name as cameraName
. It looks like the camera
object is not serializable, nor do I want it in the metadata. To avoid confusion, I preferred to keep it as cameraName
. I'll change it colorAnalysis
in another ticket.
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.
You mention that visitAnalysis
can call this and that's why you left in the irrelevant visit
metadata, but that's not the case. visitAnalysis
does it's own metaDict
setting here:
https://github.com/lsst-dm/pipe_analysis/blob/master/python/lsst/pipe/analysis/visitAnalysis.py#L527-L530
(and I don't know that you can guarantee that visit
will resolve to None
whenever you think it should...)
And do note the camera
vs. cameraName
entry. If you INSIST on naming the tag cameraName
, that will be anti-pattern to what is already in SQuaSH and will leave things inconsistent within pipe_analysis
. I would not want to live in this state while awaiting another ticket...I'd prefer keeping things consistent and, if you feel we must make the switch to cameraName
, then that should happen everywhere on this ticket or atomically on a separate ticket.
Also, I don't think the patchList
is really appropriate as a tag (how would a list of ~81 patches look in the dropdown menu...and is a list
there even allowed?) I think this might be more appropriate in the measExtrasDictList
.
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 wouldn't insist on naming it cameraName
, but would have preferred it. I've changed it to call camera
now. I also exclude any patch
information, since it probably is run on all 81 patches by default.
------- | ||
xy : `treecorr.KKCorrelation` | ||
A treecorr.KKCorrelation object containing the correlation function | ||
""" |
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.
Sounds good, but please use double ticks for strings throughout to be consistent.
b426c7e
to
1db0cab
Compare
@@ -516,6 +517,13 @@ def runDataRef(self, patchRefList, subdir="", cosmos=None): | |||
self.allStats, self.allStatsHigh = savePlots(plotList, "plotCoadd", repoInfo.dataId, | |||
repoInfo.butler, subdir=subdir) | |||
|
|||
metaDict = {kk: plotInfoDict[kk] for kk in ("cameraName","filter","tract","visit","patch","rerun")} |
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.
Well, this can also be called in visitAnalysis
and it runs through this implementation. I include it in the metaDict
only if it is not None, so that only relevant info is passed whether it is called from visitAnalysis
or coaddAnalysis
. And I modified it to include patchList
.
@@ -516,6 +517,13 @@ def runDataRef(self, patchRefList, subdir="", cosmos=None): | |||
self.allStats, self.allStatsHigh = savePlots(plotList, "plotCoadd", repoInfo.dataId, | |||
repoInfo.butler, subdir=subdir) | |||
|
|||
metaDict = {kk: plotInfoDict[kk] for kk in ("cameraName","filter","tract","visit","patch","rerun")} |
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.
The plotInfoDict
has a camera
object and its name as cameraName
. It looks like the camera
object is not serializable, nor do I want it in the metadata. To avoid confusion, I preferred to keep it as cameraName
. I'll change it colorAnalysis
in another ticket.
c7113fa
to
d651b2b
Compare
I think I've addressed all the comments above. Apart from naming the metrics, if there are no more issues, I'll run the Travis. |
To create a `Datum` instance of the `lsst_verify` package, the `quantity` argument should be associated with a unit. Since Rho Statistics are unitless, we only provide the numerical value and pass an empty string as its unit. This does not change the default behavior if `quantity` is an `astropy.units.Quantity` instance, as the `unit` argument is ignored.
26850a7
to
f4b926d
Compare
metaDict = {kk: plotInfoDict[kk] for kk in ("cameraName", "filter", "tract", "patchList", | ||
"visit", "rerun") | ||
if plotInfoDict[kk] is not None} | ||
self.verifyJob = updateVerifyJob(self.verifyJob, metaDict=metaDict, specsList=None) |
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.
Looks like you lost the changes here...
The various correlations functions involving PSF ellipticity and ellipticity residuals, defined by Rho 1-5 statistics, quantity how PSF modeling errors introduce additive systematics to weak lensing shear-shear correlation functions. Similarly, the correlation of PSF size residuals contribute to a multiplicative systematic to the shear-shear correlations (see Gibin et al., 2020). Hence, we define a new Rho 0 statistic to monitor PSF size residual correlations.
Rho statistics are correlation functions involving PSF sizes, ellipticities and their residuals. However, since the lsst-verify framework only tracks scalar quantities in the dashboard, we include a functionality to produce summary statistics of the Rho statistics. Currently, such metrics include taking the average value of the correlation function(s) below and above some scales (1 arcmin by default).
f4b926d
to
6bade95
Compare
This PR covers the calculation of several metrics related to Rho Statistics and their inclusion in the verify framework. There is an associated PR in
lsst/verify_metrics
that includes the definition of these new metrics and specifications.