Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better manage time-steps for simulations over MTG #50

Closed
VEZY opened this issue Aug 18, 2023 · 2 comments
Closed

Better manage time-steps for simulations over MTG #50

VEZY opened this issue Aug 18, 2023 · 2 comments

Comments

@VEZY
Copy link
Member

VEZY commented Aug 18, 2023

At the moment we make a TimeStepTable (or whatever Table) with every time-step for each organ that has a ModelList. This is fine when we have few organs and variables, but the number of values can grow very rapidly with e.g. an FSPM that predicts growth and yield ( e.g. > 20 variables per organ x # time-steps x number of organs).

This occupies a lot of un-necessary memory because many variables are not needed for output (so no need to keep every values of each time-step), and makes the computation slow for two cases:

  • as the plant grows, new organs are emitted, and each time the complete TimeStepTable is copied
  • when models need values from other models, we get the whole TimeStepTable, so we need to index again to get the right time-step. This is not ideal.

A solution would be to replace the TimeStepTable by another struct called e.g. SparseTimeStepTable, that would have a single Status with vector of values for some variables, but that would appear as a single value because we would keep track of the current time-step, and the value of the dynamic variables would always seem like a single value because we would index the vector by the time-step.

@VEZY
Copy link
Member Author

VEZY commented Aug 18, 2023

Or maybe use Observables ? There are several packages, more or less efficient (see e.g. Rocket.jl I think?). And each time the value is updated, push to a (pre-allocated) vector of values ? Test both and choose the most efficient. The good thing with this one is that it is easy to put the vectors somewhere accessible for the user to get after the simulation.

@VEZY
Copy link
Member Author

VEZY commented Nov 23, 2023

This is fixed in #51 by using only one status per node, that is eventually updated each time-step, and the value for some variables are saved dynamically if required by the user. So only some variables grow dynamically now, not all.

@VEZY VEZY closed this as completed Nov 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant