search

powertac / powertac-server

Power TAC simulation server
www.powertac.org
Apache License 2.0
44 stars 35 forks source link

Some balancing transactions fail to update corresponding consumption transactions #1154

Closed jecollins closed 8 months ago

jecollins commented 1 year ago

A customer that participates in the balancing market does not appear to have its production/consumption transactions updated correctly when the balancing market issues BalancingControlEvents to exercise that capacity. Here's the basic scenario:

  1. Customer subscribes to either an INTERRRUPTIBLE_CONSUMPTION tariff or to one that includes a RegulationRate .
  2. In timeslot t, customer consumes c kWh, and generates a TariffTransaction against its subscription. The transaction states the consumption c and the cost p.
  3. Later in timeslot t, the balancing market runs, and chooses the customer's BalancingOrder which was generated either by the broker directly or as a result of offering a tariff with a RegulationRate. The balancing market issues a BalancingControlEvent, which specifies the amount and the price. This gets sent to the broker, and a TariffTransaction with the regulation flag set to true is posted to the AccountingService and also sent to the broker. Both the initial TariffTransaction and the regulation transaction update the broker's bank account.

The problem is that the cost of initial TariffTransaction is not updated to reflect the actual energy use in that timeslot. So the customer is charged the full amount even if half of it was taken back later in the same timeslot by the balancing event. The energy accounting seems correct, but the cash accounting seems incorrect at this point.

jecollins commented 1 year ago

The fix for this would be far simpler if we eliminate "tiered rates" in tariffs. As far as I know this feature has never been used, and the way it's implemented in Power TAC is fairly different from the real-world examples we were attempting to emulate.

jecollins commented 1 year ago

After removing support for tiered rates, the obvious fix is to find the original transaction and modify it. However, that approach fails to leave straightforward evidence in the state log. TariffTransactions are supposed to be immutable data objects. If we make them mutable, we'll need to log the changes to the values of kWh and charge. If we do that, analyzing logs could be complicated, but it has the advantage of showing the original and changed values (or rather the ratios by which they were changed). The alternatives seem worse: (a) log the TariffTransaction when it's processed in AccountingService rather than (or perhaps in addition to) when it's created, or (b) Create a new TariffTransaction to replace the original and somehow record which transaction was superseded. For now we'll log the updateValues(ratio) method.

jecollins commented 8 months ago

Resolved.