Initialization of regulation factors

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

Initialization of regulation factors

rcarlier
Hi all,

I have been working with PowerTAC (distribution 1.4.1) for a few months, mainly with broker tariffs and pricing.
I have noticed an issue when varying the regulation rate of a tariff. I was looking for the impact of these 2 prices (up and down regulation payment) on the choice of customers and found none.
I looked into the server code and found that the TariffEvaluatorHelper's estimateCosts method uses the parameters expCurtail, expDischarge  and expDown. These are initialised by the method initializeRegulationFactors in this class, which is called by the same method in the TariffEvaluator.
Now this initialization is only called by the customer models ColdStorage, BatteryStorage and LiftTruck. Evcustomers, offices and villages don't initialize the values and keep the default 0 for the 3 parameters, despite all being capable of regulation to some extent. Therefore they never include regulation cost in their evaluation of tariffs.
I have read section 4.1.1 of the specification several times. I'm still unsure this is intentional. If it is, could someone explain the reasoning?

Thanks
Reply | Threaded
Open this post in threaded view
|

Re: Initialization of regulation factors

grampajohn
Administrator
rcarlier wrote
... this initialization is only called by the customer models ColdStorage, BatteryStorage and LiftTruck. Evcustomers, offices and villages don't initialize the values and keep the default 0 for the 3 parameters, despite all being capable of regulation to some extent. Therefore they never include regulation cost in their evaluation of tariffs.
I have read section 4.1.1 of the specification several times. I'm still unsure this is intentional.
Thanks for pointing this out. The three models that are initializing the regulation parameters are the ones I wrote. I guess I never went back and set them in the other models. I have created Issue #944 to track this problem. I probably won't have time to work on this until late next week. When I do, it will be in version 1.5.0-SNAPSHOT, not in 1.4.1. I hope that's OK.

John
Reply | Threaded
Open this post in threaded view
|

Re: Initialization of regulation factors

rcarlier
Thank you John for clearing this up.
I'll be looking for forward to version 1.5.0!
Reply | Threaded
Open this post in threaded view
|

Re: Initialization of regulation factors

rcarlier
In reply to this post by grampajohn
Hello again.

Could you explain how good values are determined for these parameters?
For Battery, the corresponding code makes some sense
tariffEvaluator.initializeRegulationFactors(0.0, maxDischargeKW * 0.5, maxChargeKW * 0.5);
For ColdStorage and LiftTruck the reasoning is more obscure.
I am also curious about the customer models where it was missing.

I would also appreciate a clarification about these parameters. If I'm not mistaken, they reflect the customers' prediction of how much their capacity will be regulated. It seems to me they are not in a good position to predict this, especially with a fixed value, as regulation depends on the balancing market's decisions. Perhaps I am forgetting some constraints customers can impose on how much their capacity can be regulated.

Thanks in advance.
Reply | Threaded
Open this post in threaded view
|

Re: Initialization of regulation factors

grampajohn
Administrator
rcarlier wrote
Hello again.

Could you explain how good values are determined for these parameters?
For Battery, the corresponding code makes some sense
tariffEvaluator.initializeRegulationFactors(0.0, maxDischargeKW * 0.5, maxChargeKW * 0.5);
For ColdStorage and LiftTruck the reasoning is more obscure.
I am also curious about the customer models where it was missing.
I had a long talk today with Govert and Erik on this. So far, the values in the three models are educated guesses, based on knowing how they work in detail. But they are not principled values. The configured values are in kWh, and represent the customer's expectation of how much regulation might be called for if they sign up for a tariff with regulation rates. There are a few assumptions built into these numbers, starting with an assumption that the average imbalance to be resolved is close to zero -- in other words, on average, up-regulation would be called for as often and with similar quantities as down-regulation. So if you look at the battery case, it expects to be able to offer its maximum charge/discharge rate every time it's called on to regulate, and on average half of the time it will be up-regulating and half the time down-regulating. That's where the 0.5 numbers come from.

The other models don't have this feature because they were written before we worked out the details on how customers could evaluate tariffs with regulation rates.
I would also appreciate a clarification about these parameters. If I'm not mistaken, they reflect the customers' prediction of how much their capacity will be regulated. It seems to me they are not in a good position to predict this, especially with a fixed value, as regulation depends on the balancing market's decisions. Perhaps I am forgetting some constraints customers can impose on how much their capacity can be regulated.
Regulation happens based on several factors:

- The customer has subscribed to a tariff with RegulationRates,

- the broker has issued a BalancingOrder against that tariff, and

- the customer has reported its current regulation capacity to the balancing market.

The customer capacity reports are issued in each timeslot when requested by the market. They represent the capacity in kWh for up-regulation (curtailment plus discharge) and for down-regulation (charge). So the customer controls these values, and in many cases (other than the batteries) they are not the full capacity. Obviously, a water heater cannot up-regulate if it's not currently running or if it's at its lowest allowable temperature, and it cannot offer down-regulation if it's currently running or if it's already at its maximum temperature. So the numbers are affected by the model details, such as the duty cycle of the heater/cooler, the proportion of time the EV is connected, the rate of energy usage outside of regulation, the energy lost in the regulation process (battery efficiency), etc. Some are big enough to worry about, some not so much.

We decided to work out a formula that can be generally applied and add it to the documentation. That will take a few weeks at least. Then we'll compute the "right" numbers and add them to the configuration. Unfortunately, the biggest model set, factored-customer, is currently not set up to handle regulation at all, so that will take longer.

Hope this helps -

John

Reply | Threaded
Open this post in threaded view
|

Re: Initialization of regulation factors

rcarlier
That was very enlightening, thanks.