This version is dedicated to the X-57 Maxwell.

I remember the joy and excitement the team had as they watched Administrator Bolden announce the program and the first piloted NASA X-plane designation in more than a decade. I was in the audience at Aviation 2016 poised to upload the model to the Hangar as soon as the announcement was made.

OpenVSP played at least a small part in the early stages of the program. Fit Model was used to build the fuselage model for the Tecnam. Nick used OpenVSP for the configuration studies. Jeff used it for the wing design. Brandon designed the signature folding props and nacelles. He went on to maintain the definitive geometry that would be the basis for all the CFD studies you’ve seen. There are other uses and users that I am regrettably leaving out. It was an honor to support their work and to have OpenVSP make a contribution.

This week, I’ll join those friends and many others at the X-57 Closeout to glean what I can from the vast learnings of this team. I know this didn’t turn out the way you’d all hoped. I also know that you’ve made a big contribution to aeronautics. You’ve changed the design space. You’ve moved the needle forward. Congratulations on your collective success. Thank you for all your work.

Once again, this release has been a long time in the making. There are only a handful of main themes here — and while you might not think they apply to you, I strongly encourage everyone to upgrade. In addition to some really cool advances (that you might not need), there are a ton of smaller improvements and fixes that will benefit everyone.

So go ahead and start your download before you finish reading this message. I’ll wait here until you come back.

Thomas Nascenzi & the team at M4 Engineering and I teamed up on an SBIR for the Navy starting a bit over two years ago. While lots of smaller features from this effort have already been released, this release marks a milestone in this project — the general release of what was originally the ‘big ask’. Don’t worry, there will be a lot more progress from this project to share in the future, but this is an exciting development for everyone involved.

The Navy uses a couple conceptual design tools (ADAPT and AIDEN) that can use OpenVSP as a geometry engine. They talk to OpenVSP through the Python API. These tools have a GUI front-end that the user spends most of their time with. The Navy wanted to be able to have the OpenVSP GUI open and interactive at the same time as their other aircraft design tool’s GUI was open and actively manipulating the OpenVSP model. Change something in ADAPT, see the change in OpenVSP and vice versa.

This may seem straightforward, but there is a lot of magic that has to happen for this to work. Making it work took a lot of Python magic as well as a lot of C++. Thomas and I worked together on this — with Thomas handling all the Python (and the good ideas) and me supporting with whatever was needed on the C++ side.

So, you can now have an OpenVSP GUI open and interactive while your custom Python application pounds away. At a minimum, you’ll be able to visualize and interact with a 3D model of your concept as your optimization study progresses. I have no doubt that users will come up with many more applications for this capability.

Of course, having a fully-featured OpenVSP GUI open while another program is manipulating the model may seem like running with flaming scissors. It might be. To address this, we’ve added some ‘parental control’ API routines. These calls allow you to disable certain features and capabilities in the OpenVSP GUI. For example, you can Nerf the OpenVSP GUI to a view-only interface for a model. We’ll see how this works out in practice and if more is needed.

We’ve moved the API documentation from being specified where things are registered in AngelScript to their native C++ home. This also allows us to generate a parallel set of Python documentation for the API. Going forward, the OpenVSP website will host both Python and C++ / AngelScript documentation for the API. The Python docs are also now included in the openvsp package and should be available in your IDE when you’re using OpenVSP.

Among all of this work, there are some small changes to the Python API. It should be pretty harmless and generally more Pythonic, but it might cause API users a few headaches.

One of the C++ changes to support using the GUI from Python affects how 3D objects are updated to the graphics card. We now attempt to update these objects less frequently. This should also provide a nice performance boost, but at the risk of losing things once in a while. If you find that something vanishes where it was previously visible, mention it on the Google Group.

Next, some bad news. In addition to lots of good stuff, 3.33.0 also included some lousy regressions. These regressions made FEAMesh and CFDMesh both slow and crashy.

If you aren’t into sausage making, skip a few paragraphs…

The performance regression was super subtle. The regression was actually over in Code-Eli (50487cc2bbfe). Notice how I nonchalantly say “This does mean that a copy of the surfaces must be made because they are no longer const.”. Yep, that was it right there. I even knew I was doing it at the time.

Something I did to improve the accuracy and reliability of a surface-surface intersection algorithm inadvertently caused us to copy and destroy a giant complex data structure a bazillion times. All the time was spent allocating and releasing memory.

The fix (c53f910aa2e4) was to allow a shift to be incorporated into the surface evaluation on-the-fly and switching back to a const reference.

The crash-causing regression was something else entirely. When our mesher (CFD or FEA) generates an initial mesh (InitMesh), it transforms every surface patch into flat 2D space and generates the initial mesh there.

You might be wondering why you can’t just use the surface’s U,V parametric coordinates for generating the initial mesh. Unfortunately, a square in U,V is not guaranteed to look anything like a square on the surface. The closer we can get to flattening the surface without distortion, the better.

For years, we’ve used an algorithm based on Mysticism and Voodoo to map surfaces from U,V to 2D space. It generally worked, but it was a dark place that will make you see things that aren’t there.

In our next regression (47e5744550eb), I tried to replace the old approach with something I thought would be an improvement. Spoiler alert, it broke things. In particular, it would distort surfaces near degeneracies in a way that fine meshes would turn out hosed.

As it turns out, this flattening problem is something that computer graphics researchers have been working on for years, so it made sense to drop the custom code and use an off-the-shelf solution instead (OpenABF). It does a great job and should provide all the benefits I was hoping to achieve when I ‘upgraded’ the algorithm earlier.

The good news is, not only are these regressions fixed in this version, I spent a bunch of time profiling FEAMesh under some extreme use cases (thanks James Joseph) which revealed some unexpected slowdowns. I was able to re-write several algorithms providing dramatic speedups.

If you previously grew tired of wondering how long ConnectBorderEdges, BuildFeaMesh, and BuildChains could possibly take, you’ll like what you see here. In addition to these three, a bunch of other speedups were made across the meshing workflow.

While I was in there, I was able to fix a bunch of bugs in and around FEAMesh. Most of these were reported by users – thanks James & Bryan.

The other big item you’ll notice in this release is we finally have full Apple Silicon M1/M2 processor support. The holdup had been our scripting language – AngelScript. AngelScript does some low level stuff such that it includes some assembly code that needs to know exactly how compilers on a given operating system and processor platform send data to a subroutine. This includes things like do you pass arguments LtoR or RtoL, how many registers there are, how do you use the registers, what do you do when you run out of registers, etc. The main AngelScript author doesn’t have an Apple Silicon machine and has had to rely on others to do this work (which is outside my range). Someone finally came along to make it work, so here we are. I helped track down one bug that turned up along the way.

So, if you’ve purchased a Mac in the last three and a half years or so, you’ll want to check out the new download option. It should be faster for you, but everything else should be the same.

You may have noticed that there are a bunch of library updates along the way. In addition, there are a bunch of updates to the CMake build system. If you build OpenVSP yourself, you’ll probably want to blow away your build directories and start over. Sorry for the hassle. If you typically use -DVSP_USE_SYSTEM_FLTK=TRUE (likely for Linux users), I suggest you don’t do that now. The FLTK project is about to release version 1.4.0 and I’ve bundled a cutting edge version here. It includes many improvements that won’t be available in a system-installed package until the final release happens and then the Linux distributions update to it and then your machine is updated too. Just use the one I bundle, you’ll get the latest.

Beyond that, there are a good number of small fixes and features tossed in. As mentioned earlier, everyone should update. It is the right thing to do.

Features:

• OpenVSP GUI available from Python API
• Facade allows OpenVSP API to run transparently on separate process
• GUI parental controls
• Python API documentation
• Surface Intersecion, CFDMesh, and FEAmesh much faster
• Add surface names to Intersect, CFDMesh, and FEAMesh progress output
• Native Apple M1/M2 support

Library Updates:

• New AngelScript – full M1 support
• Removed local modifications to AngelScript for documentation
• Moved AngelScript build to Libraries, better CMake integration
• Updated FLTK to 1.4.0-preview version
• Updated FLTK integration to Modern CMake
• Added OpenABF – Angle Based Flattening
• Updates to Code-Eli, performance improvements for meshing
• Update how Eigen is included in project

Bug Fixes:

• Fix meshing performance regression from 3.33.0
• Fix meshing crash regression from 3.33.0
• Fix on-the-fly updating of meshing lengths with model unit scale
• Fix not scaling fixed points with model scale
• Fix not scaling trim planes with model scale (thanks Bryan)
• Fix FEA crash with subsurfaces and trims (thanks Bryan)
• Fix FEA crash with empty trim part (thanks James)
• Fix corruption of Quad Meshes
• Fix FEA Individualize Rib and Plane routines (thanks James)
• Fix scroll wheel zoom on Windows
• Fix Wing insert section update from API.
• Fix error in K to F unit conversion (thanks sladesladeslade)
• Fix VSP icon in Ubuntu (thanks Cibin)