1 Aug 10:53
Re: Simultaneous simulations
Stefan Scherfke <stefan.scherfke <at> uni-oldenburg.de>
2008-08-01 08:53:36 GMT
2008-08-01 08:53:36 GMT
Moin moin, I am planning to move the different classes to the following files: Lister.py: (no changes) - Lister Simulation.py - Process - SimEvent - Simulation (new, inherits from Lister) - __Evlist - Simerror - FatalSimerror Simulation*.py (one file for each special simulation type) - Simulation* (each inherits from Simulation) Resources.py - Resource - Buffer - Level - Store - Queue - FIFO - PriorityQ Recording.py - Histogram - Monitor(Continue reading)
4. Let Simulation.__init__() do the stuff currently done by
initialize().
Point three is not as important to me as one and two, but it would
make life a bit easier for me. Point four just moves some logic to
another function so that user only need to write "sim =
Simulation(); ..." instead of "sim = Simulation();
sim.initialize(); ...". The old way initilize() will still work
for compatibiltiy reason.
Whats your opinion about that?
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 doesnt seem to be performance overhead, but
>> Ill 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 8095 % 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 youd 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
>>>
> 
RSS Feed