Report mean frequencies instead of median

[huddlej]

Current and expected behavior

Median frequencies from MCMC estimate do not always sum to 100%, but the mean frequencies should.

For example, the following figure shows recent B/Vic total frequencies by forecast date and location using posterior medians:

Then, when we calculate B/Vic total frequencies by forecast date and location using posterior means, we get the following:

Possible solution

Options include:

1. Change the local run-model script to calculate the mean across the posterior distributions there
2. Change the workflow to post-process the posterior JSON exported by run-model to generate mean frequencies
3. Change evofr to allow the user to specify an alternate point estimator to median in the get_sites_variants_tidy function or add mean as an estimator along with the existing quantile estimation.

The last option is most appealing since it doesn't require us to duplicate logic for looping over the posterior samples and it's backward compatible for forecasts-ncov and any other downstream uses of evofr.

Even if we replace the "median" entries in the JSON with "mean" (or add a new "mean" entry), the evofr-viz library we use to plot frequencies hardcodes a reference to the "median" entry. The parseModelData function needs a way to know which point estimate to use from the available ps values in the model JSON. The simplest way to pass that information may be in the model JSON's metadata, following the existing pattern of specifying variant colors in the metadata. For example, we could add an optional ps_point_estimate_key to the metadata which refers to the key in the available ps values to use as the point estimate. This change would be backward compatible, too, if the default behavior is to use the "median".

If we choose to modify the model JSON, then we need to add an argument to evofr's get_sites_variants_tidy function to allow the calling code to set the ps_point_estimate_key in the metadata.

The plan would involve the following PRs:

• Support alternate point estimate functions blab/evofr#65
• Support user-defined point estimator functions forecasts-viz#33
• Use mean instead of median for point estimates #38

[jameshadfield]

Check for user-defined ps key to use as a point estimate in the model JSON while parsing model data, using "median" as the default

I can do this next week if you'd like? Is there a JSON out there with those data?

[huddlej]

Thanks, @jameshadfield! I just finished modifying evofr to produce the JSONs needed for the viz work today, so I pushed a PR to forecasts-viz to use the new point estimator key. The PR works for me, but I'd love to know if I actually implemented this the way I should have...