Open Insood opened 4 years ago
Thank you so much for using desmod and for this feedback. It's been a little unclear whether desmod was helpful to anyone outside my organization.
Regarding parent/child relationships, the parent components retaining references to their children via the Component._children
list causes a directed acyclical graph of components to be formed. This component dag is traversed (in post order) at elaboration-time, post simulation-time, and result gathering-time.
That we can guarantee a post-order traversal may be helpful in some models, but perhaps some models do not have inter-component relationships where it is necessary.
And yes, the component hierarchy lends itself to generating DOT diagrams, but I wouldn't say that was a primary motivator.
Regarding how the component dag is retained, obviously currently it is inline using the Component._children
list, but it is perhaps worth considering whether it might be preferable to capture the component hierarchy in some other out-of-band manner.
I am interested in other perspectives on desmod's components. My view is limited since there is only one (proprietary) model that I work with. Desmod's hierarchical component dag serves that model well, but I'd love to hear about other models that have different needs.
I haven't dived too deep into Desmod's yet - I am trying to optimize a low-volume, high mix manufacturing floor with ~100 assembly stations. So far everything appears to be working well. I was using pure simpy before, but I really needed Desmod's Queue class to get here.
I'm not defining any children in my components just yet and yet everything still seems to work - hence my confusion.
Hello! Loving this library - helping me out with a simulation I'm working on.
What is the point of defining parent/child relationships? Is it only to generate DOT diagrams?