Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Priority sites criteria expecting different structure for strong_pred than what is implemented #633

Closed
Rosejoycrocker opened this issue Dec 18, 2023 · 2 comments · Fixed by #717 · May be fixed by #634
Closed

Priority sites criteria expecting different structure for strong_pred than what is implemented #633

Rosejoycrocker opened this issue Dec 18, 2023 · 2 comments · Fixed by #717 · May be fixed by #634
Assignees
Labels
bug Something isn't working

Comments

@Rosejoycrocker
Copy link
Collaborator

Rosejoycrocker commented Dec 18, 2023

strong_pred is currently a vector which at index i, gives the id of the site which is connected to site i and provides the greatest number of incoming connections to site i. Previously (in ADRIA_repo, the Matlab version), strong_pred was an nsites by 2 matrix, with the first column being site ids:

https://github.com/open-AIMS/ADRIA_repo/blob/bc29474555015b88fa0a10f7f935408f0b4f0e76/ADRIAfunctions/siteConnectivity.m#L196-L197

This structure is then used in the MCDA priority predecessors criteria to give higher value to sites which are the strongest predecessors of priority sites:

https://github.com/open-AIMS/ADRIA_repo/blob/bc29474555015b88fa0a10f7f935408f0b4f0e76/ADRIAfunctions/ADRIA_DMCDA.m#L66-L70

This structure is similarly used in the current version of ADRIA:

predprior = predec[in.(predec[:, 1], [priority_sites']), 2]

But instead of predec[:,1] being site ids, it is a copy of strong_pred, which is a vector. To fix this, predec[:,1] as used in the above, should be swapped out for the set of siteids, or just priority_sites should be used to index (assuming it is ordered and of integer type).

@Zapiano
Copy link
Collaborator

Zapiano commented Jan 8, 2024

Hi @Rosejoycrocker, there are a few things about this issue I don't understand, would you mind helping me by answering a few questions?

strong_pred is currently a vector which at index i, gives the id of the site which is connected to site i and provides the greatest number of incoming connections to site i.

About the connectivity:

  1. Does the connectivity have a direction? (in other words, does "1 is connected to 2" and "2 is connected to 1" mean different things?)
  2. Is the connectivity a non-surjective and non-injective function?

This structure is then used in the MCDA priority predecessors criteria to give higher value to sites which are the strongest predecessors of priority sites:

  1. What is a "priority predecessor"? What does "strong predecessor of priority" mean?

To fix this, predec[:,1] as used in the above, should be swapped out for the set of siteids, ...

  1. Here, siteids are the ids of the sites that are connected to each site?

@Rosejoycrocker
Copy link
Collaborator Author

Rosejoycrocker commented Jan 8, 2024

Hi @Zapiano ,

  1. Connectivity itself does have a direction, so the connectivity matrix gives the strength of connections and direction between each pair of sites in the domain. "1 is connected to 2" and "2 is connected to 1" are a bit poorly defined, but usually we would say "2 is a source for 1", so 2 is providing larvae to 1, or "2 is a sink for 1", so 2 is receiving 1's larvae.

  2. The connectivity has 4 components in ADRIA- TP_data the connectivity matrix, in_conn, in-coming connectivity, out_conn, out-going connectivity, and strong_pred. TP_data is a transition matrix, it describes how larvae transitions between each pair of sites. The in coming connectivity is in-degree centrality, so the number of in coming connections to each node (weighted by their strength), out coming is the same but for out going connections to each node (site). strong_pred is based on in_coming. For each site it lists the site id which provides the strongest incoming connection to that site. For example, strong_pred = [ 2 3 1], would mean 2 is the strongest provider for site 1, 3 is the strongest for site 2 and 1 is the strongest for site 3. strong_pred will be non-injective and non-surjective (if you define the co-domain of the mapping as the set of site ids), because the same site can be the strongest connection for multiple sites and some sites may not be the strongest connection for anything.

  3. "priority predecessor" is confusing so sorry about this, I've been talking with Ken about finding a better name. I think "strongest source sites to sites of priority" probably makes more sense but it's a mouthful. Priority predecessors are sites which are the strongest source sites to sites that should be prioritised when applying interventions. These could be important for tourism, research, historical refugia or something else.

  4. Siteids here are just the set of ordered ids. This is because the bug was that strong_pred was added to where the site ids should have been in predec, which made the calculation of predec meaningless.

We can chat about this if that's easier :)

@ConnectedSystems ConnectedSystems linked a pull request Mar 15, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
3 participants