Simulation clock

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Simulation clock

grampajohn
Administrator
This is related to the "access to time" thread. My understanding is that we'll create a "job" to drive the clock, right? The job would time out every 5 seconds (non-concurrent), create a new timeslot, and somehow notify every component that needs to react to the new timeslot. Do we have a design for this yet, or should I work on this?

John
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simulation clock

grampajohn
Administrator
Here's a post on how to dynamically schedule jobs using the Quartz scheduler. In our case, the "job" would be the simulation clock, and various plugins would ask to be notified when the time is updated. If there are sequence dependencies, there are several approaches we could use:

-  Define a sequence of "phases" for each timeslot, and divide actions into phases. Ideally, there would be no sequence dependencies among activities in a given phase.

- Use some sort of configurable controller that invokes various actions in a pre-defined sequence.

- Distribute an event object that contains a list of the actions taken so far during the current phase. If an action must wait for some other action, it refuses the event and gets moved to the back of the queue. This is the method used in MinneTAC to sequence actions on the Decision event.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simulation clock

Carsten Block
Administrator
Hi John,

Here's a post on how to dynamically schedule jobs using the Quartz scheduler. In our case, the "job" would be the simulation clock, and various plugins would ask to be notified when the time is updated. If there are sequence dependencies, there are several approaches we could use:

That's pretty much what we did in the v1 version of the server. We used a programatically created cron job to set up and execute timeslot changes. This logic is currently ported by David into the new server. 

-  Define a sequence of "phases" for each timeslot, and divide actions into phases. Ideally, there would be no sequence dependencies among activities in a given phase. 

