Simultaneous simulations

Hi everyone,

in April 08, Ontje suggested simultaneous simulations for SimPy. A  
Simulation-class should encapsulate all the global stuff needed for a  
simulation (initialize(), activate(), now(), …) so that you can run  
multiple simulations concurrently (e.g. in different threads) by  
calling simA.initialize() … simA.simulate() … simX.initialize() … See
http://sourceforge.net/mailarchive/forum.php?thread_name=200804091432.55594.The_COM%40gmx.de&forum_name=simpy-users 
  for details.

Meanwhile we have implemented that for Simulation.py and are  
considering to release our changes as a patch for 1.9.1. If you’d like  
to add this to the develoment version, we could clean up our changes  
and apply them to Simulation*.py as well.

I have attached our current modifications so that you can see what we  
want to do, testSimPy.py still runs. 

Regards,
Stefan

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,

Re: Simultaneous simulations

Stefan,
This is promising and definitely wanted for future versions of SimPy. The
one thing which needs to be looked at is the performance overhead of the
extra function call, e.g. 

def now():
    global sim
    return sim.now()

Is there an eror in your patch? When I ran

>>> a=Simulation()
>>> class Test(Process):
... 	def run(self):
... 		yield hold,self,10
... 
>>> a.initialize()
>>> t=Test()
>>> a.activate(t,t.run())
>>> a.simulate(until=100)

I got:

Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
  File
"C:\Python25\SimPy\Development\191plusdevt\Lib\site-packages\simpy-1.9.1-py2
.5.egg\SimPy\SimulationPar.py", line 920, in simulate
    dispatch[command](a)
  File

Re: Simultaneous simulations

Hi Ontje!
Ok, that was my fault/lack of understanding!

Thanks!

Klaus Müller 

> -----Original Message-----
> From: Ontje Lünsdorf [mailto:Ontje.Luensdorf <at> offis.de] 
> Sent: Monday, July 14, 2008 2:21 PM
> To: simpy-users <at> lists.sourceforge.net
> Cc: kgmuller; 'Stefan Scherfke'
> Subject: Re: [Simpy-users] Simultaneous simulations
> 
> Hi Klaus,
> 
> Am Sonntag 13 Juli 2008 18:24:44 schrieb kgmuller:
> > Is there an eror in your patch? When I ran
> >
> > >>> a=Simulation()
> > >>> class Test(Process):
> >
> > ... 	def run(self):
> > ... 		yield hold,self,10
> > ...
> >
> > >>> a.initialize()
> > >>> t=Test()
> > >>> a.activate(t,t.run())
> > >>> a.simulate(until=100)

Re: Simultaneous simulations

Hi Klaus,

Am Sonntag 13 Juli 2008 18:24:44 schrieb kgmuller:
> Is there an eror in your patch? When I ran
>
> >>> a=Simulation()
> >>> class Test(Process):
>
> ... 	def run(self):
> ... 		yield hold,self,10
> ...
>
> >>> a.initialize()
> >>> t=Test()
> >>> a.activate(t,t.run())
> >>> a.simulate(until=100)

