Slight redefinition of roles + sample workflow for negotiating tariffs

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

Slight redefinition of roles + sample workflow for negotiating tariffs

Carsten Block
Administrator
Hi John,

Attached please find a (still handwritten) overview picture as promised. The blue boxes are the roles we described in the user stories. The green annotations are the roles / entities as described in the wiki.

New roles are Game Timer (ist somehow in the wiki but not as a role so far) and tax authority (which an levy taxes or give out subsidies). The rest is pretty much the same as in the wiki. You can see that for the Wholesale market we are a bit more specific (Auctioneer + Liquidity Provider as two distinct roles), while the "Accounting Service" comprises functionality originally found in the Broker Portfolio and in the Bank role.

On page we designed a message pipe and filter architecture that we want to implemtn for the handling of negotiable tariff offers. It basically describes all things that happen in the server if a broker sends in a new tariff and at least one customer wants to negotiate with him.

1.) Once the new tariff enters the server, the accounting service stores it as a new tariff in the list of currently offered tariffs
2.) The acounting service forwards the list of currently offered tariffs (including the new one) to all registered customer models
3.) In this case customer n wants to negotiate.
4.) It creates a counteroffer and sends out the original tariff as well as ist own offer downstream to the next message handler, which is the Tariff Rule Enforcer (aka Tariff Market)
5.) The Tariff Rule Enforcer checks that the offer is valid based on a number of (tariff market rules) such as that tariff attributes are only allowed to be altered in one direction (e.g. Signup Fee can only be decreased, max number of offers may not be exceeded, etc.)
6.) If all rules are fulfilled the offer is forwarded to the accounting service again, which stores it as a new offer (like this the accounting service receives the full negotiation history)
7.) At last the new offer is send out to the broker via JMS, who might then decided to react or not to react to it.

We also thought about the case where a negotiation does not seem to find an end. Our solution for it: We use the server's scheduler functionality to periodically trigger the accounting service, which then sets all negotiations to cancelled that exceed a certain time limit.


This is only one use case. We are working on developing similar models for all use cases we need to be built in to the server. We also need to put them into the wiki or somewhere publicly available but I think we should first make the decision where to host wiki and code in order to avoid duplicate work.

Cheers,
Carsten



20101118155222891.pdf (1M) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Out of Office AutoReply: Slight redefinition of roles + sample workflow for negotiating tariffs

Wolf
Administrator
Out of Office AutoReply: Slight redefinition of roles + sample workflow for negotiating tariffs

Hello,

I'm currently out of the office. I'll be back in the office on Monday, 22 November 2010.  Until then I will read my mail only sporadically or not at all. Your mail is not forwarded. If you need immediate assistance please contact Cheryl Eiting ([hidden email]). If it requires a reply, I will do so after I return to the office.

Best,

Wolf Ketter



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
|  
Report Content as Inappropriate

Re: Slight redefinition of roles + sample workflow for negotiating tariffs

grampajohn
Administrator
In reply to this post by Carsten Block
On 11/19/2010 02:23 AM, Carsten Block [via Power TAC Developers] wrote:
> Hi John,
>
> Attached please find a (still handwritten) overview picture as promised.
> The blue boxes are the roles we described in the user stories. The green
> annotations are the roles / entities as described in the wiki.
>
> New roles are Game Timer (ist somehow in the wiki but not as a role so
> far)

Good, that was missed. I would like to call it GameController or
something like that, because I assume there will be other global
game-oriented issues besides timing.

> and tax authority (which an levy taxes or give out subsidies).

Good idea; I assume it provides rate data to Brokers and Customers, and
to the Accounting Service which applies tax and subsidy rules in its
accounting function.

> The
> rest is pretty much the same as in the wiki. You can see that for the
> Wholesale market we are a bit more specific (Auctioneer + Liquidity
> Provider as two distinct roles),

That makes sense.

> while the "Accounting Service"
> comprises functionality originally found in the Broker Portfolio and in
> the Bank role.

I'm not so sure about that. I think it's mostly from the original DU; in
fact, I think it IS what I was calling the DU, with Broker Portfolio and
Bank folded in. What is left in the DU, other than possibly access to
historic load data?

>
> On page we designed a message pipe and filter architecture that we want
> to implemtn for the handling of negotiable tariff offers. It basically
> describes all things that happen in the server if a broker sends in a
> new tariff and at least one customer wants to negotiate with him.

Tariffs are contracts that cannot be negotiated. Non-tariff contracts
(or just Contracts) can be negotiated, and the initiative for that comes
from a customer, not from a Broker.

