Feature Request: Unmatching shouldn't unmatch when eruptions close together

[ktindiana]

In current scheme, the unmatch step takes only the eruption closest to the SEP event as the likely cause of the event. Any older eruptions are unmatched. It will also unmatch CME parameters that are refit with a slightly changed start time. This is the case for sepster_20210528_2312_0824_Parker_Spiral_iss_20210529_1343.json. The CME was refit and had a start time one SOHO frame later. The later CME time was taken to indicate the correct forecast.

For March 7, 2012, to eruptions followed each other closely by less than 2 hours. It was likely the first eruption that caused the SEP event. In the current unmatching logic, if forecasts from both CMEs are there, only a forecast generated from the second eruption will be associated with the SEP event. May be better to associate all CMEs or flares within close succession with the SEP event. So within a window of the closest eruption - 2 hours, for example.

[rickyegeland]

The unmatched status is recorded in SPHINX_dataframe output, correct? It should be somewhat standard procedure to manually verify unmatching.

For Scoreboard validation, it would be nice if SPHINX could generate a Scoreboard URL to take the validation evaluator directly to the event period to inspect what happens. This may imply a feature request to the Scorebaord to accept parameters with HTTP GET.

[ktindiana]

"it would be nice if SPHINX could generate a Scoreboard URL" - this is a fantastic idea and I think we will need to ask for the Scoreboard to accept parameters via URL.

[ktindiana]

SPHINX has been updated not to unmatch if an eruption is within 3 hours of the "best" eruption (selected because it is closest in time). Going to close this issue and make the Scoreboard URL features into its own issue.