Server scenarios

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

Server scenarios

grampajohn
Administrator
I feel a strong need for a clearer vision of how the server is going to work. Perhaps one of you has it all worked out, but if so it has not been communicated effectively to the rest of us.

To start the process of working out the details, I have started writing a set of server scenarios that will give us a forum for working out the details before too much bad code gets written.

Does this seem helpful? If we are going to do this, then these descriptions should be kept up to date so we can use them as a window into the code. I've also started going through and updating the Architecture section to migrate to the new grails setup. Please check and make sure I've not communicated obvious untruths.

Cheers -

John
Reply | Threaded
Open this post in threaded view
|

Re: Server scenarios

grampajohn
Administrator
I need your input. Please read through the set of server scenarios on the github wiki.

First, I want the set to be complete. These are the "stories" we must implement for the first version of a running server. Second, I want each scenario to be worked out in sufficient detail so we can write code and configure the server to run them. Then we need to break them down into work items, write the tickets, assign them, and work through them. Feel free to begin that process if you see a scenario that's complete and you are ready to work on it. Also, if you see something missing (there are a couple on the broker side that I can think of), please write down at least a title and brief description on the wiki so we can start working it out.

There are a couple scenarios that are empty right now, including the start-of-game and end-of-game items. I think Chris or someone at KIT has already been thinking about that; if so, could you please write a draft?

I have not yet written anything about how the server interacts with the visualizer. Adis, could you plese add notes to the existing scenarios where you think the visualizer needs to be included, and add any that I've missed?

There may be one or two customer-initiated scenarios that need to be added as well. Anthony or Andreas, could you please review and add your comments also?

Thanks, everyone.

John
Reply | Threaded
Open this post in threaded view
|

Re: Server scenarios

achryso
I think that the scenarios described are quite OK. I would like to point out that my models are dummy at the moment, they are creating random households and villages etc but they are not making any use of weather conditions or dynamic shifting yet. But they give a meter reading for each customer model and the cost if given the tariff. Also my models are created from the beginning of each week, and refresh at the end of it. That means that they run once each week, not for every given timeslot. If what we care for is the load and not each household and appliance inside, then shifting should not be a problem.

At this moment, after I have successfully implemented the clock in my models and have seen that they work with the timeclock service in the common plugin, I am trying to create an competition to import them into so that they work inside competition timeslots. The thing is that I thought there would be an implemented function in Competition groovy file to create the timeslots for each Competition I create, but I discovered that there isn't. So, I guess I have to create manually the timeslots and put the inside every competition I create. Is there an easier way to do this???

I will try and implement a tariff behavior in my customer models as the one described in your scenarios and the dummy customer topic but it will take me a week or so.

Have a great weekend!

Anthony


Reply | Threaded
Open this post in threaded view
|

Re: Server scenarios

adis
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Server scenarios

achryso
In reply to this post by achryso
Hello!!!

The past weekend I slightly changed my models so that they work OK with the current version of the powertac-common plugin. I would like to make some notes over it, bacause the relationships between the objects are not the optimal and created a bunch of problems on my venture.

Meter Reading: There are competition, timeslot and customerInfo twice in the class variables.

The competition variable I think shouldn't exist at all, since each timeslot is contained inside a competition. So it is better for the meter reading to belong to a timeslot and this timeslot to belong to a competition, so there is no excess in the relationships.

Also, the timeslot and customerInfo variables should be only on the belongsTo and not as single variables too.

Finally, the toString function should be return "$customer-$timeslot-$amount"

Competition: must remove from HasMany the Meter Readings, order to have the correct relationships as noticed above.

I would like to ask if there is an automated way to create timeslots in a competition, because I had to do it manually.

I also guessed that the timeslot serialNumber is an increasing number starting from 1 and keep going...So to find the number of a timeslot I have to see the distance from the competition base (starting) time. It is crucial for me to know that because I use it in order to create the meterReading of the consumer models.

Thank you in advance.

Anthony
Reply | Threaded
Open this post in threaded view
|

Re: Server scenarios

grampajohn
Administrator
On 02/14/2011 05:07 AM, achryso [via Power TAC Developers] wrote:
> Hello!!!
>
> The past weekend I slightly changed my models so that they work OK with
> the current version of the powertac-common plugin. I would like to make
> some notes over it, bacause the relationships between the objects are
> not the optimal and created a bunch of problems on my venture.
>
> *Meter Reading: *There are competition, timeslot and customerInfo twice
> in the class variables.

There are other problems with MeterReading, the biggest being that it's
not tied to a particular Tariff (or TariffSubscription). I've tried to
be a little more clear about how MeterReading instances get created at
https://github.com/powertac/powertac-server/wiki/Customer-start-of-timeslot.
They get created by TariffSubscription as a result of the Customer
calling usePower(amount) on the TariffSubscription. This code is not yet
committed, but it should be by the end of the day today.