Also, a pipe-and-filter model from a visualization standpoint is
basically a dataflow model, but a pipe-and-filter _architecture_ begs
the question of how control is handled. Is it backward-chaining, driven
by queries (that's how MinneTAC evaluators work), or is it
forward-chaining, driven by the emergence of new information? IOC
patterns can support both. However, a complex pipe-and-filter
architecture can make dependency management complicated, because you
have many classes and components in the middle of the dependency
hierarchy. This is not ideal from the standpoint of either maintenance
or flexibility - better to have most modules either at the top or bottom
of the dependency hierarchy, and keep the modules at the bottom
relatively stable (not being replaced by casual developers).

>
> 1.) Once the new tariff enters the server, the accounting service stores
> it as a new tariff in the list of currently offered tariffs
> 2.) The acounting service forwards the list of currently offered tariffs
> (including the new one) to all registered customer models
> 3.) In this case customer n wants to negotiate.
> 4.) It creates a counteroffer and sends out the original tariff as well
> as ist own offer downstream to the next message handler, which is the
> Tariff Rule Enforcer (aka Tariff Market)
> 5.) The Tariff Rule Enforcer checks that the offer is valid based on a
> number of (tariff market rules) such as that tariff attributes are only
> allowed to be altered in one direction (e.g. Signup Fee can only be
> decreased, max number of offers may not be exceeded, etc.)
> 6.) If all rules are fulfilled the offer is forwarded to the accounting
> service again, which stores it as a new offer (like this the accounting
> service receives the full negotiation history)
> 7.) At last the new offer is send out to the broker via JMS, who might
> then decided to react or not to react to it.

I really don't understand this. It's pretty much backward from the
negotiation process we've talked about in the past, it does not map onto
the work Daniel is doing, and what you are calling the TarriffMarket
looks like what we have been calling the ContractMarket. Because it's an
active research area, the ContractMarket is an element that clearly
needs to be replaceable with a Repast model, while the "real" tariff
market was part of the MIS.

I suspect you are trying to unify contract negotiation with tariff
offering, but I think it's very premature to try to do that, not least
because it will make it harder for other researchers to explore
negotiation processes.

We need a tariff market, where brokers can offer tariffs (and pay a
fee), where brokers can examine offered tariffs (tariffs, but not
contracts, are public), and where customers can find them. Is that
another part of the Accounting Service?

I agree that the BrokerPortfolio is mostly related to accounting and
reporting. It aggregates customers to broker tariffs, and serves as the
broker->customer mapping by which brokers can communicate price changes
to customers, as specified by tariff rules. It also reports actual
production and consumption back to the broker, and it aggregates
balancing capacity to allow the DU to clear the balancing market.

Because balancing is at least potentially another market function,
involving at least the wholesale market, brokers,
broker->tariff->customer relationships, and the DU accounting function,
it is another entity that should probably be broken out and made
replaceable. There are a number of models for balancing markets, and we
don't want to fold it into a large, complex model and thereby complicate
the work of a researcher who wants to try a different model.

>
> We also thought about the case where a negotiation does not seem to find
> an end. Our solution for it: We use the server's scheduler functionality
> to periodically trigger the accounting service, which then sets all
> negotiations to cancelled that exceed a certain time limit.

I think the initial model Daniel came up with does not have this
problem, and we can leave it up to the designers of alternative Contract
Markets to solve the problem as needed. So this is not a problem that
needs solving right now.

>
>
> This is only one use case. We are working on developing similar models
> for all use cases we need to be built in to the server. We also need to
> put them into the wiki or somewhere publicly available but I think we
> should first make the decision where to host wiki and code in order to
> avoid duplicate work.

I've listed a number of use cases, which I've called "scenarios", on the
Game Design page. One of them that's fairly filled out is the
"execution" scenario. We need to see how that maps to your modularization.

I believe we should move everything over to www.powertac.org/wiki. It's
a MediaWiki instance, like Wikia, so we should just be able to copy and
paste everything. I'm going to see if I can find a student to do that.
Or I might just do it myself.

I hope this helps -

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

Re: Slight redefinition of roles + sample workflow for negotiating tariffs

Carsten Block
Administrator
Hi!

Am 22.11.2010 um 02:19 schrieb grampajohn [via Power TAC Developers]:

On 11/19/2010 02:23 AM, Carsten Block [via Power TAC Developers] wrote:
> Hi John,
>
> Attached please find a (still handwritten) overview picture as promised.
> The blue boxes are the roles we described in the user stories. The green
> annotations are the roles / entities as described in the wiki.
>
> New roles are Game Timer (ist somehow in the wiki but not as a role so
> far)

Good, that was missed. I would like to call it GameController or
something like that, because I assume there will be other global
game-oriented issues besides timing.

Game controller is good.

> and tax authority (which an levy taxes or give out subsidies).

Good idea; I assume it provides rate data to Brokers and Customers, and
to the Accounting Service which applies tax and subsidy rules in its
accounting function.

The general description how taxes or subsidies are applied will be part  of the  competition description sent out to the participants upon competition startup. Tax authority is then triggered after a timeslot is closed in order to determine how a broker generated the energy (i.e. from which generators) so that it can tax or subsidize the respective broker accordingly.


