delete Zoltar forecasts that were deleted from github

[matthewcornell]

The forecasts in this sheet were deleted from github, but not from zoltar: COVIDhub-deleted-forecasts. They were deleted from the repo b/c they only forecasted these two targets that were dropped in summer: 'day ahead inc death' and 'day ahead cum death'.

Points:

• some rows dups - 37, 38 - need to just do unique ones
• "retract on zoltar": the zoltar forecast should be completely retracted nick 90% sure: every file will only have retired targets
• "need partial retraction on zoltar": have a mix of retired and non-retired targets
• 86-92: different handling -> DO:
• any of these versioned? -> note on spreadsheet
• script generates retractions only for the two retired targets

[matthewcornell]

I wrote a script that analyzed the sheet's forecasts, and I've attached the output. Results:

• None of the 71 unique forecasts have any other versions.
• Most of them are 100% retractions (i.e., all of their targets were removed - non-zero num_retract column value).
• Some forecasts had targets that were a mix of removed and non-removed ones (both num_retract and num_dup were non-zero).
• Finally, some had no removed targets (zero num_retract, non-zero num_dup).

mc-0429-deleted-forecasts.csv

[matthewcornell]

Additional details from @nickreich:

• issue_date for new (partially or full retracted) forecasts: should reflect when actually retracted (date in github) = on google sheet 1: commit_date. If >1 per a source, use newest date = if conflict with curr issue_date: add one day
  • last three (0/non-zero nums): should be retracted, not duplicated. 12462, 16543, 17246

[matthewcornell]

Here's the latest output of what the script would do. Notes:

• the last three forecasts have is_corrected=TRUE, as we discussed. (I show all retractions now - no dups)
• the last two have source_gt_issue=TRUE, which means the source_commit_date is <= the zoltar issue_date. I set the new_issue_date (which will be used for the new retracted forecast) to the forecast's timezero + 1 day
• all other new_issue_date values are set to the source_commit_date

I have not actually run the script yet. If the attachment looks OK, I'll run it locally, then back up production and run it there.

mc-0430-deleted-forecasts.csv

[matthewcornell]

I ran the script (attached) against production, and spot-checked the new forecasts (IDs are at the bottom of the attached output file) - they all look fine to me, but please double-check.

issue_308_app.py.txt issue_308_app-out.txt

[matthewcornell]

Script had a bug. I added it plus tests to a new branch and then ran on staging. Output attached. mc-0503-staging.csv mc-0503-staging-out.txt

[matthewcornell]

Script was not calling the metadata cache code correctly. Attached has results of a staging run. Looks ok to me, including the previous troublesome one:

• https://rl-zoltar-staging.herokuapp.com/forecast/11953
• https://rl-zoltar-staging.herokuapp.com/forecast/26039

mc-0504-staging.csv

[nickreich]

looks good to me too! I looked at some other empty v2 forecasts and they looked correct as well.