Hello everyone, I'm Peter Mitri, I'm a software developer at RTE, the French TSO.
So today I'm going to speak to you about two open source tools to software that help us
optimize and share the operational cost of the European grid.
The first part of the presentation I will focus on optimization.
So I will talk about what we call the regional operational security coordination and remedial
action optimization.
In this part I will introduce the open source software which is called OpenROW.
In the second part I will talk about cost sharing through flow decomposition and in
this part I will talk about the open source software which is called flow decomposition.
I try to keep as much time as possible in the end for questions.
So yeah, I hope you have some questions.
Great.
So let's talk about first of all why we need to optimize the grid.
So I understood that many of you work in the energy sector but some don't.
So we talked a lot about congestion management in the previous presentation.
So here I'm going to try to set the scene and explain what a congestion is.
So as you may know electrical equipments in the grid have physical limits.
Outside of these limits the equipment is not safe to operate.
So for example a power line which transports electricity from point A to point B has a
thermal limit.
If we exceed this limit, if we transport too much power on this line, the line may heat
up, it may deform, it may even catch fire and of course it's pretty dangerous.
So to help set the scene, imagine here that you have a small grid or a small part of the
grid which is represented in three nodes.
So the nodes would be like sites where consumers and producers are connected to the network.
And between these nodes you have power lines which are in black here.
And let's imagine that you have most of power production on the left side and most of power
consumption on the right side.
So most of the power will flow from the left to the right.
Let's say that we have a consumption increase on the node here to the right.
Then of course the flow will increase from the left to the right and depending on the
network's topology it may very well be asymmetrical.
So we may have more increase of the flow on the bottom part here.
And we may find that the flow, the new flow that is on the line here exceeds its limit.
So this is what we call a congestion.
Of course there's not just the question of consumption and production, there is also
some accidents that can happen in the grid and that can lead to congestions.
So here you have an example.
If we lose the line that transports electricity from here to here, then most of the power will
flow through this line and this can lead to congestion on the upper line.
As a TSO, RTE has the responsibility to be robust to all eventual incidents on the network.
So we have to do something about these congestions.
So what can we do?
Fortunately we have what we call remedial actions.
So these are actions on the network that can serve one of two purposes.
The first purpose would be to redirect the flows on the lines.
So for those of you who work in the electricity sector, you may know them as topological actions,
HVDC actions or phase shift transformers.
I'll talk about them in an example in the slide that follows this one.
There's also another type of remedial actions which acts on the injections.
We call that either redispatching or counter trading.
These are actions that will change the power production plan of the producers.
In general, the first part of remedial actions which redirect the flows are called non-costly
because the only cost to operate them is the aging of the equipment.
The TSO has power over these remedial actions.
And the second type of remedial actions is costly because when we ask consumers or producers
to change their injections, we pay them for their service.
So to help set the scene, this is an example of non-costly remedial actions.
So here in the example above, we have the base case where no remedial actions applied.
So let's say that you have a congestion in the line here.
One first type of remedial actions is the topological action.
So let's say that you can split this node here into two nodes.
This will make the power flow equal on both lines, this one and this one.
And then it will relieve this line here and then we would have relieved the overload or
the congestion on the network.
Another type of remedial action is the phase shift transformer.
So let's say that we equip the line here with a phase shift transformer.
This kind of equipment is able to shift the phase of the current on the line and so act
on the active power flow and so it can relieve the congestion on the line.
The second type, in the second family of remedial actions, which are costly remedial actions,
this is maybe actually easier to understand.
What we can easily do is to call a producer which is on this node, a power plant, and ask
them to decrease their production and ask a power plant that is here to increase their
production.
So naturally this makes the power production closer to the consumption site and it reduces
the overall flows on the network and by consequence it relieves the congestion on the line.
The key difference here is that power plants 1 and 2 get paid for their balancing service.
The fact is that Europe's electricity grid is highly matched, interconnected and synchronous.
So for example if you have an incident in France it is instantly measured in Romania.
Thus the security of the network is no longer a national one, it's a European one, it's
a global one.
So TSOs have to conduct coordinated computations to ensure that the European network is secure.
This is why the Acer, the Agency for Cooperation of Energy Regulators, imposes on TSOs to conduct
what we call the regional operational security coordination.
So in this process TSOs must choose the best remedial actions on the European scale to
implement in the network in order to ensure that it is secure.
Of course it's a large escape problem so we can hardly do it by hand.
That's why we need an automatic tool which is called the RAU or the remedial action optimizer.
The RAU will have to choose the most optimal remedial actions in a given perimeter and it
also has to do so by minimizing costs that are imposed by cost remedial actions.
So using an open source RAU has many benefits.
First of all transparency because we are in a European perimeter.
So what better way to be transparent about what the RAU does and which cost remedial
actions it selects than to put its code in open source.
Given of course that it's well documented.
It also serves the purpose of coordination because this way when we put a tool in open
source different TSOs from different countries and different vendors from different countries
can cooperate more easily.
It also serves robustness, interoperability, it also serves reusability and time to market
because when a tool is used in many business contexts it becomes more versatile, it becomes
more robust and it becomes quicker to deploy.
At RTE we have developed an open source remedial action optimizer called the possible open
RAU.
So for those of you who may be know it it was called FARAO in the past.
The journey started in 2019 but two weeks ago we made the move to possible open RAU
and we did this because we wanted to join the Linux Foundation energy adventure because
LFE provides a clear governance for which all contributors accept to abide and it also
provides a clear methodology to work more efficiently and in better intelligence.
Open RAU is actually used internally at RTE but also in many European processes.
So I talked about regional operations security coordination or ROSC.
Open RAU is being implemented for the SWE region here which covers France, Spain and
Portugal.
It is already in operation for another process which is called capacity calculation on the
Italy North region and on the Co region which is actually the largest region in Europe to
conduct the coordinated computations.
It covers around a dozen countries.
A few words about what our RAU can do.
So it's an optimizer so of course it has to have an objective function.
It can either minimize the worst congestion or remove all congestion in the network.
About congestion we can model flow congestion and we can optimize flow congestion.
So this is the example I talked about in the previous slides.
We can also model voltage magnitude constraints and voltage angle constraints but for now
the RAU cannot optimize them.
It can only monitor them.
For immediate actions we can optimize phase shift transformers in a given range.
So the RAU if you give it a range of possible tap positions for the phase shift transformer
it will choose the most optimal one that reduces congestions over the whole network.
You can optimize an HVDC set point so it can change the set point of the HVDC to reduce
constraints.
It can also choose to activate or not activate some topological actions.
For example closing a switch or opening a switch.
It can optimize a subset of redispatching remedial actions so actually a redispatching remedial
actions are pretty complex and actually an open RAU would just have a subset with strong
limitations.
Also it can optimize a subset of shunt compensator actions and it can for now only model counter
trading remedial actions but we do not support optimizing them in the RAU.
So of course like I said open RAU is used in the multiplicity of business context so
it is very versatile.
It has a lot of ways you can use it by changing the input data or by changing its parameters
so if you need more information you can look on our website for all the ways it can be
used.
Under the hood the open RAU software is licensed under Mozilla public license 2.0.
It's hosted on GitHub and the code is written in Java 17 so we use JUnit for unit testing
of course we use Mavin for dependency management.
We monitor the quality of the code on Sonoma cloud and we're pretty happy with our figures.
We publish the code on OSS Sonotype and we rely closely on the possible library to be
able to model the network and to simulate it in particular to use sensitivity computations
and load flow computations.
We also this specificity of the RAU we also use Google OR tools.
I don't know if you know it but it's an open source modelization library for linear problems
developed in open source by Google and through it we can support a multiplicity of linear
solvers.
For now for example we have skip which is an open source solver also CBC but also we
can support express GROB Cplex which are commercial ones.
As a side note we tested that open RAU is compatible with Docker Jenkins Kubernetes and Cucumber
testing.
So in conclusion I'd be more than happy for you to participate in our RAU adventure either
by using it and giving feedback or by contributing to the project.
So the best way to join the adventure would be to join the possible Slack team and then
to join the RAU channel.
And there is also a quick tutorial on Java if you want to play around with the RAU on
our website.
And if you want to know what the future of the RAU looks like the roadmap is updated
once per month and it is discussed during the possible TSC which you are free to join.
I'm moving on to the next subject which is decomposition and cost sharing.
So I'm going to set the scene with a small example here.
Imagine that you have three zones.
Let's say there are three countries A, B and C. Imagine that you have big bow production
in the north of A and big power consumption in the south of A. Then naturally you'd expect
the power to flow from north to south so from producer to consumer but in reality it's not
so simple.
Any part of this commercial exchange, the power that is sold to the consumer, only
part of it will transit through the internal lines of zone A and the other part will go
through zone B then to zone C and then to zone A to the consumer.
So of course the consumer got the power they needed but some of the power went through
zones B and C.
We call these loop flows or polluting flows.
So the commercial exchange is simply the sum of internal flows plus loop flows.
And we say that they are polluting because they transit through zones in which they are
not consumed.
So as you can imagine more loop flows in the polluted zone means more loads on the zone's
internal grid.
It means eventually more remedial actions to implement possibly costly and this leads
to more costs for dispatching and counter trading.
So in the core region alone we have up to 3.7 billion euros per year of dispatching and
counter trading.
And of course loop flows are a reality.
They are a consequence of the topology of the network.
We can do nothing about them.
We cannot eliminate them.
However we can compute them and we can better share costs when we know where they come from.
So the Acer again the European regulator defined a clear methodology of computing loop flows
in the core region and this methodology is followed by a methodology to better share
costs between TSOs.
Of course using an open source tool has all benefits here and most of all transparency
because when you talk about sharing costs we talk about TSOs having to share the bills
and being transparent is very important.
At RT we developed a tool which is called possible flow decomposition.
It follows the Acer methodology so you have the documentation for it here.
And it has both a Java and a Python API.
Under the hood it's almost the same as the row so MPL 2.0.
It's developed in Java.
It uses Mavin.
It's hosted on GitHub.
It uses a lot of computations thanks to possible for load flow computations.
And most importantly it's already supported in our PyPossible API.
That's it from me.
Do you have any questions?
So maybe I wasn't paying enough attention.
Can you, so the purpose of your system is to allow you if something happens like whatever
that thing on the Pyrenees a couple of years ago for the whole system to react appropriately.
But you were showing that you're doing subsets to the computations.
I didn't understand in an emergency.
Presumably everyone needs to do something right at the same time.
The whole network.
However far the effect propagates.
So what was happening there?
What happens in an emergency versus whatever you were showing on the screen with doing
computations of various regions?
This is not really an engine that is supposed to help decision making in real time.
It's supposed to be used as an optimizer for the grid.
For example, in the regional operations security coordination, TSOs have like a photo of the
grid in the day ahead.
So 24 hours before real time.
We merge the whole grid models of different TSOs.
We conduct load flows and then we see if there are any congestions.
If there are any congestions, then we run a remedial action optimization.
The optimizer with us, okay, I found these non-costly remedial actions and these costly
remedial actions that will make the network secure.
24 hours ahead.
24 hours during the day, but it's not supposed to tell the operator which remedial action
to choose.
This is another, this is really apart from balancing.
And if you, if we go back to the example where I showed balancing, something that resembles
balancing, what we should do here is every time we change production somewhere, we have
to, so if we decrease the production here, we have to increase the production here because
the TSOs do, anyway, when we handle congestions, we cannot change the balance of the network.
So the balance between demand and offer is handled in another process.
Hello, I have a question about how much resolution you need to see into each of the grids in
order to actually make some of this.
Could you talk a little bit about the visibility that's required at the TSO level or beneath
it, for example?
Depends on the process.
So in the regional security coordination, we look at high level voltage, so 200 kilovolts
and 400 kilovolts.
And basically all big production hubs are on this voltage level, but this is a really
generic remedial action optimizer, so we can generalize it to whichever resolution we need.
Any other questions?
Is there some ideas to change the software for real-time congestion management, like
for DSOs or for other systems?
Yes, some experimentation is underway for balancing in order to be able to find creative
remedial actions in real-time.
So for now it's not an operation, but it's being experimented.
So my question is about impact.
Have you noticed that over European TSOs are using your software as well?
Is that the goal in the end to share among different TSOs as the Europeans can?
For now we are the only TSO using the RAL internally.
However, here it is Coriso, which is the computation coordinator that is using OpenRAL for these
three regions.
And also the idea of joining the possible project is to be able to develop a Python
API pretty quickly and to be able to have more users in different TSOs.
What kind of algorithm is used in OpenRAL?
We have an optimization algorithm, so a linear optimization algorithm.
I have a few slides in the appendix for this.
We can talk about it later if you want.
But basically it's a search tree in which we optimize the topological actions and inside
after every topological optimization we run a linear program to optimize linear remedial
actions.
These are remedial actions that have a linear effect on flows, for example, PSTs and HVDCs.
How do you test it?
How do you ensure that there isn't a bug that affects all OpenRAL instances running simultaneously?
With this, if it answers your question.
We have a lot of input files and expected output files.
And with this stack, with Docker, Jenkins and Cucumber, Cucumber is a framework for functional
testing.
So you write scenarios in a Gherkin language.
You say, for example, given this input file for the RAL, then I expect that there is no
congestion at the end and that this remedial action is activated.
You write it in a very natural language.
And of course there is code to run these things.
And then we put that in a Docker and in Jenkins and we run this every night upon almost 500
scenarios.
And every night we are sure that our main branch on GitHub is still solid.