>
> The competition variable I think shouldn't exist at all, since each
> timeslot is contained inside a competition. So it is better for the
> meter reading to belong to a timeslot and this timeslot to belong to a
> competition, so there is no excess in the relationships.

The MeterReading could belong to a Timeslot, or to the
TariffSubscription that generated it. I'm open to suggestions here.

>
> Also, the timeslot and customerInfo variables should be only on the
> belongsTo and not as single variables too.

You are correct.

>
> Finally, the toString function should be return
> "$customer-$timeslot-$amount"

I'll check that.

>
> *Competition:* must remove from HasMany the Meter Readings, order to
> have the correct relationships as noticed above.

I have already done that, it should be committed yet today (Minnesota time).


>
> I would like to ask if there is an automated way to create timeslots in
> a competition, because I had to do it manually.

That is a good question. Perhaps the TimeService or the Timeslot class
could serve up the current Timeslot serial number to make it easy. It
might be better to just use the Timeslot serial number rather than the
Timeslot ID in data elements like MeterReading. It would avoid an
additional access to discover which one precedes another one.

>
> I also guessed that the timeslot serialNumber is an increasing number
> starting from 1 and keep going...So to find the number of a timeslot I
> have to see the distance from the competition base (starting) time. It
> is crucial for me to know that because I use it in order to create the
> meterReading of the consumer models.

The MeterReading should be generated by TariffSubscription, because in
at least some Customer models we expect production/consumption to vary
according to Tariff terms.

I hope this helps. Let's keep in touch on this until it's all working
correctly.

John
Reply | Threaded
Open this post in threaded view
|

Re: Server scenarios

chris.flath
To some extent this question is also related to my remark on the server scenarios: If a customer is just queried by the accounting service for its last consumption / generation report this query could provide the relevant data as arguments. Currently, the customer model implement generateMeterReading(Weatherdata weather) which seems odd to me as weatherdata may be one relevant data point for generating the meter reading but certainly is not the only one.

So my question is do we envision the customers to actively self-report their meter reading or are they queried by the game?
Reply | Threaded
Open this post in threaded view
|

Re: Server scenarios

grampajohn
Administrator
chris.flath wrote
To some extent this question is also related to my remark on the server scenarios: If a customer is just queried by the accounting service for its last consumption / generation report this query could provide the relevant data as arguments. Currently, the customer model implement generateMeterReading(Weatherdata weather) which seems odd to me as weatherdata may be one relevant data point for generating the meter reading but certainly is not the only one.

So my question is do we envision the customers to actively self-report their meter reading or are they queried by the game?
The advantage of having the Customers do this autonomously is that we can run multiple Customer models in parallel if we are running on hardware that can support it. If they have to wait to be queried, they will be serialized. Also, Customers cannot simply report their production/consumption, because these behaviors in general will be influenced by Tariff terms. This means that production/consumption must be reported by TariffSubscription.

A related issue is the need to abstract out some of the low-level activities of Customer into an AbstractCustomer, thereby simplifying as much as possible the implementation of Customer models. I would like to work with Antonios to define its properties.
Reply | Threaded
Open this post in threaded view
|

Re: Server scenarios

grampajohn
Administrator
In reply to this post by chris.flath
I have added somewhat detailed sequence diagrams to two of the upcoming stories to help solidify our vision of how pieces of the server work together. See the Tariff publication and Tariff subscription stories under the Development Roadmap. Is this helpful? I think the next one is perhaps the accounting process, and I would like someone (Chris?) to do one for the forward market.

Let me know if this works. Thanks.

John
Reply | Threaded
Open this post in threaded view
|

Re: Server scenarios

Prashant Reddy
I think the sequence diagrams are indeed very helpful.

Very minor nitpick -
In the tariff publication scenario, it seems weird that if I published a tariff, other brokers get a notification about it before I get a status back?  It really shouldn't matter though since they'll both happen in the same timeslot under normal circumstances.

Thanks,
Prashant


Reply | Threaded
Open this post in threaded view
|

Re: Server scenarios

grampajohn
Administrator
On 03/07/2011 03:17 PM, ppr [via Power TAC Developers] wrote:
> I think the sequence diagrams are indeed very helpful.
>
> Very minor nitpick -
> In the tariff publication scenario, it seems weird that if I published a
> tariff, other brokers get a notification about it before I get a status
> back?  It really shouldn't matter though since they'll both happen in
> the same timeslot under normal circumstances.

Yes, I noticed that also. It's just easier to write the code that way.
If it's a bug, we could fix it by sending the status explicitly rather
than as a return value. That might actually make sense.

Thanks.

John