Skip to content
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-27388: Implement metric system for fakes in AP #65

Merged
merged 6 commits into from Dec 14, 2020
Merged

Conversation

morriscb
Copy link
Contributor

@morriscb morriscb commented Dec 8, 2020

No description provided.

Fix linting.

Debug variable name.

Debug metric name.

Fix metric name.
Debug unittest.

Remove unittest.

Debug unittest.
Copy link
Member

@kfindeisen kfindeisen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As brought up on Slack, there's not a good solution for what you're trying to do (and it's a much bigger question than a ticket about one metric). My comments below are based on the assumption that you take the AM1, AM2, etc. approach for now; that will at least keep measurements from different magnitude bins from overwriting each other.

Comment on lines +46 to +47
"package": "ap_pipe",
"metric": "apFakesCompleteness"}):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re: names, there should be a corresponding metric defined in the verify_metrics package (they cannot have periods, because they're namespaced as ap_pipe.apFakesCompleteness). I think creating a Measurement for a nonexistent metric is supposed to fail, but that's always been flaky.

Copy link
Member

@kfindeisen kfindeisen Dec 8, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, now I see what you're trying to do. The current system really doesn't support parametrized metrics, unless you have a standardized set of values (e.g., apFakesCompleteness20t25, apFakesCompleteness25t30). Support for tweaking numbers was sort-of discussed on #dm-squash in a different context, but then nothing got acted on, and I'm not sure the proposed solution would work in Gen 3.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not quite getting where to set these names (This is in addition to your comment later about connections). Should I just remove the automated naming in this code and just rely on doing everything in the pipeline config? If so, what all do I have to set?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant here that you'd have to add the metrics (the final names, with magnitudes) to https://github.com/lsst/verify_metrics/blob/master/metrics/ap_pipe.yaml if you want them to work everywhere (I think SQuaSH only uploads metrics defined in those files). You can use << notation (see pipe_tasks.yaml for examples) to cut down on the boilerplate.

Doing everything in the pipeline config would work; I think you'd just have to set connections.metric plus the magnitude values for each case.

Copy link
Member

@kfindeisen kfindeisen Dec 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So for the metric definitions in verify_metrics, something like:

apFakesCompleteness20t25: &apFakesCompleteness
    description: ...
    unit: ""
    reference:
        url: https://confluence.lsstcorp.org/pages/viewpage.action?spaceKey=~ebellm&title=Alert+Production+Metrics
    tags:
        - ap_verify
        - assoc
        - CCD

apFakesCompleteness25t30:
    <<: *apFakesCompleteness
    description: ...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I basically have another ticket for this set of work: DM-26593. This one is mostly just to make the metric and get it tested so I'll add adding this to that ticket.

python/lsst/ap/pipe/metrics.py Show resolved Hide resolved

class ApFakesCompletenessMetricConfig(
MetricTask.ConfigClass,
InsertFakesConfig,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be worth a comment why you need to inherit from InsertFakesConfig (I assume it's to grab column names?).

Comment on lines 65 to 66
doc="Minimum magnitude the mag distribution. All magnitudes requested "
"are set to the same value.",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand this description. Are you saying you draw some magnitude between magMin and magMax, and then set all the fake sources to have that one magnitude?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

(`lsst.verify.Name`, read-only).
"""
return Name(package=self.connections.package,
metric=f"{self.connections.metric}Mag{self.magMin}t{self.magMax}")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm... currently, MetricTask defines its output dataset name as "metricvalue_{package}_{metric}", without reference to Config.metricName. It might be better to have ApFakesCompletenessMetricConnections.__init__ set its own metric field based on the config, as then everything else would follow automatically. But I don't know if that would work; Connections don't like being edited.

Another solution would be to have MetricTaskConnections.__init__ set its output based on Config.metricName... I'm sure that would work, but it would be hard for anyone to understand, let alone maintain, something that tangled.

Comment on lines 122 to 124
metricName = \
f"{self.config.metricName}"
magnitudes = matchedFakes[f"{self.config.magVar}" % band]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
metricName = \
f"{self.config.metricName}"
magnitudes = matchedFakes[f"{self.config.magVar}" % band]
metricName = self.config.metricName
magnitudes = matchedFakes[self.config.magVar % band]


self.band = 'g'
magCut = 25
magMask = (fakeCat[f"{fakesConfig.magVar}" % self.band] < magCut)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
magMask = (fakeCat[f"{fakesConfig.magVar}" % self.band] < magCut)
magMask = (fakeCat[fakesConfig.magVar % self.band] < magCut)

Comment on lines +81 to +83
self.fakeCat = fakeCat.assign(diaObjectId=ids,
filterName=["g"] * len(fakeCat),
diaSourceId=ids)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit surprising. Shouldn't the catalog returned by fakesTask already have a filter column?

Copy link
Contributor Author

@morriscb morriscb Dec 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The columns here are to mimic the results of matchFakes, not create fakes. The fakes have all magnitudes in all bands created. This is faking columns after processing. Added a comment.

def testValid(self):
"""Test the run method.
"""
metricComplete = self.makeTask(20, 30)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this equivalent to self.task?

def testValidEmpty(self):
"""Test the run method with a valid but zero result.
"""
metricComplete = self.makeTask(25, 30)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest making this

Suggested change
metricComplete = self.makeTask(25, 30)
metricComplete = self.makeTask(self.magCut, self.magCut + 5)

(with appropriate changes to setUp()). That way the test will be valid if the setup changes later.

Change valid test to use self.task.

Add comment.

Simplify string names in test and code.

Add error handling to runQuantum.

Add/modify docs.

Add connections init for metric config.

Remove automated renaming.

Fix linting.
Change order of operation in test.

Remove places.

Change to exclicit value.

Add places to test.

Change to 2 places in Almost Equal comparison.
@morriscb morriscb merged commit c197479 into master Dec 14, 2020
@morriscb morriscb deleted the tickets/DM-27388 branch December 14, 2020 22:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants