Over the past several months, I've gotten super interested in topology optimization. Specifically, multiphysics cases. The bummer is... all the tools are so insanely expensive, and their ux literally might be harder to use than flying an aeroplane. So I made my own. 

These were all generated with my own internal software I made. The nodes on the left dictate the boundary conditions, constraints, and objectives given to the solver. 

Here is an image-by-image breakdown

1-a result of a linear elasticity load case. objective was to minimize compliance (essentially how much the solid "agrees/moves" with the forces. stiffer is better) target volume was 30% of the original. 

2- the same output as above, but with a contour map of the von Mises stress. it is cut halfway on the y-axis to inspect interior values. (I'll say this now so I don't have to every time I show a post-processed contour. Yes, I compute the values; I'm just yet to add a scale where you can inspect them. Currently, if you hover your mouse over the contour, it will read a value. That's what the "tooltip format" setting is for (far right). 

3- Same but with a displacement magnitude map. I can also do axis-specific (xyz each)

4- A thermal-only problem. Objective: maximise heat conduction. I kinda cheat a bit here, but I add a void penalty proportional to a convection coefficient. It allows me to say "void can absorb heat" without actually simulating a fluid for advection. This output is pretty cool in my opinion. You can see it chose to essentially maximise surface area and consequently contact with the void. 

5- The above problem cut in half, with a contour of temperature. shows how temperature lowers as you move away from the heat flux. 

6- A CFD-only problem. Objective: minimize pressure drop. Fluid fraction 0.5, solid fraction 0.5. Stokes fluid (I know we are not in a stoke reynolds regime with 1m/s velocity. With this very simple example, laminar,k-e, and Spalart-Allmaras all produce near identical results (I support all these models, although an important note: K-E does NOT have proper wall function support. Deliberate choice; I can explain if you reach out to me), and Stokes is obviously MUCH faster to compute. Another important note. You may ask why there is a glaring hole into the void on the edge of the pipe. Technically, the optimizer sees no penalty for exposing to the void, as it's a non-slip bc, meaning it's basically just... a wall that isn't rendered. More complex than that, but that's the easiest way to think about it here. 

7- This is the extracted fluid domain of the above problem's output, with the velocity magnitude contour. Stokes, so there are no cool shear lines to look at (that comes in later, don't worry) 

8- same exact domain as before, but for pressure. outlet was a 0-gauge outlet, so 0 Pa. 

9- same domain again, but the vorticity. its stokes, so there's not MUCH to look at, but I still think it's cool to show. 

10- these are the velocity streamlines. They show the magnitude along the path of randomly seeded lines. Pretend you placed a bit of dust in an airstream, and then tracked its speed and path. That is what this is showing. In a simple Stokes pipe, it doesn't help much. But when turbulence is involved, it helps a lot to track eddies/other turbulent artifacts. 

11-ok, this is actually not a top opt output. This is a static solve using LAMINAR flow. This is actually the same original domain that was used in the Stokes pipe example, just... unoptimized. Important to note here: I restricted the solve to 50 Picard iterations, and it DID NOT CONVERGE to a respectable residual. It hit a limit cycle at around 2\^-2. target was 1\^-4. This happens often with static solves, because the boundaries are hard. During an optimization, the mesh is porous due to the Brinkman alpha max, which allows fluid to seep through solid and explore the domain. It makes it MUCH easier to converge. So optimizations are TYPICALLY not plagued by this, although there are certainly cases where it is. 

12- same as above, but with streamlines. Looks a bit like chaotic spaghetti, and we hit a rendering flaw where some lines turned black, but it's useful to see how chaotic those other regions of the flow can become as backflow.

13- backflow is MUCH more obvious here. These arrows not only represent magnitude but also direction. They are vectors of the fluid. 

14- Here's those vortices on the shear lines I was talking about earlier. Laminar flow keeps the core of the jet high velocity because it's much more resistant to diffusion, unlike k-e or Spalart-Allmaras. So you get to see really clear shear boundaries along the jet's path. 

15- Here's where it starts to get complex. This is a conjugate heat transfer problem. It's one of three coupling types I support (others are thermoelasticity and FSI (under construction currently)). I am essentially telling the thermal engine that the air flowing around it can advect (the way moving fluid takes heat. Think of a fan in the same temperature room you are in. It's not making the air colder, but the fact it's moving removes heat from your body, making you feel colder) and the thermal engine then moves material, shifts airflow, and the cycle repeats with the new paths. Some things to note. Why Stokes. Stokes is MUCH better at making clear, coherent pathways. The other models CAN, but they need to be tuned (mainly Brinkman and inlet turb settings), and I just haven't taken the time to do so on this example. Plus those models love to form TONS of channels, and that means I need a higher-resolution mesh... and top opt scales very poorly as mesh increases. Not a great idea. 

16- this is that above problem's velocity magnitude contour. Not a whole lot to speak to here. 

17- same but vorticity. Even though it's Stokes, being sent through channels like this disturbs the fluid enough to show some vortices. 

18- same but pressure. I think it's cool to see how uniformly the pressure decreases. This is entirely because half the objective is tied to pressure drop. It wants it to be as smooth and minimal as possible, so across the entire design the pressure drops evenly. 

19- ok so i do have to explain something here. Known bug I'm working on. When channels get thin, things like streamlines and arrows don't render. So I'm showing you the arrows, but... there's not much to look at in the middle of the domain. It's interesting at the inlet and outlet, so it's worth seeing. 

20- and same but streamlines. 

That's all. 

FAQ-

Is it released? - No. It is not. I obviously built it to be a product at some point; however, I have much work to do, and also need to figure out the whole... sales thing. Future problem. If you work at any company where this sort of tool would benefit you, I'm happy to toss it to you for free for a month or two to get some feedback. When it's done, of course. 

What verification have you done? - I have FD perturb checked each adjoint across the whole application. Those are correct, and I have qualitatively compared forward-solve results to SimScale if applicable (they don't do anything like CHT, so kind of blind in that regard, but the formulations are textbook and results look correct.) i stil need to sit down and formally test several cases quantitatively (min-max values) but the way everything else has gone, i assume that will do just fine. 

Is this the whole app? - not even close. I have a huge library of constraints that weren't applicable to these scenarios, as well as many load types for each individual engine (structural, thermal, and CFD). And many more objectives as well. I would like to note that objectives can be set AS constraints in a problem. For example, a constraint could be that the design can't perform more than 1.5x worse than the unoptimized design's compliance.  The goal of this post was to cover the most ground across all engines, not showcase every last feature. 

Why is the mesh resolution so low? - same as stated above. Time to compute. 

If you have any more questions, please feel free to shoot me a dm

a series of mulitphysics topology optimization results.