WEBVTT 00:00.000 --> 00:13.360 Hello everyone and thank you for coming. Today I will introduce you the tool that we use internally 00:13.360 --> 00:22.160 at RTE and that's also open source. In the back, can you hear me? Can you hear my voice? 00:22.560 --> 00:28.960 louder? Okay, a bit louder. So today I will introduce Antaresimulator. 00:31.040 --> 00:39.600 So yeah, it's a tool that's been open source since 2018. It changed license. So at first it was 00:39.600 --> 00:49.920 under it was license under GPL but then it changed to something like MPL for reasons that I can't 00:50.000 --> 01:02.080 explain but yeah. So first I will introduce hi-tworks. So the idea is very simple. You have a set 01:02.080 --> 01:13.120 of interconnected areas. So a network that can be countries or regions. Whatever you prefer. 01:14.080 --> 01:22.640 And on each of these areas, you have some power consumption like residential, industrial, 01:23.440 --> 01:31.440 cars, electric cars. On some areas, you have some dispatchable production. So production 01:31.440 --> 01:41.200 that you can control. With technical limitations, for example, you cannot start a nuclear 01:41.280 --> 01:50.160 reactor instantly. And you also have some non dispatchable production and more and more of it, 01:51.600 --> 02:01.200 which cannot be controlled or very, very little. We also have links in interconnecting the different 02:01.200 --> 02:07.440 areas. We've also some limitations on the flux, on the important export capacity. 02:07.840 --> 02:17.840 So the modeling is very simple because it's aimed at very long-term simulations. So we keep it 02:17.840 --> 02:25.520 simple. We don't have non-linear stuff and things like that. It's just linear optimization in the back. 02:28.640 --> 02:36.560 So the basic equation is the following. It's the balance constraint. So for each area you have to 02:36.640 --> 02:44.800 produce enough energy to satisfy the load. But you can also use, you can also import some 02:44.800 --> 02:56.000 energy if you need it and you can also export. So if you have too much. And yeah, I have to talk 02:56.000 --> 03:03.920 about the two terms in red. So the unsupply energy and the spill energy. So these are how to say 03:04.720 --> 03:12.160 slack variables. So we give our system a little bit of slack because if we don't introduce these variables, 03:12.160 --> 03:19.200 we get infeasible problems, problems that have no solution. And our users basically they like it 03:19.200 --> 03:25.520 when there's no unsupply energy or as little as possible because it means that the electric system 03:25.520 --> 03:35.920 is correct is adequate. And spill energy is the contrary. So we have to produce too much. 03:35.920 --> 03:43.520 For example, non-dispatible energy and we cannot evacuate that production to the into the network. 03:44.800 --> 03:51.040 This is a problem as well, but not in general, unsupply energy is much worse than spill energy 03:51.360 --> 04:05.920 for our users at least. So the idea is, well, we get a lot of data from climate scenarios, 04:05.920 --> 04:14.880 from load, wind, solar, some of these are connected. And so we establish Monte Carlo scenarios 04:15.840 --> 04:25.280 and we also have some data coming from energy producers like outages, maintenance scenarios 04:26.480 --> 04:37.520 and also inflows for lakes, rivers concerning the hydrogeneration. So we mix all of these together 04:37.600 --> 04:48.000 with some consistency to establish some scenarios, a lot of them. In general, it's 1,000 scenarios, 04:48.000 --> 04:58.400 but sometimes it can be more or less. So I really like this explanation. So we take one scenario 04:58.400 --> 05:04.240 for load, one scenario for the wind generation and so on. And these are linked, one scenario for 05:04.240 --> 05:12.640 hydro and so on. And so we mix them to establish years. So a year is actually a Monte Carlo scenario. 05:12.640 --> 05:20.400 Years are independent. So there is no memory. There is no memory between one year and another. 05:22.720 --> 05:31.760 So it helps us for parallelization. For example, we can parallelize years. So it's really nice for us. 05:34.240 --> 05:45.440 And then we can have some curves, some stochastic results because all of this is probabilistic. 05:46.160 --> 05:59.280 And for example, the expected loss of load or such indicators. Our users, they watch these 05:59.280 --> 06:11.840 peaks very, very carefully. I didn't talk about unit commitment. It's quite technical, but it's 06:11.840 --> 06:22.000 about simulating the how the dispatchable production works and how it is how we start some 06:22.000 --> 06:33.040 thermal clusters in order to satisfy the demand. So we have quite a few users and reference study. 06:34.320 --> 06:39.040 For example, internally at RTE, we have winter and summer outlook that are done with 06:40.000 --> 06:47.600 Ontaris simulator. So these studies are used mainly in order to 06:49.680 --> 06:57.360 assess the adequacy for the next season. So this would be not long term, not so long term, but medium term. 06:58.960 --> 07:07.040 We have the French adequacy report, which is more like a legal obligation on our part of the French 07:07.120 --> 07:16.640 DSO. So we have to publish a report every, I think it's every two years in order to comply with our 07:16.640 --> 07:25.280 legal obligations. We also have some R&D studies about electric vehicles. We continue to read stuff 07:25.360 --> 07:38.400 like that. How do you say? Innovative topics. And then a lot of studies also European studies, 07:38.400 --> 07:42.960 because since Ontaris is open source, it can be used in European studies. There's no need for 07:42.960 --> 07:50.400 to pay for licenses and stuff like that. So anyone can use it, considering they have the ability to 07:50.400 --> 08:01.440 use it. And finally, we RTE published a report on Energy Pathways, 2015. That was in October 2021. 08:02.240 --> 08:10.000 And this report is quite big. Actually, it's a big, a big book, I have it on my desk. 08:10.720 --> 08:21.600 So it's, well, is it all what I said? So it established six scenarios and around that 08:22.400 --> 08:33.360 tries to, how to say. To explain what will happen in each of those scenarios, how much they 08:33.440 --> 08:42.160 will cost to the taxpayer, how much materials are going to be used and so on and so forth. 08:47.280 --> 08:55.920 So during the remaining time, I will talk about next features for Ontaris. So we have, 08:56.800 --> 09:06.480 for a long time, we've had an old legacy GUI, which was written in C++. Surprisingly, 09:06.480 --> 09:17.280 our users like the old one. They are kind of used to it, but we're trying to migrate to a web-based 09:17.920 --> 09:25.120 interface. So we had a project a few years ago. We started a project a few years ago that was called 09:25.120 --> 09:33.440 that is called Ontaris web. And it offers nice features like this variant manager. It looks like 09:33.440 --> 09:41.120 a GUI tree for some of those dollars familiar with GUI, except for Ontaris study. The reason was that 09:43.600 --> 09:51.920 studies are quite large, a few gigabytes of data and they're often deplicated. If you only 09:51.920 --> 10:01.680 just want to change a small subset of data, you have to copy the whole study and make a copy 10:01.680 --> 10:10.720 and then you make 100 copies and then your server is full. So we wanted to avoid this by having 10:10.720 --> 10:20.320 this variant manager where you can actually change what you want and avoid the duplication. 10:22.000 --> 10:28.640 There's also this system map, nice system up, that allows to navigate the whole system. 10:28.640 --> 10:32.800 That's not really a new feature, it already existed, but it looks nicer on the web interface. 10:36.400 --> 10:45.120 And finally, we have a task manager, so it allows us not only to launch simulations remotely 10:45.200 --> 10:51.440 on a central server. Actually, in this case, it's a slurm cluster. If I'm not mistaken. 10:52.560 --> 10:59.120 So we're trying with this Ontaris web tool, we're also trying to migrate from desktop to 11:00.240 --> 11:10.400 more like something more centralized. What tells can I say? We're probably going to be using 11:10.480 --> 11:18.080 the cloud a lot more in the future because it's more efficient. We can run a simulation like 11:18.080 --> 11:21.600 10 times faster because they have super powerful clusters. 11:27.200 --> 11:35.440 Another change is what we call the modular. So up until now, if we want it to add a model, for example, 11:35.440 --> 11:43.200 like I don't know a battery, we had to change the code. It's not so convenient because the code is 11:44.960 --> 11:55.040 a bit old, it's in French, and we need a developer to do that task. However, we're trying to move 11:55.040 --> 12:04.240 to configuration-based models. So we write down the equations, not in a C++ file, but in a 12:04.320 --> 12:11.440 YAMO file, and so it allows the users to write their own models without relying on software developers 12:12.240 --> 12:21.520 in theory. That's something that we're developing right now. We had a Python prototype first, 12:21.520 --> 12:26.480 it works pretty well, and now we're making it porting it into C++. 12:26.560 --> 12:37.040 And one of the difficulties will be to have hybrid simulations with the old model here, 12:37.040 --> 12:43.600 the old models static, a cloud-based. We're going to have both these and these into the same 12:43.600 --> 12:53.200 simulation. So that's one complexity. We have multiple repositories, one for an entire simulator, 12:53.280 --> 12:59.280 one for an entire expansion, which I didn't mention. We have some documentation available. 13:01.600 --> 13:08.160 And also, I would like to mention that our study dairy and RTE international provides trainings, 13:08.160 --> 13:16.240 as well as SAS for an entire S. So yeah, you can contact them at this address, if you would like to. 13:16.560 --> 13:22.560 Any questions? 13:22.880 --> 13:24.880 Who is? 13:30.320 --> 13:35.520 Thank you very much for the presentation. A quick question about the dynamic models. 13:35.520 --> 13:36.080 Yeah. 13:36.080 --> 13:40.480 Do you mean that dynamic models are the same? You're running the simulation. 13:40.480 --> 13:46.480 They have a outcome that happens, so you can re-configure the model of the simulation 13:46.560 --> 13:52.560 to run the simulation. Do the simulation use dynamic addition on the expansion of nodes 13:52.560 --> 13:58.080 during the simulation, or do you have a outcome to change the model and start the new simulation 13:58.080 --> 13:59.920 with the data assembly? 13:59.920 --> 14:06.080 Okay, the quick. The question was about dynamic models. If it's going to 14:07.440 --> 14:12.480 actually reconfigure the simulation, the model during the simulation, or if not. 14:13.040 --> 14:21.040 The answer is no. This only allows us to configure the models beforehand, before running the simulation. 14:21.520 --> 14:32.720 We'll look at the variance on that. You have independent years. Can you have the network changing 14:32.720 --> 14:37.440 over time for you just running different contact all those on the same? 14:37.440 --> 14:41.440 For now, the only thing that changes is the data. The network is fixed. 14:42.000 --> 14:52.480 Sorry, the question was, can the network change the question was, can you have the network change over time? 14:52.480 --> 14:56.400 And the answer is no, you can only have the data associated to the network change. 14:58.400 --> 15:00.400 And I think times up.