Closed Peter9192 closed 1 month ago
Related to this, it would be nice if the UI could reflect the status of the ongoing run, e.g. with a progress bar.
If user triggers a model run we should cancel already running models.
If user triggers a model run we should cancel already running models.
Or should we disable the UI for triggering runs until the current run is completed/explicitly cancelled?
Also, this implies that multiple (different) experiments can't run simultaneously. Why is that?
If user triggers a model run we should cancel already running models.
Or should we disable the UI for triggering runs until the current run is completed/explicitly cancelled?
Also, this implies that multiple (different) experiments can't run simultaneously. Why is that?
Disabling is also possible. I was imagining very quickly changing settings causing multiple model runs.
I was imagining very quickly changing settings causing multiple model runs.
I can imagine that we would create some "quick settings" that would allow this. In that case, the requirement should be refined to
"If user triggers a model run we should cancel already running models for that experiment"
Perhaps "re-evaluate" is a useful term for such an event.
Currently, CLASS runs in the main thread, which is still OK since we have a very minimal setup. But eventually we might do heavier simulations, and then it would be great if CLASS could run "in the background".
We could use web workers, but we need to figure out how to set this up in such a way that it's easy to communicate with the model. Ideally, if the model has a BMI-like interface, we would like to be able to control it from the main thread (e.g.
model.update()
).