johngallo
commented
5 years ago Clarification: doing this fix is better than leaving as is, but I am not positive how big of a problem it really is. No time at the moment to check. A first step could be to determine how big of a problem this is, and if it should be addressed before the advertised release of v 3.0b2 on the website. Based on my memory of the curves, having preferred climate as 1 should still yield the same rank order of cores as if the preferred climate were the coolest core. This is probably ok if giving climate preference a weight of 1 and climate analog factor a weight of 0, but more nuanced weights being used are probably resulting in But it is the values, and relative values that are off I believe.
Right now, we have a problem that I overlooked before. We claim that the user can just put in the current climate layer and not click the advanced parameters and they will get a decent climate analysis. But, we have the default value for the "Preferred Climate Signature Value for a Core" = 1 . If the climate input layer is the recommended Climatic Water Difference layer, then a value of 1 is a very wet/cool place. Most places in the Continental US have a CWD of 200 to 1000. Then again, people may use a difference climate input that has a range of 0-1, and then the default climate preference would be the hottest core in the region!
Here is the proposed solution. In the code we query the table to find out what the signature value is of the coolest/wettest core in the region (at the current time). (i.e. the lowest value). (this is field cclim_env from the cores table)
Then we use this value for the rest of the model UNLESS the user provides a different value.
Then we change the parameter to be called
"Preferred Climate Signature Value for a Core (leave blank for min)"
and change the help message from
"At future time T, what is the preferred climate value of a core area? An initial approach to determining this value would be to look at a map of climate signature at the current time, and to look at the climate signature values of the places that currently have a preferred climate for the species and/or ecological processes that are being targeted. In other words, just because a linkage has a great climate analog match, does not mean it is a perfect climate-wise linkage. If it is matching a relatively hot/dry core to a core that is also relatively hot/dry in the future, it is not as good as if it were matching a cool/wet core to a core that is cool/wet in the future."
TO
"At future time T, what is the preferred climate value of a core area? Unless the user specifies differently, the model will assume the answer to this question is the climate value of the core that is currently the most cool/wet of all the cores.
But the user can override this p by supplying a value. An initial approach to determining this value would be to look at a map of climate signature at the current time, and to look at the climate signature values of the places that currently have a preferred climate for the species and/or ecological processes that are being targeted. And use these areas to determine the preferred climate. (In other words, just because a linkage has a great climate analog match, does not mean it is a perfect climate-wise linkage. If it is matching a relatively hot/dry core to a core that is also relatively hot/dry in the future, it is not as good as if it were matching a cool/wet core to a core that is cool/wet in the future.)
The user can also map the Climate Signature Values of each core by turning labels on and using the cclim_env from the cores table after a test model run has been completed. (fclim_env is the future climate envelope, and is only present if a future climate input layer is used.)"