OpenVSP 3.37.0 Released
528 views
Skip to first unread message
Rob McDonald
Mar 4, 2024, 12:30:13 PM3/4/24
to OpenVSP
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)
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)
Cibin Joseph
Mar 4, 2024, 12:55:38 PM3/4/24
to ope...@googlegroups.com
Always excited to see a new version released.
That 'visualize and interact' API capability sounds powerful! Need to check that out.
--
You received this message because you are subscribed to the Google Groups "OpenVSP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openvsp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/4485d2ef-d016-4376-a8c2-b0b46f8eb5b3n%40googlegroups.com.
Tim Swait
Mar 7, 2024, 5:59:27 AM3/7/24
to OpenVSP
That sounds brilliant, especially the tighter Python integration, well done!
Also such a shame the X57 was cut.
Tim Swait
Mar 7, 2024, 3:09:32 PM3/7/24
to OpenVSP
I'm having problems with this unfortunately. I just removed 3.36 and installed the 3.37 from the .deb package on Ubuntu 22.04. The first thing I noticed when I opened it is that the text in all the menus is tiny and at very low dpi (see below). Then I found that the sliders are now really badly laggy. You click a slider, pull it to a position, release the button and then have to wait for several seconds (2-5 depending on which slider) before it jumps across and the model updates. If you try waggling the slider about then you can be waiting 30 seconds or a minute for anything to happen and it to update after you release the mouse button. It's a very long way from being able to smoothly update parameters as it used to do and it's almost unusable now. When I run it from command line then this shows "error : Unknown IO error", which isn't a terribly useful message for debugging I'm afraid! Probably something Graphics Driver or Card related? I've attached a text file with the hardware specs of the laptop I'm running it on if this helps.
Also how is the realtime link to Python supposed to work? I've opened a file through the GUI, opened the same file through the Python API and changed some parm values (e.g Total Span). However nothing changed in the view in the GUI. Also if I move the sliders in the GUI and then GetParmVal through the Python API then it just gives me the values for the saved file, not what I've just moved the sliders to. Is there some other thing required to set up this realtime link?
Rob McDonald
Mar 7, 2024, 3:28:30 PM3/7/24
to ope...@googlegroups.com
I did update FLTK for this release. It looks like it resulted in a different typeface being used on your machine. Is this Windows, MacOS, Linux, or what?
You should be able to use ctrl-+ to zoom in.
The slowdown doesn't make sense, there should be no reason for that.
Here are some instructions on how to access the new Python stuff.
Rob
To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/1eb41b9b-8950-4666-b558-ec806e1de3d0n%40googlegroups.com.
Tim Swait
Mar 7, 2024, 3:57:45 PM3/7/24
to OpenVSP
It's Linux, Ubuntu 22.04 and I installed it from the .deb package.
The small text isn't just a different typeface, it's also very low dpi (lines 1 pixel wide) and doesn't properly fill the spaces for it. Cntrl+ or - doesn't change the size of the text. It looks like something that might be used as a fallback when it can't load the typeface that is being requested, see the blown up screen shot below the typeface equivalent of None! This is why I think there might be some graphics acceleration issue which is possibly related to the massive slowdown in updating anything. I attached the full hardware spec of my machine in the last message, but it's an Asus laptop with AMD Ryzen 9 4900H with Radeon Graphics CPU and nvidia GeForce RTX 2060 Mobile graphics card. I'm using the nvidia proprietary drivers, which are the recommended option and seem to be working well as far as I can tell.
Thank you for the instructions on using the Python link, yes that does work for me now.
BTW, the icon on the task bar is now the OpenVSP logo instead of the FLTK one, which is nice.
Rob McDonald
Mar 7, 2024, 4:33:25 PM3/7/24
to ope...@googlegroups.com
I believe FLTK switched to using the Wayland compositor by default with this new version. I'll see if there is something I can do there...
This is not a graphics acceleration issue. Your hardware is fine.
Rob
To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/73972bc6-bb48-45a1-b12b-57c42312220an%40googlegroups.com.
Reply all
Reply to author
Forward
Message has been deleted
Message has been deleted
Message has been deleted
0 new messages