Closed dfulu closed 1 year ago
Merging #65 (d9e5ef8) into main (e420789) will not change coverage. Report is 1 commits behind head on main. The diff coverage is
100.00%
.
@@ Coverage Diff @@
## main #65 +/- ##
=======================================
Coverage 68.15% 68.15%
=======================================
Files 22 22
Lines 1617 1617
=======================================
Hits 1102 1102
Misses 515 515
Files Changed | Coverage Δ | |
---|---|---|
pvnet/models/multimodal/deep_supervision.py | 79.83% <ø> (ø) |
|
pvnet/models/multimodal/multimodal.py | 96.90% <ø> (ø) |
|
pvnet/models/multimodal/weather_residual.py | 88.54% <ø> (ø) |
|
pvnet/__init__.py | 100.00% <100.00%> (ø) |
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more
Pull Request
Description
Closes #63
min_sat_delay_minutes
to be consistent with what we get in productionNote that the
min_sat_delay_minutes
model parameter should be set to the same value assatellite.live_delay_minutes
in the data config.Also note that I have updated the config
gcp_configuration.yaml
to havelive_delay_minutes=30
but have updated theapp_configuration.yaml
to havelive_delay_minutes=60
. These are different because our production system currently makes satellite data available so that the delay alternates between 30 and 60 minutes. Ideally (reflected ingcp_configuration.yaml
) the model could use the data from -60 to -30 minutes if it is there and ignore it if it is missing (and hence filled with zeros). In practice (as reflected inapp_configuration.yaml
) we found this may cause our predictions to alternate between higher and lower depending on the delay, so in production we simplify to use a constant 60 minute delay.Checklist: