WEBVTT 00:00.000 --> 00:11.000 So, thank you for being here to the end. 00:11.000 --> 00:16.000 So, my talk will be about James, which is a kind of a language for an existing audience. 00:16.000 --> 00:18.000 So, my name is Anthony Steyer. 00:18.000 --> 00:22.000 I'm a research engineer at Altsi, the French, the T.S.U. 00:22.000 --> 00:29.000 So, in terms of size, but also in terms of budget, I guess. 00:29.000 --> 00:34.000 And I have to say that for a week, since we have a significant budget for R&D, 00:34.000 --> 00:37.000 we'll serve the chance to have an R&D management. 00:37.000 --> 00:41.000 So, it's very, it's a favourable tool for construction. 00:41.000 --> 00:50.000 And my, so research area is the many related to one of the institutions of our sea, which is a 00:50.000 --> 00:58.000 conductive prospective analysis of the secretive supply and the innovative evidence on the health of the French government. 00:58.000 --> 01:03.000 So, I start with a small segmentive note, because it matters here. 01:03.000 --> 01:06.000 So, the data change model as data. 01:06.000 --> 01:12.000 What means here, the model in the context of finance? 01:12.000 --> 01:18.000 In this community, the term is a bit overloaded. 01:18.000 --> 01:23.000 So, people use this term to speak about a tool, like faxar, like antares. 01:23.000 --> 01:29.000 Also, people use the name, not only to speak about the study case, like faxar Europe, 01:29.000 --> 01:33.000 but also the antares to any extent. 01:33.000 --> 01:39.000 And also, maybe, you can do the term to speak about the related optimization. 01:39.000 --> 01:44.000 Here, what I would call model is much more simple. 01:44.000 --> 01:50.000 It's just the abstract mathematical distribution of the given type of components of the internal system. 01:50.000 --> 01:58.000 So, for instance, the mathematical equation that we are using, to describe the behavior of the storage unit of the nuclear power plant, 01:58.000 --> 02:03.000 or of the visualization line. 02:03.000 --> 02:10.000 So, some also make all this basic model, but here, what the model is, just the type of model. 02:10.000 --> 02:13.000 And it's a mathematical structure. 02:13.000 --> 02:20.000 So, then, I'll be talking about the language, not a tool or a tool in domain. 02:20.000 --> 02:25.000 And also, the presentation I'm going to give you, speaking about the language. 02:25.000 --> 02:29.000 So, this is an elementary language to represent the components of components. 02:29.000 --> 02:35.000 And therefore, to describe systems in a set-point name, an elementary school. 02:35.000 --> 02:38.000 So, what is jams? 02:38.000 --> 02:42.000 So, jams stands for generate in a system's learning scheme. 02:42.000 --> 02:46.000 So, from a terrestrial prototype, this is a graph-based algebraic coding language. 02:46.000 --> 02:50.000 So, to configure and extend the models of components. 02:50.000 --> 02:55.000 And this is coming with the data structure to represent the analysis. 02:55.000 --> 03:01.000 So, for now, to interpret your projects, have been developed. 03:01.000 --> 03:05.000 So, first, we developed a pattern to interpret your projects. 03:05.000 --> 03:07.000 It was made up to the first step. 03:07.000 --> 03:14.000 And then, we industrialized this pattern to a specific school. 03:14.000 --> 03:16.000 That is, now, inside our task network. 03:16.000 --> 03:24.000 The task network means the tool that is used in traditional and absolutely for a prospective stage. 03:24.000 --> 03:31.000 So, we have now the presentation website that is recently sent out on the language. 03:31.000 --> 03:36.000 So, basically, how we have our jams working here. 03:36.000 --> 03:41.000 So, we are just describing the analysis system as a hyper graph. 03:41.000 --> 03:46.000 So, the vertices of the graph are basically just some components. 03:46.000 --> 03:52.000 And so, the graph is described in a number of I. 03:52.000 --> 03:59.000 So, the components are the vertices and the data instantiate models. 04:00.000 --> 04:04.000 And the models are described in the also file. 04:04.000 --> 04:06.000 That is called the library file. 04:06.000 --> 04:19.000 So, basically, the library file is the file that contains the mathematical expressions of each type of components. 04:19.000 --> 04:23.000 So, I just know the time. 04:23.000 --> 04:30.000 So, basically, I. 04:30.000 --> 04:40.000 So, basically, the edges of the graph are the connections between components and the accurate parts. 04:40.000 --> 04:44.000 So, how does the model look like in a library file? 04:44.000 --> 04:52.000 It just the simple declaration of the parameters, the variables, the parts and some mathematical constraints. 04:53.000 --> 04:57.000 The contribution of the models to the global objective of the system. 04:57.000 --> 05:06.000 So, here, for instance, we see a very simple model for what you can call a best with a splage and a transparent logic. 05:06.000 --> 05:10.000 When an edge is designed. 05:10.000 --> 05:12.000 And then in the system file. 05:12.000 --> 05:18.000 So, the file that you present the system, we just have for each component. 05:19.000 --> 05:23.000 The reference to the model that the component is instantiating. 05:23.000 --> 05:30.000 And the declaration of the numerical value of the parameters that are in the template. 05:30.000 --> 05:36.000 So, basically, the core concepts are, in fact, the optimization concepts like variables parameters. 05:36.000 --> 05:41.000 By equal to variables and parameters are indexed by time and scenarios. 05:42.000 --> 05:45.000 We have also, like, the objective constraints. 05:45.000 --> 05:49.000 And as we regard the graph, we use the notion of port. 05:49.000 --> 05:51.000 And the ports have fields. 05:51.000 --> 06:00.000 Basically, the components can exchange in their expressions to fields. 06:00.000 --> 06:04.000 So, well, those genes fit among existing modeling tools. 06:04.000 --> 06:09.000 So, basically, we try to find a good compromise between algebraic modeling languages like, 06:09.000 --> 06:13.000 an example, and the classical tools, object-oriented tools like, 06:13.000 --> 06:15.000 an entire spectrum, etc. 06:15.000 --> 06:22.000 So, basically, we try to be as expressive in terms of mathematical experience as an example. 06:22.000 --> 06:29.000 That we try also to, naturally, embark the graph nature of the system. 06:29.000 --> 06:33.000 From a mathematical point of view, we are representative, 06:33.000 --> 06:37.000 and mix, mix, integer, enough, and problems. 06:37.000 --> 06:42.000 Over time, cross scenario grids of index indices. 06:42.000 --> 06:47.000 To represent, so, deterministic, or to stage to get stickier to the cases. 06:47.000 --> 06:51.000 And the main targets, the applications are adequacy assessment studies, 06:51.000 --> 06:56.000 production cost simulation, and capacity expansion planning. 06:56.000 --> 07:02.000 I like to make the analogy with model class, so, basically, we are a bit trained to build a modelic habit. 07:02.000 --> 07:07.000 The difference with modelic case is that, when the case is designed for dynamical systems, 07:07.000 --> 07:12.000 to simulate ODS, whereas, we are simulating optimized systems. 07:12.000 --> 07:19.000 So, the systems are simulated by solving the optimization techniques. 07:19.000 --> 07:25.000 So, what were the motivation for this architectural architectural breakthrough? 07:25.000 --> 07:29.000 So, first I will, so, as I remind you, I explained the breakthrough. 07:29.000 --> 07:34.000 So, the idea is that in classical, object-oriented, object-oriented modeling environments, 07:34.000 --> 07:40.000 like PISA, Antis, the mathematical equations of the components. 07:40.000 --> 07:45.000 So, the models of components, they are outputted inside the software. 07:45.000 --> 07:51.000 And then the software builds an optimization problem through a multi-survivant interface, 07:51.000 --> 07:58.000 give it to a software, and then read the results based on the optimization. 07:58.000 --> 08:03.000 And now, we are trying the models from the tools that is to say, 08:03.000 --> 08:06.000 we consider the mathematical equations as inputs. 08:06.000 --> 08:12.000 And then, the instructor is just a piece of code that dynamic reads the equations 08:12.000 --> 08:14.000 to build the optimization problem. 08:14.000 --> 08:17.000 We are still using a multi-survivant interface. 08:17.000 --> 08:21.000 It's not an alternative to a multi-survivant interface like in a pair of atoms. 08:21.000 --> 08:27.000 It's just a small layer of code on top of it. 08:27.000 --> 08:31.000 And then, basically, the idea is to build the community of models, 08:31.000 --> 08:38.000 so, just to say, for instance, we can represent in our library, the legacy models of Antares. 08:38.000 --> 08:41.000 So, the models that before were outputted in Antares, 08:41.000 --> 08:44.000 we have also a library of the pipe's models. 08:44.000 --> 08:51.000 So, the equations of the pipe's circumference, and we can imagine to maintain several libraries 08:51.000 --> 08:53.000 depending on the use cases. 08:53.000 --> 08:58.000 So, this is kind of, actually, a short breakthrough for Antares later, 08:58.000 --> 09:00.000 and I will explain the motivations. 09:00.000 --> 09:06.000 So, as I said, this is our tool for large scale planning studies that have art is, 09:06.000 --> 09:09.000 the official tools for for for for for for for for for for for for this. 09:09.000 --> 09:12.000 So, national studies and European studies. 09:13.000 --> 09:20.000 The first motivation at the beginning of the project is mostly, let's say, versatile modeling, 09:20.000 --> 09:28.000 and then also the main ability of the code in a relative context and interoperability. 09:29.000 --> 09:34.000 So, that's why we designed the language and the interpretorial inside of pipes. 09:34.000 --> 09:38.000 So, first, the first motivation, so versatile local modeling. 09:38.000 --> 09:45.000 So, this topic rose when we saw that it was more and more difficult to maintain a stable code, 09:45.000 --> 09:50.000 while addressing a lot of new questions from the users. 09:50.000 --> 09:53.000 So, for instance, can we add this new type of components? 09:53.000 --> 09:59.000 Can I change my components to have, I don't know, a storage injection capacity, 09:59.000 --> 10:01.000 as depends on the state of charge. 10:01.000 --> 10:05.000 So, a lot of evolution asked by the users. 10:05.000 --> 10:11.000 So, we were saying that the classical options that we add were a bit immediately like. 10:11.000 --> 10:16.000 Historically, we could use modeling artifacts that is, we say, if you want to model a flexible load, 10:16.000 --> 10:21.000 you can say, okay, it's a load, a generator and a crystal for strength. 10:21.000 --> 10:26.000 So, you can use the art grid grammar that is then a bit of mess. 10:26.000 --> 10:33.000 You can also implement a new component in your code, but then you have to manage the impacts 10:33.000 --> 10:38.000 on all your options of interpretation. 10:38.000 --> 10:46.000 Or, in the gents way, now you can just add a few lines in your normal library type, 10:46.000 --> 10:51.000 configuration file, to introduce a new type of component. 10:51.000 --> 10:54.000 Without any change in the software code. 10:54.000 --> 11:00.000 So, we think that it will reduce the time to market of new models for users. 11:00.000 --> 11:06.000 And it will also help seeping more stable properties. 11:06.000 --> 11:11.000 So, that's the second motivation, maintainability in an evolutive context. 11:11.000 --> 11:18.000 So, we think that we manage to, by doing this to decouple modeling from industrial software engineering, 11:18.000 --> 11:25.000 for better, maintainability and for better synergies between teams. 11:25.000 --> 11:33.000 And the last motivation that, let's say, came up later, is the interoperability between tools. 11:33.000 --> 11:35.000 So, why interoperability? 11:35.000 --> 11:39.000 It's mainly that for our academic and industrial algorithms, 11:39.000 --> 11:43.000 our aim is to reduce, let's say, the communication cost with our partners, 11:43.000 --> 11:47.000 and also to better capitalize on common words. 11:47.000 --> 11:52.000 The problem with interoperability is that it's a bit like trying to fit, 11:52.000 --> 11:58.000 and let's say, circle things into square halls, or raise us up. 11:58.000 --> 12:05.000 So, two possible approaches are possible to share steady cases in a tool agnostic way, 12:05.000 --> 12:07.000 reducing the ambiguities. 12:07.000 --> 12:11.000 The classical approach is semantics. 12:11.000 --> 12:15.000 I try to build ontologies to list all the possible, let's say, 12:15.000 --> 12:21.000 components of the energy system that we can sync up and trying to list the parameters. 12:21.000 --> 12:25.000 Now, the way that we are proposing, it's an alternative, it's more like complementary, 12:25.000 --> 12:30.000 that replacing the first one, but we think that a more direct way, 12:30.000 --> 12:37.000 maybe, is just to share the math behind, to share the symbolics. 12:37.000 --> 12:45.000 So, I think that, since to James, we're able to share a steady case with all the 12:46.000 --> 12:52.000 important information that you need to re-simulate the test case, but still, 12:52.000 --> 12:57.000 why can't we add here, we are able to share the mathematical formulation, 12:57.000 --> 13:03.000 but still, a tool is not only a mathematical formulation, it's also a solution workflow. 13:03.000 --> 13:08.000 So, we think that the solution workflow will remain a tool dependent, and we're fine with this, 13:08.000 --> 13:14.000 because it's also what is interesting in the multiplicity of tools. 13:14.000 --> 13:22.000 To finish my talk, I will just introduce you to a small, to test cases that we, 13:22.000 --> 13:29.000 we conducted to illustrate the last motivation, in terms of with pipsa. 13:29.000 --> 13:36.000 So, I think that at this time of the day, you know what is pipsa and probably what is pipsa 13:37.000 --> 13:46.000 and we wonder how we could try to take advantage from this very nice dataset, from this very nice community, 13:46.000 --> 13:50.000 and to make a bridge with our ecosystem. 13:50.000 --> 13:56.000 So, we build a simple converter from a pipsa network to James's study case. 13:56.000 --> 14:01.000 The idea was to confirm the expressiveness of the James language, 14:01.000 --> 14:05.000 also to connect, as I say, with this interesting ecosystem. 14:05.000 --> 14:10.000 And also to be able, in the end, to run internal or public, 14:10.000 --> 14:13.000 on-ties of pipsa test cases, with the same software, 14:13.000 --> 14:19.000 reducing infrastructure and graphical interface, and sharing advanced optimization methods, 14:19.000 --> 14:25.000 like our bend-dose decomposition code that we are developing. 14:25.000 --> 14:29.000 So, basically, we just wrote, as I said earlier, the pipsa nodes, 14:29.000 --> 14:36.000 and for just one yellow file, that represents the mathematical equations of pipsa. 14:36.000 --> 14:42.000 And we just have a small piece of code that takes the pipsa network objects, 14:42.000 --> 14:51.000 and they export the data in our format, but it's just about changing the format of data series. 14:51.000 --> 14:55.000 So, we are conducting numerical comparison tests, 14:55.000 --> 14:59.000 so a parallel run between pipsa and our James interpreter, 14:59.000 --> 15:06.000 and we manage just to have the same numerical result, same objective value. 15:06.000 --> 15:11.000 So, this is a work in progress, so for now, we are not managing all the pipsa components, 15:11.000 --> 15:18.000 but we will soon, and we will also conduct large-scale test cases. 15:19.000 --> 15:25.000 So, to conclude, the James is a project that started almost three years ago now. 15:25.000 --> 15:32.000 So, we first had a prototyping in Python, and now it is integrated into our online simulator, 15:32.000 --> 15:37.000 and then I read about it, because we still have to manage the legacy code of our files. 15:37.000 --> 15:44.000 And for the next year, we are going to have a rough data interface that manage James object, 15:44.000 --> 15:50.000 and you are going to continue working on new features for this language, 15:50.000 --> 15:55.000 and we are going to manage this feature, run up the pipsa. 15:55.000 --> 16:02.000 So, the key takeaways, so we are proposing a high-level language that takes the mathematics parameters, 16:02.000 --> 16:09.000 both of the software code, so that we are able to share self-contained the input data for running 16:09.000 --> 16:13.000 to the case, and for replicating the simulations. 16:13.000 --> 16:16.000 We have two generic and separate interpreters. 16:16.000 --> 16:21.000 So, one eye-performance, let's say, interpreters inside the automation method, 16:21.000 --> 16:27.000 and one, let's say, sandboxing the interpreter in Python called James Python. 16:27.000 --> 16:36.000 And those code are just, let's say, single-is, just mathematical and linear expressions. 16:36.000 --> 16:40.000 There is no business logic happening in those interpreters. 16:40.000 --> 16:48.000 We think that this approach favors the versatile modernity of code, and interoperability. 16:48.000 --> 16:53.000 And for sure, we are open to new collaboration around James. 16:53.000 --> 17:01.000 So, James, let's say, it was developed in the context of an RNG project, 17:01.000 --> 17:03.000 with the external partners. 17:03.000 --> 17:08.000 So, we already have some academic and street partners on the topic, 17:08.000 --> 17:10.000 but we are open to new collaborations. 17:10.000 --> 17:16.000 For instance, to study interoperability with your favorite tool, 17:16.000 --> 17:21.000 or to start structuring it together, reference libraries of models, 17:21.000 --> 17:25.000 or to work on the graphical interface. 17:25.000 --> 17:28.000 So, that's was James, thank you for your attention, 17:28.000 --> 17:30.000 and I'll give you a few questions. 17:36.000 --> 17:38.000 At a PhD student during that, 17:38.000 --> 17:40.000 we had just a year ago. 17:40.000 --> 17:44.000 Did you guys implement a course student as much as you do? 17:44.000 --> 17:48.000 Did you implement a dynamic structure? 17:48.000 --> 17:51.000 We can do it during the course of simulation changes, 17:51.000 --> 17:53.000 and structure of the grid as it goes. 17:53.000 --> 17:57.000 Or is it a great structure fixed during the simulation? 17:58.000 --> 18:04.000 And, you mean, over the waffle process, over time? 18:04.000 --> 18:07.000 If you have a simulation over time, 18:07.000 --> 18:09.000 you can expand your system. 18:09.000 --> 18:13.000 You can provide a new, like, clear the area for expanding, 18:13.000 --> 18:17.000 and then you start simulation in the tries to see what is the structure 18:17.000 --> 18:19.000 that the grid can develop over time. 18:19.000 --> 18:21.000 You don't know then of the structure, 18:21.000 --> 18:25.000 it just tries to test different ways of expansion. 18:26.000 --> 18:32.000 So, the question is whether rival to manage a structure of the network 18:32.000 --> 18:37.000 that is evolving over time? 18:37.000 --> 18:40.000 I would say that you have to put it, 18:40.000 --> 18:44.000 say your expansion for the days from the building, 18:44.000 --> 18:45.000 for the simulation, 18:45.000 --> 18:50.000 but you can afford them to have a real capacity 18:50.000 --> 18:52.000 at the building of the simulation. 18:53.000 --> 18:58.000 That's what I love when I saw your presentation. 18:58.000 --> 19:02.000 We were also working on that in the industry 19:02.000 --> 19:04.000 working on that as well. 19:04.000 --> 19:07.000 I'm using the graph to express the grid. 19:07.000 --> 19:10.000 And graph to the power of its engine as well. 19:10.000 --> 19:12.000 Or do you guys want that with it? 19:12.000 --> 19:13.000 No, it's it. 19:13.000 --> 19:16.000 Let's see that we are focusing on coffee chosen. 19:17.000 --> 19:30.000 So, the question was if we studied the possibility to have a dynamic structure of the graph 19:30.000 --> 19:33.000 or the simulation time, 19:33.000 --> 19:37.000 but it's still to be explored. 19:37.000 --> 19:49.000 So, I'm not the software developer behind this, 19:49.000 --> 19:52.000 but the question is, 19:52.000 --> 19:54.000 are we doing the manager, 19:54.000 --> 19:58.000 how is that expression? 19:58.000 --> 20:02.000 So, I'm not the software developer behind this, 20:02.000 --> 20:05.000 but the question is, 20:05.000 --> 20:07.000 are we doing the manager, 20:07.000 --> 20:12.000 how do we pass the manager expression in our language? 20:12.000 --> 20:16.000 I think it's based on INTRL and graph. 20:16.000 --> 20:23.000 So, it's a package to manage expressions, 20:23.000 --> 20:26.000 but let's say that we are then our own structure 20:26.000 --> 20:31.000 to represent the mathematical expressions. 20:32.000 --> 20:36.000 So, in April, it's cool to be in my work with some of its sounds, 20:36.000 --> 20:39.000 and really be unrelated to what it is doing. 20:39.000 --> 20:42.000 I work with an application, which is the evaluation of the visual, 20:42.000 --> 20:45.000 and then it has this expressive capability, 20:45.000 --> 20:47.000 or references the thing. 20:47.000 --> 20:49.000 So, you have to work on that, 20:49.000 --> 20:51.000 and if you're listening to it, 20:51.000 --> 20:54.000 you have to express the mathematical expressions 20:54.000 --> 20:55.000 on the right hand side as well. 20:55.000 --> 20:57.000 It's funny, it's like, 20:58.000 --> 21:02.000 with the whole thing in the type change, 21:02.000 --> 21:05.000 we need to pay the score actually for the score. 21:05.000 --> 21:10.000 And I think it's a little bit different. 21:10.000 --> 21:17.000 That's one of the things that's used by the library 21:17.000 --> 21:22.000 that has mathematical expressions, 21:22.000 --> 21:25.000 and we could from the graph view, 21:26.000 --> 21:29.000 it's like the always structure of the mathematical expressions, 21:29.000 --> 21:35.000 and the right hand and the right hand and the right hand. 21:35.000 --> 21:38.000 The right is the key, it's pressing, 21:38.000 --> 21:40.000 you get all of that, 21:40.000 --> 21:42.000 the right is really the key to it. 21:42.000 --> 21:45.000 It blocks a lot of stuff when you're building it. 21:45.000 --> 21:48.000 And I saw from a software engineering perspective, 21:48.000 --> 21:51.000 I think it's very interesting, 21:51.000 --> 21:53.000 because it gives a very care, 21:53.000 --> 21:56.000 it's a fast contract between a distance, 21:56.000 --> 21:59.000 a graphical length of face and your simulator. 21:59.000 --> 22:01.000 Thank you very much. 22:01.000 --> 22:05.000 Thank you. 22:05.000 --> 22:07.000 You mentioned that, 22:07.000 --> 22:10.000 the mathematical description was confirmed, 22:10.000 --> 22:12.000 so I'm not going to answer the question, 22:12.000 --> 22:15.000 but I'm not going to answer it, 22:15.000 --> 22:16.000 but I'm going to answer it, 22:16.000 --> 22:19.000 and you describe it through that, 22:20.000 --> 22:34.000 so the question is that, 22:34.000 --> 22:36.000 the question is, 22:36.000 --> 22:39.000 are semantics and symbolics, 22:39.000 --> 22:42.000 complementary or incompatitions somehow? 22:42.000 --> 22:44.000 I would say that, 22:44.000 --> 22:47.000 if I add to choose between both approaches, 22:47.000 --> 22:50.000 the more you go for the second one, 22:50.000 --> 22:53.000 because let's say that you have the old information 22:53.000 --> 22:56.000 that you need to do the simulation, 22:56.000 --> 22:58.000 whereas if you are doing semantics, 22:58.000 --> 23:01.000 then you have to check some documentation of certain specifications 23:01.000 --> 23:05.000 to understand the logic behind. 23:05.000 --> 23:09.000 Still, I think that's to organize our library of models. 23:09.000 --> 23:14.000 It could be interesting to refer to some standards, 23:15.000 --> 23:18.000 because we still have the... 23:18.000 --> 23:24.000 I think we have the material of the issue of organizing this library. 23:44.000 --> 23:56.000 So the question is about a potential use case, 23:56.000 --> 23:59.000 mixing in the upper film, 23:59.000 --> 24:04.000 and you can test from a link. 24:04.000 --> 24:09.000 So the question is about a potential use case, 24:09.000 --> 24:12.000 mixing in the upper film, 24:12.000 --> 24:15.000 or from a link in cash from a link. 24:15.000 --> 24:17.000 So for now, 24:17.000 --> 24:23.000 I think that we will very stick to mixing the gel in our programming problems. 24:23.000 --> 24:27.000 So that's what one of our, let's say, peer direction. 24:27.000 --> 24:31.000 Then I think that still it opens a lot of possibilities 24:31.000 --> 24:33.000 for also use cases, 24:33.000 --> 24:35.000 than the one I mentioned, 24:35.000 --> 24:37.000 like a depostaticist, so expansion time, 24:37.000 --> 24:40.000 because somehow, in the end, 24:40.000 --> 24:43.000 the language is very mathematical. 24:43.000 --> 24:47.000 There is very few almost new energy concepts inside, 24:47.000 --> 24:51.000 maybe the only energy concept is just the time dependency 24:51.000 --> 24:52.000 and scenario dependency, 24:52.000 --> 24:57.000 but let's say that we kept the world energy in the acronym 24:57.000 --> 25:00.000 because this is, 25:00.000 --> 25:04.000 the language is designed intentionally for those applications, 25:04.000 --> 25:07.000 so it's more generative. 25:35.000 --> 25:39.000 So I believe so. 25:39.000 --> 25:42.000 Sorry, the question is whether, 25:42.000 --> 25:45.000 let's say, this tool, 25:45.000 --> 25:47.000 so distinguish with the, 25:47.000 --> 25:52.000 and if the benefit was used also to benefit 25:52.000 --> 25:55.000 to the collaborations between the TS or Europe, 25:55.000 --> 25:56.000 for instance, 25:56.000 --> 25:59.000 I think that the case in the sense that, 26:00.000 --> 26:02.000 in our priorities, 26:02.000 --> 26:04.000 a really true, for, 26:04.000 --> 26:07.000 especially for European studies, 26:07.000 --> 26:09.000 to have a, let's say, 26:09.000 --> 26:11.000 a smooth process between the, 26:11.000 --> 26:14.000 between the different partners, 26:14.000 --> 26:17.000 because there are several tools, 26:17.000 --> 26:20.000 and it's not easy to communicate between the two tools. 26:20.000 --> 26:21.000 So I think with, 26:21.000 --> 26:22.000 that we, 26:22.000 --> 26:24.000 James, we would be able to, 26:24.000 --> 26:25.000 to share, 26:25.000 --> 26:28.000 study cases to share data in a well organized way, 26:28.000 --> 26:31.000 that is, 26:31.000 --> 26:33.000 we can use that, 26:33.000 --> 26:37.000 this is a tool I'm going to integrate with this. 26:37.000 --> 26:39.000 So that's, 26:39.000 --> 26:40.000 I think that's, 26:40.000 --> 26:42.000 providing, 26:42.000 --> 26:44.000 I don't know. 26:44.000 --> 26:45.000 Thank you. 26:45.000 --> 26:46.000 Thank you. 26:46.000 --> 26:47.000 Thank you. 26:47.000 --> 26:48.000 Thank you. 26:48.000 --> 26:50.000 Thank you.