 Welcome everybody. It's early morning here in the States, but like I know it's like end of the afternoon for many of you who are joining from Europe. This is the Community Service Dynamics Modeling Systems webinar series. My name is Irina Overeem. I am the Deputy Director of CSDMS. CSDMS for those of you who don't know has been around for about 15 years now. It's an NSF, so National Science Foundation funded program that promotes modeling in the Earth Service processes. And so our facility has been rallying the communicating, educating people about sustainable software and fair software development and building a bit of cyber infrastructure tools to enable people building their own scientific software. And so the team includes software engineers and I saw like Mark is for example is here too. And one of the purposes of these CSDMS Euro webinars is to exchange idea with like other Earth Service process modelers that are European based and are doing, have similar programs and do similar things and see what we can learn from each other. And so Sam rallied the British Antarctic Survey Cyber Infrastructure team and we're going to hear from Jonathan and Johnny goes by Johnny. I suspect and from James. So I'll hand it over to Sam. Thank you. Yeah. So this is basically these European things came around because we've got a little bit of seed corn funding, which is aimed at bringing communities together. And so as Irina says, we're looking at telling people about the CSDMS community over here and vice versa, telling the CSDMS community and broader, you know, what some of the exciting digital things going on in Europe are. Thanks very much for US folk joining us so early in the morning. I know it's early, particularly early, especially if you go west, west of Colorado. So yeah, thank you very much for joining us. Yeah, we've got I've got one little bit of advertising to do before I hand over to James and Johnny. We have a, we're co-organizing a workshop with CSDMS in the UK in October time. And so I just wanted to say hold this date. We haven't got any specific information as in terms of what the content will be and logistics, etc. But we do have dates and that's the 28th to the 31st of October. And it'll be workshop posted in the Lake District, which is the northwest of the UK, northwest of England rather. And we'll be looking broadly at things around what what enables the next generation of environmental modeling. Details a little bit fuzzy at the moment, but watch this space over the next few months as we as we flesh out details there. And it would be great to see some of you guys there. And I can see some familiar names in the audience that I know will be really interested in the workshop. So that's great. Yeah, as Irene says, we have James and Johnny from the British Antarctica Survey here today. They are going to be telling us about what to read their title developing AI and research pipelines for operational use towards digital twins. And I won't give any more by way of an introduction because they will go through all the network themselves. So James and Johnny, do you want to let your slides up and check we're all working okay? Brilliant, that's looking good. So I'll hand over to you. Excellent. Thank you very much, Sam. And thanks CSDMS for having us along. So I'm James Byrne. I'm lead research software engineer at the British Antarctic Survey. And I'll just allow Jonathan to do a quick intro as well. Hi, I'm Jonathan Smith. I'm a principal research scientist who is co-leading the autonomous marine operations planning side in the AI lab. And just for those of you who might not know, the British Antarctic Survey is unsurprisingly the British effort towards polar research and operations. So we cover both Antarctic and the Arctic as well, but also anywhere that has an interesting cryospheric science and related scientific disciplines as well. So it's a very multidisciplinary research organization. So the point of us coming along here is really not to focus necessarily on modeling, but to try and state where we are in the British Antarctic Survey and the Natural Environment Research Council who are our administrative body with respect to building pipelines towards digital twins. So we're very much looking at how we're applying software engineering practices in the polar research domains. And we're aiming and what we're trying to describe what we're aiming for by employing the concept of digital twins. So I understand that Gordon Blair gave a talk to the group very recently. I know Gordon and he's definitely the person you want to be talking to when talking about digital twins because he will definitely make you enthusiastic for them. So I'm not going to tread on his turf at all. So, but what is really important is how we're looking at coupling the data and process-driven approaches that exist within the organization and how software engineering helps us do that. So just to go through how we're going to cover that. So we're looking at the stages from research through, from research and experimentation through to operations and then following on to impact. So this is very much how our strategic vision, our strategic vision within the BAS is structured is how do we make sure that research is delivering any of our operations will say impacts at the end of it. So there's very much the stages from motivation through to research. So in this case, I'm going to talk about ICENET-CI's forecasting, how we then use pipelines in order to apply that research into an operational domain. Then Johnny is going to go through the autonomous marine operations planning infrastructure. So that's really wrapping around pipelines. And then we'll start defining how we are approaching digital twins through standardized approaches across all of these different endeavors. So starting off with motivations to be very start right at the start. We're obviously focused in the British Antarctic Survey on studying the balance between ice and water and their interaction of a global climate system. So I don't think I need to explain to anyone here that the Antarctic Arctic are very significant influences towards climate. And we need to understand this a variety of different scales and across a variety of different domains. But in doing that, we need to be looking at driving real world impact. So we're not purely research focused. We very much integrate research into the way we approach our planning and operations. We aid decision making to optimize the use of our resources. We're contributing to wider approaches environmentally and technologically. We're influencing environmental and ecosystem conservation through our partnerships with other organizations. And we're very much looking at influencing policymaking and reporting. This is not an exhaustive list, but it shows that we need to be considering things at quite a high level at all times. So I'm going to start by talking about ice net. So this is something that I'm personally involved with very heavily. And I use it as a case in point as to why we take the approaches that we do when thinking towards longer term goals like digital twins. So it's a very useful frame of reference because it very much starts off as a research project. So at the top there, you'll see a very deep convolutional network, very common infrastructure called the unit. And we basically, we use that in order to process historical CIS observations, atmospheric data, potentially other forms of data in order to produce CIS predictions at the output. Now, this was done a few years ago by an excellent researcher called Tom Anderson, and he generated some research code. But then we've really worked out how to then wrap that into the, the funny little diagram you see on the right there with what I call the ice net onion. So this is very much taking research and what could be considered a model and then wrapping it in a pipeline and infrastructure and an ecosystem. And so that's what I'm going to go through here. So it's an example of enabling and lowering the barrier to ongoing research whilst looking to deliver multilateral operational integrations. And to do that we've got some key characteristics that we imposed, say imposed, that we converted Tom's original ice net code base with. So we first started off by turning it into a very dedicated Python library. So rather than it just being research code base, we very much formulated it into something that could be maintained and used very easily by other researchers and operations. We then incorporated patterns and common approaches to software engineering that allowed us to to utilize different AI ML backends that's further lowering the barrier for people who were doing research into these methods. And we also designed it in such a way that it would be very easy to fit into workflow systems. So this then lowers the barrier to operationalizing these types of this type of research. And finally, we very much looked at the code base that had resulted from all of this and said, well, how can we start to decompose the common functionality out of it and then generalize it to other environmental forecasting use cases? So hopefully that'll become a bit more obvious. But one thing to note here is that whenever we're producing or whenever anyone produces research like this, be it machine learning or otherwise, they start to produce lots of digital assets that then really communicate the value of that of that product, if you like. So ice nets library can produce all kinds of analysis and some of them displayed here comparisons with observational models or like metrics around how it's performing. But these tools that are embedded within it are not necessarily restricted to a single purpose. The purpose of the ice net library is very much around sea ice forecasting. So that offers us an opportunity to say, well, okay, how can we, in my software engineering lingo, incorporate the UNIX philosophy, we can build a library that does one thing, it does it extremely well, but then it delivers all of the assets elsewhere. And that's very much in keeping with the UNIX philosophy, which basically goes on along two points, which is make each thing do one thing well, and then think that all outputs will become another thing's input. And that very much like drove that central bubble of the onion that I described earlier. So in building out, as we layered up that functionality, so you end up with a library in the middle and you'll see in the top left of this diagram, the little ice net library, and it literally is just called ice net, but then you can build a whole suite of different tools and approaches alongside it in order to then layer up the automation, the interaction with other things. Some of these elements got generalized, so there's things called the one which is work in progress is called the download toolbox, which allows us to download all of the forms of data that we necessarily need in order to run this pipeline, but that can then be used by other pipelines as well. Also, there's a model ensembler, which deals with running very large ensembles, or very small ensembles, if you really want to, of these models as well. And we're in a process of decomposing this so that these tools can be used elsewhere. So, ice net is still on the journey. As you can see, there's only a couple of generalized tools out of this, but many more have been designed with this, you know, tear it out and use it for something else in the future, and you'll see why that's important as we go through. The other reason to think about wrapping that initial ice net library in a pipeline layer explicitly is because it facilitates us scaling out both our research and operations, that allows many people to be working on things at the same time without having to reinvent the will, but it also allows us to automate things, should we be feeding them between other systems. And this is definitely where my software engineering hack comes on, which you'll hear quite strongly, and Jonathan will hopefully balance me out a little bit with some proper science later on. But we are very much minimizing the duplication of data and efforts. So on the left, we have a consistent data store, like fed by the download toolbox now, that actually allows us to share the source data across many different runs and many different experiments that people might be doing. It also allows for a lot of configurability between these different environments. So you'll see there that they're called ephemeral environments, allows us to actually feed a config into a kind of blind blank environment, as it were, and to stump the config in there and then reproduce the results that were previously encountered. Conversely, you can just blow them away and minimize your usage and if you're running in HPCs and things like this, which is very helpful. So the ice net pipeline is very simple when drawn by this, but drawn like this, but it can be implemented in a number of different ways. At the moment, we just use bash for the environment setup, which might seem pretty archaic, but it works extremely well because it makes it extremely portable between HPCs. It uses the library. So these pipelines are not actually part of the library itself. It's another repository. It's another thing that wraps the ice net library, which can then continue to progress through different releases. And then the pipeline is slightly agnostic to whatever version of ice net you are using. As I said, we can use ensembling tools and configuration management quite easily. The outputs of the run, so those digital assets I mentioned that are created by the library can be made quite easily, standards compliant. So we actually call tools that are baked into the library in order to associate things like CF convention or compliant metadata to the outputs provided the pipeline is successful in producing a reasonable output. And that actually drives logic further down the chain. And it's kind of implicit documentation as well. So having this separate layer of a data pipeline, as it were, an implementation of how to use the system or the library at its core kind of acts as a form of implicit documentation, which actually makes it quite easy to say to someone, this is how you run a forecast, because there's actually a script here that runs all of the library components that produce a forecast from end to end. So there's a lot of complexity that could, you know, you could say are, well, why not put it all into the library, but then it makes the library extremely difficult to sort of generalize or break apart or modularize. And certainly it makes it a little bit more difficult to create these kind of ephemeral environments that can be spun up and destroyed very quickly. The other thing to note as well, this decoupling of the model to the heart of any of these infrastructures is very much allows us to look at automation. So if you're talking about operationalizing your data pipelines in order to feed other systems, then you definitely want to be approaching a workflow management system and looking to get triggering all of these things automatically and studying their outputs. So that gets me on to talking about infrastructures and why we might want to do that kind of crazy automation. Well, as I say, we're a very multidisciplinary organization. We do a lot of science around the period of regions and that means there's a lot of heterogeneous data in the mix. There's a lot of different fields of study, but people might want to create complex systems from many outputs that exist within this landscape. So the scale diversity and potential impact of coupling these systems together demands that we take some software engineering approaches to the integration of them. And that definitely drives us towards standardization. So you'll see a few things around here. We do quite a lot of work in machine learning around sea ice and iceberg tracking. We have a lot of Earth observation pipelines and numerical simulations relating to ice sheet modeling and observation of wildlife from space. For example, we see ice net on the top right there. We also have remote sensor networks, which very much another field of study that I'm interested in. So things like iridium communications from a variety of different experiments in the field are very important. We're also looking quite a lot at data improvement using various types of research. So these can be, if these are reusable libraries or have exemplar pipelines, they can be dropped in nice and easily. And then we have static data sets and ship and remote vehicles that I'm definitely not going to tread on Johnny's talk in a moment. So hopefully I've demonstrated that the only sustainable operational data, environmental data science will employ some level of pipeline development to deliver the digital assets and impacts responsibly and efficiently. I'm a software sustainability fellow, I know Sam is as well. And a big part of this is actually advocating for approaches that are going to reduce the negative impacts of what we're doing in environmental data science, either in environmental data scientists. So now moving on to infrastructure. So why you might ask, are we talking about infrastructure in a slightly different way to the pipelines themselves? Well, it allows us to share that digital assets used and provided from systems consistently. That's allowing people to undertake research, do the operational integration. It's a way of feeding systems that might then be responsible for furthering on those assets to other places. It's also a form of education and appropriation. It's a way of giving people transparent access, fair access to the digital assets under the hood. So you definitely want to be looking at infrastructure in a different vein to the pipelines themselves, which can tend to be quite complex and heavily developed. So again, we go back to the motivations of why we're doing this. So once the pipeline assets are produced, they're delivered to one of potentially many hosted infrastructures that we might have. In the case of iSNET, this could be to talk about where we might want to place new sensors or where in particular we collaborate with WWF on various elements of ecosystem conservation. And there's a bit there about autonomous marine operations planning that again, I'm not going to touch on Johnny's turf too much, but this is where the digital assets get fed out into other infrastructures in order to help them do what they need to do. As I say, when you separate out into a separate, when you separate the pipeline and the infrastructures from one another, the digital assets you produce within the pipelines then become your interface between the two, which means the infrastructure can develop very, very fast and very heavily and be modularized in great ways, as long as it just deals with the compliant data that you're producing from the pipelines. And that layer of separation really helps you to iterate quickly. So I won't talk too much more about that, but I will hand over to Johnny now. Sorry, I've missed the slide there. So these are some of the infrastructure interfaces that we have, sorry. So you will have, as I mentioned, we have a collaboration with the government and WWF. We provide a variety of different forecasts. The infrastructure provides things like APIs as well as user interfaces, but also automated systems that then send alerts to people. So now I will definitely hand over to Johnny. There you go, Johnny. Perfect. Thanks, James. So I'm going to talk briefly about autonomous marine operations planning. So what we've been doing in this work is we've got a proviso to meet net zero carbon production by 2040. And this is under the natural environment research council and bass is part of that council. So one of the main aspects of carbon for the whole of bass is 60% of the carbon is produced through ship operations. So any reduction that we can make in ship operations and think of ways to do things differently can actually lead to significant carbon savings. So our work in autonomous marine operations planning is looking at using these pipelines that James has discussed before to first dynamically mesh the digital environment. And that's on the left hand side represented by meshify. And then to constrain how things like sea ice or ocean currents or winds or waves affects the response of the ship or autonomous vessels. So what we do is we take all these different forecasts or legacy data sets. We mesh them to create a digital environment. We then determine what the ship actually can then do in that digital environment before going to the next stage of the project where we do eco and time friendly polar navigation. So you can think of this work very similar to Google Maps as you get in your car. You now get a specified fuel usage routes as well as the quickest route. So we're taking characteristics of how our ice breaking vessel the Sir David Attenborough responds in sea ice conditions. And we can actually then incorporate this into a route planning scheme to then determine the fuel usage for this vessel between a start location and the destination. But it doesn't just stop there. So when we actually get in the ice things change a bit. So you can consider the next stage of the project as something like Tesla's autopilot. So you're changing lanes on a motorway is constantly determining the risk of these actions that you're taking. So the other work that we're well underway and we'll look forward to share in the future is ice router. So this is a probabilistic machine learning method that can incorporate uncertainty in the sea ice conditions and then determine risk aware routing at much higher resolution. And then once we've got this understanding of the fuel usage for these different marine routes we can go to the next stage. So it's taking a level out and this is autonomous marine planning. So you can consider like Amazon delivery logistics when you get a package delivered they've determined what the best van to put the package on is and then also in their delivery logistics they now incorporate in the states a left hand right hand turn. So they take a lot of right hand turns to minimize the risk of going across traffic. So what we're doing here is we're using these digital environments we're using the polar route work that we've been doing and then putting it all into an AI logistics plan so this is a heuristic based planning scheme. So if we go on to the next slide I'm just going to talk you through polar route first and then we'll go through a very brief background to the logistics plan. So we're leveraging all this environmental information to determine these carbon and fuel efficient routes and we're now operationalizing this on the bridge of the Sir David Attenborough. So just for this little example here which is taken at the peninsula around Antarctica this transit would take about one day 18 hours and by taking the eco-friendly route you're increasing your transit time by 14 minutes but you're having a saving of almost 4% carbon and what does this equate to? Well it's the sabers running a petrol powered car for almost two years and then that's an insane saving that you can make only by increasing your transit time of 14 minutes and then using this work we can go on to the next stage so James if you switch to the next slide. So scientists are submitting ship time by application forms so we can leverage this information to then say can we organize the science being done into a better system to minimize the fuel usage. So what we see on the left hand side is the marine facility planner where scientists would submit their science proposals. In the middle you'll see a ship time out application form and with some key information so this task for example is a cruise it requires a total of 60 plus days and goes from a point of zero to a point of zero and then the next stage is to understand constraints about the item that could be doing this task so for a ship it would be this is what the crew would need this is the equipment you would need a ship has to be operational for the whole time of the task and this is like giving very basic constraints as machine code that a planner would be using as they're going through this decision so then once we've done that you can move on to the next slide. So we can then add constraints and all these things and we can look into three different time scales so if we can if we're able to reconcile a good planning scheme we can look at ways that we could have improved in the past to minimize fuel usage we can look at ways that we can plan five years plus ahead and then also we can quickly plan a very short time intervals this is called now casting so if something goes wrong shit hits the fan a mechanical problem rises we can replan multiple months ahead or even multiple years and this is only possible if we leveraged the full understanding of environmental forecasting route planning and marine logistics planning and in the marine logistics planning we're basically leveraging the constraints that a marine planner would use and if you move to the final slide in my section we we've just done a proof of concept where we've looked at the national oceanography center or knock previous five years from 2017 to 2023 it's would normally take three weeks to manually plan this and our initial proof of concept that this is early stages of this project we've already got fuel saving okay it's only 0.3% but that equates to 60 000 pounds worth in cost savings and this is equivalent to 60 000 tons of fuel and it takes the marine planner the autonomous AI system three minutes while it would take a marine planner three weeks so we're now giving these marine planners decision support tools that they can quickly try new scenarios or test out new ideas so we're going to basically expand this going forward and basically expand to the next stages so I'll pass back to James cool thank you very much Johnny so I just move on to the the last layer of the bubble or I say bubble sorry it's a bubble diagram but it's the last layer of the onion you'll be glad to hear so the end game for Bass is to be looking at the idea of an Antarctic digital twin so I drew this this diagram a long time ago when we were trying to work out how the Sir David Attenborough fit in with the idea of having an Antarctic digital twin with all of these different systems working together and I think this comes back to what Gordon was talking about in his talk in praise of the arrow or when he was talking about in praise of the arrows it's the idea of all of these systems being able to talk to one another in so much as you can couple the data and process models together to ask some of the questions that you need to as an integrated question as it were but in order to do that you can't build an infrastructure every time you can't build it or you shouldn't have to build a large middleware infrastructure every time you want to ask a new question so this idea of having a minimal middleware implementation basically requires data models process models operational models all to exhibit some standards when they are built so that you can quite easily come along and say I tell you what I need some information from over here and over here in order to ask some of the questions and this is really I think where Johnny's team has been focusing their efforts for the environment is obviously very difficult but the recent program called the information management framework for environmental digital twins which is not a short title so we call it IMFE really looked into what are the governance and implementation structures that you need to think about in order to make things interoperable by default with the with isnet in mind I drew this diagram and really the only things that need to change are the catalog descriptions of what assets make up isnet and the presentation of those two other components that you might want to integrate now that's a very simplistic way of looking at it but actually it doesn't that really conforms to this thin middle approach to building complex systems and it's also very important for consistency in building sustainable infrastructure because then you're minimizing the amount of overhead that you have to maintain in order to sustain that integration for whatever purpose it is which is very important if you've ever done any support work so this is a work in progress and the IMFE was very much looking at the top-down approach to how to do this but we're also very keen that there's a bottom-up set of developments that are just looking at building something that conforms to this initial picture and then over time the emergence of digital twins in the environment will become more of a reality. So just to go through a notion of generalizing this obviously I talked about isnet there I kind of came up with this diagram which basically says that you would have a similar template across all of the components that might need to interoperate. So the only real point to look at on the left really is the things that you're describing to other people so it might be the generalized components that they can incorporate into their own systems the data that they might want to use to ask questions and the assets within any given component. Generalizing these kind of implementations is also very important as a safer for people being able to adopt things within their own systems so in the case of isnet we're looking at CI's concentration but should we want to come use these things like the ensembling tool for example have been successfully used in IC emulation where we've got a numerical model a process-based model that requires some level of emulation in order to be operationally expedited answers and this is something that we're looking at internally but you can do this across the board you can say okay at the infrastructure level we might want to have conformant interfaces that are consistent across different sets of predictive systems or in the case of things like the the routing packages you might have a whole load of cartographic info structure for displaying routes and this is where really where it comes from it's building things with that generalizability in mind. And so this just brings me on to the very last sort of summary of building our environmental digital research infrastructure and so it's building an infrastructure of the future so it's very much building it a brick at a time so I won't mention as it's being recorded the name of the blocks that are on the right hand side there because I don't want to get into a trademark issue but there are some clear principles that we should probably embody so common capabilities should be exploited and openly utilized so that's very much advocating for the open source approach we should foster the community development far and wide and efforts like this where we can come and talk to you and and hopefully you can connect with us are great for that because only by building communities are we really going to understand what's already available we need to make it easy to align to existing efforts from the outset so that is very much looking at the strategic ideas that are coming top down but also then being willing to align to them from the bottom up as well and hopefully therefore driving them. We need to remember that our environmental research is often used in other contexts so operational infrastructures are very important to pass but you might also we might also need to just remember that there might be social impacts there might be social uses for what we're doing as well. We're trying to champion new environmental data science through the community as I said and we should be willing to showcase high impact solutions that can be reused elsewhere and promoting that reuse and so I'll stop there I've always got a nice onion at the end because I really like the alliums so hopefully there's a couple of questions and please do feel free to connect with Jonathan or myself on the emails there thank you very much I'll stop sharing that. Thank you very much both that was that was really really interesting have we got any questions from the audience? I think you can unmute yourself or put your hands up or put your question in the chat if you'd rather do neither and I'll keep my eye on the chat to get us warmed up. I kind of feel like BAS is ahead of the game in a lot of senses in this realm like what you were talking about there James seemed really well developed and I'm kind of curious how much how much of that was developed out of necessity because for instance you have this you have ships you have autonomous things that you need to root as the example that Johnny gave there so how much of it was developed out of necessity and how much of it was pre-planned so and I think what really my question here is how much of the thinking behind this was done beforehand and you sat down as an organisation and thought we need to build this digital infrastructure we need to build this onion to use your analogy how much of it was done reactively like for instance you build the the research bit in the centre of the union and then realise that you need the next layer and then the next layer. Yeah it's a really good question thank you I think the I would love to say it was all pre-planned and orchestrated from a strategic level but I would be slightly disingenuous if I were to do so. I think there has been a bit of one of the benefits of working for BAS and the Natural Environment Research Council there's a whole I think is that all of the organisations have this sort of mix between research and operations so you end up with a very diverse pool of talent that is offering new opinions and I think very much when we see the AI lab for example at BAS that actually gave rise to the partnership with the Alan Turing Institute who are the AI leaders in in the UK that gave rise to ISNET that created research but then it was allowing people to see it and promoting it that then sort of gave us the impetus for someone like me to come along and say well actually I work in IT and I've worked in industry if you really want to make that available and useful to people then you need to start wrapping it in you know nice friendly layers that people can come along and integrate with and I think so it is it's always going to be a mixture of proactive and reactive but I think this really sort of points at community is the thing that makes it work is really just allowing people to input ideas and then seeing where they go I mean the some things have been you know not I wouldn't say unmitigated disasters but certainly we've had a few threads that have collapsed but then we've had other threads like the AMOP team who utilised the ISNET forecast where that research because of our need to get to net zero has just ballooned and Johnny I don't know if you want to come in there like because the team is growing very quickly yeah this reactive side of things was probably the main driving factor as things are changing and as we've got these new targets to meet you have to have an infrastructure that can support it and then there's talk of scaling to the point by 2040 to have hundreds of autonomous vessels all operating together and the only way to do that is to actually have the infrastructure that can support it and just to pick up on that I think that's where there's a clear strategic direction but the the the points in the roadmap are not like yet always thought out so that's what we do reactively I feel real thank you any questions from other folks I was curious about the fact that you start presenting like multiple sources of data like AI generated predictions and like then there's like end users that are really like trying to make decisions and doing policy with it right you're talking about like the connections to the world WWF etc and so I wondered like how difficult it is to communicate like sort of the uncertainty in that whole process and whether that's like acceptable to your like decision making like partners yeah it's really I mean from a from a predictive point of view that's really troublesome of course is how do you represent uncertainty and any of these types of systems I think the big thing for me is not being an environmental research per se researcher per se but rather than someone who builds those environmental infrastructures is to be very clear about what product is it is that you're developing and what solution it is in the real world context of that uncertainty so say for example to put a case in point if we're going to develop an early warning alert system then the research associated with the logic behind that is public research so that you know they have a scientific publication that backs up the reasoning for having an alert based on it but at that point you know you're as a technologist I'm handing over that to public research that says this is the method used you have to be sure that you want to use that method in order to inform say a community at the very end I think that's really important as well is that we you know you're not removing your the scientific life cycle you're like supplementing it with digital delivery and you're not claiming that one because this is a danger with AI in particular is for it to say oh well we we built this really fancy tool why don't you trust it and it's just kind of like well you have to prove it it's not it's not an all or nothing yeah great any other questions I've got one for Johnny actually so this this aim up tool sounds like it would be more broadly useful than just to BAS and my question simply is it being used outside of BS or the research councils or is it it's it kind of internal only so the aim in the long run is to tie into the marine facility planner which is currently being used by many different national Antarctic research councils so I think the Australian group is using it the Norwegians there's several inside the UK that are using it but at this stage we are only very early days so in the long run it will be tied into a pre-existing system but we need to first get the proof of concept there and get it along the line brilliant thank you we have a question from Juan sorry for the pronunciation if that was incorrect oh no it's it's great thank you actually sorry for the pronunciation Dr. Byron okay I wonder how from your perspective how do you see applying this architecture or a modification of it to a coastal water quality monitoring program like something related to to monitoring hydrodynamics and but that has several layers of for example socioeconomic and socio-ecological variables and also has to deal with this this issue making like pipeline how how do you see it applied with yeah it's a good it's a really good question so I think so we in NERC we have several different centres so we actually have a centre for ecology and hydrology who I think would be quite well placed with this but in terms of specific implementation but actually there is a collective effort that called the environmental data service that is really looking at how do we make the heterogeneous data sources available almost as quickly as possible one might say so you would use pipelines in that case in order to take data sets if there's any way of automating quality assurance and publication the publication process of a data set and making it available within that environmental data service you then build your infrastructures on top of that in order to provide data delivery or particular use cases and then obviously I'll say obviously but then that availability of data through something like the environmental data service would then allow you to build the digital twins as it were that allow people to ask questions of these disparate data source so I think the the specific yeah the specific hydrodynamic question I can't answer to but the the general consensus I think it's fair to say within NERC is that actually we have to be building these types of pipelines and infrastructure in a generalised sense so that everyone can benefit hopefully that answers your question oh wonderful thank you thank you and I think in a lot of senses that's where strategic proactive planning kind of comes in because it's it it's quite a difficult task isn't it thinking about data coming from different research centres from different disciplines etc and I think we're probably only really at the start of that journey and thinking about you know what the environmental data service the EDS could do in terms of you know providing data that could be used in digital twins and that type of research infrastructure yeah definitely at the start of the journey I think the promising thing is that by having all of the centres involved in a project like that you're enabling you're bringing everyone into the conversation the worst thing is that you develop digital research infrastructure which is then bespoke to a individual centre and then try and retrofit it somewhere else so at least it's acknowledged as like you say a strategic development it's very important and I suppose guess opening opening this out to not just the UK and our research centres a lot of this would be then generally applicable across any group of organisations that have data around the broad environment or social things just because we're talking about UK research centres doesn't mean that a lot of this stuff isn't applicable elsewhere I think that's a really important point actually is that the idea of digital twins is golden rightly pointed out you know that comes from the engineering and built environment more than anywhere else certainly as an ex aeronautical engineer or involved with aeronautical engineering they were very commonly used but they were constrained so we've taken that influence and we should definitely be forwarding it on to other areas that might be interested in adopting these technologies so openness is very important yeah definitely I mean just listening to like how powerful this technology could be and the shipping planning like actually like triggers sort of this idea of like wow if you would do this in New Arctic it would like actually be used for like Arctic shipping and like potentially like for like vessel movements that like are strategic or like military or so like so I don't know it seemed that the the openness of like sort of the scientific development or the development for this for scientific purposes is a bit of a conflict in that in that realm potentially so yeah I don't know whether you've like heard anything about that or gotten some other people to comment on that so at BAS we have to adhere to the open source code which I think is probably which means that everyone can use it there's always that proviso that you can use it at your own risk and for your own operations but the the advantage that it has if you use say root planning software to save fuel no matter what it's being used to save fuel for it's still a benefit saving fuel so it's a difficult model than that one but yes if you build the technology people come to like use it that's really interesting yeah I think ultimately the benefit of being open and allowing everyone to use it far exceeds the well hope would exceed the the risk of being open because ultimately the risk yes would be from people who want to get the leg up on on delivering services like or you know automated marine planning but in reality they're going to be at the same stage as everyone else so as long as the support is given to people who want to adopt it for benevolent means then hopefully hopefully you're you're going to your impact story is going to be a lot more positive yeah I suppose yeah if stuff ends up being used for nefarious means for give an example it's better for it to be open source right rather than being something proprietary used by is is one way of looking at it it's a really interesting topic isn't it okay any questions from anyone else if not then I would like to thank James and Johnny again that was that was really interesting I've jotted down lots of things to follow up on so that's really good great talk this is has been recorded so it will be online later for anyone to watch back the next talk I believe I'm just checking the webpage now is on the 26th of March 26th of March and it's going to be with mark what systems services can do for you overview of CSDMS products and then we have another two talks coming up in April on the 16th and the 29th and just for reference I'm going to post those quickly in the chat now Irene did you have any closing comments no just to thank James and Jonathan for like showing us and like sort of highlighting the like more infrastructure parts of the of the system too which is like something that the CSDMS community always like embraces that there's this like whole machinery in the back end of science that should deliver and helps like it needs a lot of thought too and so it's nice to see that that commonality is there across organizations and that we can learn from each other