Vignette: Introduction to gadget3 & key concepts

[lentinj]

• A combination of these, but ditching what is now low-level minutiae: . https://gadget-framework.github.io/gadget-course/getting-started-with-the-gadget-framework.html . https://gadget-framework.github.io/gadget3/articles/model_structure.html

[lentinj]

@bthe The single-stock vignette is starting to appear here: https://github.com/gadget-framework/gadget3/blob/wip-vignette-writing/vignettes/introduction-single-stock.Rmd

We had a conversation at some point about when to introduce spawning (versus recruitment), and I can't remember what the conclusion was. Any thoughts?

[bthe]

We had a conversation at some point about when to introduce spawning (versus recruitment), and I can't remember what the conclusion was. Any thoughts?

Yes, I had been thinking of something on lines of a simple imm/mat model with a beverton-holt or ricker spawning function instead of defining stepwise recruitment as we typically have. We had something like this described here: https://gadget-framework.github.io/gadget-course/defining-stock-interations.html#spawning

It would also be good to show how to set up time varying parameters for the spawning functions as a prelude to adding random effects. Defining custom (spawn) functions would also be good to have somewhere.

[lentinj]

I was wondering if spawning should replace (stepwise) recruitment in one of the full examples, or whether it should be an example of customising a model further. Another full example for just spawning seems excessive to me.

How about we have vignettes of:

• A full Single stock model, with recruitment
• A full Imm/mat model, with recuitment
• A full imm/mat model, with spawning & a random walk (i.e. we introduce spawning & random effects together)

Defining custom (spawn) functions would also be good to have somewhere.

I think that would be a good example for the "Customising gadget3" vignette, do you have something concrete in mind?

[bthe]

Yes, that sounds like a good plan. Are you going to base all the interaction with the model on g3_fit ?

I think that would be a good example for the "Customising gadget3" vignette, do you have something concrete in mind?

I think the SS3 stock recruitment function would be a good start, also the stuff missing from the list of spawn functions here: https://github.com/fishfollower/SAM/blob/master/stockassessment/inst/include/SAM/recruitment.hpp

[lentinj]

Are you going to base all the interaction with the model on g3_fit ?

As we've discussed in another thread somewhere, I'm presuming that g3_fit will eventually vanish. gadgetplots will work directly with the model output, and a summary S3 method on the model output does the human-readable bit. So I'm writing stuff to make that easy, and only showing g3_fit bolted straight to gadgetplots.

g3_iterative OTOH, is pretty fundamental at this stage. I'm currently assuming all optimisation is done through this going forwards.

My worries about including references to gadgetutils:: and gadgetplots:: in the vignettes seem to be relatively unfounded. I'm currently setting eval=nzchar(Sys.getenv('G3_TEST_TMB')) on those blocks anyway, so we don't run a model optimisation each time we regenerate the vignette, but it's easy enough to do so for testing. --as-cran isn't bothered by the references to non-CRAN packages in these blocks.

We could store some canned output to put in it's place, but the output of the optimisation isn't that interesting, and linking to an example HTML output from gadgetplots is probably more interesting for the model output.

[bthe]

Ok, the reason why I was asking is that it would be good to be able to add plots into the vignettes to illustrate the effects of different parameter values in e.g. the spawn functions.

g3_iterative OTOH, is pretty fundamental at this stage. I'm currently assuming all optimisation is done through this going forwards.

At least in the near term, yes.

[lentinj]

I think curve(g3_eval(...)) (or similar) would be enough for making such plots, running a full model seems excessive. But it's a good plan.

EDIT: On second thoughts, I'm guessing you're more referring to something like the end of https://gadget-framework.github.io/gadget-course/getting-started-with-the-gadget-framework.html#recruitment - which would be better done with an actual model. But certainly for things like the selectivity functions the above is true.

[bthe]

Yes, exactly. So I think it would be good to bypass g3_fit to do the plotting, and work directly with the report arrays so this can be achieved quickly.