Closed johngallo closed 3 years ago
johngallo
commented
5 years ago google doc: https://docs.google.com/document/d/1vvtPOsnYWa4q9mo_he1bIC8oIckVn--EM_LBFNOepPw/edit#heading=h.mgcwtft6qv7f
talk about the overall feature: https://figshare.com/articles/Video_Software_for_prioritizing_habitat_linkages_based_on_climate_gradients_climate_analogs_or_a_balanced_blend_/9161864
johngallo
commented
5 years ago This is a REPOST of the original comment at the top of this thread, with edits and changes marked with a ** to help developers that have already read the original comment.
Currently, the climate Analog Linkage priority value curve is set by several user defined parameter values, as well as by R min and R max, which are set based on the input data, . For situations where there are a few cores, or where only going a sort distance into the future, it is possible, and likely, that Rmax is just a bit over 1. (see the modoc sample data for this Issue's genesis. 5 cores. 50 years into the future, The Rmax is 1.04)
So, the problem is that having the default Y axis value of 0 (relative priority) of Rmax is problematic in these cases, as it penalizes linkages that are just barely hotter than the perfect climate analog. The power user can notice this,and set the y axis value in this situation for something high, like 0.75. Hence, for the default value of 0, every landscape will have a different shaped curve.
**Note for designers: The following was not considered when making the original algorithm, and is part of the problem. in landscapes with mountains that we have looked at, the range in climate signatrures is about 300, 400, or 500 CWD units, and the relative differnce beween current climate and future climate of a core is about 50 or so. With a CWD of about 600. Hence, it appears in this situation that the larges rMAx that could be possible is 650/600, or about 1.08. But rMin can be 300/600 quite easily, (i.e. 0.5).
That is the current situation. And should be fine tuned. There are a few options for this. As of Aug 4th, I am thinking that Option 1b or Option 2 are both acceptable, and that it is probably best given our timeline and budget to do the one that is easiest.**
**Option 1:( Compared to the way we have been doing it for the last 8 months), to instead have the standard process be to define the shape of the curve on the right side of graph based on a user defined value for the X coordinate. So, instead of the right hand most point being defined as X= Rmax (the maximum ratio existing on the landscape), and y = user defined value, you would instead also define the X value of the right hand most point. Or to simplify things, you could make the y value for this point 0 automatically. The same could be done with Rmin, although that side of the curve is less of a problem, even with small data sets. So, option 1a is to do just the above, 1b is to do it for the left side of the curve too..
(i) Optional fine tuning addition to Option 1: give a Warning Message for edge cases: At a later date, we can make this into an issue: Base this on the idea in the original post, but update it with the current terminology.
(ii) Option fine tuning Part II. was sketched out in the original post of this thread, and can be described more fully into an issue and programmed in at a later date.
(iii) Option 1, PART III, was sketched out in the original post of this thread, and can be described more fully into an issue and programmed in at a later date.
OPTION 2:
Use the current code, but, 1) keep the default Y axis value for this right hand most point (currently 0), but move the ability to change this paramater to LP_settings.py . This essentially hardcodes it except for power users. 2) Add a new parameter: a user-defined minimum allowable value for the X coordinate of the furthest right point on the curve. Make the default value = 1.15, and we can refine that later after sensitivity testing. the model then compares this with Rmax. It Rmax is lower, thenit uses this value. Hence, in the case of the Modoc sample data, the algorithm would use this value rather than Rmax (which is 1.04 in this case).
johngallo
commented
5 years ago OK, Nat Mills thinks that Option 2 is easier than 1b, and will take a stab at this.
johngallo
commented
5 years ago A sketch on a path foward 1) Add some code: Add a new parameter (probably near the beginning of the script): the minimum allowable value for the X coordinate of the furthest right point on the curve. (you or I will need to name it, both in the code and also in the graphical user interface. we can change the name later if we want.) For now, you can hard code the value to be 1.15. Draft name in ArcGIS tool GUI: "Minimum allowable X-Axis value for the furthest right point on the value function curve." 2) Find where Rmax is defined, and where it is used. Right after the former, OR before the latter, add some code that looks to see if rMax or this new value is higher, and then use the higher of the two values for in the current code (for the X value of the furthest right point on the curve.) 3) Once that is working, make the new parameter a user defined variable in the script, then add it to the script tool graphical user interface, and populate the default value to be 1.15 5) remove the hardcoding of 1.15 from the script
johngallo
commented
5 years ago Some breadcrumbs for making a new parameter of step 3, above: 1) Add the new parameter name to "def config_lp" in lm_config.py (currently line 278)
2) call that parameter from lp_main.py in a similar manner as the others (e.g. lm_env.CANALOG_MIN ) 3) Add the parameter to the ArcGis Script tool (right click the tool-> Properties-> Parameters; scroll to bottom, add the parameter and fill in the properties. Make the default value = 1.15 4) do step 4 above (remove the hardcoding) 5) test and if it works, make the commit! (this won't be perfect, as this new parameter will be at the bottom of the GUI, but it should work better than now.)
johngallo
commented
5 years ago Draft for GUI:
Draft parameter name: Lowest allowable Maximum Climate Analog Ratio on the "Value Curve"
Draft Help: "Problem that this Parameter Addresses: For situations where there are a few cores, or where only looking a short distance into the future, it is possible, and likely, that the Maximum Climate Analog Ratio (R) for two cores on a landscape (Rmax) is just a bit over 1. [R is CDT/ CS0, (i.e. is the climate value of the destination core (D) at the future time step, T, divided by the climate value of the starting (hotter) core at the present time, T= 0.)]
This is a problem if Rmax is the only value being used to define the right hand most part of the Climate Analog Value Curve (i.e. the graph that correlates different values of R with different linkag epriority values). If the target climate analog value is 1 (the default), then this makes an extremely steep curve on the right side of the Value Curve. And in this case, a destination core that is just a bit hotter in the future compared to the current climate of the starting core, will be penalized more than common sense dictates.
Parameter Description: This parameter fixes the problem. With this parameter, the user defines the x axis value that is the minimum allowable value associated with the right hand most part of the graph (i.e. Lowest allowable Maximum Climate Analog Ratio on the "Value Curve"). If this user defined value is greater than the Rmax of the particular landscape, then this user defined value is the one that the model uses as the maximum Climate Analog Ratio of the Value Curve. The default value of 1.15 is a good balance of opposing factors for fixing the problem. For many landscapes Rmax is greater than 1.15, so with the default value used, this parameter would then be ignored by the model."
dkav
commented
3 years ago Fixed with 386bca95e71591babc3debb5d639990cf90d6551.
NOTE: this comment is outdated, see the one two comments down on Aug 4th
Currently, the climate Analog Linkage priority value curve is set by several user defined parameter values, as well as by R min and R max, which are set based on the input data, . For situations where there are a few cores, or where only going a sort distance into the future, it is possible, and likely, that Rmax is just a bit over 1. (see the modoc sample data for this Issue's genesis. 5 cores. 50 years into the future, The Rmax is 1.04)
So, the problem is that having the default Y axis value of 0 (relative priority) of Rmax is problematic in these cases, as it penalizes linkages that are just barely hotter than the perfect climate analog. The power user can notice this,and set the y axis value in this situation for something high, like 0.75. Hence, for the default value of 0, every landscape will have a different shaped curve.
That is the current situation.
However, it is probably best to instead have the standard process be to define the shape of the curve based on ALL user defined paramaters. Then, instead of Rmax be defined a the maximum ratio existing on the landscape, you would define it as being the maximum ratio that has a value greater than 0. (i.e. the x-intercept, y = 0). This would also simplify the GUI and user guide, reducing the need for a parameter defining the y value of Rmax, hardcoding it as 0. The same could be done with Rmin.
Warning Message: In this setting, give the user a warning message if their data has an R that is lower than the R min or R max set by the user, and say those R will receive a value of 0 for Analog priority value. (And that if/then exception would need to be programmed in). This may be just fine with the user, but they should be aware of it.
PART II, Advanced: But in edge cases the user might want Rmax to be with a y value of say 0.25, and all R values over this have a Y value of 0. This can be described more fully and programmed in at a later date.
Unresolved thoughts: I am not sure if we give a power user the ability (in the lp_settings.py file) to instead have R min and R max set by the input data, as is currently the case. Rule of thumb could be that with just a few cores on a landscape define the curve manually, but if greater than 100, then doing so automatically is safer... If we do this, then we should also keep the ability to define where on the Y axis R min would be for sure, and possibly even keep this for Rmax too.