-
Notifications
You must be signed in to change notification settings - Fork 2
DM-48045: Create template metrics and template QC process for Prompt Processing. #408
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
base: main
Are you sure you want to change the base?
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.
Code looks good, but I've got a few thoughts on how we structure this. Mostly along the lines of "can we combine this with that"?
I'm willing to be persuaded either way, so don't feel I'm saying we have to go one way or the other. Let me know your thoughts on what I've said.
Oh, and you'll probably have seen that it's failing GitHub checks on black formatting and isort.
@@ -0,0 +1,22 @@ | |||
description: | |
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.
Do we really want to add another two pipelines on top of coaddQualityCore.yaml
?
Could we instead just add this to coaddQualityCore.yaml
, using either deep
or template
as the default connections.coaddType
, then override that in either drp_pipe
or ap_pipe
(depending on which we choose - deep or template).
I think I'd prefer for the default here to be deep
, since that's what's generally found in coaddQualityCore.yaml
. We'd just make sure that it wasn't run as part of drp_pipe
(if we didn't want it to be).
I saw the chat on dm-science-pipelines about overriding coaddName
, but I don't think that's referring to this - I think that's specifically referring to doing all the coaddQualityCore
tasks with template
as well as deep
.
@@ -0,0 +1,22 @@ | |||
description: | |
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.
See above comment.
|
||
plt.subplots_adjust(hspace=0, wspace=0) | ||
|
||
patch_counter = 90 # The top left corner of a tract is patch 90 |
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.
Isn't hard-coding this risky? Just thinking that other skymaps may not have the same number of patches per tract.
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.
This class should be using the skymap tractInfo. See PerTractPropertyMapPlot
for an example.
@@ -441,3 +442,17 @@ def getInputSchema(self) -> KeyedDataSchema: | |||
yield self.key_is_ref_star, Vector | |||
yield self.key_is_target_galaxy, Vector | |||
yield self.key_is_target_star, Vector | |||
|
|||
|
|||
class UniqueAction(VectorAction): |
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.
Is this used? I can't find anywhere in the PR where this is used. Was it added, then not needed, or have I missed something?
|
||
def __call__(self, data: KeyedData, **kwargs) -> Vector: | ||
patches: Optional[tuple[str, ...]] | ||
match kwargs: |
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.
While I like what this is doing grammatically (patch vs. patches 😄 ), and I see that we do the same for band/bands, I wonder whether we should just keep it simple and have just patches=None
as a keyword so that it's easier to see at a glance.
self.produce.metric.units[f"{name}_stdev"] = "" | ||
|
||
|
||
class CoaddQualityPlot(AnalysisTool): |
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.
Why not combine the metric and the plot generation into a single atool? Or do you want to keep them separate so that plots are only generated when needed, but metrics are made for everything?
|
||
__all__ = ( | ||
"CoaddDepthSummaryPlotConfig", | ||
"CoaddDepthSummaryPlotTask", |
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.
Similarly, do we want to combine these two tasks into one? Or keep them separate so that we don't have to make plots if all we want are metrics?
@@ -552,6 +553,37 @@ def __call__(self, data: KeyedData, **kwargs) -> Vector: | |||
return cast(Vector, mask) | |||
|
|||
|
|||
class PatchSelector(VectorAction): |
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.
FYI I added a PatchSelector
recently, but it doesn't look like you actually need it.
while patch_counter >= 0: | ||
for n in range(10): # column index | ||
ax = plt.subplot(10, 10, m + 1) # there are 10x10 patches per tract | ||
patchSelector = PatchSelector(vectorKey='patch', patches=[patch_counter]) |
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.
There's no point making a ConfigurableAction
inside a call method where it can't actually be reconfigured in a pipeline. You already put patch
and band
in the schema so you may as well just do patch_mask = data["patch"] == patch_counter
, and same for band_mask
.
No description provided.