Should default values be stored in species_params?

[gustavdelius]

Currently many of the automatically calculated defaults for parameters like h, gamma, ks, etc. are then stored in columns of the species_params slot. This has the disadvantage that they are then not recalculated when other parameters are changed that formed the basis of the default values.

I propose that we should not store the default values but recalculate them when needed. The species_params() function should get an extra argument include_defaults which when set to true returns the calculated defaults.

The above applies only to those species parameters that are used to fill other slots in the MizerParams object, i.e., those that are used by setParams(). There are some species parameters that are used directly:

• alpha
• interaction_resource
• erepro and R_max

For these we need to put defaults into the species_params slot if they were not provided by the user.

[gustavdelius]

Actually, things are a lot more subtle. It is probably helpful to consider a concrete example. So let's look at the calculation of the default for gamma. This is calculated by get_gamma_default() "so that if the prey abundance was described by the power law $\kappa w^{-\lambda}$ then the encounter rate would lead to the feeding level $f_0$", where $f_0$ is taken from the f0 column of the species_data frame or is set to f0=0.6 if not supplied. So under which circumstances should this gamma be recomputed? Potential answers are:

1. Never. The default is only determined once and then the value only changes if the user explicitly changes the gamma column.
2. When the user changes f0. Given that the user changes f0, they probably want to see some consequence of that change.
3. When any of the parameters change that go into the calculation of the default. There are quite a few of them: f0, h, lambda, kappa, beta, sigma.
4. When the encounter rate changes, and it makes no difference whether that is because the parameters change or whether it is because the prey abundance changes. The problem with this is that the concept of f0 does not really apply unless the encounter rate is a perfect power law.

It seems that any of the options has the potential to lead to confusion. I am currently leaning towards keeping option 1 but alerting the user when they change a parameter that they might think will have a knock-on effect that it will not. So a warning should be issued if the user changes:

• [ ] f0: warn that this has no effect unless they clear gamma first
• [ ] fc: warn that his has no effect on the metabolic rate unless they clear ks first.
• [ ] k_vb and t0, a and b: warn that this will not change h and thus will not change the model growth curves
• [ ] beta and gamma or the predation kernel in general: warn that this will not only change where the predator feeds, but will also affect the rate at which they feed. Perhaps suggest what change to gamma should be made to counteract the change in the predation kernel?
• [ ] When changing an allometric exponent lambda, n, p or q, warn that this pivots the power laws around w = 1 gram and should almost certainly be accompanied by a change in the coefficient of the power law.

These warnings should be issued by species_params<-().

[gustavdelius]

As @astaaudzi just pointed out, we should also issue a warning when users try to change the gear parameters by changing corresponding columns in the species_params, like catchability for example.

[gustavdelius]

I just noticed that in commit 3add1ce I stopped the storing of w_mat25 in species_params because I felt it was to annoying for the user to have to change w_mat25 by hand when they change w_mat given that most users are happy with the default relation between w_mat and w_mat25. I now realise that this change is inconsistent with the above proposal that all calculated defaults should be stored in species_params.

[gustavdelius]

One way to resolve this would be to keep the species parameters that the user has set separate from those that mizer has calculated defaults for. So introduce a fixed_species_params data frame that holds all the species parameter values that have been explicitly supplied. Each time that is changed with species_params<-, all values in fixed_species_params are copied over to species_params and everything else is recalculated.

We would still want to warn users if they change a species parameter that would normally lead to a recalculation of a default but does not because they have already specified a value explicitly.

As far as the user is concerned, this solution will appear no different from the solution where no default values are stored but are recalculated whenever they are used. It might however be easier to implement because the mizer code can still assume that all necessary parameters are contained in species_params.

[astaaudzi]

Hi @gustavdelius - have you made any changes on this? I agree that it would be important for mizer to store all parameters, including default, but have no opinion on how to do it best, as long as there is as little change for the user as possible. Your proposed solution of having a set of fixed params supplied by the user and those that are calculated automatically would be good I think as the user also would be perhaps be made more aware as to which parameters are calculated by mizer (mizer already warns about that, which is good)

[gustavdelius]

It seems I forgot to update this issue. This has been implemented in mizer 2.5.0, see https://sizespectrum.org/mizer/news/index.html#given-versus-calculated-species-parameters-2-5-0 and https://sizespectrum.org/mizer/reference/species_params.html