Consistent transaction semantics

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

Consistent transaction semantics

grampajohn
Administrator

Colleagues -

From the beginning, there has been confusion about when to use positive and negative numbers, about bids and asks, and now I've gotten confused about the meaning of market transactions (see issue #413). I think it's time to straighten this out. I can see three alternatives, all of which have been used at one time or another already in this project. My goal is to choose one of them and use it everywhere.

  1. Use flags in shouts and transactions to specify the direction of the transfer. This is currently done in shouts - if the flag says BUY, then a positive price and a positive quantity says that the issuers wishes to buy that quantity and is willing to pay that price. To use this approach consistently, we would have to use similar flags in tariff transactions and market transactions, and between customers and their tariff subscriptions.
  2. Use subclasses to distinguish between production and consumption, and between bids and asks. This approach was used in construction of orderbooks in the Grails prototype, largely because of constraints imposed by GORM. To use this approach consistently, we would need two types of tariff transactions, two types of market transactions, and Shout would become Bid and Ask.
  3. Use positive and negative numbers consistently everywhere, with a clear and unambiguous viewpoint. This approach is used in customer interaction with tariffs - if a customer uses a negative amount of power, that means they are producing power. To use this approach consistently, we need to choose a viewpoint, and use positive numbers to mean "credits" and negative numbers to mean "debits" for both money and energy. So a bid would be a shout with a positive amount of energy and a negative amount of money. A tariff transaction representing a customer's consumption would have a negative amount of energy and a positive amount of money (because transactions are all broker-centric). This way, one could collect all the tariff and market transactions for a timeslot, add up the money to get the net change in bank balance, and add up all the energy quantities to get the balance.

I am leaning toward the third alternative, because it seems the most clear and parsimonious alternative, but I would like your input before committing it to code. That would mean dropping the BUY/SELL flag in Shout, for example.

Thank you in advance for your thoughts

John

Reply | Threaded
Open this post in threaded view
|

Re: Consistent transaction semantics

Prashant Reddy
Hi,

I think it's difficult for broker and customer model developers to
always understand whose perspective is being used to determine
negative vs. positive in the various types of transactions.  If we
rely on perspectives, as we inevitably must I guess, I'd like to just
highlight the need for very clear and prominent documentation on this.

Also, it is occasionally possible at least in wholesale markets to
have negative clearing prices, correct?  In that case a buyer actually
gets a credit and the seller a debit.  I worry that it might be
confusing to infer those semantics using just negative vs. positive
values, although it's possible.  Developers may subconsciously be
inferring perspective or buyer/seller role based on whether the signs
for energy and money agree or disagree and that's not reliable.

Neither of the above concerns are show-stoppers for alternative 3, but
I wanted to raise them as possible sources for confusion.

Thanks,
Prashant
Reply | Threaded
Open this post in threaded view
|

Re: Consistent transaction semantics

markus
I think the choice of alternative depends on your design objective. A number of objectives come to mind, such as:

(A) Easy to implement on the server side
(B) Low-footprint in terms of the resulting messages
(C) Clear to understand on the client side

Personally, I like models that are explicit about every detail (C) as long as it is not seriously in the way of (A) or (B).

In that sense, I prefer options (1) and (2) from your original post. Both of them give you the ability to perform validations on the messages you receive (rejecting the purchase of a negative amount of energy, for example) which you do not get with (3).

In terms of domain semantics, I regard both, (1) and (2), as equally valid views of the real world. For simplicity reasons, I prefer (1) over (2).

Hope that helps,

Markus
Reply | Threaded
Open this post in threaded view
|

Re: Consistent transaction semantics

Prashant Reddy
I'm with Markus on using this principle:
    "Models that are explicit about every detail (C) as long as it is
not seriously in the way of (A) or (B)."

Prashant
Reply | Threaded
Open this post in threaded view
|

Re: Consistent transaction semantics

grampajohn
Administrator
In reply to this post by markus
Thanks, Prashant and Markus, for your thoughts. I'll respond by adding a bit more detail. I agree with Prashant that the perspective needs to be very clear if approach #3 is going to work. Markus suggests several alternative goals for a consistent solution to this problem, and I think his objective (C) is the most important. I would add ease of implementation for broker developers also, and I would say that clarity, rather than ease of implementation, is most important on the server side. I may not be the brightest bulb out there, but I've written a lot of the code, and if I'm still confused then it is not clear.

Let me make the case for alternative #3 - using positive and negative numbers consistently. First, there are just two viewpoints, customers and brokers (keeping in mind that a genco is a kind of broker), and they overlap in only one place, which is Tariffs. In addition to tariff specifications, brokers see tariff transactions, market transactions, bank transactions, balancing transactions, distribution transactions, orderbooks, cleared trades, and market positions, and have to generate shouts as well as tariff artifacts including rates and hourly charges. Customers must evaluate tariffs (but they do not need to see tariff specifications), and must use the tariff subscription api when producing or consuming power.

