Hi Eshetu,
First, let me try to provide some more details about the relationship between the Average Runoff Proxy (ARP) parameter and the Runoff Proxy Index (RPI) raster. Each value in the RPI raster is the result of dividing the corresponding value in the Runoff Proxy (RP) raster by the ARP value. (In other words, the RPI values are the result of normalizing the RP values, using the ARP value as the normalization factor.) Since you did not specify an ARP value, the model calculated the mean of all the pixel values in the RP raster you provided. Then, to create the RPI raster, it divided each pixel value in the RP raster by that calculated mean. The resulting range in the RPI raster, 0.6 to 2.6, indicates that the RP values range from 60% of the mean to 260% of the mean.
If you check the logfile, you will see the following message:
INFO Normalizing raster (D:\cadiz postdoc work\NDR Invest\GIS_Project\Watershed and river\NDR_output\1990 NDR_application-rate_load_type\intermediate_outputs\masked_runoff_proxy_1990_apprate.tif) using auto-calculated mean: 423.15673828125
which indicates the mean of the values in the RP raster you provided to the model is 423.15673828125. (You should compare this to your RP raster, just to be sure). If you were to run the model again, specifying that same value for the ARP parameter (and otherwise using the same inputs as before), you should get the same results.
Assuming the RP raster you provided to the model is based on precipitation data, then yes, in a sense, it is possible to calculate ARP from precipitation data—in the default case, as I’ve just explained, the model calculates the mean of all the values in the RP raster. The reason there is no generally recommended range or upper limit to ARP is that a meaningful ARP value is context-dependent: it will (and should) vary depending on the specific geography and the collection of RP values.
Now, when it comes to specifying an ARP value (instead of letting the model auto-calculate it based on the RP raster), there are at least two reasons why you might do this. One possibility is, if your RP values fall in a skewed (non-normal) distribution, you can tune the ARP parameter to correct for this. Another is, as you mentioned, using a fixed ARP across scenarios may help you compare scenarios. However, you should keep in mind that this approach is useful only if the RP input differs between scenarios (you can imagine that if both the RP input and the ARP remain constant across scenarios, the resulting RPI will also remain constant).
Finally, here is an example of how you might control the ARP value to compare scenarios, as described by one of my colleagues. Of course, this probably won’t exactly describe your goals, but I hope it can guide you and provide some useful insights!
For example, consider that a user wants to compare climate scenarios and is using precipitation as the RP raster input, and has precip data for two time periods - historical and 2050. The user could take the mean of all pixel values in the historical RP raster and provide this as the ARP input parameter in BOTH the historical and the 2050 scenarios. This way, if the precipitation in 2050 is expected to increase, for example, then the historical RPI values might range from 0.6-2.6 while the 2050 RPI values might range from 0.9-3.2. The same could be done using quickflow index rather than precip.
However, I am not 100% sure that the model would produce very different results for these 2 scenarios, unless there is some difference in the spatial distribution of rainfall in the 2050 scenario. If in fact rainfall (or quickflow) increases at the same rate across all pixels in the study area, then the model might be insensitive to these changes in rainfall. It would be worth testing this by keeping the LULC input constant between the scenarios to isolate the impact of RPI.