Understanding XDSM diagrams video transcript¶

Hello all John Jasa here with another installment in our Practical MDO series. Today we’ll be talking about understanding XDSM diagrams. XDSMs are a fantastic tool. They really help you understand how a model is constructed, how data is passed between each part of the model, and how you can share these models with other people and get them up to speed very quickly. This has to do with both the modeling and optimization subcategories of this course. This is because we can denote how a model is connected but also show how the actual optimization process solves this model.

This is what an XDSM looks like and if you’re overwhelmed right now, please do not be alarmed. We will go over this in detail and build it up piece by piece. Basically, an XDSM diagram allows you to visualize and see a model or multidisciplinary optimization process and understand what is going on here. They are very, very helpful even if you’re working alone on a project, but they’re especially helpful in a collaborative setting where you need to share the model with somebody and explain how data is being passed between different parts of the model. So first XDSM stands for extended design structure matrix. It was created by Lambe and Martins in a paper they published in 2012 and has really taken off in the MDO community. The DSM idea is not new but XDSM allows you to have a standardized way to portray complicated design problems. I’ll briefly scroll through the paper here that Lambe and Martins put together. It’s a fantastic and comprehensive theoretical approach to understanding how and why XDSMs were put together and I’ll have a link to this paper in the description of this video. Please check it out if you want to go into more detail.

First I’ll have a very simple XDSM and I’ll walk you through this diagram and explain what every part means. So first we have a function. This function here you can think of as an analysis block. In our case here I’ve written out the explicit function y equals x squared plus 2 over x as a very simple disciplinary analysis. Here the inputs would be x to this function and y would be the outputs. And so in XDSM parlance this means that x is an input and it comes down from the top. Here anything on the vertical axis is an input to the system and data is being fed from x into this analysis block. Analysis blocks are shown in green and later they’ll be shown on the diagonal. Anything on the horizontal is an output. So in this case we see this function y equals x squared plus 2 over x we know that y is an output. We are computing the value of y based on the input values of x. Now we’re looking at y here as an output to the right hand side of this function, but y could also be coming out on the left hand side. This would represent the idea of design coupling. This is where the output from one analysis block either travels forward like we’ve shown before or backwards like we’re showing now. In this green analysis block we have y as an output. y could be coming out to another group or system or it could be coming into an optimizer like we show here.

If we’re trying to minimize this we would need to find the x value that makes y be the smallest and to do this we could set up an optimizer around this small function. The optimizer would try different x values, evaluate them using this analysis block, and then pass the value of y back to the optimizer. This is an iterative process that takes time to complete. In this case it’d be very simple because it’s just a function, but the optimizer would be able to solve for the optimal value of x that produces the smallest y.

So XDSMs are able to show feed forward coupling like we showed before with x going into this function and then coming out on y on the right hand side, and also able to show feedback coupling. Here we have x going into this function and y coming out on the left hand side and going back to the optimizer. We can also show a loop here, as these four lines show, and the process flow showed as we went through the optimization process. And then lastly in the top left hand side here we see x star and y star. This allows us to see the optimal values of x and y at the optimum point. There can be many intermediary variables shown on the right hand side but anything on the left hand side denoted with an asterisk means that that’s the optimal value coming out of the optimizer.

And so I slightly jumped the gun here. I said this is for analysis but I showed you an optimization loop. But let’s look at a more complex and real problem here. So this is the one that I flashed up before here. Take a look at it again, but again, please do not be alarmed by it. This is something that comes out of an aerostructural design problem. So here we’re trying to change the wing size and shape accounting for both the aerodynamic and structural effects during flight. This comes from an open source tool that I helped develop during my PhD called OpenAeroStruct. To help us visualize what’s going on let’s examine the performance of a simple aircraft wing in flight. Here we’re looking at the ScanEagle, which is a small UAV or uncrewed aerial vehicle. We’re looking at it in steady flight, which means that we have steady state loads on the wing. We’re interested in the aerostructural performance. But first let’s build it up. We’re interested in the aerodynamic performance. To evaluate this we’ll have to use a computational model using some sort of mesh. This mesh is shown on the upper left hand side of the screen here and a kind of realistic view of the airplane is shown on the lower left hand side. But this mesh goes into the aerodynamics analysis module. After this mesh goes in we’re able to get some aerodynamic properties out. In this case we’re interested in the loads, the wing loading that’s happening on this aircraft. So again the mesh here is an input to the analysis block called aerodynamics and the loads are an output.

Now I mentioned that we’re interested in aerostructural design so let’s take a look at what it means to also include the structures. Here we have some notion of a spar shown in yellow here, which could be like a carbon fiber tube running down the wing. Now we add the idea of structures in a disciplinary analysis block. So the aerodynamic loads are being computed from the aerodynamics block shown in green and being passed to the structures block also shown in green. Anything on the off diagonal is data that is being passed between them. So the structures is computing some sort of displaced mesh. You can imagine that when the wing is loaded it deforms under that load. This is what we’re computing via the structural disciplinary analysis block. We then pass this displaced computed mesh back to the aerodynamic side of things. This allows us to recompute the aerodynamics effects and iterate over this loop here. As you can see we have aerodynamics giving us the loads going into the structures, giving us the mesh going into aerodynamics.

