Start Rt sampling after infection initialization
I maintainer di solito rispondono entro 2 giorni
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 38/100
Direzione di ricerca
Start in pyrenew/latent/population_infections.py and pyrenew/latent/subpopulation_infections.py; find where the Rt process gets the full infection length and where first_day_dow is forwarded. Apply the rt_first_day_dow adjustment inside those classes, sample only n_days_post_init, and use the first sampled Rt for exponential initialization. Update latent-infection and weekly integration tests to expect shorter sampled trajectories, no initialization Rt states, and weekly alignment for both parameterizations. Revise docstrings and the latent-infection tutorial for the new time origin.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
PopulationInfections and SubpopulationInfections currently sample Rt across initialization and post-initialization days. Since initialization infections follow an exponential curve determined only by the first Rt there and isn't changed by the latent infection process, it shouldn't be sampled. Instead, we should start the Rt process at the first post-initialization day and use that first Rt to determine initialization growth, taking care to preserve weekly calendar alignment.
This change applies to both state and innovation parameterizations
The core change belongs in the two latent infection classes. It does not require changing public method signatures, but it changes the meaning of the initial Rt parameter and the sampled trajectories.
Required changes
| Code | Required change |
|---|---|
pyrenew/latent/population_infections.py |
Sample Rt for n_days_post_init; use its first value for exponential initialization and the complete sampled trajectory for renewal. |
pyrenew/latent/subpopulation_infections.py |
Make the same change for both the baseline Rt process and subpopulation deviation processes. Calculate each subpopulation’s initialization growth from its first combined Rt. |
| Tests | Update expected trajectory lengths and weekly alignment; verify that initialization adds no sampled Rt states and uses the first post-initialization Rt for growth. Cover both parameterizations and both infection classes. |
| Docstrings and latent-infection tutorials | Explain the new time origin for initial Rt and how it determines the initialization curve. |
Calendar alignment
The latent classes currently receive first_day_dow for the beginning of the full infection history. Before passing it to an Rt process, they should calculate:
rt_first_day_dow = (
None
if first_day_dow is None
else (first_day_dow + n_initialization_points) % 7
)
That adjustment belongs inside the latent classes. MultiSignalModel still needs the full infection timeline for observations and ascertainment.
The temporal-process classes—RandomWalk, AR1, DifferencedAR1, and the weekly wrapper—already accept a requested trajectory length. Their sampling algorithms need no change for this issue. The builder, observation models, and completed ascertainment fix also need no substantive changes.
User-facing behavior
Keep the existing arguments:
log_rt_time_0_rvchanges meaning: it supplies log Rt on the first post-initialization day, instead of the first initialization day. It still determines exponential initialization growth.I0_rvretains its meaning: infection prevalence at the beginning of initialization.n_initialization_pointsretains its meaning: the length of the infection history needed before renewal begins.sample(...)and the returned infection-array shapes remain unchanged.
For recorded daily Rt outputs such as rt_single and rt_subpop, retain the full infection-axis shape by filling initialization entries with deterministic copies of the first Rt. Those entries describe the constant Rt assumed for initialization.
Sampled state/innovation arrays and recorded weekly Rt arrays become shorter. Users inspecting those directly will need to update their time coordinates and shape assumptions. Existing weekly integration tests also need these adjustments.
Ordinary model-construction code can stay the same, while the statistical meaning of initialization changes. No compatibility option for the old initialization behavior is required.
- Lingua principale
- Python
- Stelle
- 30
- Fork
- 11
- Merge medio
- 5g 4h
- PR unite (30g)
- 9
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di CDCgov/PyRenew
-
Complete non-centering in temporal-process innovation parameterizationsForse già presa @cdc-mitzimorris l’ha presa 3 giorni fa. Apertaclean up
Difficoltà 4/5 3-5 giorni Idoneità per principianti 53/100
CDCgov/PyRenew#921 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
Standardize initial value handling across `TemporalProcess`esForse già presa @cdc-mitzimorris l’ha presa 3 giorni fa. Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
CDCgov/PyRenew#917 · 2 commenti ·
I maintainer di solito rispondono entro 2 giorni
-
Update wastewater measurements tutorial to avoid representing 0 concentrations as `-inf` log concentrationsForse già presa @cdc-mitzimorris l’ha presa 9 giorni fa. Aperta
CDCgov/PyRenew#915 · 1 commento · 1 assegnatario ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
I maintainer di solito rispondono entro 2 giorni
-
Demonstrate how missing values should be specified and how they are handledForse già presa @cdc-mitzimorris l’ha presa 13 giorni fa. Aperta
CDCgov/PyRenew#911 · 5 commenti · 1 assegnatario ·
I maintainer di solito rispondono entro 2 giorni
Tutte le issue di CDCgov/PyRenew
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
-
Validate finite output clamping limits in StepPredictor.prepare_clamping_params to prevent silent NaN/Inf propagationForse già presa @muskan-creates352 l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
mllam/neural-lam#848 ·
I maintainer di solito rispondono entro 2 giorni
-
infra
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
fab-geocommuns/RNB-coeur#1166 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
deepspeedai/DeepSpeed#8951 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
aws/context-ontology-accelerator#343 ·
I maintainer di solito rispondono entro 1 giorno