Closed gustavdelius closed 3 years ago
Of course preserving R_max
may not always be possible. For example in the tuneParams()
app the user might increase the abundance of a species to a value that requires a higher reproduction rate than that set by R_max
. In that case I believe the user should be issued with a warning and the R_max
should be increased to just a tiny bit above the minimum required value.
I have now implemented this in mizerExperimental, ready for testing.
Originally I had envisaged the tuning process as a two-step process:
Therefore the functions that are designed to support step 1, like
steady()
andtuneParams()
, used to switch off density dependence in reproduction for simplicity, given that it would need to be changed in step 2 anyway.@Kenhasteandersen and @juliablanchard have now argued that it would be nice to set
R_max
already during step 1 of the process and to have it preserved by the tuning tools. While I don't understand the benefit of settingR_max
already during step 1, I can see the benefit of having reproduction parameters preserved by the step 1 tools just in case someone has a need to re-visit step 1 after having already done some work on step 2.So I propose a
preserve
argument tosteady()
andtuneParams()
which can be set to "R_max" if the originalR_max
should be reinstated at the end of the functions. I prefer thepreserve = "R_max"
syntax topreserve_R_max = TRUE
because it could possibly be extended in the future to allow requests for preservation of other parameters during the tuning.