Grid integration - Pyosch/powertac-server GitHub Wiki

For the co-simulation of Power TAC and the grid, a python-based grid model is integrated into the Power TAC simulation process. The grid model is based on the python package pandapower and a publicly available dataset on distribution grid topologies, also available via a python package. The grid model is capable of calculating (optimal) power flows of loads, generators and storages allocated to different nodes. The grid model's interaction with Power TAC is determined by two APIs.

1. Interaction of Customer Models and Grid (Customer-Grid Interface)

By this API the customer models are mapped to the grid. The grid model provides information on the size of the grid in terms of the number of nodes as well as the loads, generators and storages currently operated at these nodes. The information will be sent from the grid to power TAC via a json-file containing:

• Node ID
• Load/generator/storage at node alongside
  • Max. power
  • Min. power (other than zero)

Whilst the individual models can be allocated and adjusted to different nodes of the grid easily, the existing population models will be subdivided into instances of smaller size in the first place. In other words, we will have several instances or blocks of populations assigned to grid nodes for population models. The split is done in an iterative approach. At first, the existing population models are allocated randomly at different nodes of the grid. Then, a power TAC run is started creating a log file from which the models´ demand and generation time series are withdrawn. The time series are fed into the grid model and a power flow calculation gives an indication of how the population models need to subdivide to fit the grid´s capacity. Knowing the structure of the populations´ demand and supply and the resulting power flow, the population models are split into several instances of smaller size. Once this is done, the new instances are allocated in the grid and power TAC is started again, so the new demand and generation time series can be evaluated. If the resulting demand and generation of all population models have the same order of magnitude as the node they are assigned to, the matching is done. Otherwise, the process has to be repeated until a suitable configuration is found. As a restriction of this approach, each instance´s population size must not be smaller than 50 to 100 to make sure that the statistical performance of the population models is not affected. The described approach ensures that the multiple population model instances can act independently from each other and dependent on the node they are assigned to which might result in different preferences in tariffs. The API is defined by a json-file.

2. Interaction of Power TAC and Grid Model (Grid Model Interface)

The second API determines the interaction between Power TAC and the grid model and enables bidirectional information exchange. Power TAC sends information on the consumption and production behavior of the customer models for each of the loads, generators and storages at each node back to the grid model. The grid model runs an optimal power flow in order to manage arising congestions in the grid. The results of this optimal power flow are then sent back to power TAC via a json file. The API is designed as a domain service that is called by the server information. Thus, there is no direct link between the customer models and the grid model.

REST API for information exchange between the grid model and Power TAC

The grid model is running on a REST "server", implemented in flask on the Python side. This server needs to be started separately before running simulations with grid considerations. In the standard configuration, it can be accessed via localhost:5000/. This url can be extended with the specific requests mentioned below.

REST API for information exchange between Power TAC and the grid model

In order to implement the API, a new GridService is implemented following the implementation of the BalancingMarketService. The GridService extends TimeslotPhaseProcessor and therefore acquires phase 3 after the CustomerModelService, which was used for the BalancingMarketService in the previous Versions of powerTAC, without grid considerations. The BalancingMarketService therefore moves to phase 4 and the subsequent Services increase by one phase accordingly.

The phase of the GridService subdivides in the steps, depicted in the following figure:

After the start of phase 3, the customers at each node are requested from the Customer Repo. Afterwards, the current subscriptions of each customer are requested from the Customers. Along with the information about the subscriptions, the information about the amount of energy used and generated by each customer, as well as the available regulation capacity can be acquired from the TariffSubscription.

The REST server of the grid model is then addressed via an url request by power TAC. This call is designed in correspondence to the WeatherService, which requests weather information from a REST interface during the tournaments. The GridService calls an OpfRequester, which connects via an url request to the grid API on the Python side. During a synchronous request, power TAC sends a json-string to the grid model containing:

• Node IDs
• Load/generator/storage of customers at node alongside
  • Power value according to market clearing per customer
  • Max. power value depending on available flexibility per customer
  • Min. power value depending on available flexibility per customer
  • List of lists with the cost c between two power values per customer [[p1, p2, c1], [p2, p3, c2], …] (Additional Information)

Maybe we don't even need to provide min and max power seperately, since they would be in the list anyway

Within the grid model, this information is mapped to the corresponding energy resources in the model and an optimal power flow solves the congestions that may appear with the flexibility provided. The resulting power values for each energy resource as well as the flexibility used from each customer are sent to power TAC via a json-string. The resulting balancing control is then posted to the TariffSubscriptions in order to update the regulation capacity for the balancing control sequence. The price for the flexibility, used by the grid model during the optimal power flow, is determined by the regulation rates is the corresponding customer subscriptions.

Afterwards phase four with the balancing control starts. In this phase, the price for the remaining capacity is determined.

TBD: Within power TAC, the provided flexibilities are evaluated and charged accordingly.

Pricing A: During the phase four (BalancingMarket) the price for flexibility is cleared and applied for all flexibility that has been using during phases three and four. ->Problem with A: Where does the price for flexibility come from, if the DSO is not supposed to know details of the customers tariffs.

Pricing B: Change phase three and four. Clear the balancing market to get a price for the flexibility and then run the opf based on these prices. -> Problem with B: If the opf uses up too much flexibility, the price in the balancing market would be affected due to a smaller availability of flexibility.

------- Further Notes ---------

Grid information request

By extending the url of the REST server with ../gridinfo/<grid_element> Power TAC can request the information about the <grid_element>. Elements are for example 'sgen', 'load' and 'storage'. By retrieving this information from the grid model, the information for the adjustments of the customer models in API 1 can be adjusted.

The process between grid simulation and Power TAC:

- After phase 2, net consumption of customers and their flexible capacity are defined in Power TAC.

- Brokers offer tariffs with a regulation rate, this rate is what should be paid to subscribed customers for regulation. The price of customers’ flexibility in OPF would be the regulation rate that customers are subscribed to. Knowing available capacity for each customer and the associated price, grid simulation as OPF runs to dispatch the flexibilities in order to relieve the potential congestion. (output: scheduled regulation)

- Brokers also offer the same prices for regulation in the balancing market, yet the balancing market is cleared with a VCG auction and the clearing price for each broker might not be the same as what she offers. Therefore, brokers get paid the clearing price and will pay the customer the predefined rate for flexibility. This means that they can profit from the balancing market if the regulation tariff rate is lower than balancing market clearing price. (the quantity of regulation accepted in the balancing market should be subtracted from what is scheduled in grid simulation as leftover capacity)

- DSO should pay the cost of congestion management (any cost to relieve congestion) to brokers after clearing in the balancing market. Because it is an alternative for grid enhancement.

- At the end of this stage, leftover capacity would be scheduled to remove any imbalance.

This can be written in a table format as follows:

Messages required to exchange in API 2: grid model interface

Grid side	Power TAC side
NodeID	CustomerID
CongestionEvents	CustomerInfo:Consumption(production)
CustomerInfo : updated after OPF	CustomerFlex
SchedFlex: OPF schedules flexibility to relieve congestion	CustomFlexPrice:price for each flexible resource: regulation rate based on tariff

CustomerFlex: Up-reg. capacity--> EV/battery discharge, DR - Down-reg. capacity--> EV/battery charge