 So my talk is going to be different than the previous two talks. I'm going to talk specifically about software, so no real science, just software. And, excuse me, thanks to the organizers for inviting me. So what I'm going to talk about is an extension of the basic model interface for coupling mod flow to other models. I work for the USGS, my name is Joe Hughes, Chris Langevin, he's also with the USGS. And this has been a collaborative effort between us and Del Torres, our time rusher here. So let's get started. All right, maybe you don't know what mod flow is so I'll tell you. So, mod flow started out it was originally released in 1988, well actually 1984. It's a groundwater model that's how it started out so it's got a long history in the USGS. And so the latest version is something we call mod flow six we released it in 2017. All that doesn't really matter. But the one thing that that we've done in this newest release is trying to rebrand mod flow because it's kind of transitioned over the years and I'll have a slide to talk a bit about this. And from really something that is strictly a groundwater only model to something we're calling a hydrologic simulator that groundwater is still a piece but we also have things like surface water some way to represent surface water to kind of evaluate surface groundwater interactions. And this, this latest version is is an object oriented version. So, you know, over all these years it started in 1984, and as there have been releases since then and this is the sixth one. But they've all changed somewhat over that the way they're constructed again whatever the latest, you know, kind of, maybe not fad but kind of techniques for programming are available at the time like in 84 there wasn't dynamic memory allocation and in the fourth round came one line later so again these models of transitions. So it's object oriented because right everybody likes to do new things with with software. So that means that we can have multiple versions, multiple models of the same type, and also multiple models of the different type again, getting to this thing that we're calling it a hydrologic simulator. Now is basically we can simulate groundwater flow but we also have capabilities for simulating flow and channels, lakes, unsaturated zone, and then there's a groundwater transport component as well. That can also do transport in those channel and lake and unsaturated zones as well. And then we're continuing to develop this. The latest version has has the capabilities of basically a whole host of of of versions of mod flow in the past. So again it's basically incorporated all of the kind of the history of mod flow into this one one version. And then within that is this application programming interface this API that we've developed that I'll bore you with for the rest of this talk. There's just some pictures. I don't know why that didn't show up that's interesting. There's a white these white spots here. There should be things there that you can't see. So, again, we can support these multiple models of the same or different types and what that allows us to do is embed these models within each other. Each of these models these little squares that you see here could run separately by themselves or they can run together and we can use a variety of different discretization types. So unstructured and structured. And, and, and this is kind of this concept right we have these these halos that we can actually use to exchange data between these models so that we can do these simulations this would be the release of a contaminate that basically is moving from one grid. To another grid and this is a terrible model nobody should do that because you get very big blocky stuff at the end. But again so so it's a pretty complicated system that we put together. And again but this object oriented approach that we've developed is is has lends itself to that but then also create some complications that I'll talk about for our implementation of the basic model interface. So I'll just talk about a brief history of basically us coupling mod flow to other models. And so it started all the way, at least the earliest one that I know of is is something that coupled mod flow to a channel model called branch in 1996. Since then we've had something see what which does variable density flow it's coupling of mod flow and empty 3d in 2002, and so on and so forth all the way down to we've even with the release of this latest version of mod flow there are still people that are mod flow to other things. And so, but a common theme in all of this is what we've, what, what people have been trying to do for the longest time is kind of incorporate the surface water component, or other model components within mod flow. And, except for this rass mod flow, all of them basically, you know, had some kind of, you know, custom interface that was developed to build these two models together. And, you know, certain like this mod branch uses like the first version of mod flow, 88, and it became. And that's why we, we, we, we started to go down the route of implementing the basic model interface is that it was always so hard to basically, if a new version of one model came out, it was always so difficult to actually then incorporate the latest version into some coupled models. So that's why the first and last version of my branch came out in 1996 because it's been so difficult to do that. So within this API within this latest version of mod flow, we've incorporated the basic model interface and also something that we've called the extended model interface. And the reason that we've done this as many of those previous codes what they did for the, they had a tight coupling of the two codes, so that within a single time step you would iterate back and forth. Within that that iteration till both of those models were more than one model was converged. And that's something that the basic model interface doesn't doesn't support it's basically one model runs than the next model runs. It's basically kind of a feed forward. And then within this API there's also some specific functions, mostly related to the object oriented nature of code. So just kind of graphically so this is the, the standard basic model interface we have our initialize, we have our update, and then we have our finalize. Again it's all straightforward. People that are interested the mod flow structure, and it's basically any controllers construct controllers approach. So all that we've done with this extended model interface is basically expand the update portion. So, this part's just some miscellaneous details right where you get data into the model right at a given time step, and you do the time step and then you finalize right where you write output, because one of the things that we do right if we're running this model multiple times within a time step we don't want to write output, each time it goes through. I mean within this do time step basically what we've done is expose basically what we call our outer Picard iteration to where we formulate our matrix, and we would do this for multiple models you formulate your matrix. You know solve the matrix and some kind of linear system of equations, and then test whether it's converged and this converge to be based on just this one model or two models right. I mean that you're exchanging between these two models. Are they in some kind of equilibrium at that point. So it's really a pretty minor extension of BMI what we've implemented but it allows us to do this tight coupling. I won't talk about this for the sake of time. Our current state for this API and I'll show some examples I won't bore you with just slides. I'll bore you with some boring examples. So this multi model and multi package, you know capabilities makes it a bit complicated with BMI because you know the standard BMI calls are basically get value set value. We have two models would say if we're talking about hydraulic conductivity, we have two hydraulic conductivities there isn't a unique hydraulic conductivity for the model. So we had to basically come up with some ways that we can access individual pieces of the data. One of the other things the current state is. We started to try and restrict what people could use but it seemed inevitably when we restricted what people had access to someone would contact us and say. We do expose this variable. So what we did is basically expose everything, which means there are no guardrails, which means that somebody could modify anything within the code, just, you know, internal variables. And so, you know, again, no guard rails, right. And the other thing at this particular point, you know, and I think it's generally the case you, you know when you're coupling two models you have to have a good understanding of those models. And in our particular case variable names, right. We're still working on standard names but and then also derive very something that maybe an input variable but somehow the model calculates internally, but may not calculate, except during the initialization phase. So there's some complications along that. So we had a publication in 2022 environmental modeling and software environmental software and modeling I sometimes reverse those that talks about this. The application programming interface, the extended model interface and our implementation and within that that particular paper. We had a number of examples. And I'll talk in more detail about this metaswap mod flow because that that one's actually using the XMI. But within that paper we basically have a simple example where somebody just wants to try out a new what we call a package so that would be some process that you're representing that interacts with the groundwater system. We also use similar to what what we saw where we're using sci pi to basically do optimization. I'll talk more about that also para mass and mod flow and James, I'll point the laser at him he'll have a, he's got some presentation on that poster presentation on that. And then also mod sim mod flow which is a river operations model, coupled to mod flow. So let me go into this one. So what's metaswap swap. So metaswap is a model developed in the Netherlands it's a meta model. There's, it's a metal model of swap. So basically what it does is it's it's a emulator of Richard's equation. It uses the sequence of steady state water content profiles, and he uses a swap code to build a series of tables, right that basically relates that the groundwater head infiltration and root uptake to the main pressure root zone and groundwater recharge. So, again, very fast can go through and, and, and represent Richard's equation. We can do irrigation with this. And because of our delta is colleagues, it's used the reason when we did this example is it's used this coupled metaswap and mod flow are used in their natural national hydrologic instrument. And so it's used extensively in the Netherlands it's tailored to the Netherlands because in most of the Netherlands that depth of water is less than two meters and actually having a real Richard's emulator is important. So these are just, you know, kind of some some of the code. What we're using in this example is something. These are both things that delta is developed one is this I mod coupler, which is basically similar to pi mt but it's specific to this metaswap mod flow coupling, and then something xmi pi which is would be similar to pi mt, except it's our particular flavor that basically implements also the xmi extensions. And this is the update function, and we have within this update function where we're exchanging information from mod flow to metaswap. We're preparing time steps and then within this iteration loop within this do iteration we're basically calling multiple times this within this iteration loop we're calling metaswap and we're calling mod flow. And then when we've got convergence between these two are basically finalizing than writing out but. And some of the data that's exchanged this is the metaswap to mod flow coupling part of things were basically updating the groundwater storage parameters based on metaswaps understanding what the storage below the below the water table is. We're also exchanging recharge basically the water that comes out of the unsaturated zone and recharges groundwater system. And then we're also if irrigation is turned on we're basically then setting groundwater pumping rates based on the need for for water within the to apply irrigation and then when we exchange water for exchange data for mod flow to metaswap basically what we're exchanging is that that that's the condition that basically we want to equilibrate to on on both in both of those codes. And so this particular example for metaswap where it's, you know, again I'm a software developer do little tiny tiny models so this is a nine by nine by three so it's nine rows by nine columns by three layers you know it's it's it's a nice picture of the world. We've got an agricultural land use potatoes and irrigation is enabled. So this would be like you know one of these polder systems in in in the Netherlands where we've got canals on both sides. Here we've got an irrigation well and again here's our, our farm field and working to have an observation point. And then this is a cross section here. Again, three layers seeing you know the upper layer is is the one where the water table is fluctuating. And then this lower layer is a deeper layer that we can pull water out of. Let's settle event and what we're going to do is represent relatively dry conditions in 2018. And here are some of the results. Some of the interesting things I guess here so since we do have a full Richards equation. This little again you can't see the line that's funny how things disappear. Where we're actually pulling water out of the groundwater system up into the unsaturated zone. So, you know that's one of the capabilities that we have. So, and then we're also applying irrigation at this time running short on time. So here's just a picture of the groundwater system where we've got, you can see a little dot popping around here that's the rainfall that's shown there. Again, so we've got reach charge conditions when we get to this point we'll see that the pumping well will start pulling water into the pumping well. So these are just basically portions of the upper two layers, not seeing that deep layer in there. And it's a tightly coupled solution and running out of time. And so, in conclusion with this API that we've developed users can create these custom packages without making changes to the under underlying code which was not the case which is one thing. Not the only thing but it is a great thing about the basic model interface. And then again because we support both BMI and this extension we can either do iteratively coupled or tightly coupled simulations. And then for us as software developers. This provides us with a sustainable way to design and maintain these softwares and then couple these codes that we've done so far and future codes as well. So with that, I'll take any questions. Thank you, Joe. That was awesome. We have time for one question. The software is not sexy. Everyone wants to break. Hey, thank you. I'm wondering when you talk about the tight coupling, for instance, if you cover the ground water model with the hydrological surface water model. So do they have any information chain for example like infiltration for a surface water model. I mean one thing that could be exchanged would be the surface water head. So that you could do bi-directional flow of water between the groundwater and the surface water. So my understanding is that the surface water model will kind of like recharge the groundwater. And the groundwater, the exfiltration will go to the surface water as well. So the two models can influence each other. So when you're tightly coupled, so how often do you specify the frequency they interchange each other. Well, so if we were doing the tight coupling, that would be within the time step. So as many times as it took to get convergence, you would solve the surface water model. And it would come up based with what the groundwater heads were. It would come up with basically some exchange of water that went between. And you would solve the groundwater model again with the updated surface water levels. And then you would do those until the surface water levels and the groundwater levels were no longer. Changing or the flux, whatever that was, you know, and then when those were no longer changing, you would say that the time step is complete. And then I can move to the next time step. Thank you.