You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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".
The text was updated successfully, but these errors were encountered:
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.
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".
The text was updated successfully, but these errors were encountered: