WEBVTT 00:00.000 --> 00:08.400 It took a while. Thanks everyone. Thanks for joining this little hot-on 00:08.400 --> 00:12.840 Pipesaw. My name is Lucas Tripple. I'm a research software engineer at 00:12.840 --> 00:16.200 Teo Berlin, and they're from Brown School who is leading the development 00:16.200 --> 00:22.000 Pipesaw since now 10 years. Let me give you a very quick introduction 00:22.000 --> 00:26.600 of what is Pipesaw doing and energy system modeling in general before I start with 00:26.600 --> 00:31.600 what is new inversion 1.0. What Pipesaw users are interested in is 00:31.600 --> 00:35.600 basically understanding all the dynamics of the large scale energy system. 00:35.600 --> 00:41.600 Especially if we have tons of renewables in there. They depend on 00:41.600 --> 00:45.600 there's a lot of spatial and temporal dynamics. They're not available all the time. 00:45.600 --> 00:50.600 We have loads and demand which could change. We have, if you're running a sector 00:50.600 --> 00:55.600 company model, we have the transmission and the transport sector, 00:55.600 --> 01:00.600 heat sector, all could be linked to the electricity sector and there are many 01:00.600 --> 01:05.600 many feedback loops. If I want to know what is the technology now I could 01:05.600 --> 01:10.600 invest in and which is cheap. I also have to check what are the other 01:10.600 --> 01:14.600 technologies which I could invest in. That's why you always have to look at the 01:14.600 --> 01:20.600 system and what we are often doing is just dumping all of those various 01:20.600 --> 01:24.600 constraints and various objectives in the single objective function and then 01:24.600 --> 01:29.600 optimize that by operating costs and kpex. Operating costs, what is 01:29.600 --> 01:34.600 cost to one my system and kpex or what can I do to invest in new 01:34.600 --> 01:38.600 technologies which technologies should I use there. This is then 01:38.600 --> 01:43.600 constrained to many things like availability of wind and solar and 01:43.600 --> 01:49.600 stock capacity that could also be like policies or have to meet 30% of 01:49.600 --> 01:55.600 CO2 reduction until specific year. This is what pipsize basically 01:55.600 --> 02:02.600 made to help you with and it stands for pipsons of power system analysis 02:02.600 --> 02:06.600 but these days it's more a power pipson for energy system analysis and 02:06.600 --> 02:12.600 also include sector coupling so also handles industries so you could 02:12.600 --> 02:16.600 even add materials in there. It's fully written in pipson. 02:16.600 --> 02:22.600 Some would argue that Julia, using Julia's faster, we always build this 02:22.600 --> 02:26.600 very large optimization problem and then spend most of the time 02:26.600 --> 02:31.600 solving it actually in the solver. The compute is not too much too important 02:31.600 --> 02:35.600 and also memory peaks and everything is all handled by the solver and 02:35.600 --> 02:40.600 the advantage of pipson is that it's very accessible. All the data 02:40.600 --> 02:45.600 we use in pipson is stored in pandas so most of our users are either 02:45.600 --> 02:49.600 from research but also from industry but are not no software 02:49.600 --> 02:54.600 engineers and pandas is very easy for them to do handle. 02:54.600 --> 02:59.600 It's very highly customizable but this is just the framework but you 02:59.600 --> 03:03.600 need to run pipson models so any energy system model is tons of data. 03:03.600 --> 03:07.600 You just choose the prettiest plots on the left side. 03:07.600 --> 03:11.600 You see Germany and there the installed transmission capacities 03:11.600 --> 03:15.600 transport and installed power plants and also some industry locations. 03:15.600 --> 03:19.600 The transmission capacities are actually data from the OSM talk 03:19.600 --> 03:23.600 if you joined that earlier on the other side we see weather data which 03:23.600 --> 03:27.600 needs to be translated into energy system data so how much power could 03:27.600 --> 03:31.600 I could use at a specific location. Here you also see all those different 03:31.600 --> 03:37.600 dynamics and they also vary across time and space and also wind and 03:37.600 --> 03:41.600 solar and I hand it differently and there the pipson ecosystem 03:41.600 --> 03:45.600 is helping you out because pipson is the framework which helps you to 03:45.600 --> 03:51.600 build this optimization model. We have there also other data libraries 03:51.600 --> 03:55.600 like AdLite which starts the conversion of weather data into energy 03:55.600 --> 03:59.600 system data that's power plant matching which is basically 03:59.600 --> 04:03.600 de-duplication software for power plant data sets and there are many 04:03.600 --> 04:07.600 different pipsa workflows. The pipsa workflow could be something like 04:07.600 --> 04:11.600 pipsa URL or pipsa Earth and what is happening there is basically that 04:11.600 --> 04:15.600 all the data which is used when needed for pipsa is sanded in 04:15.600 --> 04:19.600 specific workflow and then all the retrieving and the process 04:19.600 --> 04:23.600 of the data is then dumped into one of the models and then you 04:23.600 --> 04:27.600 figure out how do you want to cluster you can add your own workflows and 04:27.600 --> 04:31.600 this is just what users came up with to be a table in our 04:31.600 --> 04:35.600 maintaining pipsa URL. Pipsa USA is done by some people on 04:35.600 --> 04:39.600 Stanford. Pipsa Earth is done by the Pipsa Mit Earth initiative. There's 04:39.600 --> 04:43.600 also multiple models for great Britain. There's one for South 04:43.600 --> 04:47.600 America as South Africa. There's a New Zealand version so there are many 04:47.600 --> 04:51.600 many different models and also Pipsa's quite 04:51.600 --> 04:55.600 tested already. There are tons of applications either people 04:55.600 --> 04:59.600 build their own model on their own with the pipsa framework or we 04:59.600 --> 05:03.600 lie on one of those existing workflows and then 05:03.600 --> 05:07.600 made some changes to it. We have not a full list of users. We can't 05:07.600 --> 05:09.600 have a full list of users. There's just some 05:09.600 --> 05:15.600 some truths and publications. If you check the dogs we try to 05:15.600 --> 05:19.600 keep a long list there and if you're interested in what other people 05:19.600 --> 05:23.600 you can get some inspiration there. As I've already said 05:23.600 --> 05:27.600 it was developed since right away. Ten years now actually last week 05:27.600 --> 05:31.600 was the ten years anniversary of our first public release. 05:31.600 --> 05:37.600 And version 1.0 just came out in October last year. 05:37.600 --> 05:41.600 There's not really a reason why we waited so long. We just never did the jump. 05:41.600 --> 05:47.600 But now since it was such a long release we added tons of new features 05:47.600 --> 05:53.600 and did a full refreshment of the two of it. One of the biggest new features 05:53.600 --> 06:01.600 is that we now support the psochastic optimization. The psochastic 06:01.600 --> 06:07.600 optimization allows you to handle uncertainty. And certainly why are we interested 06:07.600 --> 06:11.600 in that? I mean you just need to check the news these days. Nobody knows what 06:11.600 --> 06:15.600 the US government is doing. You had the Russian invasion of Ukraine 06:15.600 --> 06:21.600 where gas prices were raising or all kinds of prices. We know now that gas 06:21.600 --> 06:25.600 pipelines can just blow up. You could also have uncertainties like just 06:25.600 --> 06:29.600 policies. You do not know they plan to reduce emissions under 06:29.600 --> 06:33.600 2050 by that amount but it could change in the future. And this is 06:33.600 --> 06:37.600 all uncertainty you need to handle if I want to do it in investment decision 06:37.600 --> 06:41.600 today. And you could do that quite okay already with pipsa 06:41.600 --> 06:47.600 by just you could use MGA which is a niche feature in pipsa to dive in that 06:47.600 --> 06:51.600 solution space. You could use all those workflows that's easy to define many 06:51.600 --> 06:55.600 different scenarios and then one name and parallel together. You could then 06:55.600 --> 06:59.600 do sensitivity analysis on them. But you will never get a single result 06:59.600 --> 07:05.600 which works across all of different scenarios. Until now because pipsa 07:05.600 --> 07:09.600 are one point zero now and to reduce the source programming out of the 07:09.600 --> 07:13.600 box which basically just means you have to come up with the set of 07:13.600 --> 07:17.600 scenarios and their probabilities. Those probabilities need to be given that 07:17.600 --> 07:21.600 could be for weather. They could be just given for like 07:21.600 --> 07:25.600 the chance of a weather event to happen. It could be if you want to 07:25.600 --> 07:29.600 hatch against very catastrophic but unlikely events they would have a 07:29.600 --> 07:33.600 very low probability or you just use a normal distribution. 07:33.600 --> 07:37.600 If this is what you need to define a set of scenarios and 07:37.600 --> 07:41.600 when you do that pipsa will cast the full network or 07:41.600 --> 07:45.600 parameters you have and use scenario dimension to it. 07:45.600 --> 07:49.600 And that allows you then that you for that all this patch decisions you have 07:49.600 --> 07:53.600 you can adjust in for each scenario for some 07:53.600 --> 07:57.600 will come to an example in seconds but all decisions 07:57.600 --> 08:01.600 which are used for the operation of the network are then 08:01.600 --> 08:05.600 scenarios specific. While investment decisions so what 08:05.600 --> 08:09.600 in which technology do I even want to invest is 08:09.600 --> 08:13.600 optimized across all of the possible scenarios. 08:13.600 --> 08:17.600 It works out of the box with pipsa in the API now. Let's look at 08:17.600 --> 08:21.600 the simple small example where we have just a low 08:21.600 --> 08:25.600 medium and high gas price and the probabilities are kind of 08:25.600 --> 08:29.600 similar. If we solve all of those scenarios 08:29.600 --> 08:32.960 individually and deterministic we see if the gas prices low 08:32.960 --> 08:37.200 we just go full on on gas because it's the cheapest and nothing else can 08:37.200 --> 08:41.600 compete with that and we have the lowest system costs but if you 08:41.600 --> 08:45.600 go to the medium and the high gas price we also mix in wind and solar 08:45.600 --> 08:51.200 and for the high one even ignite. But all of those work for 08:51.200 --> 08:55.200 the specific scenarios and optimize for that specific scenario but all of 08:55.200 --> 09:01.200 those do not are not optimized for each other. If we want the same 09:01.200 --> 09:07.200 model now statistically we include all of those three scenarios 09:07.200 --> 09:11.200 and we see that the statistics solution is of course not the 09:11.200 --> 09:15.200 best one in any of those scenarios but it's the best one 09:15.200 --> 09:21.200 across all of them together. This is then just risk neutral 09:21.200 --> 09:23.200 optimization and I hope I'm not losing everyone but 09:23.200 --> 09:29.200 with neutral optimization is I do not care about which scenario 09:29.200 --> 09:33.200 actually happens. I just want to have the minimal cost 09:33.200 --> 09:39.200 across all of them. This is not how most people would actually behave. 09:39.200 --> 09:43.200 If I plan like battery storage which costs half a billion in Sweden 09:43.200 --> 09:49.200 I want to be sure that or even for birth case scenarios I don't go bankrupt. 09:49.200 --> 09:53.200 So I want to hedge against those worst case scenarios which could 09:53.200 --> 09:57.200 be catastrophic to me. This is also possible in pipes 09:57.200 --> 10:01.200 are now with the risk adverse optimization and this is included with 10:01.200 --> 10:07.200 the CVA so you can define or you want to penalize the 10:07.200 --> 10:11.200 worst scenarios of your optimization problem and you don't have to 10:11.200 --> 10:15.200 define what are the worst scenarios. This is all handled by pipes 10:15.200 --> 10:21.200 itself and yeah one also just in the API where we easy to 10:21.200 --> 10:25.200 access and if we see here the same optimization problem 10:25.200 --> 10:31.200 done with the CVA attached we see we pay a little of premium 10:31.200 --> 10:35.200 because the system costs are better but we are hatched against 10:35.200 --> 10:41.200 the high cost scenario better and we have a better system which 10:41.200 --> 10:47.200 in this worst case scenario. This was a speedy one off of only 10:47.200 --> 10:51.200 the stress optimization functionality we have now in pipes 10:51.200 --> 10:55.200 there is much much more with version 1.0 first of all if you ever looked 10:55.200 --> 11:01.200 pipes up before October last year already it's worth to look on it again because 11:01.200 --> 11:05.200 we have an all new documentation everything is fresh up and clean and 11:05.200 --> 11:09.200 yeah the quality of the documentation is very high now 11:09.200 --> 11:13.200 we have other new features a couple of plotting functionality 11:13.200 --> 11:17.200 we don't have a GUI what we saw earlier GUI is still not the 11:17.200 --> 11:21.200 thing there are developments on that as well but it's very hard to find 11:21.200 --> 11:27.200 a single GUI for all those different ideas how pipes are can be used 11:27.200 --> 11:33.200 there is the plotting module there is a new interactive maps there are 11:33.200 --> 11:37.200 the new components classes there is a network collection which 11:37.200 --> 11:41.200 possible to compare different networks doesn't matter if they have 11:41.200 --> 11:43.200 multi-wise and if they are still has to have just 11:43.200 --> 11:49.200 a single temporal dimension yeah those are all new features on 11:49.200 --> 11:53.200 on pipes are it's worth to check out the new documentation we 11:53.200 --> 11:57.200 have a large community on the discord channel already 11:57.200 --> 12:01.200 this link is missing but you can reach it a bit just going on pipes 12:01.200 --> 12:06.560 or arc and then the link you will find there if you have any questions you can reach out 12:06.560 --> 12:10.560 now or just join one of those channels is it either discord 12:10.560 --> 12:16.560 the documentation or get up yeah and that's pipes are 12:16.560 --> 12:18.560 the speed version 12:40.560 --> 12:44.560 you can use it for medium loadages as well we don't do that 12:44.560 --> 12:48.560 the question is can you use it for medium and high medium and low 12:48.560 --> 12:52.560 voltage levels as well yes you can do that we are not doing that too much you may 12:52.560 --> 12:56.560 look on those very large capacity expansion 12:56.560 --> 13:00.560 problems and there you are not too much interested in that because then the 13:00.560 --> 13:06.560 models get too complex but you could also run pipes for low voltage or even 13:06.560 --> 13:10.560 at home to run energy management that they come with the battery so 13:10.560 --> 13:22.560 what's coming next version 1.1 next week probably but after that we have plans 13:22.560 --> 13:28.560 on doing more of the GUI stuff where it's also easier to run pipes or models and then 13:28.560 --> 13:34.560 easier to run all those different existing workflows we have already but no announcement 13:34.560 --> 13:36.560 for 13:56.560 --> 14:00.560 if it depends on what you want to do with the flooding map flooding map 14:00.560 --> 14:04.560 and one example is the volcano where you have a volcano eruption 14:04.560 --> 14:08.560 and then the solar capacity is lower that's easy to integrate 14:08.560 --> 14:12.560 flooding map the modeler then has to decide what is actually the impact 14:12.560 --> 14:18.560 on the system do power plants fell out or do so what it's possible 14:18.560 --> 14:20.560 but it's up to the modeler basically 14:20.560 --> 14:26.560 yeah yeah yeah yeah yeah yeah so 14:28.560 --> 14:30.560 sorry again 14:38.560 --> 14:44.560 there it's no the question is are there after with the question the question is are their 14:44.560 --> 14:48.560 pre-existing components how to model like heat pumps for example 14:48.560 --> 14:54.560 There are not, you have to come up with the version on how you embed them in pipes yourself right now. 14:54.560 --> 15:00.560 There are also plans on allowing you to have a components library where you can pre-select list of components. 15:00.560 --> 15:02.560 You can then easily attach to a network. 15:02.560 --> 15:08.560 Currently, it's not possible because currently there are also many different ways on how you could add them to the network. 15:08.560 --> 15:14.560 But it's possible to add, it's just not trivial. 15:14.560 --> 15:16.560 Yeah? 15:16.560 --> 15:20.560 Yeah, it's the package that's divided by profile. 15:20.560 --> 15:31.560 The mix is quite wide, so I'm software developer and working only as a software developer now for the package. 15:31.560 --> 15:36.560 But I'm the first one before it was basically mainly post dog and PhD driven. 15:36.560 --> 15:43.560 But I wouldn't say they don't have software developer knowledge, but it's the research driven and they came from energy system modeling, 15:43.560 --> 15:45.560 not from software engineering. 15:45.560 --> 15:48.560 We have brought in this app and we also get many, many more contributions. 15:48.560 --> 15:51.560 We are not just our university working on that. 15:51.560 --> 15:57.560 There are other institutions, which sometimes have more software engineering knowledge. 15:57.560 --> 16:01.560 Otherwise, that wouldn't be possible. 16:01.560 --> 16:03.560 So far it works. 16:03.560 --> 16:04.560 It's quite well. 16:04.560 --> 16:10.560 The question is, you are always really relying on a couple of core people who have the big brain and know everything. 16:10.560 --> 16:13.560 And it's hard to get new people on board. 16:13.560 --> 16:17.560 And that takes a lot of time and then resources and then you're defending as well. 16:17.560 --> 16:20.560 So community contributions we have a lot. 16:20.560 --> 16:27.560 But it's hard to get community contributions, which are like complex topics like stochastic optimization. 16:27.560 --> 16:30.560 Thank you.