Stefan,
I don't think that anything should happen to a process in a hold when a simulation has come to an end. If you end the simulation at t = 10, t = 15 is outside the simulation time frame. If, on the other hand, the event at t  = 15 is part of the model execution, just don't end the simulation at t = 10, but let it end with the event at t = 15.

I clearly argue from the semantics a modeling point of view, not from a Python programming point of view.

Klaus Müller


Stefan Scherfke wrote:

Hi Klaus, happy New Year to you, too! charge() should be called no matter whether the charging process was interrupted or not. The code I posted works quite fine during the simulation. The problem arises only, when the whole simulation ends while the controller is "in a hold": Imagine I want to simulate until t = 10. If the controller yields "hold, self, 10" at t = 5, it should continue to work (and call charge()) at t = 15. But at t = 15 the simulation already has stopped without the controller realizing this, so charge() doesn’t get called. Normally, if you delete/close a generator (here the PEM), it raises a GeneratorExit error to the generator/PEM, so I can except and handle the end of it. Since a SimPy process keeps a reference to its PEM in _nextpoint, if the PEM was in a "hold" when the simulation finished, then no GeneratorExit will be raised. So the simulator should imho check the event list for all outstanding events and either call close() directly on each generator or just set _nextpoint = None for each process. I can try to implement and test this and post my results here later. cheers, Stefan Am 2010-01-07 um 13:47 schrieb Klaus G. Muller:

Stefan, Happy New Year! An interesting question. My answer to this is one of semantics: the simulation is NOT over, if something still needs to be done in the model. The battery controller process (the one in the "yield hold") should therefore be interrupted by whatever ends the charge process, like so: charge_start = self.sim.now() duration = self.get_charge_duration() yield hold, self, duration if self.interrupted(): # This will be called if the battery is full or if someone # pulled the plug (and thus interrupted the charging) duration = self.sim.now() - charge_start self.battery.charge(self.kw, duration) What do you think? I believe this is a clean way of miodeling the charge termination action. Klaus Müller Stefan Scherfke wrote:

Moin moin, is there an easy way to notify a PEM that the simulation finished while the PEM was in a "yield hold"? Example for a battery controller: … charge_start = self.sim.now() duration = self.get_charge_duration() yield hold, self, duration # This will be called if the battery is full or if someone # pulled the plug (and thus interruped the charging) duration = self.sim.now() - charge_start self.battery.charge(self.kw, duration) … If the simulation ends while the PEM has yielded "yield hold, self, duration", "self.battery.charge()" wont get called. I’ve tryied to wrap the yield in a try: yield except GeneratorExit, but this works neither. It seems like the generator is not deleted correctly, when the simulation finishes and so no GeneratorExit is raised. My current work-around for this is to call charge() manually for each process, when the simulation has finished, but this is not really satisfying … Ontje and I are currently fiddling around with it and try to find out, where references to the PEM could be still alive after the sim. The eventlist is set to None and process._nextpoint is also None … Any ideas? Best regards, Stefan ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ 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 Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 

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