- Use some sort of configurable controller that invokes various actions in a pre-defined sequence. 
- Distribute an event object that contains a list of the actions taken so far during the current phase. If an action must wait for some other action, it refuses the event and gets moved to the back of the queue. This is the method used in MinneTAC to sequence actions on the Decision event.
In the original server (see e.g. https://launchpad.net/tacenergy/+download) we used exactly such a controller but with every requirement change the controller had to be adjusted, which required coding. That's the very reason why we switched to spring integration for the new server (not yet complete channel setup at https://github.com/powertac/powertac-server/blob/master/grails-app/conf/spring/resources.xml) to become more flexible.  Depending on the type of channel we configure(!) you can change method invocation from synchronous (thread waits for return value) to asynchronous to polling etc. No code changes required at all as long as we do not call one service method from another!  Also, for each channel we can add wiretaps on demand, which send a message copy e.g. to the visualizer. 



If you reply to this email, your message will be added to the discussion below:
http://power-tac-developers.975333.n3.nabble.com/Simulation-clock-tp2284153p2290628.html
To start a new topic under Power TAC Developers, email [hidden email]
To unsubscribe from Power TAC Developers, click here.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simulation clock

grampajohn
Administrator
On 01/21/11 10:15, Carsten Block [via Power TAC Developers] wrote:

> Hi John,
>
>> Here's a post on how to dynamically schedule jobs using the Quartz
>> scheduler
>> <http://www.intelligrape.com/blog/2009/12/01/rescheduling-a-quartz-job-programmatically/>.
>> In our case, the "job" would be the simulation clock, and various
>> plugins would ask to be notified when the time is updated. If there
>> are sequence dependencies, there are several approaches we could use:
>
> That's pretty much what we did in the v1 version of the server. We used
> a programatically created cron job to set up and execute timeslot
> changes. This logic is currently ported by David into the new server.

That makes sense, but timeslots are a market artifact, not just a time
artifact, and it should not require a database operation to retrieve the
current time, whether it's cached or not. I believe we need to separate
the "time" concept from the "timeslot" concept, and make time globally
available on both the server and broker platforms. I show a simple way
to do this in
https://github.com/powertac-plugins/powertac-common/blob/tariff-dev/grails-app/services/org/powertac/common/TimeService.groovy.
To use it, you def timeService in your module, and call
timeService.getCurrentTime() to get a LocalDateTime instance that
represents the current time. The other problem is to define the transfer
function between system time and simulation time, communicate it from
server to broker, and implement it separately in the server and broker.
I haven't yet worked out the details, but I believe it can be defined by
3 numbers: origin, offset, and compression. This will significantly
reduce latency effects, and reduce the disadvantage experienced by
brokers that have longer communication latencies.

>
>> -  Define a sequence of "phases" for each timeslot, and divide actions
>> into phases. Ideally, there would be no sequence dependencies among
>> activities in a given phase.
>
>> - Use some sort of configurable controller that invokes various
>> actions in a pre-defined sequence.
>> - Distribute an event object that contains a list of the actions taken
>> so far during the current phase. If an action must wait for some other
>> action, it refuses the event and gets moved to the back of the queue.
>> This is the method used in MinneTAC to sequence actions on the
>> Decision event.
> In the original server (see
> e.g. https://launchpad.net/tacenergy/+download) we used exactly such a
> controller but with every requirement change the controller had to be
> adjusted, which required coding. That's the very reason why we switched
> to spring integration for the new server (not yet complete channel setup
> at https://github.com/powertac/powertac-server/blob/master/grails-app/conf/spring/resources.xml)
> to become more flexible.  Depending on the type of channel we
> configure(!) you can change method invocation from synchronous (thread
> waits for return value) to asynchronous to polling etc. No code changes
> required at all as long as we do not call one service method from
> another!  Also, for each channel we can add wiretaps on demand, which
> send a message copy e.g. to the visualizer.

This is good, but it does not address the sequence problem. We need a
more detailed design with examples.

Cheers -

John

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simulation clock

grampajohn
Administrator
I propose that simulation time be directly derived from system time with a simple formula. As long as all machines involved in a simulation are running ntp, they could in principle all derive the current simulation time independently. Here's the formula:

sim-time = base + (stime - start) * rate

where sim-time is the current simulation time, base is the beginning of the simulation, stime is the current system time, start is the system time when the simulation starts, and rate is the time-compression factor (720 if we run a one-hour timeslot in 5 seconds).

So if the start time of a scenario is  21 June 1990 at noon, we start the simulation at 13:30:00 on 22 Jan 2011, the rate is 720, and current system time is 13:31:46, then the sim-time is

1990-6-21-12:00 + 106 sec * 720 = 1990-6-22-9:12

So to synchronize the brokers with the server, we communicate three numbers during the login phase: [base, start, rate]. Presumably this is done before the start time, of course, so brokers know exactly when the simulation will start.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simulation clock

Carsten Block
Administrator
Timezones are then still an issue we need to cope for, right?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simulation clock

grampajohn
Administrator
On 01/22/2011 08:15 PM, Carsten Block [via Power TAC Developers] wrote:
> Timezones are then still an issue we need to cope for, right?

I think we should just stick with UTC: timezone offset = 0. That's what
we've done in SCM. The only difficulty would be during transitions
to/from DST in the real-world data, but that should not be a huge
problem as long as we know when they are, or better yet, preprocess the
data to get rid of DST transitions.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simulation clock

grampajohn
Administrator
As long as we stick with UTC, we can use org.joda.time.Instant instances to represent time instead of LocalDateTime. This a conceptually simpler type (represented simply as a long), and has the advantage that you can add, for example, a Duration and get another Instant. To extract elements from an instant like HourOfDay or DayOfWeek, you first convert to a DateTime in timezone DateTimeZone.UTC as

  time = new DateTime(instant, DateTimeZone.UTC)
  hour = time.getDayOfWeek()
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simulation clock

grampajohn
Administrator
After coding this up and testing (see Issue #84), I'm becoming convinced that we would be better off with DateTime rather than Instant, because you have to convert to DateTime anyway if you want to reason about hours, days, weeks, etc. The only real difference in the underlying representation is that DateTime includes a Chronology and a TimeZone. The ISO chronology is default, and the time zone is always DateTimeZone.UTC.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Simulation clock

grampajohn
Administrator
The simulation clock is implemented and tested, and issue #71 is closed. It's called TimeService; it computes simulation time as discussed earlier, with the addition of a "modulo" parameter that controls the boundaries of the time values it records. So if you set the modulo to 15 minutes, for example, the time will always be x:00, x:15, x:30, or x:45. It's a true simulation clock, so you can put actions on its queue and they will be run when their scheduled times arrive. Those actions can, of course, add themselves back to the queue at a later time, so you can easily get repeating actions. The clock is driven by a scheduler job called ClockDriveJob.

Examples of how you use this stuff are in the test scripts TimeServiceTests and TimeServiceSchedTests.

Enjoy!

John
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Simulation clock

Wolf
Administrator

This is excellent!

 

Thanks,

 

Wolf



Disclaimer
De informatie verzonden in dit e-mail bericht inclusief de bijlage(n) is vertrouwelijk en is uitsluitend bestemd voor de geadresseerde van dit bericht. Lees verder: http://www.eur.nl/email-disclaimer.

The information in this e-mail message is confidential and may be legally privileged. Read more: http://www.eur.nl/english/email-disclaimer.

Loading...