In many ways, you could say that the modern history of OpenVSP started with a conversation I had with Mark Moore at Oshkosh 2005. I’m not atthe show this year, but why not release OpenVSP 3.29.0 to mark the occasion. If you’re there this week — have a great time.
This release is mostly about a small number of things that took a large amount of work rather than a large number of small things.
The biggest OpenVSP change is the ability to generate quadrilateral meshes using CFDMesh and FEAMesh. These are not high-quality quads. They are trivial conversions of tris to quads. If you need quads, they in fact have four sides. If you are picky about your quads, they may not meet your needs — except that they have one more side than triangles.
Rather than convert tris to quads at the last possible moment (say as the files are written to disk), the conversion process was performed somewhat earlier. This allowed the inserted points to be added _on_ the surface (or intersection curve). It also means that all the internal data structures were modified to work with quads as well as tris. This should mean that most of the infrastructure is in place if someone were to come along and want to work on quad mesh improvement algorithms to generate higher quality meshes.
The other big change is a long-awaited update to VSPAERO. Many changes across the board — although many are not user-visible.
The OpenVSP side of the VSPAERO GUI has been updated to integrate these changes, but many of the new VSPAERO capabilities are not yet supported from the GUI (some may never be).
Force summation calculations in VSPAERO have been improved. Accuracy and consistency should be improved – particularly for unsteady cases.
There are now adjoint and complex step derivative versions of the VSPAERO solver. API hooks have been added to allow tight integration with OpenMDAO and structural analysis tools. These capabilities are only available on Linux and MacOS. These capabilities are not available from the GUI. There is no new documentation for these capabilities. If you want to use them, you will need to be comfortable with C++ and be able to figure it out yourself. There will be papers, examples, and documentation for this stuff in due time. This is still being actively developed. Do not ask for hand holding at this time.
The VSPAERO GUI has made *.vspgeom files (previously marked experimental) the default for panel models. The DegenGeom files are still default for thick surface models. The option now says ‘Alternate file format’ instead of ‘Experimental’.
Work has begun on porting OpenVSP and VSPAERO to the Apple M1 chip. I have moved my primary development machine to a M1 Mac, so hopefully progress will be quick. It is now to the point where it will compile, it will run, and it will crash. If you want to help progress this port, you will need to compile OpenVSP on your own M1 machine and start debugging problems. The port is not yet ready for non-developers to try out. If you are a ‘regular’ user, you can continue using the x86-64 version through the Rosetta 2 translation software.
Unfortunately, some of the differences in the chip architectures are going to lead to subtle problems that will take a long time to hunt down and fix. For example, when converting “int i = (int)((float)INFINITY);” will result in i = 2147483647 on the M1, but i = -2147483648 on x86-64. We should not generally be relying on float to int overflow behavior, so this sort of thing represents a bug that should be fixed no matter what. One such case has already been found.
Quite a few build system changes (mostly VSPAERO) including addition of an automatic differentiation tool for the VSPAERO adjoint version. These changes warrant a version bump.
Features
- Optional quad meshing for CFDMesh and FEAMesh
- Option to turn off high-order elements in FEAMesh
VSPAERO Changes
- Improved force (especially drag) calculations, and bug fixes there in.
- Adjoint solver, stand alone now works for steady and usteady
- Adjoint solver + solver = Optimizer with an API. (Steady and unsteady)
- Initial API hooks for integration with OpenMDAO
- Initial API hooks for tightly coupled structural solves
- Complex step version should anyone care
- Fix for thin/cusped trailing edges on panel meshes.
- The degen geom and vspgeom files are both supported equally in terms of comp ids/surface now… it was a mess before
- Sticking with DegenGeom for default VLM solves
- VSPGEOM for Panel solves as default
- Some of the output files have changed as folks were asking for more info in things like the span loading data, etc.
- Cut planes added for solution visualization
- Span loading for thick geometries
- Preliminary supersonic panel support
- Bugs. Some fixed, some added.
Bug Fixes
- Fix control surface addition for Wing Geoms
- Silence echo of BEM file on read
- Fix airfoil thickness scaling problem with blended wings
- Fix VSPAERO Viewer movie creation on Windows (hopefully)
- Fix int to float conversion overflow in InterpDistTable in CFDMesh