> The
> rest is pretty much the same as in the wiki. You can see that for the
> Wholesale market we are a bit more specific (Auctioneer + Liquidity
> Provider as two distinct roles),

That makes sense.

> while the "Accounting Service"
> comprises functionality originally found in the Broker Portfolio and in
> the Bank role.

I'm not so sure about that. I think it's mostly from the original DU; in
fact, I think it IS what I was calling the DU, with Broker Portfolio and
Bank folded in. What is left in the DU, other than possibly access to
historic load data?
Balancing the grid after a timeslot is closed and (possibly) charging customers for the imbalances they caused. 


>
> On page we designed a message pipe and filter architecture that we want
> to implemtn for the handling of negotiable tariff offers. It basically
> describes all things that happen in the server if a broker sends in a
> new tariff and at least one customer wants to negotiate with him.

Tariffs are contracts that cannot be negotiated. Non-tariff contracts
(or just Contracts) can be negotiated, and the initiative for that comes
from a customer, not from a Broker.
We closely examined contracts and found that the non-negotiable case is only a specific negotiation (where the initial offer is directly accepted by the counterparty) as long as negotiations as well as publish-subscribe tariffs are both initiated by brokers. Daniel modeled the initial RFQ offering vice versa (i.e. customer initiating that process) and we discussed that yesterday in depth. In the end there was no good reason why it *had* to be the case that customers initiate RFQs. In fact, there is no real world justification for it - at least not on the distribution level we want to model in the competiion.


Also, a pipe-and-filter model from a visualization standpoint is
basically a dataflow model, but a pipe-and-filter _architecture_ begs
the question of how control is handled. Is it backward-chaining, driven
by queries (that's how MinneTAC evaluators work), or is it
forward-chaining, driven by the emergence of new information? IOC
patterns can support both. However, a complex pipe-and-filter
architecture can make dependency management complicated, because you
have many classes and components in the middle of the dependency
hierarchy. This is not ideal from the standpoint of either maintenance
or flexibility - better to have most modules either at the top or bottom
of the dependency hierarchy, and keep the modules at the bottom
relatively stable (not being replaced by casual developers). 

Probably I was wrong using the word pipe-and-filter. In fact we use the spring integration extension of the spring IOC container (see http://www.springsource.org/spring-integration), which provides a simple to configure message bus infrastructure that - amongst others - can implement a pipe and filter pattern, but also messages routers, gateways, service activators, wiretaps (a nice way to do logging by interception) and so on. An excellent reference is "Enterprise Integration Patterns" by Hohpe and Woolf (Addison Wesley, 2003) but also the spring integration reference documentation available online at http://static.springsource.org/spring-integration/reference/ 

>

> 1.) Once the new tariff enters the server, the accounting service stores
> it as a new tariff in the list of currently offered tariffs
> 2.) The acounting service forwards the list of currently offered tariffs
> (including the new one) to all registered customer models
> 3.) In this case customer n wants to negotiate.
> 4.) It creates a counteroffer and sends out the original tariff as well
> as ist own offer downstream to the next message handler, which is the
> Tariff Rule Enforcer (aka Tariff Market)
> 5.) The Tariff Rule Enforcer checks that the offer is valid based on a
> number of (tariff market rules) such as that tariff attributes are only
> allowed to be altered in one direction (e.g. Signup Fee can only be
> decreased, max number of offers may not be exceeded, etc.)
> 6.) If all rules are fulfilled the offer is forwarded to the accounting
> service again, which stores it as a new offer (like this the accounting
> service receives the full negotiation history)
> 7.) At last the new offer is send out to the broker via JMS, who might
> then decided to react or not to react to it.
I really don't understand this. It's pretty much backward from the
negotiation process we've talked about in the past, it does not map onto
the work Daniel is doing, and what you are calling the TarriffMarket
looks like what we have been calling the ContractMarket. Because it's an
active research area, the ContractMarket is an element that clearly
needs to be replaceable with a Repast model, while the "real" tariff
market was part of the MIS.

1.) See argumentation. Daniel's model is nice but does not have a representation in reality.
2.) Invoking tariff publish-subscribe from the broker side while invoking negotiations from the consumer side *heavily* 1increases server complexity. We already have way more complexity than, for example, TAC AdAuctions and thus I strongly suggest that we unify the different types of establishing a tariff contract between customer and broker.
3.) While it will be possible to implement the different plugins in RePast and while we will provide "empty" RePast demos for it so that interested developers can easily get started with it, the reference implementations from KArlsruhe will most likely be pure Java ( or maybe Groovy).


