Remove Likelihood?

[kellpossible]

We are currently using Likelihood as it is defined in the ADAM paper and CMAH:

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.

[kellpossible]

After long discussion, we decided to try option 3. at least in the short term, pending further discussions.

[kellpossible]

Manu has suggested that we reposition the words "High" and "Low" to be above and below the scale rather than sitting on the scale. Potentially we could also use alternative words like "Maximum"/"Minimum" or "Highest"/"Lowest".

Or like the Utah forecast "Certain"/"Unlikely"

[kellpossible]

Additional comments from Manu:

hey I asked my students if they thought that the 'possible' setting for likelihood seemed closer to low or to high, and they said it looked closer to low. it's really a 'middle' setting, but the scale has no middle. 5 levels would solve this... I think I asked if it looked medium or low, they said low

[kellpossible]

Work in progress analysis paper about our use and definition of likelihood here: https://github.com/kellpossible/avalanche-report/blob/main/docs/avalanche-likelihood-definition.md I would propose that this paper is completed complete with references, so we have a full understanding of the purpose, definition, pros, cons of using likelihood before spending more much time iterating on its use within our software.

[kellpossible]

There is currently a study about avalanche forecast communication going on over at https://caicsignup.avalancheresearch.ca/en/index.php it would be interesting to see what questions they are asking and whether it can help feed into the decisions we make here.