Remove Likelihood?

We are currently using Likelihood as it is defined in the [ADAM](https://arc.lib.montana.edu/snow-science/objects/ISSW16_O20.03.pdf) paper and [CMAH](http://www.avalancheresearch.ca/wp-content/uploads/2017/11/2018_StathamOthers.pdf):

> Likelihood of avalanche(s) is the chance of an avalanche releasing within a specific location and time period, regardless of avalanche size. While probability is dependent on scale, in practice forecasters express their likelihood judgments independently of scale, using qualitative terms such as possible or almost certain (Statham 2008) across different scales. The CMAH considers two factors that contribute to the likelihood: sensitivity to triggers and spatial distribution.

There are some concerns over the value of this term in communicating avalanche forecasts. Manu, @PSAvalancheConsulting and I had a discussion recently about this topic, and we didn't quite reach consensus. I thought that I would summarize it here:

## Points in favour of keeping "Likelihood"

+ It provides a convenient way for users to estimate the "danger" or "riskiness" of a particular avalanche problem type.
+ It was introduced at around the same time that the hazard per avalanche type was removed.
+ It might be too much information and too difficult for people to interpret the "distribution" and "sensitivity".

## Points against keeping "Likelihood"

+ The term is ambiguous.
+ Likely to suffer from different interpretations across languages (which is a major concern for us).
+ We already have trouble getting short and precise translations for its values #47
+ Its application to avalanche forecast is different to how it is used in other contexts. Probably mostly because we are attempting to achieve a higher resolution on the lower end of the scale than is typical.

From the ADAM paper:

> "Defining likelihood for a rare event such as triggering an avalanche is challenging. As forecasters, we want to make people aware of a potentially dangerous situation. We tell them “today, it is likely that you trigger an avalanche”. If we look up various definitions for “likely” we end up with values of more than 50% or even 66% percent (EAWS, 2016c; Mastrandrea et al., 2010). However, send ing out 1000 skiers on 1000 avalanche slopes at considerable avalanche danger, would luckily not result in 500 or more accidents"

+ With CMAH and ADAM we are essentially deriving likelihood from two values which are already imprecise by multiplying them together, this results in a multiplication of their associated errors.
+ We are already working with limited resources forecasting in our region, providing this value may give a false sense of the certainty associated with the forecast.
+ A higher onus is on the recreational user in this region anyway.
+ If someone stops reading the forecast after seeing the likelihood they may miss important details in the rest of the problem type description, which are not captured in the simplification.
+ For such a nebulous term with high associated error, the values assigned to it use very specific language which may convey a false sense of accuracy.
+ Confusion over whether likelihood refers to the likelihood of a person triggering vs a natural release. CMAH definition seems to imply that it covers both forms of release mechanism. To be fair, "Sensitivity" itself suffers a little from this?

## Problems with deriving Likelihood automatically

There are some situations where deriving likelihood automatically from distribution and sensitivity may not work well. For instance, wet or deep persistent slab, the sensitivity to trigger may be low, but weather may increase the actual likelihood.

## Alternatives

1. Remove "Likelihood" entirely and rely on people reading the "Distribution" and "Sensitivity" in the forecast details.
+ Perhaps add graphs for these, but that may get a bit busy for people to read.
2. As per #28 move to something like the Norwegian system.
3. #53 This will make the translations less ambiguous, and the imprecise language also conveys the nebulousness of the term and associated error better.