DOPTEST

[javiarrobas]

This is for the development of the district optimization testing framework (DOPTEST), the natural extension of BOPTEST toward districts. I suggest having such a framework living in a branch of this repository for the moment, but we can decide to go for a separate repository if we find that that's not sustainable.

The main differences with respect to a regular BOPTEST case are:

• Addition of local electrical and/or thermal grids that allow for energy exchange between the buildings in the district.
• Addition of distributed energy resources other than buildings like a shared buffer tank or a shared heat pump.
• Possibility to overwrite pricing signals perceived by each household. This is needed since now each independent agent in the district may have competing objectives. We are still price takers for the net electricity exchange of the district with the wider grid.
• Computation of KPIs that assess both individual agents and overall system welfare.

Having BOPTEST functionality working with district models brings new interesting use cases, but also some design and technical challenges.

As use cases, we can think of:

• Controller developers focused on the operation of buildings. That is the same use case as the one of BOPTEST, but in this case, the controller developer can control separate dwellings that coexist in the test case. In this case, each dwelling is expected to be controlled individually, but having them share an electrical or thermal grid may lead to further insights like how the electricity intake/offtake of that dwelling affects the rest of the district.
• Controller developers focused on the operation of local thermal and/or electrical grids. I am thinking here of congestion management e.g. through curtailment of distributed energy resources.
• Aggregators that want to investigate technically feasible demand response settings and viable business models.

As for design and technical challenges, we can anticipate the following:

• Development of an integrated district model, in the first place.
• Extending the BOPTEST KPI Calculator and API as to return KPIs that assess the operation of each individual building AND the operation of the district as a whole.
• Decision on the measurement and input signals that are exposed to the user.
• Decision on the baseline controller. Particularly: should controllers react to pricing in the case of the baseline controller? That could be convenient for researchers investigating demand response that just want to deal with pricing signals and assume a coherent response reaction from buildings.
• Weather data needs to correlate with spot pricing data when studying the value of withdrawing electricity from the grid. That means that we need historical weather measurements to be consistent with the highly dynamic price signal used.

We can think of similar frameworks like CityLearn. The main difference is that DOPTEST will not focus on RL controllers and will be using detailed models for buildings, energy systems, and grids.

The figure below sketches the DOPTEST concept for the case of the tiny cluster with three buildings. This is a simplification and other signal exchange blocks are expected, but it is a starting point for conceptualizing the idea.

I suggest the following workflow for the implementation:

• [x] Creation of an integrated district model in Modelica. A tiny cluster of three dwellings as the shown below will serve as a starting point. Each dwelling is modeled as a single zone. We plan to use a particular model from the MoPED repository, which already configures district models with the characteristics required for DOPTEST. There is ongoing work in the MoPED repository to get to district models that are suitable for DOPTEST. Note that the models there are tested with OpenModelica, so having compatible FMU compiled with OpenModelica should not be a problem. We did not check yet the compatibility with pyfmi for simulation though.
• [x] Add DOPTEST as another BOPTEST testcase, without any modification of the BOPTEST framework itself. For this initial implementation, we use the model from the previous step. The model will be adapted to add one read power block and one read zone temperature block per building.
• [ ] Extend the API call for getting KPIs or create a new one that returns not only the final sum for each KPI but also the results by each source signal that leads to such KPI, which are readily accessible in the KPI Calculator through each case.kpi_dict, see e.g. the definition of ener_dict. This is needed to show the KPIs of each individual agent.
• [ ] To relax the assumption that each building is represented by a single zone, we may want to add a building label on the read blocks. This is more intrusive in BOPTEST functionality but would allow for buildings in the district modeled as multi-zone.
• [ ] Evaluate at this stage whether it makes sense to have DOPTEST being a branch of this repo or if creating a fully new repo is more convenient.

@dhblum I'll try to come up with an implementation of the first and second tasks of my list above by next week. I'll ping you then, to hear your feedback before moving forward. I may create a draft PR from my fork to a doptest branch here for convenience in reviewing the edits.

@lucasverleyen @hafeezSaeed96 @CasBex @louisher @yucunlu @attila-balint-kul FYI.

Please feel free to add any comments, ideas or suggestions that you may have.

[javiarrobas]

From a BOPTEST Project meeting on 14/02/2023 we have decided to keep DOPTEST as a separate BOPTEST fork (instead of a branch as stated above).

[P11GH]

Hi @JavierArroyoBastida how is doptest going? Is there a website?

[javiarrobas]

Hey @P11GH, thanks for showing your interest! I'm afraid we do not have a website yet. I would say we have covered the two first points of my comment above in a first test case prototype with the tiny cluster model. That work will be presented and published for the BS2023 conference, so try to stay tuned there. The modeling effort is taking place in the MoPED repository, and the actual implementation lives in this branch of my BOPTEST fork as of now. I plan to keep working on it in the coming months.

[P11GH]

Thank you very much