Thanks for your feedback. This code fragment doesn't work because you are 
mixing to different simulations (there's no error checking on that yet ;). 
You instanciated a new simulation "a" and a new process "t". The process must 
be bound/added to simulation "a". This must be done by specifying the _sim 
parameter in the constructor like this:

t=Test(_sim = a)

By default, all processes, monitors, ... are bound to the default global 
simulation object.

Regards,
Ontje

Re: Simultaneous simulations

Hello everyone,

on a first glimpse there doesn’t seem to be performance overhead, but  
I’ll test it with a larger example next week to get more reliable  
information about that.

I also took a first closer look at the other Simulation*.py files and  
they are 80–95 % the same code as Simulation.py. I think before I  
start to transfer our changes from Simulation.py to 3*2500 lines of  
nearly the same code, we should consider refactoring everything. Most  
of the changes in the other simulations add only a few extra lines or  
methods.

In my opinion it should be possible to extract classes like Process  
and implement a default Simulation class from which SimulationRT and  
the others will inherit. With that, we might reduce the LOC from ~10k  
to maybe ~3k and remove dublicate code which will improve further  
development and maintenance drastically.

How do you feel about this?

Regards,
Stefan

Am 13.07.2008 um 18:24 schrieb kgmuller:

> Stefan,
> This is promising and definitely wanted for future versions of  
> SimPy. The
> one thing which needs to be looked at is the performance overhead of  

Re: Simultaneous simulations

Stefan,
I second the proposal to refactor the code as you suggest. I would also suggest 
separating the plotting and GUI code out of the core simulation classes. There 
are other capable packages like pylab/matplotlib and pyx which are great at 
plotting and if SimPy were to focus on its core goal of discrete event 
simulation, it would make a better case of being accepted as a core python module.
-vikas

Stefan Scherfke wrote:
> Hello everyone,
> 
> on a first glimpse there doesn’t seem to be performance overhead, but  
> I’ll test it with a larger example next week to get more reliable  
> information about that.
> 
> I also took a first closer look at the other Simulation*.py files and  
> they are 80–95 % the same code as Simulation.py. I think before I  
> start to transfer our changes from Simulation.py to 3*2500 lines of  
> nearly the same code, we should consider refactoring everything. Most  
> of the changes in the other simulations add only a few extra lines or  
> methods.
> 
> In my opinion it should be possible to extract classes like Process  
> and implement a default Simulation class from which SimulationRT and  
> the others will inherit. With that, we might reduce the LOC from ~10k  
> to maybe ~3k and remove dublicate code which will improve further  
> development and maintenance drastically.
> 
> How do you feel about this?
> 

Re: Simultaneous simulations

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Simpy-users mailing list
Simpy-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simpy-users

Re: Simultaneous simulations

All:
I am perfectly happy with refactoring and going to one base module from
which all Simulation*.py can inherit. So far, I had no difficulties
/significant overhead in maintaining the four libraries.

I feel strongly for maintaining SimPlot and SimGUI in SimPy, though. They
are NOT part of the core simulation libraries, but they are useful, "out of
the box" utilities. Without installing any other library, you immediately
have (default) plotting and GUI capabilities, once you have installed SimPy.

Of course there are more powerful libaries out there. We recommend already
the use of matplotlib for publication-qulaity plotting.

What we should do is offer well-documented interfaces to other
graphics/plotting/statistics packages, like wxPython, matplotlib and R,
without removing SimPlot or SimGUI. The packages we choose to interface to
should be mainstream packages, i.e., packages which are well documented and
used by many users. Which packages should we choose here? Suggestions?

I would also be happy to hear ideas for how best to offer these interfaces,
without sacrificing the "batteries included" plotting and GUI capabilities
now provided by SimPy. 

Klaus Müller

-----Original Message-----
From: simpy-users-bounces <at> lists.sourceforge.net
[mailto:simpy-users-bounces <at> lists.sourceforge.net] On Behalf Of Vikas
Kawadia
Sent: Freitag, 25. Juli 2008 13:53
To: simpy-users <at> lists.sourceforge.net
Subject: Re: [Simpy-users] Simultaneous simulations

Stefan,
I second the proposal to refactor the code as you suggest. I would also
suggest 
separating the plotting and GUI code out of the core simulation classes.
There 
are other capable packages like pylab/matplotlib and pyx which are great at 
plotting and if SimPy were to focus on its core goal of discrete event 
simulation, it would make a better case of being accepted as a core python
module.
-vikas

Stefan Scherfke wrote:
> Hello everyone,
> 
> on a first glimpse there doesn’t seem to be performance overhead, but  
> I’ll test it with a larger example next week to get more reliable  
> information about that.
> 
> I also took a first closer look at the other Simulation*.py files and  
> they are 80–95 % the same code as Simulation.py. I think before I  
> start to transfer our changes from Simulation.py to 3*2500 lines of  
> nearly the same code, we should consider refactoring everything. Most  
> of the changes in the other simulations add only a few extra lines or  
> methods.
> 
> In my opinion it should be possible to extract classes like Process  
> and implement a default Simulation class from which SimulationRT and  
> the others will inherit. With that, we might reduce the LOC from ~10k  
> to maybe ~3k and remove dublicate code which will improve further  
> development and maintenance drastically.
> 
> How do you feel about this?
> 
> Regards,
> Stefan
> 
> 
> 
> Am 13.07.2008 um 18:24 schrieb kgmuller:
> 
>> Stefan,
>> This is promising and definitely wanted for future versions of  
>> SimPy. The
>> one thing which needs to be looked at is the performance overhead of  
>> the
>> extra function call, e.g.
>>
>> def now():
>>    global sim
>>    return sim.now()
>>
>>
>> Re: If you’d like
>> to add this to the develoment version, we could clean up our changes
>> and apply them to Simulation*.py as well.
>>
>> Yes, please, do!
>>
>> Klaus Müller
>>
>> -----Original Message-----
>> From: simpy-users-bounces <at> lists.sourceforge.net
>> [mailto:simpy-users-bounces <at> lists.sourceforge.net] On Behalf Of Stefan
>> Scherfke
>> Sent: Donnerstag, 10. Juli 2008 15:48
>> To: simpy-users <at> lists.sourceforge.net
>> Subject: [Simpy-users] Simultaneous simulations
>>
>> Hi everyone,
>>
>> in April 08, Ontje suggested simultaneous simulations for SimPy. A
>> Simulation-class should encapsulate all the global stuff needed for a
>> simulation (initialize(), activate(), now(), …) so that you can run
>> multiple simulations concurrently (e.g. in different threads) by
>> calling simA.initialize() … simA.simulate() … simX.initialize() … See
>>
http://sourceforge.net/mailarchive/forum.php?thread_name=200804091432.55594 
>> .
>> The_COM%40gmx.de&forum_name=simpy-users
>>  for details.
>>
>> Meanwhile we have implemented that for Simulation.py and are
>> considering to release our changes as a patch for 1.9.1. If you’d like
>> to add this to the develoment version, we could clean up our changes
>> and apply them to Simulation*.py as well.
>>
>> I have attached our current modifications so that you can see what we
>> want to do, testSimPy.py still runs. 
>>
>> Regards,
>> Stefan
>>
>>
>>
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
> Build the coolest Linux based applications with Moblin SDK & win great
prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Simpy-users mailing list
> Simpy-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/simpy-users
> 

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Simpy-users mailing list
Simpy-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simpy-users

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Simultaneous simulations

Moin moin,

I just run a test with 10001 processes. The standard SimPy needed  
~25.7 seconds to run, our modified version did it in ~27.7 seconds,  
which is about 7–8% slower. I think for that large number of  
processes, the overhead is not to big.

Furthermore, with our modification you can gain an enormous speedup in  
combination with parallel python (http://www.parallelpython.com/).  
With ParallelPython using both cores of my pc, the same 10k processes  
needed only ~13.5 seconds. And I can even use others PCs for the  
simulation! With 2 cores of the local pc and 2 cores from a pc in LAN,  
I can reduce runtime to ~8 seconds!

I think that is worth the 7% overhead for normal simulations. 

regards
Stefan

> Hello everyone,
>
> on a first glimpse there doesn’t seem to be performance overhead, but
> I’ll test it with a larger example next week to get more reliable
> information about that.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Simultaneous simulations

Hello again!

How shall we implement our changes? Shall we checkout a certain  
version from the repository or just take the released version 1.9.1 as  
basis? Are you currently working on a new version or is 1.9.1 still up  
to date? And shall we provide a patch-file or just zip everything into  
a package?

regards
Stefan

Am 31.07.2008 um 10:07 schrieb kgmuller:

> All:
> I am perfectly happy with refactoring and going to one base module  
> from
> which all Simulation*.py can inherit. So far, I had no difficulties
> /significant overhead in maintaining the four libraries.
>
> I feel strongly for maintaining SimPlot and SimGUI in SimPy, though.  
> They
> are NOT part of the core simulation libraries, but they are useful,  
> "out of
> the box" utilities. Without installing any other library, you  
> immediately
> have (default) plotting and GUI capabilities, once you have  
> installed SimPy.
>
> Of course there are more powerful libaries out there. We recommend  
> already
> the use of matplotlib for publication-qulaity plotting.
>
> What we should do is offer well-documented interfaces to other
> graphics/plotting/statistics packages, like wxPython, matplotlib and  
> R,
> without removing SimPlot or SimGUI. The packages we choose to  
> interface to
> should be mainstream packages, i.e., packages which are well  
> documented and
> used by many users. Which packages should we choose here? Suggestions?
>
> I would also be happy to hear ideas for how best to offer these  
> interfaces,
> without sacrificing the "batteries included" plotting and GUI  
> capabilities
> now provided by SimPy.
>
> Klaus Müller
>
> -----Original Message-----
> From: simpy-users-bounces <at> lists.sourceforge.net
> [mailto:simpy-users-bounces <at> lists.sourceforge.net] On Behalf Of Vikas
> Kawadia
> Sent: Freitag, 25. Juli 2008 13:53
> To: simpy-users <at> lists.sourceforge.net
> Subject: Re: [Simpy-users] Simultaneous simulations
>
> Stefan,
> I second the proposal to refactor the code as you suggest. I would  
> also
> suggest
> separating the plotting and GUI code out of the core simulation  
> classes.
> There
> are other capable packages like pylab/matplotlib and pyx which are  
> great at
> plotting and if SimPy were to focus on its core goal of discrete event
> simulation, it would make a better case of being accepted as a core  
> python
> module.
> -vikas
>
> Stefan Scherfke wrote:
>> Hello everyone,
>>
>> on a first glimpse there doesn’t seem to be performance overhead, but
>> I’ll test it with a larger example next week to get more reliable
>> information about that.
>>
>> I also took a first closer look at the other Simulation*.py files and
>> they are 80–95 % the same code as Simulation.py. I think before I
>> start to transfer our changes from Simulation.py to 3*2500 lines of
>> nearly the same code, we should consider refactoring everything. Most
>> of the changes in the other simulations add only a few extra lines or
>> methods.
>>
>> In my opinion it should be possible to extract classes like Process
>> and implement a default Simulation class from which SimulationRT and
>> the others will inherit. With that, we might reduce the LOC from ~10k
>> to maybe ~3k and remove dublicate code which will improve further
>> development and maintenance drastically.
>>
>> How do you feel about this?
>>
>> Regards,
>> Stefan
>>
>>
>>
>> Am 13.07.2008 um 18:24 schrieb kgmuller:
>>
>>> Stefan,
>>> This is promising and definitely wanted for future versions of
>>> SimPy. The
>>> one thing which needs to be looked at is the performance overhead of
>>> the
>>> extra function call, e.g.
>>>
>>> def now():
>>>   global sim
>>>   return sim.now()
>>>
>>>
>>> Re: If you’d like
>>> to add this to the develoment version, we could clean up our changes
>>> and apply them to Simulation*.py as well.
>>>
>>> Yes, please, do!
>>>
>>> Klaus Müller
>>>
>>> -----Original Message-----
>>> From: simpy-users-bounces <at> lists.sourceforge.net
>>> [mailto:simpy-users-bounces <at> lists.sourceforge.net] On Behalf Of  
>>> Stefan
>>> Scherfke
>>> Sent: Donnerstag, 10. Juli 2008 15:48
>>> To: simpy-users <at> lists.sourceforge.net
>>> Subject: [Simpy-users] Simultaneous simulations
>>>
>>> Hi everyone,
>>>
>>> in April 08, Ontje suggested simultaneous simulations for SimPy. A
>>> Simulation-class should encapsulate all the global stuff needed  
>>> for a
>>> simulation (initialize(), activate(), now(), …) so that you can run
>>> multiple simulations concurrently (e.g. in different threads) by
>>> calling simA.initialize() … simA.simulate() … simX.initialize() …  
>>> See
>>>
> http://sourceforge.net/mailarchive/forum.php?thread_name=200804091432.55594
>>> .
>>> The_COM%40gmx.de&forum_name=simpy-users
>>> for details.
>>>
>>> Meanwhile we have implemented that for Simulation.py and are
>>> considering to release our changes as a patch for 1.9.1. If you’d  
>>> like
>>> to add this to the develoment version, we could clean up our changes
>>> and apply them to Simulation*.py as well.
>>>
>>> I have attached our current modifications so that you can see what  
>>> we
>>> want to do, testSimPy.py still runs. 
>>>
>>> Regards,
>>> Stefan
>>>
>>>
>>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
>> Build the coolest Linux based applications with Moblin SDK & win  
>> great
> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Simpy-users mailing list
>> Simpy-users <at> lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/simpy-users
>>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Simpy-users mailing list
> Simpy-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/simpy-users
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Simpy-users mailing list
> Simpy-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/simpy-users
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/