Looking for an Alternative to simpy?

[Klaus Popp]

Visit https://github.com/KlausPopp/Moddy

From my point of view, it is more intuitive and can generate sequence diagrams....

[Leonardo Fontoura]

I was taking a look at your code and noticed that your task scheduling code is simply inserting events at the appropriate index using list.insert. This is terribly inefficient (and a deal breaker for anyone doing relatively big simulations) and I suggest that you swap it for a heap.

[Klaus Popp]

Dear Leonardo,

thanks for your feedback. You are right, the scheduler is not yet performance optimized. For me it was not an issue so far, as my models are typically small. Do you have a suggestion to improve this? (what do mean with "swap it for a heap")? 

Best Regards, Klaus

[Klaus Muller]

Klaus,

When I programmed the first version of Simpy in 2002, I did the same, I used a Python list as event notice store. That worked fine, because my models were tiny, just enough to demo and test. When others started to use Simpy on larger models, it became obvious that the overhead of list insertion/removal slowed them down too much. Just perform a timing analysis, and you will see that this part of your system is a hot spot.

The simple solution is to use a low overhead sort mechanism. The heap offers that. I switched, and Simpy got a lot faster and much more useful.

Good luck!
Klaus G. Müller

--
You received this message because you are subscribed to the Google Groups "python-simpy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python-simpy...@googlegroups.com.
To post to this group, send email to python...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python-simpy/e226ab8c-a3b8-4750-b5a2-08ff8b9c6ac1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andreas Beham]

Dear Klaus,

I am not very convinced of your approach, in particular in that it follows already tried approaches and besides the automatic sequence diagram we're not given a lot of novelity.

I find it very cumbersome and hard for a programmer to describe the model using ports and bindings. While that is of course an adequate modeling language, I would rather choose a visual editor to create those models than a programming language. Your examples are quite simple, yet they require quite a large amount of code (almost 100 LOC for the simple hello). The visual model of hello however looks totally trivial, so why do we need 100 LOCs to create such a trivial thing? It raises the question why not start creating with the visual model in the first place and generate the code from that visual model? If you look e.g. at AnyLogic simulation environment they do exactly the same thing, but offer a graphical editor where you create the interactions and where you create the model from the structure diagram. Almost all of the big simulators out there (Arena, FlexSim, PlantSim, etc.) successfully follow this approach. And all of them have some rather complex programming in the background that is auto-generated from the visual model.

I simply don't see any advantage in reversing the process. One advantage of a programming language based model over a visual model is the ability to refactor more easily. The burden of visual models is when they grow large it is hard to change them. When you want to change the logic of the simulation you have to rewrite components and rewire them having to perform a lot of clicks and change a lot of arrows. At some point people who have done this feel that it is easier to start everything from scratch. A programming language based model does not have those disadvantages to such a degree. Text can be replaced quickly and sometimes the programming editor can combine a lot of individual changes to one bigger change (refactoring support). Nevertheless, in your model for example, you're using strings a lot. Ports are strings and this strange state indicator is a string. Strings are in general harder to refactor than fields or methods. So, I think you're not fully using the main advantage of programming language based simulation modeling.

Then you claim that the output that you obtain is an "advantage" (e.g. structure diagrams). However consider that you also have to do a lot of extra work (extra LOCs) to get that advantage. I don't see that it is an advantage when I have to do something extra, a lot extra actually. As a programmer I am looking for ways to create models with as little LOC as possible and I want to have simple models with only few LOCs. In your example even a simple model is having quite a large number of LOCs, I don't dare to think about more complex examples.

Another thing why I don't find that framework very interesting or novel is that a lot of the complexity in simulation models is hidden in the interactions. This is actually the hard part to understand. The components are often simple and can be described using ports, but the bindings and how those create interaction and dynamic are extremely difficult to understand a priori. That's also why you do simulation in the first place, of course. In that I think the sequence diagram is a nice addition as an output (e.g. to validate the model), but when modeling and when looking only at the model it is still very difficult to understand what's going on. I don't think this is any simpler than simpy which is also very complex if you have lots of concurrent processes that create each other.

I think both structure diagramming output and sequence diagramming output could be added to simpy which I think would take the best of both.

 

Sincerely,

Andreas

[Klaus Popp]

Hello Andreas,

Thank you for your feedback, even if it is mostly negative.

My motivation to write moddy was to have a tool that quickly produces sequence diagrams with timing information, as a basis for discussions with team members or customers. I am working as a Product Manager and System Architect for embedded Systems. I tried to use IBM Rhapsody SysML, but this was extremely compliated. 

At that time I wasn't aware of the tools you mentioned (AnyLogic etc). 

Perhaps you can now better understand why moddy is as it is... 

Regarding your remarks:

Modelling via visual model vs. programming language:

I agree with you that at least the structure of the model should be creatable with a visual editor. I simply had not the time (and skills) to do it.

But to describe the behaviour, I doubt that it is easier to model it with a visual tool. At least, a visual representation is more difficult to review.

And simpy has also no visual modeller, right?

You are complaining about the complexity of "hello": 

The hello tutorial uses just the basic elements of moddy.

Have you seen that there are additional 2 ways to describe model behavior: "State machines" and "Sequential Programs". Depending on the problem, you can chose one of them, and each "part" can use its own approach

You said: "Ports are string"

That's not true. The createPorts takes the port name as a string, but from that string it creates a member variable with that name. After creation of the port, the port is referenced by its member name within the class (not as a string)

Finally, I didn't get what you mean with your remark: "Another thing why I don't find that framework very interesting or novel is that a lot of the complexity in simulation models is hidden in the interactions. This is actually the hard part to understand." -> cam you explain?

And now, I will have a look at AnySim. 

Thanks again.