We see a kind of notional displacement here in the animation. However in this case we don’t know how much displacement the wing is undergoing. This is an interesting problem to solve because the aerodynamic and the structural quantities are inherently linked. You cannot compute one without the other and if you just go through once it will not be the correct answer. Instead we need to somehow solve this coupling. One way to do this is to use something called a solver. In this case we have a nonlinear block Gauss-Seidel solver which is shown with NLBGS in the XDSM diagram. If you’re interested in learning more about nonlinear solvers please see the linked lecture in the description. We’ll go into much more detail about what solvers do and how they operate. For now just know that they can be represented in XDSM diagrams as we’re about to show.

So previously we had disciplinary blocks shown in green but now we have a solver shown in this light orange. The aerodynamic and structures disciplines are passing this information to the solver and the solver is iterating across these different disciplines and it’s saying “please continue to iterate until the loads in the mesh reach a steady state.” We don’t know what the correct loading or the mesh deformation is. It could be a little amount like that. It could be a bigger amount like we’re showing here. Or it could be a kind of medium amount. Just know that we needed to solve this coupling using a non-linear block Gauss-Seidel solver for the purposes of this XDSM diagram.

Here I have any values that we’re not certain about their final value shown in italics here. That means these aerodynamic loads and displaced mesh are changing over time as we iterate through the solver. We do have the displaced aerodynamic loads coming out in the final setup. These will be the converged values. This means that once the solver is finished iterating throughout the model we have the final converged values. This allows us to compute functional values or performance metrics for this aircraft. So in this case we take the displaced mesh and aerodynamic loads, the final converged values, combine them with the coefficient of lift coefficient of drag and other aerodynamic metrics, as well as the structural weight and other structural metrics, and we put these into a functional disciplinary analysis block as inputs. We are then able to compute performance metrics like fuel burn, coefficient of moment, and structural failure, all things that we would care about in an optimization problem.

So let’s continue kind of building this up. We started with the aerodynamics block. We also need some notion of a geometry block. This is something that’s actually producing the mesh that we use during the computations. This geometry block has outputs as we see here in terms of baseline mesh but it can also have inputs such as the twist of the wing. We could also have the spar thickness coming in as an input to the structure. Now we could iterate on this by hand. We could vary the twist and the spar thickness, run this analysis, and see what the failure and fuel burn criteria are. But in the intelligent way, and the whole point of this course, is to use an optimizer. We can then use an optimizer to iterate through this entire model, including the solver, to get the optimal values of twist and spar thickness while trying to minimize fuel burn or weight or any other performance metric that we’re interested in.

Let’s take a look at what this means by following the process flow through the XDSM diagram. I will highlight when a block is run and then show data transfer across the gray lines by using a red highlighted marker. We start with the optimizer. It gives a twist value to the geometry and then computes a mesh. This mesh is passed into the aerodynamics module and the loads are computed. These loads are then passed to the structures and a displaced mesh is computed. We iterate through this as I mentioned before with a nonlinear solver and find the converged values for the displaced mesh and aerodynamic loads. It may take many more than two iterations than what I’m showing here but for purposes of visualization we just have two iterations. We then take all the performance metrics from the aerodynamics and the structures as well as the converged solver and bring them into the functional analysis block. This runs to compute the failure criteria, fuel burn, etc, and is passing that information back to the optimizer. This process is then repeated until the optimal answer is found. Here we might be minimizing fuel burn subject to a lift equals weight constraint (so we can stay up in the air) and we want to find the best twist and spar thickness values for the wing design. Again this is just shown as a realistic aerostructural example with a pretty complex XDSM diagram where we need some understanding of not just feed forward coupling but feedback coupling, solvers, as well as an optimization loop.

Let’s talk about how to create XDSM diagrams now that we’ve talked about what they are and what they mean. My preferred way of making XDSM diagrams is by using a tool called pyXDSM. It is maintained by the MDO Lab at the University of Michigan. It is a Pythonic, programmatic way of creating XDSM diagrams by using Latex. Here is an example of a diagram that you can produce and it’s in a GitHub repository here. I’ll send a link in the description. But if you check out the examples here it’s got a very complex example here called kitchensink.py and you can see the kind of Python code that you would use to create these XDSM diagrams. You can see connections, inputs, systems that are being added. But I want to show you a slightly simpler one.

Here’s just 30 lines to create something that looks like the example image shown in the repo. So you can add systems, these analysis blocks, you know the d1, d2, f, and g, and also have the data that’s being passed between them shown in these gray off diagonal markers. pyXDSM is what I use for all visualizations within this lecture. I’ll continue to use them throughout this course and I highly suggest that you check it out. It’s got a little bit of a learning curve but frankly it’s pretty approachable. And because of its Python interface you can also understand the model pretty quickly just by looking at the code as well.

