Closed jonrkarr closed 3 years ago
My understanding is that if a repeated task references multiple models, each model is completely separate from every other model. It would be possible (I think) to set the values in one model explicitly based off of the values in a second model, but otherwise, there is no cross-talk between them at all.
I agree the text should be clarified here--I think it was written without really thinking through what would happen with multiple models being involved.
(I would definitely never implicitly set any values in one model that happened to have the same IDs as the values in a different model. That should always be explicit.)
As far as what the output looks like, this is a huge problem with SED-ML and has been for years. I basically have no idea what a CSV file of the output data would look like, other than 'do something that seems reasonable in the current situation'.
(And now it occurs to me that perhaps this is what you meant? Require that, for output purposes, all models have the same set of requested output variables? That could work, but as far as I know is a new idea for SED-ML. Better than a 'shrug, I dunno', though.)
The output can be dealt with as a multiple dimensional matrix. While CSV can't handle this, HDF5 can. This can even work with nested repeated tasks, which just adds more dimensions (at least that's my interpretation of what nesting means).
Sub-tasks could work with independent executions of multiple models. The problem is that the specifications say that the next sub-task should begin from the end state of the previous sub-task. Conceptually, this means that the end state of the simulation for the previous sub-task needs to be copied to the initial state of the simulation of the next sub-task.
It seems to me that the specifications implicitly assume that the sub-tasks will all reference one model. In that case, simulation tools may be able to implement the state transfer without explicitly copying state as I outlined.
Copying state between successive sub-tasks can work for different models, but I think the specifications should be clearer what should happen in that scenario.
I don't think model state should ever be copied from one model to another outside of a SetValue that does it explicitly. My understanding of the spec is that it's only talking about sub-tasks where the model is the same, and does not apply when the models are different.
That makes sense,
Sub-tasks are intended to start from the output of the previous task. This implicitly assumes that each sub-task references the same model, or at least that the model has the same variables. This constraint should be described in the specifications.