gadget-framework / gadget3

TMB-based gadget implemtation
GNU General Public License v2.0
8 stars 6 forks source link

Predation selectivity reporting #152

Closed lentinj closed 1 month ago

lentinj commented 2 months ago

As part of #29 I'm rethinking how reporting is done for predation. __predby_ is the main array used, but also reported is suitability.

There's support for munging the suitability array in g3.fit, but it got commented out: https://github.com/gadget-framework/gadget3/commit/4d3169b919413a956fc9009cfa7cf4b0f510cb57 - @willbutler42 was it not working, or generally not useful?

For ~all models (with length-based selectivity), logging every computed selectivity value is hugely wasteful, especially for predation. We could just g3_eval() the selectivity function directly in ~all cases. But we don't have any means to attach functions to model output, at least not yet.

We could compute selectivity once for the report, producing only the dimensions that actually have relevance to the selectivity function. This would mean any gadgetplots functions would need to handle e.g. a pred_age dimension appearing, but I'm guessing that's largely a matter of working ggplots.

Any other thoughts?

lentinj commented 2 months ago

I've locally bodged around a bug by having a (predator)_(prey)__suit variable, which is essentially the content of Fp(l,L) / 4.21, and simpler for the other predation functions.

It's a bit wasteful, but does make code a lot cleaner. Would the value be useful in reporting? It's not suitability, since it's already based on available biomass, but reveals a bit more about how the predation is working.

lentinj commented 1 month ago

@vbartolino do you have any opinion on this, i.e. is Fp(l,L) / 4.21 an interesting value from your point of view? If it is, then I'll keep storing it. If not, then I should probably rewrite the code a bit to save memory.

vbartolino commented 1 month ago

I do not think it will be particularly useful to store Fp(l, L). Moreover, the parameters defining the suitability Sp(l, L)in 4.21 as well as the prey variables N_l and W_l will be at hand so if someone is interested can always compute it from the existing reports, correct? Contrarily, reporting Cp(l,L)will be essential

lentinj commented 1 month ago

if someone is interested can always compute it from the existing reports, correct?

You could, but it'd be a bit fiddly as you'd have to know how several things are defined to do so.

Contrarily, reporting Cp(l,L)will be essential

Yup, that's in the bag, and what I've referred to in various places as (pred)_(prey)__cons. For the most part this is done, but still some tests to tidy up before I can commit it.

willbutler42 commented 1 month ago

As part of #29 I'm rethinking how reporting is done for predation. __predby_ is the main array used, but also reported is suitability.

There's support for munging the suitability array in g3.fit, but it got commented out: 4d3169b - @willbutler42 was it not working, or generally not useful?

For ~all models (with length-based selectivity), logging every computed selectivity value is hugely wasteful, especially for predation. We could just g3_eval() the selectivity function directly in ~all cases. But we don't have any means to attach functions to model output, at least not yet.

We could compute selectivity once for the report, producing only the dimensions that actually have relevance to the selectivity function. This would mean any gadgetplots functions would need to handle e.g. a pred_age dimension appearing, but I'm guessing that's largely a matter of working ggplots.

Any other thoughts?

If I remember correctly, this was commented out because the age dimension was not required (its noted, that this may change shortly).

We have talked about how best to present selection patterns and I do like the potential g3_eval() approach but at the moment this is only really possible with some guesswork, e.g., (see https://github.com/gadget-framework/gadgetplots/blob/master/R/plot_suitability.R#L37).

Your second suggestion sounds good and would capture the most useful information, e.g., not reporting across time if the parameters are fixed in time. Regarding the plotting end, it would just be a case of writing an access function that can check for plausible combinations of length/age/time/area/other dimensions

lentinj commented 1 month ago

I've made g3a_suitability_report() in the above, currently it's a standalone action that, fed with predator/prey & suitability function, will add a report with dimensions as required prey length, predator length, age, etc. It can't do time-based suitability, that would need a slightly different approach.

Either g3a_suitability_report() could be added to models yourself, or it could be done automatically by a g3a_predate(..., report_suitability = TRUE) option. The latter seems easier to me, any preferences?

vbartolino commented 1 month ago

Either g3a_suitability_report() could be added to models yourself, or it could be done automatically by a g3a_predate(..., report_suitability = TRUE) option. The latter seems easier to me, any preferences?

I agree, a logic argument TRUE/FALSE seems cleaner

lentinj commented 1 month ago

Right, I think this is all done, and now merged into rewritten-predation. Basically, any model will now have suit_prey_a_pred_a__report reports by default.