Stop storing an unused "weight" property from tip frequencies

[tsibley]

This property was introduced with the original frequencies work¹ as an
anticipated need², but it was never used. Omit it for now to avoid
carrying around unnecessary baggage; it can be added back in the future
easily if its time comes.

I uncovered this while authoring a JSON Schema for the tip-frequencies
format.³

¹ In PR #497 as a7bda1e.
² nextstrain/augur#83 (comment)
³ nextstrain/augur#852

[trvrb]

I do think it's highly relevant to work to properly include "weights" even if we haven't done so up to this point. For example, we could be weighting tips based on case counts relative to sequencing intensity to get a better picture of frequencies.

That said, if it's not implemented, it's not implemented and can be safely removed.

We had been "weighting" regions in the seasonal flu build, but just recently turned this off: nextstrain/seasonal-flu@40f850b

However, I think that even including --weights in augur frequencies was not producing a tip-frequencies.json with a weights attribute and instead was directly modifying the area under the curve of each tip kernel. @huddlej: Does this sound correct?

In this case, maybe we just continue this direction and plan rely on this built-in weighting in Augur rather than doing something on the fly in Auspice?

[tsibley]

+1 for handling weights one way or another. @huddlej and @jameshadfield likely have the most input here?

However, I think that even including --weights in augur frequencies was not producing a tip-frequencies.json with a weights attribute

Yep, that's my understanding having recently read through this code and looked at output files.

When I ran my tip-frequencies schema in nextstrain/augur#852 against all s3://nextstrain-data/*frequencies.json, only one file fell out as not validating because it had this weight attribute for each node:

https://data.nextstrain.org/flu_seasonal_h1n1pdm_na_pandemic_tip-frequencies.json

This file was last modified on 12 May 2018 and all the weights are 1.0.

That said, if it's not implemented, it's not implemented and can be safely removed.

AFAICT with some careful grepping and looking, it's not used. However, I would appreciate @jameshadfield's confirmation that I didn't miss some spot.

[huddlej]

Just confirming all the comments so far; the weighting in augur frequencies changes the kernels of the KDEs internally. We never used the weights in the JSON.

[jameshadfield]

Yes, my memory is that this was included to future proof auspice but never actually used, and the code seems to back this up!