Skip to content

DM-54625: Add preconvolution pipelines#269

Merged
isullivan merged 2 commits intomainfrom
tickets/DM-54625
May 6, 2026
Merged

DM-54625: Add preconvolution pipelines#269
isullivan merged 2 commits intomainfrom
tickets/DM-54625

Conversation

@isullivan
Copy link
Copy Markdown
Contributor

No description provided.

Copy link
Copy Markdown
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.

I'm pretty sure the DECam/HSC versions of the new pipeline are broken -- they use the wrong ISR task. Unfortunately, I don't see a good fix, short of having separate LSST and non-LSST versions in _ingredients.

The other problem is that the contracts have been deferred to the instrument-specific tasks, and that means the ones for subtractImagesScore have slipped through the cracks.

Comment thread pipelines/_ingredients/ApPipeWithPreconvolution.yaml
Comment thread pipelines/_ingredients/ApPipeWithPreconvolution.yaml Outdated
Comment thread pipelines/DECam/ApPipeWithPreconvolution.yaml
Comment on lines +9 to +15
imports:
- location: $AP_PIPE_DIR/pipelines/_ingredients/ApPipeWithPreconvolution.yaml
tasks:
isr:
class: lsst.ip.isr.IsrTask
config:
file: $AP_PIPE_DIR/config/DECam/runIsrWithCrosstalk.py
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This is incorrect, because ApPipeWithPreconvolution is based on ApPipeWithIsrTaskLSST, which isn't applicable to DECam. You could get around the problem by splicing _ingredients/ApPipeWithPreconvolution and DECam/ApPipe, but that would have the same contract/subset problems we get in ap_verify.

I suppose one question to ask is whether we actually need ApPipeWithPreconvolution for non-LSST cameras.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

This gets at the central problem I was trying to work around, but maybe it is too ugly of a kludge. I only wanted to make a single ApPipeWithPreconvolution and not duplicate it for ApPipeWithIsrTaskLSST and ApPipe, so for DECam and HSC I still inherit from ApPipeWithIsrTaskLSST but override the isr definition back to lsst.ip.isr.IsrTask. This is clearly misleading, but it does work. I would rather not do the splicing approach because of the contract and subset problems you mention, but dropping ApPipeWithPreconvolution for non-LSST cameras seems like a reasonable option.
I am willing to do the splicing approach if you think that would be best, drop ApPipeWithPreconvolution for the other cameras, or leave it as-is but add comments explaining what is going on and why. Your call.

Copy link
Copy Markdown
Member

@kfindeisen kfindeisen May 6, 2026

Choose a reason for hiding this comment

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

Oops, you're right, I don't know how I missed that. 🤦 Yes, I agree that overriding the ISR definition is probably best (IsrTaskLSST's connections seem to be a bit unstable, but hopefully IsrTask isn't changing anymore?).

I think highlighting the class change with a comment might be good enough. You might also add a unit test to guard against code drift (maybe that <instrument>/ApPipe and <instrument>/ApPipeWithPreconvolution have identical ISR task definitions?)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Good idea. I have added a unit test that verifies that the ISR task configs are the same between ApPipe and ApPipeWithPreconvolution versions of the pipeline.

@isullivan isullivan force-pushed the tickets/DM-54625 branch from 3486e8d to d65ebc0 Compare May 6, 2026 18:15
@isullivan
Copy link
Copy Markdown
Contributor Author

@kfindeisen I believe this PR is ready for re-review.

Copy link
Copy Markdown
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.

Looks good, assuming GitHub posts all my comments (I got some weird errors trying to record them).

msg: "calibrateImage.exposure != analyzePreliminarySummaryStats.data"
- contract: calibrateImage.connections.ConnectionsClass(config=calibrateImage).stars_footprints.name ==
getRegionTimeFromVisit.connections.ConnectionsClass(config=getRegionTimeFromVisit).dummy_visit.name
msg: "calibrateImage.stars_footprints != getRegionTimeFromVisit.dummy_visit"
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Missing the contracts checking consistency of calibrateImage with subtractImagesScore -- or are the checks vs. subtractImages supposed to take care of that?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

No harm in adding those contracts as well.

- location: $AP_PIPE_DIR/pipelines/_ingredients/ApPipeWithPreconvolution.yaml
tasks:
# Override the class for `isr`, which is set to `IsrTaskLSST` in the base
# pipeline in `_ingredients`
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This comment seems to be missing from the DECam version.

Comment thread tests/test_pipelines.py Outdated
with self.subTest(file=str(precon_file)):
base_file = precon_file.dirname().join("ApPipe.yaml")
self.assertTrue(base_file.exists(),
msg=f"Expected sibling ApPipe.yaml next to {precon_file}.")
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Might be better to report base_file directly, just in case there's a weird bug in defining it.

Comment thread tests/test_pipelines.py
Comment on lines +215 to +222
self.assertEqual(precon_isr.task_class_name, base_isr.task_class_name,
msg=f"isr task class differs between ApPipe.yaml and "
f"ApPipeWithPreconvolution.yaml in {precon_file.dirname()}.")
self.assertTrue(
base_isr.config.compare(precon_isr.config, shortcut=False),
msg=f"isr task config differs between ApPipe.yaml and "
f"ApPipeWithPreconvolution.yaml in {precon_file.dirname()}."
)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Ugh:

Task nodes are intentionally not equality comparable, since there are many different (and useful) ways to compare these objects with no clear winner as the most obvious behavior.

Maybe add a comment that you can't just do assertEqual(precon_isr, base_isr)?

Comment thread tests/test_pipelines.py
Comment on lines +218 to +222
self.assertTrue(
base_isr.config.compare(precon_isr.config, shortcut=False),
msg=f"isr task config differs between ApPipe.yaml and "
f"ApPipeWithPreconvolution.yaml in {precon_file.dirname()}."
)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

For this, you could probably get away with assertEqual -- since the configs are being read directly from files, any floating-point handling should be deterministic.

@isullivan isullivan force-pushed the tickets/DM-54625 branch from d65ebc0 to 20f84c9 Compare May 6, 2026 19:20
@isullivan isullivan force-pushed the tickets/DM-54625 branch from 20f84c9 to a001b5f Compare May 6, 2026 19:23
The Preconvolution pipelines have to redefine ISR for non-LSST cameras, so add tests to make sure that the configs are still consistent.
@isullivan isullivan force-pushed the tickets/DM-54625 branch from a001b5f to 2230013 Compare May 6, 2026 21:20
@isullivan isullivan merged commit 22340d6 into main May 6, 2026
3 of 4 checks passed
@isullivan isullivan deleted the tickets/DM-54625 branch May 6, 2026 22:45
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.

2 participants