Last = 1000 too high

[Thomalpas]

In functioning.jl, stability.jl and utils.jl there are numerous functions that have default argument last=1000, referring to number of timesteps to calculate various metrics over.

This worked with the default length of simulation of 500 when we were saving every 0.25, but now that is no longer the case this default of 1000 means the functions will most likely error on a default length simulation, so I recommend changing it, maybe to 100? Happy to do this if we agree :)

[ismael-lajaaiti]

I'm invoking @alaindanet I think you wrote this. 👀 🪄
Another solution is to change the default to min(length(solution.t), 1000) so we ensure that we will never encounter an error if I'm not wrong.

[alaindanet]

TADA 🪄 It has changed on simulation_output_utils, it is now defaulted to 10 :)

Ref: #87

Note that the function names have changed a bit!

It would be great to not have error on last wrong specification but at the same time, a warning should be send or something because those functions are targeted for steady state analysis and if you set length(solution.t), you are definitely including non-steady state dynamics.

To go in your way @ismael-lajaaiti , setting last to the last 10% of timesteps if last < length(solution.t) with a warning could be a solution where steady state spirit is conserved and the function will not throw error anymore. What do you think?

[ismael-lajaaiti]

Yes your suggestion seems good to me 👌

Side note : I have a question regarding the meaning of doing this kind of analysis. Because, if no stochasticity is involved the steady is ... steady (assuming that your steady state is a fixed point), and thus the biomasses shouldn't change, right? Then in this case, I don't understand how you could compute something like a coefficient of variation on such simulation trajectories. Can you tell me what I'm missing? 🙏

[alaindanet]

Cool! 😄
I will try to do it today!

On your side note, it is true that CV will be meaningless for most simulations with type III functional response. But as soon as you have a type II functional response, you might end up with oscillatory dynamics which are relevant for CV and synchrony computation.

[alaindanet]

The warning is implemented and tested on the branch simulation_output_utils. There is also a quiet argument inspired by @ismael-lajaaiti ;)

This is part of the #87 pull request! Thanks @Thomalpas and @ismael-lajaaiti !

[iago-lito]

Closed by #87.