Timeslot references in domain types

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Timeslot references in domain types

grampajohn
Administrator
Dear colleagues -

An issue has arisen that calls into question the use of timeslot references in weather reports and other domain types. Part of the problem is that these references need to be separately resolved in both server and broker environments, and there is some complexity in TimeslotRepo to make sure the timeslots exist when references to them show up. In the xml messages, timeslots are represented by serial numbers, with zero being the first timeslot in the boot sequence.

There have been suggestions in the past that logs would be easier to understand and parse if timeslot IDs and time strings were universally replaced with timeslot sequence numbers.

We have an opportunity right now to make this change, starting with version 1.0.0. It will require some refactoring of the server and of brokers, but the result should be simpler and easier to understand. So I think we have three choices:

1. Leave the representation alone, in which time data shows up in various places in four different formats: timeslot references (or object ID values), time strings, long values giving time in milliseconds, and timeslot sequence numbers. This will require some refactoring of the server startup sequence to fix issue #660, but otherwise will not break any existing code.

2. Switch to timeslot sequence numbers for weather reports, which will fix issue #660, but will leave the current confusion over time representation. This may affect some existing broker code, but only for brokers that are using weather reports.

3. Put in some effort over the next week or two to clean up time representation and settle on timeslot sequence number as the universal representation. It is easy to do arithmetic on them, logs will be easier to read and parse, and they can easily be converted to references or time values as needed. This will require some updates to broker code, so everyone will be affected. Of course, the sample broker would be updated in the process, and we can post some code examples for converting timeslot sequence numbers to times or timeslot references. Also, note that the simulation timeline always starts with timeslot 0 at midnight.

I see #3 as somewhat risky in the short term, but in the longer term it should make the Power TAC system significantly easier to work with.

I would like to make a decision on this by next Wednesday 1/9. Please let me know your thoughts. In particular, I will give considerable weight to opinions that strongly object to #3.

Thanks.

John
Reply | Threaded
Open this post in threaded view
|

RE: Timeslot references in domain types

Wolf
Administrator

I think option #3 is the best way to go!

 

Best,

 

Wolf

 

From: grampajohn [via Power TAC Developers] [mailto:ml-node+[hidden email]]
Sent: zaterdag 5 januari 2013 16:58
To: Wolf Ketter
Subject: Timeslot references in domain types

 

Dear colleagues -

An issue has arisen that calls into question the use of timeslot references in weather reports and other domain types. Part of the problem is that these references need to be separately resolved in both server and broker environments, and there is some complexity in TimeslotRepo to make sure the timeslots exist when references to them show up. In the xml messages, timeslots are represented by serial numbers, with zero being the first timeslot in the boot sequence.

There have been suggestions in the past that logs would be easier to understand and parse if timeslot IDs and time strings were universally replaced with timeslot sequence numbers.

We have an opportunity right now to make this change, starting with version 1.0.0. It will require some refactoring of the server and of brokers, but the result should be simpler and easier to understand. So I think we have three choices:

1. Leave the representation alone, in which time data shows up in various places in four different formats: timeslot references (or object ID values), time strings, long values giving time in milliseconds, and timeslot sequence numbers. This will require some refactoring of the server startup sequence to fix issue #660, but otherwise will not break any existing code.

2. Switch to timeslot sequence numbers for weather reports, which will fix issue #660, but will leave the current confusion over time representation. This may affect some existing broker code, but only for brokers that are using weather reports.

3. Put in some effort over the next week or two to clean up time representation and settle on timeslot sequence number as the universal representation. It is easy to do arithmetic on them, logs will be easier to read and parse, and they can easily be converted to references or time values as needed. This will require some updates to broker code, so everyone will be affected. Of course, the sample broker would be updated in the process, and we can post some code examples for converting timeslot sequence numbers to times or timeslot references. Also, note that the simulation timeline always starts with timeslot 0 at midnight.

I see #3 as somewhat risky in the short term, but in the longer term it should make the Power TAC system significantly easier to work with.

I would like to make a decision on this by next Wednesday 1/9. Please let me know your thoughts. In particular, I will give considerable weight to opinions that strongly object to #3.

Thanks.

John


If you reply to this email, your message will be added to the discussion below:

http://power-tac-developers.975333.n3.nabble.com/Timeslot-references-in-domain-types-tp4025363.html

To start a new topic under Power TAC Developers, email [hidden email]
To unsubscribe from Power TAC Developers, click here.
NAML


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


Reply | Threaded
Open this post in threaded view
|

Re: Timeslot references in domain types

jurica.babic
In reply to this post by grampajohn
Hi John,

I am also voting for approach #3

Regarding Visualizer:
Visualizer heavily relies on millisecs obtained through the use of Timeslot or Instant objects.
I will need a guide on how to get millis out of timeslot sequence number.

Also, as the third option introduces lightweight timeslots, is there a possibility to add timeslot info for messages that currently do not have timestamp (e.g. CashPosition)?

Cheers,
Jurica
Reply | Threaded
Open this post in threaded view
|

Re: Timeslot references in domain types

grampajohn
Administrator
jurica.babic wrote
I am also voting for approach #3

Regarding Visualizer:
Visualizer heavily relies on millisecs obtained through the use of Timeslot or Instant objects.
I will need a guide on how to get millis out of timeslot sequence number.
The TimeService will provide this feature. It already knows the sim base time and the length of a timeslot, so it has all the necessary information to convert sequence numbers to Instant, time-of-day, day-of-week, etc.
Also, as the third option introduces lightweight timeslots, is there a possibility to add timeslot info for messages that currently do not have timestamp (e.g. CashPosition)?
Yes. That was already on my list. Are there other types that should have time information that do not carry it now?

John
Reply | Threaded
Open this post in threaded view
|

Re: Timeslot references in domain types

jurica.babic
It will be great if we convert all time representations (that use Timeslot or Instant objects) using the new approach.

Apart from CashPosition, I would like the timeslot info for:
- MarketPosition ("from/dateExecuted" time, currently there is only "to" time)
- Order ("from/dateExecuted" time).

If I find anything else I will let you know.

Thanks.

Jurica