I suspect you are trying to unify contract negotiation with tariff
offering, but I think it's very premature to try to do that, not least
because it will make it harder for other researchers to explore
negotiation processes.
Not doing it now makes it even harder to do it later on and - as said before - we really have to cut down complexity! Negotiation processes are not affected. We can still impose arbitrary negotiation rules only that the broker has to initially publish a tariff that he then can mark as "negotiatiable" or not. Note that this is not a strong restriction as we agreed that there will be a default broker with a default tariff where all customers are initially subscribed to. Economically this is an Anchor Point (sometimes also called reference Point) anyway from which customers and brokers evaluate the current tariff offerings.  

We need a tariff market, where brokers can offer tariffs (and pay a
fee), where brokers can examine offered tariffs (tariffs, but not
contracts, are public), and where customers can find them. Is that
another part of the Accounting Service?

Accounting Service is storing publicly available tariff (and making them accessible to everybody, i.e. customers as well as all brokers). Also it knows the states of all negotiations. Remember, a negotiation can be as simple as "subscribe" (as customer response to a published tariff), but might also go over several rounds with several offers being exchanged between one broker and one customer. While the initial tariff offering is public to everybody, neither the offers nor the subscriptions are. These are only known to the involved parties.

Negotiation rule enforcer *can* be added to the channel configuration. It contains negotiation rules (e.g. those Daniel suggested) and basically filters offers from customers and / or brokers rejecting those offers that do not comply with the negotiation rules. Like this, e.g. maximum number of round but also minimum concessions etc. can be imposed.  

Tax Authority is charging a fee for each published tariff (we found tax authority to be a reasonable choice but can also give that function to e.g. a "tariff publishing fee collector". It is not part of the accounting service as the accounting service only does the book keeping and no other business logic). 

Information distribution is configured through the message channels (and some routers, filters, splitters, etc.). Like this we can inform brokers as well as customers of newly published tariffs while only a particular broker and customer is informed about subscriptions or (counter-) offers.


I agree that the BrokerPortfolio is mostly related to accounting and
reporting. It aggregates customers to broker tariffs, and serves as the
broker->customer mapping by which brokers can communicate price changes
to customers, as specified by tariff rules. It also reports actual
production and consumption back to the broker, and it aggregates
balancing capacity to allow the DU to clear the balancing market.

Right. Price changes are initiated by a broker, forwarded to the accounting service, which stores the price changes, and then they are forwarded to the affected customers.

Because balancing is at least potentially another market function,
involving at least the wholesale market, brokers,
broker->tariff->customer relationships, and the DU accounting function,
it is another entity that should probably be broken out and made
replaceable. There are a number of models for balancing markets, and we
don't want to fold it into a large, complex model and thereby complicate
the work of a researcher who wants to try a different model.

Right. The DU is the very role that is responsible for balancing and thus we do not want to put any other functionality there a a researcher interested in realizing an instance of the DU should really focus on this issue and on nothing else (same holds true for the other roles too). 

>
> We also thought about the case where a negotiation does not seem to find
> an end. Our solution for it: We use the server's scheduler functionality
> to periodically trigger the accounting service, which then sets all
> negotiations to cancelled that exceed a certain time limit.

I think the initial model Daniel came up with does not have this
problem, and we can leave it up to the designers of alternative Contract
Markets to solve the problem as needed. So this is not a problem that
needs solving right now.

This problem only persists if there is no Negotiation Rule Enforcer configured, which might (as Daniel currently does) impose a maximum number of offers before a negotiation has to be finished or cancalled. The nice thing is that we can freely configure our competition to support either case. 

>
>
> This is only one use case. We are working on developing similar models
> for all use cases we need to be built in to the server. We also need to
> put them into the wiki or somewhere publicly available but I think we
> should first make the decision where to host wiki and code in order to
> avoid duplicate work.

I've listed a number of use cases, which I've called "scenarios", on the
Game Design page. One of them that's fairly filled out is the
"execution" scenario. We need to see how that maps to your modularization.

We took http://powertac.wikia.com/wiki/Game_Design#Execution into account. The line "DU clears the balancing market and runs resulting Bank transactions." is not in our model as (after our last discussion) we decided not to have a balancing market (i.e. call options on offer in the wholesale market).

I believe we should move everything over to www.powertac.org/wiki. It's
a MediaWiki instance, like Wikia, so we should just be able to copy and
paste everything. I'm going to see if I can find a student to do that.
Or I might just do it myself.

I'm a bit concerned now that we spread our project about so many different websites and tools (github, media wiki, trac + svn for internal stuff, and possibly another bugtracker. Although it's quite late again, I thought about applying for an open source license over at atlassian.com. If granted we would get access to the best in breed, i.e. Jira Issue tracker (possibly with GreenHopper agile development frontend), Fisheye code sharing, Confluence enterprise wiki (with extremely nice permission management that would help us to get rid of two different wikis), Bamboo integration server, and clover code coverage tools. Again: All these components are perfectly integrated. Thoughts?


I hope this helps -

