Component modeling

[quesnel]

When node-editor contains more than 20 models, the modeling task become complicated especially when several parts are the same. Using groups (Ctrl+G) can help but is not sufficient. We propose to introduce components. Components are a level above the DEVS models. They are like DEVS coupled models and can group DEVS models and irritator components. A component has no impact on the simulation. It only exists for the modeling part. A component can appear several times in the list of models. In all cases they will instantiate the same models during the simulation.

A component stores:

• list of models
• public input ports
• public output ports
• public parameters
• public observations

For a first try, I propose to introduce component into the useless none model.
It will pay attention to the models created recursively in case a component instantiates itself directly or indirectly.

[ovese]

So, does this mean if a model for a dynamic system contains more than 20 atomic models like sums, constant, integrators, multpliers...is it a wrong approach?

[quesnel]

No. There is no limit in irritator (max is irt::simulation::models::capacity()). I just wanted to say that developing a model is complicated when there are a lot of nodes.

[duboz]

Yes, the idea is to benefit from the DEVS closure under coupling property at the modelling level. I.e. components can be viewed as atomic models. It facilitates the design of complex models.

[ynedelec3]

It's a good idea, I hope I understand correctly the concept, considering I worked on other complex model schemes.

Maybe could these components be associated also (if not too hard to code) with public metadata distinct for each instance (e.g. comments, quality or trust index, geographical location, perhaps some dependencies on a basic level) which would allow third-party frameworks to use and why not support them ?

[duboz]

Yes, good idea. This is related with models documentation (issue #46).