numagic/lumos

automatically collect outputs from submodels into top level model

yunlongxu-numagic opened this issue · 4 comments

yunlongxu-numagic commented

at the moment, if we add an output to a submode, in order to have it accessible from its parent models or other ancestor models, we need to:

  1. add the output to the ancestor's outputs as well
  2. call get_output to retrieve the value
  3. call make_vector with the additional output to assemble the outputs vector

It would be nice if all of these happen automatically, so that when we try to add an output temperature to a submodel model.submodel1.submodel2, then it would automatically:

  1. add submodel2.tempreature to the output of model.submodel1
  2. add submodel1.submodel2.tempreature to the output of model
yunlongxu-numagic commented

I can already see an issue on model output collection when creating the outputs vector in the parent model -> this will require the assembly of all outputs from the children model, but it is possible that one could have children model that are NOT executed by the parent model (it's probably not nice to have that, but the code cannot check this until runtime)

yunlongxu-numagic commented

another design implication: imagine the vehicle shares a tire model between all four tires. So the model tree has only one child node called 'tire', then how do we store all tire outputs from all four tires? To avoid this problem, one should create 4 tire nodes instead of one tire node.

This probably makes sense for the tires, as quite likely they'll need different instances for different parameters, but will this cause us problems else where? (eg, when want to optimizing parameters where the parameters are tied between subsystems, when we really have identical subsystem installed on the vehicle)

yunlongxu-numagic commented

we also need to take care of how/when the model size is determined. eg: at the moment, the model I/O size is fixed by class definition, and can be retrieved with class methods here, but now model I/O size is dynamic and can only be defined after model instantiation.

The only place where we need it to be a class method now is probably here, where we creating the model I/O somewhat dynamically based on children models --> this is something we should probably be able to get rid of. So maybe this shouldn't be a problem

yunlongxu-numagic commented

closing this for now, but we will look back at it for model I/O reformulation