Thanks, yes. We also took you comment into account that external signals for customer load shedding might be interesting. We agreed that we will prepare the server so that it supports such a case although, most likely, the initial customer models we develop will not (again) in order to cut complexity.


Cheers,
Carsten


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

Re: Slight redefinition of roles + sample workflow for negotiating tariffs

grampajohn
Administrator
On 11/23/10 02:27, Carsten Block [via Power TAC Developers] wrote:
> ...
>>
>> I'm not so sure about that. I think it's mostly from the original DU; in
>> fact, I think it IS what I was calling the DU, with Broker Portfolio and
>> Bank folded in. What is left in the DU, other than possibly access to
>> historic load data?
> Balancing the grid after a timeslot is closed and (possibly) charging
> customers for the imbalances they caused.

The "charging" part is what I'm concerned about, because it could well
be a market function.

>
>
>> >
>> > On page we designed a message pipe and filter architecture that we want
>> > to implemtn for the handling of negotiable tariff offers. It basically
>> > describes all things that happen in the server if a broker sends in a
>> > new tariff and at least one customer wants to negotiate with him.
>>
>> Tariffs are contracts that cannot be negotiated. Non-tariff contracts
>> (or just Contracts) can be negotiated, and the initiative for that comes
>> from a customer, not from a Broker.
> We closely examined contracts and found that the non-negotiable case is
> only a specific negotiation (where the initial offer is directly
> accepted by the counterparty) as long as negotiations as well as
> publish-subscribe tariffs are both initiated by brokers. Daniel modeled
> the initial RFQ offering vice versa (i.e. customer initiating that
> process) and we discussed that yesterday in depth. In the end there was
> no good reason why it *had* to be the case that customers initiate RFQs.
> In fact, there is no real world justification for it - at least not on
> the distribution level we want to model in the competiion.

I think the big difference here between what you propose and what we've
talked about so far is that this new model is strictly bilateral and
based on counteroffers to general tariffs. The original model was an RFQ
model, and so it was multilateral, and that seems to make the most sense
if it's customer-initiated. I have no problem with having a bilateral,
broker-initiated model as the first implementation. I do have a problem
with building a structure that makes it hard to implement a multilateral
model later.

