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

The Great Convergence #69

Open
patricoferris opened this issue Oct 21, 2023 · 1 comment
Open

The Great Convergence #69

patricoferris opened this issue Oct 21, 2023 · 1 comment

Comments

@patricoferris
Copy link
Contributor

This is a meta issue for bringing in all of the disparate changes we've applied whilst iterating quickly and which we're all carrying in our heads.

Find Pairs

In #66 @robinmessage merged @sadiqj's work which was the right thing to do to make progress in other areas. Unfortunately, I don't think that branch was quite ready. In particular, we need to actually find all potential matches and then shuffle them and choose 100. In particular we will need the changes in #68 (once they're tidied up).

CPC and finding potential matches

The find potential matches has both changed a little methodologically and has been optimised. In #61 @robinmessage has a faster version of the original algorithm which is really useful (this allowed much of the rapid testing and debugging). However, the CPC calculation has also changed to use the new fine circular approach (extra commits in #65). We have a decision to make on this.

Option 1: Follow Tom's Code

Tom has used a mixture of square CPC and fine circular CPC whilst producing the additionality numbers. The square CPC is used for the initial building of what we call M then during the find pair we switch to FCC for the actual pairs. This is more of a computational limitation rather than an ecological reason as far as I can tell.

Option 2: FCC everywhere

Since Robin's code in #65 has to be run anyway and generates FCC for all of the JRC tiles, there's really no reason we couldn't also use this in M as well I think.

1000m buffer

In Tom's method there's a step to use a 1000m buffer around the project whenever we want to generate a K from which we wish to generate M. It would seem that this was tied to Option 1 above. So if we go down the Option 2 route perhaps we don't need this, if we do then #67 is needed. Note this is not in the written methodology.

Pool Cov.

@robinmessage's PR #63 aligns our find pairs with whatever R's matchit library does. We should properly write in the methodology what we decide to do rather than relying on the external "Whatever R's matchit library does".

@patricoferris
Copy link
Contributor Author

Most of the results I've been generating have relied on the pf341-fpp-fcc branch which is Robin's branch + reverting some of the WIP potential matches commits and adding the changes to make FCC work in build_m and calculate_k.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant