Infrastructure for mizer extensions about mizer HOT 3 CLOSED

Great! Looking forward to it and it will provide a great framework to extend and adapt mizer to various needs. Will need to provide some examples on how to prepare an extension into a package :)

from mizer.

@astaaudzi , the first example I will provide is an extension implementing unstructured resources, i.e., I will take the code implementing those out of mizer again and put them into a separate package.

One bit of my proposal I already want to discuss with you now: I propose to supplement the @n and @n_pp slots by an @vars slot that shall be a list holding all the new dynamical variables that extensions may want to add to mizer.

Of course it would be most natural to also include n_pp in that list, so that the plankton resource would not play a special role compared to the other resource spectra that other extensions may want to introduce. And it would be even more elegant if also n was a member of that list. However then everyone would need to update their old scripts that may have accessed the @n slot directly to accessing @vars$n instead. Am I right that backwards compatibility is more important to us than elegance? Are we therefore happy to have slots @n, @n_pp and @vars?

from mizer.

Just an update: In pull request #141 I have added

• a slot @n_other to hold the list of abundances of other dynamic ecosystem components,
• a slot @other_dynamics to hold the list of functions to be called in side the project() loop to update the abundances of the other components,
• a slot @other_params to hold the list of parameters for the other components,
• a slot @other_encounter to hold the list of functions that calculate the contributions by the other components to the encounter rate,
• a slot @other_pred_mort to hold the list of functions to calculate the contribution by the other components to the predation mortality rate. That will not be relevant for resources, but for example for unstructured consumers (mammals, sea birds).
• a slot @rates_func to hold the function that calculates the rates needed by project().

The first 4 slots have allowed me to move my code for unstructured resource components into its own R package, see https://gustavdelius.github.io/mizerUR/. These slots will also allow @astaaudzi to put her code for multiple size-structured resources into an R package.

The slot @rates_func will be needed by @reumj for his size-dependent interaction matrix and by @pwoodworth-jefcoats and others for time-dependent temperature.

Over the weekend I intend to write a vignette explaining the current extension mechanism with examples.

from mizer.