The idea behind alternative #3 is that each quantity in each of these messages represents an increment to either a money account or an energy account. So a "normal" market transaction, sent to a broker, that represents power transferred (in the future) from a genco to a broker, would have a positive amount of power, and a negative amount of money. Power comes in, money goes out. Assuming that the value of the power matches the amount of money involved, then the simple utility calculation for that transaction would be zero. A positive quantity in a market position would mean that power will be delivered to the broker in that timeslot. Similarly with a tariff transaction, a positive money amount means that the customer is paying the broker, putting money into the broker's bank account, and a negative energy quantity means the customer is taking energy out of the broker's energy account.

For tariffs and tariff specifications, we have a couple of choices: take the customer's viewpoint, or keep the broker's viewpoint. Currently, it uses a mixed viewpoint. Payments (for signup, early withdrawal, and periodic payments) take the broker's view - positive numbers represent credits to the broker. Prices are always positive. You have to look at the power type and do some logic to figure out whether the price will result in money coming from customer to broker or vice-versa. In a tariff subscription, customers input their hourly meter readings with usePower(), which takes positive numbers to mean consumption and negative numbers to mean production. This represents the customer's viewpoint with respect to their energy accounts. Negative usage numbers lead to negative money values through Tariff.getUsageCharge(), so a tariff transaction with positive kwh and money represents power flowing to the customer and money flowing to the broker.

So the current situation is confused, incomplete, and contains some inherent ambiguity. Solutions 1 and 2 will require multiple flags or types, which will have to be invented, explained. and coded for. If we were to adopt solution 3. I would recommend that all transaction types take the broker's viewpoint, and that tariffs and their associated rates and hourly charges take the customer's viewpoint. It would be the responsibility of tariff subscription to translate the customer's power-usage signal to a transaction that takes a broker viewpoint.

John
Reply | Threaded
Open this post in threaded view
|

Re: Consistent transaction semantics

Wolf
Administrator
I think approach 3 is a good solution, since we can just sum up all the numbers and get the right results, and it conveys a lot of managerial insights. Since in Power TAC the participants are the brokers, it is a good idea to conceptualize transaction types from their viewpoint, and to model tariffs from the customer side (since they will make the acceptance decision or not).  Further, this doesn't contradicted Markus's design objectives.

Cheers,

Wolf

Reply | Threaded
Open this post in threaded view
|

Re: Consistent transaction semantics

grampajohn
Administrator
Unless someone else volunteers to tackle this issue and get the code fixed and tested, I'm going to do it using option #3. Any takers?

John
Reply | Threaded
Open this post in threaded view
|

RE: Consistent transaction semantics

Wolf
Administrator

Please go ahead.

 

Thanks much!!!

 

Cheers,

 

Wolf

 

From: grampajohn [via Power TAC Developers] [mailto:[hidden email]]
Sent: Friday, 04 November, 2011 16:02 PM
To: Wolf Ketter
Subject: Re: Consistent transaction semantics

 

Unless someone else volunteers to tackle this issue and get the code fixed and tested, I'm going to do it using option #3. Any takers?

John


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

http://power-tac-developers.975333.n3.nabble.com/Consistent-transaction-semantics-tp3477182p3480338.html

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



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: Consistent transaction semantics

grampajohn
Administrator
In reply to this post by grampajohn
Does anyone object to the name "Shout" being changed to "MarketOrder"? The current term has always required some explanation. As long as I'm working on #414, this would be a good time to make the change.

John
Reply | Threaded
Open this post in threaded view
|

Re: Consistent transaction semantics

Wolf
Administrator
No objections, this avoids the confusion.

Thanks,

Wolf

Sent from my iPhone

On Nov 4, 2011, at 20:07, "grampajohn [via Power TAC Developers]" <[hidden email]> wrote:

Does anyone object to the name "Shout" being changed to "MarketOrder"? The current term has always required some explanation. As long as I'm working on #414, this would be a good time to make the change.

John


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


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: Consistent transaction semantics

grampajohn
Administrator
In reply to this post by grampajohn
grampajohn wrote
Does anyone object to the name "Shout" being changed to "MarketOrder"? The current term has always required some explanation. ...
Actually, this is probably a bad choice of terminology, because a "market order" commonly refers to an order without a limit price, as opposed to a "limit order". Now that we are not using a SQL database, I think it might be best to just use the term used throughout the industry, which is simply "order".

Does anyone have an objection to this, or a good alternative?

John
Reply | Threaded
Open this post in threaded view
|

Re: Consistent transaction semantics

chris.flath
From what I remember the original introduction of the term "shout" stems back to the term "order" being reserved by Grails. So if this is not an issue it makes a whole lot of sense using "order".