Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sign of payment appears to be incorrect in regulation-associated tariff transactions #1010

Closed
jecollins opened this issue Mar 3, 2019 · 2 comments

Comments

@jecollins
Copy link
Member

jecollins commented Mar 3, 2019

Normal tariff transactions occur when customers consume or produce energy. For tariffs with regulation rates, the payment/credit for regulation is specified in the regulation rate. Curtailable tariffs (INTERRUPTIBLE) can be used for up-regulation if the broker issues balancing orders against them.

In a TariffTransaction, the signs for energy and money are oriented to the broker's viewpoint -- negative values mean energy or money is flowing out of the broker's account, while positive values mean energy or money is flowing into the broker's account.

From the standpoint of a customer, positive values mean energy or money is flowing into the customer. So the normal case is that in a TariffTransaction, the signs of the energy value and the money value are opposite. A RegulationRate normally specifies a positive payment value for up-regulation (a customer is paid to produce energy or cut its consumption). This sign is then inverted when composing a TariffTransaction to represent the regulation event. This appears not to be happening for the TariffTransactions generated by regulation events. The transaction is generated in TariffSubscription.postBalancingControl().

In the logs from the 2018 tournament, it seems that the signs for payment in the regulation transactions are backward. The relevant test case for CapacityControlService also appears to be incorrect.

@jecollins
Copy link
Member Author

Correction: The test case for CapacityControlService appears to be correct. The balancing market produces signs in the opposite sense from the rest of the system, an artifact of the the original work by Mathijs.

@jecollins
Copy link
Member Author

This was happening because the method Tariff.getRegulationCharge() broke the assumption that all things tariff take the customer's view. Once this was fixed, two other sign manipulations in TariffSubscription and CapacityControlService had to be adjusted to properly convert from the customer view to the broker view..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant