Solving coupled systems video transcript¶

Hello everybody, John here with another fantastic edition of the Practical MDO series. Today we’re talking about solving coupled systems.

When you have a coupled system or an implicit system you must use a solver to converge that system. We’re going to show you how to recognize when you have a coupled or implicit system in your model, when you need a solver, and then I also have a few notes about how to identify coupling within OpenMDAO. This is just an introductory lecture to the idea of solving coupled or implicit systems and there are so many different relevant topics that we could and should discuss. That being said there are other lessons related to this that I highly encourage you to check out and they’ll be linked in the description below.

This firmly has to do with the modeling portion of our practical MDO course.

Let’s first focus on how to recognize when you need a solver. What is a coupled or implicit system and what does this mean? I will share a few figures that come from Engineering Design Optimization by Martins and Ning and I have a link in the description to a free pdf of the book with additional information.

So here I will show you a few different representations of the same system.

Here is a system comprised of A, B, C, D; some different components or subsystems and the little dots on the off diagonals represent data being passed between them. This is commonly known as a design structure matrix. We use a lot of extended design structure matrices or XDSMs throughout this course but on the left here is just kind of the idea of a very simplistic design structure matrix. So A is passing info to B as well as D. B is passing info to C and C is passing info to D. There’s no notion of backwards coupling. There’s nothing that’s downstream of another component that’s passing information to an upstream component like B is not passing anything to A. D is not passing anything to B for instance. If there was a sort of coupling there’d be gray dots in the lower left triangle instead of just the upper right triangle.

Here is a directed graph. It’s another view of the exact same system again we have A, B, C, D; A is feeding information to B and D. B is feeding it to C and C is feeding it to D. This shows the exact same system. For some people they like kind of looking at the system in the design structure matrix, other people are maybe more used to the directed graph. I know a lot of the machine learning community is looking at directed graphs; it’s reminiscent of neural network diagrams a lot of the time, so maybe this is more helpful for you.

And then on the right we have the XDSM or the extended design structure matrix. I have an entire lecture dedicated to understanding XDSM diagrams and what they mean. They come up often in MDO and are a kind of standardized way to view models and the relationships between models. Here we see again, you know, A is passing to B and D, B to C, C to D; there’s no backwards coupling; there’s nothing going upstream. I just want to rehash that, you know, these are all three different depictions of the exact same feed forward system. We wouldn’t necessarily need a solver for any one of these given that they’re all explicit components and they’re passing information only downstream.

But we’ve now added coupling! Now C is talking to B. C is taking information giving it to B and B needs information from C to compute what it needs to do. So all of a sudden we now have backwards coupling. If sirens are going off in your head, yeah, they should be. We need a solver now to resolve this backwards coupling. Note on the left hand design structure matrix we now have a dot between B and C on the lower triangle. Additionally on the directed graph in the middle there’s an arrow going from C to B and of course we already had the arrow going from B to C so now we see, okay, there’s two way coupling. This kind of two-way coupling is very apparent in the directed graph. And then lastly on the right we have the XDSM and we see that B is passing u_B to C and C is passing u_C to B.

Okay so these all show the exact same system now; it’s this feedback coupled system and we would need a solver on something like this. I’m talking about subsystems that pass information both downstream and upstream of each other. Now these are all explicit components but if we had even just one implicit component we would also need a solver here. Please see the linked lecture about implicit versus explicit components to learn more about what the differences here are. For the purposes of this just know that explicit is something where you can kind of write out an equation to solve for the outputs with respect to the inputs. Whereas for an implicit system you actually need a solver to obtain the state values for that system.

Okay so that was a quick look at how to recognize when you need a solver. What that means, you know, when there’s feedback coupling or an implicit system. Now let’s solve a simple system by hand. Before I do this I’ll introduce a little bit more of the the terminology here and this crops up in a few other lectures. But we could be talking about any system here we’re trying to get the residuals of the states, this x vector, to zero. So we’re trying to change the values within the state vector x until we know that we have the correct solution.

There are nonlinear and linear solvers and there’s a there’s a lecture that goes into much more detail about both of those, and here’s a linear system. So a linear system is kind of canonical. It’s Ax equal to b where again x is the state vector, A is a matrix, it might have any arbitrary number of values here and b is a vector as well. So here we’re trying to change the values of x until A times x equals b. We can rearrange this and see that Ax minus b needs to equal 0 and that is the same as our residual equation of x equal to 0.

Now this is for a linear case, let me show you a nonlinear example here. So this is something that might be reminiscent of high school algebra. It’s two equations and two unknowns. Here we have x and y and we have two equations relating x and y. This is a nonlinear set of equations and we can solve for x and y by hand. By rearranging the bottom equation, y minus 3 equals 3 x squared, we can get a representation for y. We can then plug this in to the top equation and get only x within this equation. Then by expanding out this binomial multiplication and kind of rearranging the terms here we see that x must equal zero. Okay in this case that was pretty simple. We like that. x equals zero, now we can plug it back into the bottom equation here and get y must equal three. Okay that’s very straightforward, this is no problem. I’m showing you a nonlinear system and I’m telling you “hey systems are tough to solve” but you just did it no problem algebraically on the screen.

But imagine that we have just three equations or three unknowns. Or we can have a whole bunch more equations and unknowns. Anything that can be written as residuals of x equals to zero is a nonlinear system that we might want to solve. Here’s something from my PhD dissertation where I was doing computational fluid dynamics or CFD on a supersonic aircraft. Here there are a whole lot more than two or three equations and unknowns. Each one of these mesh cells has unknowns associated with it, including the velocity of the fluid around this aircraft. You can imagine that if we have hundreds of thousands or millions of cells, all of a sudden the the system of equations becomes extremely huge.

So this just gives a sense of scale for kind of the size of nonlinear systems that we’re actually solving when we’re doing these large-scale MDO problems. There are many such cases where you have thousands or millions of unknowns and we need to solve them efficiently. This is where using computational solvers to solve coupled and implicit systems really comes into play.

Lastly I’ll have some notes specific to OpenMDAO and I’ll also show a little bit of the accompanying Python notebook.

I want to first highlight that in the command line terminal there are a few different options that can really help you. The first is the OpenMDAO check command. You just go to command line utility, type openmdao check and then the name of your Python file, your run script where you have your model, it will output a lot of really helpful information. In this case I’ve set up Sellar example to be a coupled system that does not have a nonlinear solver on it. When you run this check it says “warning: this contains cycles” and it lists the cycles, the components that are talking to each other but it says “hey we don’t have an iterative nonlinear solver here or a linear solver.” So this is the most clear-cut way within OpenMDAO to check your solver setup. If you have a model or a file that you’re trying to run you can just type openmdao check. It will go through and do multiple checks and I want to stress that it doesn’t only check the cycles for your solvers but it checks a lot of other things too; if you have components out of order, if you have a recorder on the problem, if there’s a component with no outputs, maybe it only has inputs but you’re not actually giving anything else to any other part of the model. There’s a lot of helpful things within this openmdao check command.

Another helpful OpenMDAO tool is the N2 diagram so just like we did the openmdao check we can do openmdao n2 sellar_example.py and here it produces a graphical representation of the problem. In this case here we see the cycle and I’ve highlighted here the kind of backwards feedback coupling here. Now we know that if we have backwards coupling we need to add a solver to the model and that we also don’t have a solver in this model currently. Additionally you can look on the right hand side here to see which solvers are acting on the model. Here we see there is a nonlinear run once solver, which is not enough to solve the coupled system. It only runs through the model, first d1 and then d2, and doesn’t loop around here. So the N2 is a very visual way of looking at your coupling and the types of solvers that you have set up on your problem. That’s really all I wanted to highlight about notes specific to OpenMDAO in this lecture. There are a few other notes here at the bottom of the notebook, but there’s nothing too major. Really there’s a lot of other lectures that go into much more detail about solvers and how to use solvers within OpenMDAO.

So the whole point of this lesson was to introduce the idea of coupled or implicit systems and the fact that we need to solve them. If you only have a feed forward system you don’t necessarily need a solver. Everything can be written as a series of equations that you simply solve one after another. However in the case of coupled and implicit systems you’ll have to use nonlinear and linear solvers to get the correct state and derivative values for your system. I’ve shown you a few ways that you can identify coupled systems within OpenMDAO and this is just one of many different lectures related to solving complex multidisciplinary systems. As always please hit those like and subscribe buttons and thank you very much for watching!