imspy_predictors RT: default to Chronologer#398
Merged
Conversation
Make Chronologer the goto retention-time predictor (it reaches ~4× tighter median residual than the imspy transformer baseline on timsTOF data, per rt_im_exploration.ipynb benchmarks). The transformer is still reachable via load_deep_retention_time_predictor(backend="transformer"). hub.py gains a per-model "url" override field; the new entry rt/chronologer_base.pt pulls Chronologer_20220601193755.pt straight from the upstream Searle Lab repo (Apache-2.0, attribution kept in the chronologer.py docstring). We deliberately don't re-host — any upstream fix or retraining propagates automatically. SHA-256 is locked (1a500c24...) so corruption surfaces immediately. Backward-compatible: existing callers passing backend=None get the new default; passing backend="transformer" preserves the previous behavior. The Chronologer branch falls back to the transformer if the upstream chronologer package isn't installed or the download is unreachable.
2 tasks
animesh
pushed a commit
to animesh/rustims
that referenced
this pull request
May 28, 2026
PR theGreatHerrLebert#398 made load_deep_retention_time_predictor() default to Chronologer, but DeepChromatographyApex.__init__ calls it with no args and then runs self.model.to(self._device). Chronologer is a wrapper class with its own internal device handling and no .to() method, so DCA now raises AttributeError on instantiation when no explicit model is passed. Fix: DCA explicitly requests backend="transformer" — it's the model class DCA was designed around, and other callers can keep using the no-arg default (Chronologer) without surprises. Caught by an end-to-end integration run on monster3's primitives DIA pipeline: cell A (--rt-model dca) of the v4 production-weights comparison failed immediately at the RT step.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
load_deep_retention_time_predictor()now defaults to Chronologer (Searle Lab residual-CNN, Apache-2.0) — roughly 4× tighter median residual than the imspy transformer on timsTOF data, perrt_im_exploration.ipynbbenchmarksload_deep_retention_time_predictor(backend="transformer")pretrained/hub.pygains a per-model"url"override; the newrt/chronologer_base.ptentry pullsChronologer_20220601193755.ptdirectly from the upstream Searle Lab repo — no re-hosting, so upstream fixes propagate automatically. SHA-256 locked (1a500c24…) so corruption surfaces immediately on downloadWhy now
Cross-deposit reproducibility analysis on six modern timsTOF deposits showed the imspy transformer RT was the weakest of the three predictors we ship. Chronologer's residual-CNN architecture wins consistently. Now that the vendor-free Chronologer adapter is in
imspy_predictors.rt(landed in PR #397), wiring it as the default is mechanical.This is Chunk A of a three-chunk plan. Chunks B (CCS goto = fine-tuned) and C (intensity goto = fine-tuned) are deferred until the production fine-tune notebook (
claudius-proteomics/notebook/production_finetune.ipynb) runs and produces weights on disk.Backward compatibility
load_deep_retention_time_predictor()andload_deep_retention_time_predictor(backend=None)calls now return Chronologer — behavior change, but the call signature is unchangedload_deep_retention_time_predictor(backend="transformer")calls preserve the previous behavior exactlychronologerPython package isn't installed, or the base-weights download is unreachable, the function logs a warning and falls back to the transformer path. No hard breakageTest plan
tests/test_predictors.py::test_deep_chromatography_apexstill passes (the test only checks class importability, not loader defaults)python -c "from imspy_predictors.rt import load_deep_retention_time_predictor; m = load_deep_retention_time_predictor(); print(type(m).__name__)"returnsChronologer(or, in a env without the upstream chronologer package, prints a warning and returns the transformer)python -c "from imspy_predictors.rt import load_deep_retention_time_predictor; m = load_deep_retention_time_predictor(backend='transformer'); print(type(m).__name__)"returns the legacy model