>
>
>> Also, a pipe-and-filter model from a visualization standpoint is
>> basically a dataflow model, but a pipe-and-filter _architecture_ begs
>> the question of how control is handled. Is it backward-chaining, driven
>> by queries (that's how MinneTAC evaluators work), or is it
>> forward-chaining, driven by the emergence of new information? IOC
>> patterns can support both. However, a complex pipe-and-filter
>> architecture can make dependency management complicated, because you
>> have many classes and components in the middle of the dependency
>> hierarchy. This is not ideal from the standpoint of either maintenance
>> or flexibility - better to have most modules either at the top or bottom
>> of the dependency hierarchy, and keep the modules at the bottom
>> relatively stable (not being replaced by casual developers).
>
> Probably I was wrong using the word pipe-and-filter. In fact we use the
> spring integration extension of the spring IOC container
> (see http://www.springsource.org/spring-integration), which provides a
> simple to configure message bus infrastructure that - amongst others -
> can implement a pipe and filter pattern, but also messages routers,
> gateways, service activators, wiretaps (a nice way to do logging by
> interception) and so on. An excellent reference is "Enterprise
> Integration Patterns" by Hohpe and Woolf (Addison Wesley, 2003) but also
> the spring integration reference documentation available online at
> http://static.springsource.org/spring-integration/reference/ 

OK, but I don't see any of this as simplifying the job of getting this
server working. Keep in mind that we are not solving an
enterprise-integration problem here, and most of our developers are not
full-time and have no experience with any of these tools or concepts.
Anything that lengthens the learning curve for new developers, or that
makes it harder for researchers to make their desired modifications, is
not where we want to go. If a tool or framework or method makes it
easier for our developers and for researchers to contribute effectively,
that's good. Otherwise it's not.

>
>...
> 3.) While it will be possible to implement the different plugins in
> RePast and while we will provide "empty" RePast demos for it so that
> interested developers can easily get started with it, the reference
> implementations from KArlsruhe will most likely be pure Java ( or maybe
> Groovy).

That's not a problem that you are using Java/Groovy. But we need to make
sure that we don't make it unnecessarily difficult to use Repast to
replace the parts we want researchers to be able to replace, including
customer models and markets. That's a strong argument, in my opinion, to
separate the market mechanisms (Tariff market, Contract market,
Balancing market) out of the Accounting Service, or to at least to make
them replaceable components withing the Accounting Service.

>
>
>> I suspect you are trying to unify contract negotiation with tariff
>> offering, but I think it's very premature to try to do that, not least
>> because it will make it harder for other researchers to explore
>> negotiation processes.
> Not doing it now makes it even harder to do it later on and - as said
> before - we really have to cut down complexity! Negotiation processes
> are not affected. We can still impose arbitrary negotiation rules only
> that the broker has to initially publish a tariff that he then can mark
> as "negotiatiable" or not. Note that this is not a strong restriction as
> we agreed that there will be a default broker with a default tariff
> where all customers are initially subscribed to. Economically this is an
> Anchor Point (sometimes also called reference Point) anyway from which
> customers and brokers evaluate the current tariff offerings.  

I am still not convinced that we ever want to unify the contract and
tariff markets, because it will make important research questions harder
to address. I think the best way to simplify in the short term could be
to not have the contract market.

>
>> We need a tariff market, where brokers can offer tariffs (and pay a
>> fee), where brokers can examine offered tariffs (tariffs, but not
>> contracts, are public), and where customers can find them. Is that
>> another part of the Accounting Service?
>
> Accounting Service is storing publicly available tariff (and making them
> accessible to everybody, i.e. customers as well as all brokers). Also it
> knows the states of all negotiations. Remember, a negotiation can be as
> simple as "subscribe" (as customer response to a published tariff), but
> might also go over several rounds with several offers being exchanged
> between one broker and one customer. While the initial tariff offering
> is public to everybody, neither the offers nor the subscriptions are.
> These are only known to the involved parties.
>
> Negotiation rule enforcer *can* be added to the channel configuration.
> It contains negotiation rules (e.g. those Daniel suggested) and
> basically filters offers from customers and / or brokers rejecting those
> offers that do not comply with the negotiation rules. Like this, e.g.
> maximum number of round but also minimum concessions etc. can be imposed.  
>
> Tax Authority is charging a fee for each published tariff (we found tax
> authority to be a reasonable choice but can also give that function to
> e.g. a "tariff publishing fee collector". It is not part of the
> accounting service as the accounting service only does the book keeping
> and no other business logic).
>
> Information distribution is configured through the message channels (and
> some routers, filters, splitters, etc.). Like this we can inform brokers
> as well as customers of newly published tariffs while only a particular
> broker and customer is informed about subscriptions or (counter-) offers.

That all seems fine.

>
>
>> I agree that the BrokerPortfolio is mostly related to accounting and
>> reporting. It aggregates customers to broker tariffs, and serves as the
>> broker->customer mapping by which brokers can communicate price changes
>> to customers, as specified by tariff rules. It also reports actual
>> production and consumption back to the broker, and it aggregates
>> balancing capacity to allow the DU to clear the balancing market.
>
> Right. Price changes are initiated by a broker, forwarded to the
> accounting service, which stores the price changes, and then they are
> forwarded to the affected customers.
>
>> Because balancing is at least potentially another market function,
>> involving at least the wholesale market, brokers,
>> broker->tariff->customer relationships, and the DU accounting function,
>> it is another entity that should probably be broken out and made
>> replaceable. There are a number of models for balancing markets, and we
>> don't want to fold it into a large, complex model and thereby complicate
>> the work of a researcher who wants to try a different model.
>
> Right. The DU is the very role that is responsible for balancing and
> thus we do not want to put any other functionality there a a researcher
> interested in realizing an instance of the DU should really focus on
> this issue and on nothing else (same holds true for the other roles too).

As long as the balancing function can be implemented as a market, I'm OK
with this.

>
>...
>>
>> I've listed a number of use cases, which I've called "scenarios", on the
>> Game Design page. One of them that's fairly filled out is the
>> "execution" scenario. We need to see how that maps to your
>> modularization.
>
> We took http://powertac.wikia.com/wiki/Game_Design#Execution into
> account. The line "DU clears the balancing market and runs resulting
> Bank transactions." is not in our model as (after our last discussion)
> we decided not to have a balancing market (i.e. call options on offer in
> the wholesale market).

As long as the design does not rule out a balancing market, I'm OK with
this.

>
>> I believe we should move everything over to www.powertac.org/wiki
>> <http://www.powertac.org/wiki>. It's
>> a MediaWiki instance, like Wikia, so we should just be able to copy and
>> paste everything. I'm going to see if I can find a student to do that.
>> Or I might just do it myself.
>
> I'm a bit concerned now that we spread our project about so many
> different websites and tools (github, media wiki, trac + svn for
> internal stuff, and possibly another bugtracker. Although it's quite
> late again, I thought about applying for an open source license over at
> atlassian.com <http://atlassian.com?by-user=t>. If granted we would get
> access to the best in breed, i.e. Jira Issue tracker (possibly with
> GreenHopper agile development frontend), Fisheye code sharing,
> Confluence enterprise wiki (with extremely nice permission management
> that would help us to get rid of two different wikis), Bamboo
> integration server, and clover code coverage tools. Again: All these
> components are perfectly integrated. Thoughts?

This is being addressed in a separate thread, I believe.

Thanks for your efforts. I think we are converging.

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

Re: Slight redefinition of roles + sample workflow for negotiating tariffs

Carsten Block
Administrator
> > Balancing the grid after a timeslot is closed and (possibly) charging
> > customers for the imbalances they caused.
>
> The "charging" part is what I'm concerned about, because it could well
> be a market function.

So far, in Europe it is not.

> I think the big difference here between what you propose and what we've
> talked about so far is that this new model is strictly bilateral and
> based on counteroffers to general tariffs. The original model was an RFQ
> model, and so it was multilateral, and that seems to make the most sense
> if it's customer-initiated. I have no problem with having a bilateral,
> broker-initiated model as the first implementation. I do have a problem
> with building a structure that makes it hard to implement a multilateral
> model later.

A multi-bilateral model (Gregory likes to call it like this) is possible too. A customer starts negotiating with several different brokers in parallel and ultimately chooses one tariff.

> OK, but I don't see any of this as simplifying the job of getting this
> server working. Keep in mind that we are not solving an
> enterprise-integration problem here, and most of our developers are not
> full-time and have no experience with any of these tools or concepts.
> Anything that lengthens the learning curve for new developers, or that
> makes it harder for researchers to make their desired modifications, is
> not where we want to go. If a tool or framework or method makes it
> easier for our developers and for researchers to contribute effectively,
> that's good. Otherwise it's not.

Exactly, the ultimate goal is to provide interested "non-core" developers who implement a module, say a Customer model, with a small set of interfaces (and descriptions on when these are invoked by the server and what type of data he might receive over them), which they need to implement. They should be able to either rely on a pre-configured RePast instance to accomplish that task or a pre-configured spring ioc template to do so.

For the "core-server" developers, on the other hand, we want to have a simple (i.e. mostly configuration-based) approach to easily "rewiring" server logic (i.e. interaction between modules) in future as a means for staying flexible in general to this end while at the same time being specific in one very particular instantiation of the server.  

> > 3.) While it will be possible to implement the different plugins in
> > RePast and while we will provide "empty" RePast demos for it so that
> > interested developers can easily get started with it, the reference
> > implementations from KArlsruhe will most likely be pure Java ( or maybe
> > Groovy).
>
> That's not a problem that you are using Java/Groovy. But we need to make
> sure that we don't make it unnecessarily difficult to use Repast to
> replace the parts we want researchers to be able to replace, including
> customer models and markets. That's a strong argument, in my opinion, to
> separate the market mechanisms (Tariff market, Contract market,
> Balancing market) out of the Accounting Service, or to at least to make
> them replaceable components withing the Accounting Service.
See above. A clearly defines set of interfaces is there to ensure this. Also we will strictly enforce modularity by strictly prohibiting any interaction between different modules (say customer and auctioneer) other than over pre-defined interfaces (which might have to be extended or changed in future).


> I am still not convinced that we ever want to unify the contract and
> tariff markets, because it will make important research questions harder
> to address. I think the best way to simplify in the short term could be
> to not have the contract market.
The server functionality will be there and we can simply configure it one way or the other.

> As long as the design does not rule out a balancing market, I'm OK with
> this.
Balancing market, in essence, is another product in the wholesale market. We do not specify it right now but it seems to be reasonable to implement that in future.




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

Re: Slight redefinition of roles + sample workflow for negotiating tariffs

grampajohn
Administrator
On 11/24/2010 01:35 AM, Carsten Block [via Power TAC Developers] wrote:
>  > > Balancing the grid after a timeslot is closed and (possibly) charging
>  > > customers for the imbalances they caused.
>  >
>  > The "charging" part is what I'm concerned about, because it could well
>  > be a market function.
>
> So far, in Europe it is not.

In the U.S., and as far as I know in Latin America, it is.

>
>  > I think the big difference here between what you propose and what we've
>  > talked about so far is that this new model is strictly bilateral and
>  > based on counteroffers to general tariffs. The original model was an RFQ
>  > model, and so it was multilateral, and that seems to make the most sense
>  > if it's customer-initiated. I have no problem with having a bilateral,
>  > broker-initiated model as the first implementation. I do have a problem
>  > with building a structure that makes it hard to implement a multilateral
>  > model later.
>
> A multi-bilateral model (Gregory likes to call it like this) is possible
> too. A customer starts negotiating with several different brokers in
> parallel and ultimately chooses one tariff.
>
>  > OK, but I don't see any of this as simplifying the job of getting this
>  > server working. Keep in mind that we are not solving an
>  > enterprise-integration problem here, and most of our developers are not
>  > full-time and have no experience with any of these tools or concepts.
>  > Anything that lengthens the learning curve for new developers, or that
>  > makes it harder for researchers to make their desired modifications, is
>  > not where we want to go. If a tool or framework or method makes it
>  > easier for our developers and for researchers to contribute effectively,
>  > that's good. Otherwise it's not.
>
> Exactly, the ultimate goal is to provide interested "non-core"
> developers who implement a module, say a Customer model, with a small
> set of interfaces (and descriptions on when these are invoked by the
> server and what type of data he might receive over them), which they
> need to implement. They should be able to either rely on a
> pre-configured RePast instance to accomplish that task or a
> pre-configured spring ioc template to do so.
>
> For the "core-server" developers, on the other hand, we want to have a
> simple (i.e. mostly configuration-based) approach to easily "rewiring"
> server logic (i.e. interaction between modules) in future as a means for
> staying flexible in general to this end while at the same time being
> specific in one very particular instantiation of the server.

I agree with this as long as you can write or point us to clear
instructions for (1) configuring a server, and (2) building new
configurable components that integrate seamlessly with the server. As I
said, my main concern here is learning curve. A secondary one is tool
configuration.

>
>  > > 3.) While it will be possible to implement the different plugins in
>  > > RePast and while we will provide "empty" RePast demos for it so that
>  > > interested developers can easily get started with it, the reference
>  > > implementations from KArlsruhe will most likely be pure Java ( or
> maybe
>  > > Groovy).
>  >
>  > That's not a problem that you are using Java/Groovy. But we need to make
>  > sure that we don't make it unnecessarily difficult to use Repast to
>  > replace the parts we want researchers to be able to replace, including
>  > customer models and markets. That's a strong argument, in my opinion, to
>  > separate the market mechanisms (Tariff market, Contract market,
>  > Balancing market) out of the Accounting Service, or to at least to make
>  > them replaceable components withing the Accounting Service.
> See above. A clearly defines set of interfaces is there to ensure this.
> Also we will strictly enforce modularity by strictly prohibiting any
> interaction between different modules (say customer and auctioneer)
> other than over pre-defined interfaces (which might have to be extended
> or changed in future).\

