Details
-
Type:
Bug
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: afw, pipe_tasks
-
Labels:None
-
Story Points:2
-
Epic Link:
-
Sprint:AP S21-2 (January)
-
Team:Alert Production
-
Urgent?:No
Description
Stacks that include the merge of DM-27174 cannot read coadds written before the merge. A minimum working example is:
>>> from lsst.afw.image import ExposureF
|
>>> ExposureF('/datasets/DC2/repoRun2.2i/rerun/w_2020_48/DM-27780/coadd/deepCoadd/y/3828/0,0.fits')
|
Traceback (most recent call last):
|
File "<stdin>", line 1, in <module>
|
lsst.pex.exceptions.Exception:
|
File "src/image/VisitInfo.cc", line 272, in virtual std::shared_ptr<lsst::afw::table::io::Persistable> lsst::afw::image::{anonymous}::VisitInfoFactory::read(const InputArchive&, const CatalogVector&) const
|
Archive assertion failed: catalogs.front().getSchema() == keys.schema {0}
|
File "src/table/io/InputArchive.cc", line 103, in std::shared_ptr<lsst::afw::table::io::Persistable> lsst::afw::table::io::InputArchive::Impl::get(int, const lsst::afw::table::io::InputArchive&)
|
loading object with id=3367, name='VisitInfo' {1}
|
File "src/table/io/InputArchive.cc", line 103, in std::shared_ptr<lsst::afw::table::io::Persistable> lsst::afw::table::io::InputArchive::Impl::get(int, const lsst::afw::table::io::InputArchive&)
|
loading object with id=3361, name='CoaddPsf' {2}
|
lsst::afw::table::io::MalformedArchiveError: 'Archive assertion failed: catalogs.front().getSchema() == keys.schema {0}; loading object with id=3367, name='VisitInfo' {1}; loading object with id=3361, name='CoaddPsf' {2}'
|
This error does not apply to other Exposure files, such as calexps.
Since Exposure itself does not use Persistable to read/write VisitInfo, and the problem is specific to coadds, I believe the problem is an incompatibility in afw::table::ExposureTable and/or afw::table::ExposureCatalog (used by afw::image::CoaddInputs, meas::algorithms::CoaddPsf, and meas::algorithms::CoaddTransmissionCurve). Although afw::table::ExposureRecord appears to have some safeguards to allow reading of old schemas, these are not propagated down into VisitInfo, where the exception is actually raised.
Attachments
Issue Links
Activity
Couple final comments on the PR, but otherwise you're good. Thanks for fixing this so quickly!
I'll leave it to your judgement whether we should have a ticket about genericizing the persistable versioning that PhotoCalib and VisitInfo now both share. I think it would be a good thing to have and would make the lack of forward-compatibility explicit, but I don't know how easy it would be to implement so that Persistables can use it easily.
John Parejko, can you take a look (80 lines)? Thanks!