Add counterfactual minus guided/unguided diff at location level

[Zapiano]

Followed an approach similar to #452 (comment) but for a spatial level.

Note: Depends on #847

Example of code

using ADRIA
using WGLMakie, GeoMakie, GraphMakie

Makie.inline!(false)

# Load domain
dom = ADRIA.load_domain(...)

# Create scenarios
num_scens = 2^10
scens = ADRIA.sample(dom, num_scens)

# Run model / Load ResultSet
rs = ADRIA.run_scenarios(dom, scens, "45")

# Extract cf_difference_loc for guided and unguided (in that order)
rc = ADRIA.metrics.relative_cover(rs)

# Compute difference between guided and counterfactual using the 0.6-th quantile
gd_res = metrics.ensemble_loc_difference(rc, scens; agg_metric=0.6)

# Compute difference between unguided and counterfactual using the median
ug_res = metrics.ensemble_loc_difference(r_cover, scens; diff_target=:unguided)

# Plot maps of difference to the counterfactual
ADRIA.viz.map(rs, gd_res[summary=At(:agg_value)]; diverging=true)
ADRIA.viz.map(rs, ug_res[summary=At(:agg_value)]; diverging=true)

Plots

• 1024 scenarios

Guided - Counterfactual (0.6-th quantile)	Unguided - Counterfactual (median)

[ConnectedSystems]

Bump @Zapiano

[ConnectedSystems]

How close are we to merging this?

[Zapiano]

How close are we to merging this?

I'll start looking into this now and let you know what's missing or of it's ready soon.

[Zapiano]

@ConnectedSystems This one is ready for another review. Note that now it depends on #847

[ConnectedSystems]

Thanks.

An example usage would be appreciated too @Zapiano

[Zapiano]

Thanks.

An example usage would be appreciated too @Zapiano

I've added an example in this PR. Once this PR is approved I can add this plot to the documentation on a separate PR.

[ConnectedSystems]

I'm not sure the indicated use it the best approach.

It forces only one set of bootstrapped results (only the median?), and forces additional computations to be done (e.g., what if I only want gd_res?)

# Extract cf_difference_loc for guided and unguided (in that order)
rc = ADRIA.metrics.relative_cover(rs)
gd_res, ug_res = ADRIA.metrics.cf_difference_loc(rc, scens)  # <- this method name feels awkward

# Plot cf_difference_loc for unguided and guided
gd_fig = ADRIA.viz.diff_map(rs, gd_res[2, :])  # <- why `[2, :]`? (I know why, but feels awkward)
ug_fig = ADRIA.viz.diff_map(rs, ug_res[2, :])

Instead, I suggest something like the below which, to me, is a cleaner UX.

rc = ADRIA.metrics.relative_cover(rs)

# outcome, scenario spec, percentile value of interest
gd_res = ADRIA.metrics.ensemble_difference(rc, scens, 0.5; timestep=2, scenario_type=:guided)

# outcome, scenario spec, statistical function of interest
ug_res = ADRIA.metrics.ensemble_difference(rc, scens, mean; timestep=2, scenario_type=:unguided)

On the plotting, it kind of feels like we're getting to the point where we want our own YAXArray subtype.

ADRIA.viz.map(rs, gd_res::SomeCustomYAXArray?)  #<- uses different defaults to the "usual" `viz.map()`

[Zapiano]

@ConnectedSystems this was updated to address your comments. The description was updated with new example of usage and plots.

[Zapiano]

On the plotting, it kind of feels like we're getting to the point where we want our own YAXArray subtype.

ADRIA.viz.map(rs, gd_res::SomeCustomYAXArray?)  #<- uses different defaults to the "usual" `viz.map()`

I'm not sure I understand the purpose of having our own YAXArray subtype.

[ConnectedSystems]

I'm not sure I understand the purpose of having our own YAXArray subtype.

To be able to define our own custom styling for specific use cases and be able to make different styles (e.g., different set of default options) when plotting some arbitrary results (e.g., some_plot(a_matrix)) compared to some_plot(a_general_yaxarray) and some_plot(a_yaxarray_with_context_specific_metadata)

[ConnectedSystems]

@Zapiano fyi there are conflicts now because of the merge of #863. Could you rebase or merge main as appropriate?

[Zapiano]

@Zapiano fyi there are conflicts now because of the merge of #863. Could you rebase or merge main as appropriate?

I rebased but the tests are not passing. I'll let you know when this is ready again.

[Zapiano]

@Zapiano fyi there are conflicts now because of the merge of #863. Could you rebase or merge main as appropriate?

I rebased but the tests are not passing. I'll let you know when this is ready again.

@ConnectedSystems the tests that were not passing is a problem on the main branch apparently (#890). If you prefer waiting for that to be fixed so we are sure the tests are passing for this PR as well it's fine, otherwise this one is ready to merge.

[ConnectedSystems]

Have you updated to the latest dependencies?

[Zapiano]

Have you updated to the latest dependencies?

Yes.

[ConnectedSystems]

I'm not sure I understand the purpose of having our own YAXArray subtype.

FYI, Makie's theme recipes seem more stable now, and better documented:

https://docs.makie.org/stable/tutorials/wrap-existing-recipe

[ConnectedSystems]

This PR can be merged once #890 is confirmed to be addressed by #891

[Zapiano]

@ConnectedSystems tests are passing and I've updated testset names for the tests that are related to this PR as we discussed.

[Zapiano]

@ConnectedSystems just reminding you that this is ready for review.

[ConnectedSystems]

Two minor comments, but this is ready to be merged once those are addressed.

[Zapiano]

Two minor comments, but this is ready to be merged once those are addressed.

Done, and all tests passing.

[Zapiano]

@ConnectedSystems I made two changes:

1. I updated the example (and tests) to use the YAXArray dim/label names instead of the index 2 directly when assessing the aggregate metric
2. I have deleted the function diff_map and I'm using map instead, with an option for diverging color palette. That seems more flexible if we want to plot other maps that also need this palette in the future but are not "diff maps".