That's fine.

>
>
>  > I am still not convinced that we ever want to unify the contract and
>  > tariff markets, because it will make important research questions harder
>  > to address. I think the best way to simplify in the short term could be
>  > to not have the contract market.
> The server functionality will be there and we can simply configure it
> one way or the other.
>
>  > As long as the design does not rule out a balancing market, I'm OK with
>  > this.
> Balancing market, in essence, is another product in the wholesale
> market. We do not specify it right now but it seems to be reasonable to
> implement that in future.

That will be fine as long as the balancing _process_ is not wrapped up
in a big, complex component. That's what I'm afraid of in the
"accounting service". Perhaps I still don't understand it. My test of a
clean assignment of responsibilities to components is that a component
has a simple, one-sentence description of its responsibility, that is
ideally free of conjunctions.

Cheers -

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

Re: Slight redefinition of roles + sample workflow for negotiating tariffs

Carsten Block
Administrator

Am 24.11.2010 um 15:52 schrieb grampajohn [via Power TAC Developers]:

> That will be fine as long as the balancing _process_ is not wrapped up
> in a big, complex component. That's what I'm afraid of in the
> "accounting service". Perhaps I still don't understand it. My test of a
> clean assignment of responsibilities to components is that a component
> has a simple, one-sentence description of its responsibility, that is
> ideally free of conjunctions.