Now if you don’t want to go that route and you’re more of a visual learner and a visual implementer you can just do by hand. That’s A-okay. Here I am using Google Slides. I’ve never used Google Slides before, this is all new to me. But you can just type it out. You can kind of draw some boxes connect them together. I highly recommend if you’re not going to make a formal XDSM through pyXDSM at least drawing out your model and seeing how things are coupled together and what they mean. So here Google Slides, heck you can just put it together. It’s going to look okay. It’s not going to look as formal. It’s not going to look like these journal articles, but that’s A-okay. It can get your point across and help you understand the model as well as other people.

Another option besides using pyXDSM or Google Slides or drawing it out by hand is something called openmdao-XDSM. This is a plugin for OpenMDAO which produces an XDSM diagram of your code. So if you have a model in OpenMDAO and you want to see an XDSM diagram of it, this will allow you to do that automatically. It produces it just based on the actual code and the connections and the systems within there and it is a very low friction way to visualize your model. This has its pros and cons, though. One pro is that it has everything that’s in your OpenMDAO model. You’ll never forget a coupling or a discipline because it’s exactly what’s in your model. But a con is that it has everything in your OpenMDAO model. So if you have a bunch of variables that are intermediary variables being passed between them, you might not care about what they actually mean or what it looks like on the XDSM diagram.

I’m throwing a lot of different options at you to see what sticks and see what you prefer using. Again I prefer using pyXDSM just because it makes very professional looking documents and it’s easy to make them and then share them with other people and change them after the fact.

So let’s talk about how to use XDSM diagrams in a large collaborative setting. So here is an example of an actual problem that we at NASA Glenn were trying to solve. This is a pretty complex kind of mission-based aircraft design problem. Different than previous examples analysis blocks are shown in red on the diagonal. The green in the top left side is kind of the driver for this analysis. In this case it’s Dymos, which is a dynamic optimization problem. One neat way that you can use XDSM to kind of divvy up work is to add people’s names to different blocks for what they’re responsible for. So I know it’s small here but if you check out each one of these blocks they have somebody’s name on the bottom. We have the propeller which Daniel is in charge of, the atmosphere which Sydney is in charge of. I was handling the aerostructural side of things Eliot had the flight dynamics, etc. So XDSMs allow you to look at the block that you’re responsible for, the inputs to that block, as well as the outputs that are coming out of it. This really helps teams, I mean if you’re working with, you know, eight to ten people, understand the model. If you weren’t able to put this together and visualize your model and have people responsible for different parts of it, it would be very challenging to remember what kind of inputs and outputs there are. I kind of picture this as a jigsaw puzzle where you need to define the puzzle edges before you can put all the pieces together. XDSM helps you do that.

Lastly I’ll have a comparison between N2 diagrams and XDSM diagrams. If you’re not familiar with N2 or n-squared diagrams, please check out a link in the description below. XDSMs and N2 diagrams are very similar, however, I would say that XDSMs are more for presentations and N2s are more for debugging. The n-squared diagrams are produced automatically by OpenMDAO and they’re a beautiful way to very quickly check your model, its connections, and even get in-depth detail about your model. However, when I say in-depth I mean really in-depth. For very large models or complicated systems these can easily become, you know, huge. It would be challenging to pass this off to somebody who’s never looked at your model and have them understand it right off the bat. The goal is for XDSMs to kind of fill that need. You can pass this off, it’s more of a higher level view, and somebody can get more up to speed with your model very quickly. Additionally XDSM diagrams have a very formalized set of meaning behind each one of these blocks. So here I have an n-squared diagram of the exact same aerostructural problem that I’ve been showing with the XDSM setup. As you can see, it’s got kind of these code based names. It’s a little bit less polished than these kind of journal article presenting XDSMs. And so that’s another kind of a thing to consider if you’re looking at n-squared versus XDSM diagrams. However we can still see the backwards coupling, we can still see the aerostructural coupling, within this model. So I’d say it’s helpful to create and investigate XDSM diagrams and n-squared diagrams. They show different but related information about your model and optimization process. Again there’s a lecture that goes into more detail about n-squared diagrams in the link below.

So I know we talked a lot and I said the word XDSM a lot. But if there’s one main takeaway it’s that you should always create an XDSM diagram of a model you’re analyzing or optimizing. It doesn’t only help you, it helps anybody that you’re sharing this model with. It allows you to work collaboratively in a group, allows you to share this information, see what the puzzle pieces are for the puzzle you’re trying to solve, and understand more about what this actual optimization problem is. Again it was developed at the MDO Lab at the University of Michigan and it’s really taken hold at NASA Glenn and other MDO focused research centers. I highly recommend that you get acquainted with XDSM diagrams, make them, and share them with others. This saves so much time, when you’re debugging a model, you need to point to something and now you have a visualization to help you point and say “hey I think this variable should be here,” “I think it should be there” and then you can talk it through with your collaborators. It’s very valuable to be able to do that and XDSM provides a formalized and standardized way of doing that. So again check out the links in the description below for these papers, GitHub repositories, and links to other lectures, and please make sure to like, comment, and subscribe if you enjoyed this video or have any sort of questions. Check out more in the series! Thank you.