Accounting Service is there to do the bookkeeping similar to a bank that maintains a "log" and the current state of my bank account as well as of my depot. The DU (we originally called it balancing power provider) is the role that actually calculates the balancing power needs according to a procedure it implements. It might need to retrieve data (such as the real consumption etc.) from the accounting service and it might send "charging information" back to the accounting service so that the latter one can, for example, deduce some money from a broker's bank account.
 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Slight redefinition of roles + sample workflow for negotiating tariffs

grampajohn
Administrator
On 11/24/2010 10:29 AM, Carsten Block [via Power TAC Developers] wrote:

>
> Am 24.11.2010 um 15:52 schrieb grampajohn [via Power TAC Developers]:
>
>  > That will be fine as long as the balancing _process_ is not wrapped up
>  > in a big, complex component. That's what I'm afraid of in the
>  > "accounting service". Perhaps I still don't understand it. My test of a
>  > clean assignment of responsibilities to components is that a component
>  > has a simple, one-sentence description of its responsibility, that is
>  > ideally free of conjunctions.
>
> Accounting Service is there to do the bookkeeping similar to a bank that
> maintains a "log" and the current state of my bank account as well as of
> my depot. The DU (we originally called it balancing power provider) is
> the role that actually calculates the balancing power needs according to
> a procedure it implements. It might need to retrieve data (such as the
> real consumption etc.) from the accounting service and it might send
> "charging information" back to the accounting service so that the latter
> one can, for example, deduce some money from a broker's bank account.

That's good for now. We may have to refactor later once we more clearly
understand the information needs and clearing process for a balancing
market.

John
Loading...