OpenVSP 3.51.1 Released

[Rob McDonald]

Something unusual for OpenVSP -- a new version with no new features, no bug fixes, and hopefully no changes in behavior.  So why bother?

I was working on presentations for the OpenVSP Workshop and I felt that some things were slower than I'd like them to be.  So, I decided to do some profiling.  I found that things were generally pretty reasonable, but there was lots of memory churn.  This is often where I get to -- because previously I didn't have a good strategy for improving these kinds of cases.

So, I decided to point my friend Claude at the reports (don't do this unless you want to burn through a ton of tokens - ask me for more efficient ways if you go down this road.).  Claude had some strategies to try -- while certainly uglier code, they look to be maintainable and reasonable enough (the added complexity isn't too great).

After that initial success, I pointed it at a few other things and found a few more wins.  Among these was a change to how HumanGeom is done that at least means that the vsp executable got a lot smaller and should take up less memory.  I also sent after some compiler warnings in dependencies that have really been annoying me.

In this work, I wasn't targeting one-and-done things (eg analysis).  Instead, I was mostly targeting frequently recurring tasks (things that happen when you move a slider).  So the improvement should come for real interactive geometry manipulation.

So, if this was successful, everything should work the same -- only faster.

I could really use your help.  Please pull this version down and try it out.  If you find anything that behaves differently (other than speed) from 3.51.0, please report that to me.  If you have success with this version (faster, but no breaks), please report that too.

Features:
 - AI assisted, profile guided optimization in several areas.
 - Refactor HumanGeom math to store less data and do less math.

Build System:
 - Update Code-Eli with lots of changes
 - Update Pinocchio with compiler warning cleanups
 - Suppress some compiler warnings for sixseries
 - Clean up some warnings in Cartesian
 - Remove pathlib dependency in Python dev environment
 - Point CMake on Windows with old Python at python.exe instead of python3.exe

[José Roberto Clark Reis]

Hi Rob, really interesting....

Is there any particular use case or scenario you would suggest? Or just everyday use? I am a terrible programmer, but usually software will break when I touch it.... 

Cheers

--
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 visit https://groups.google.com/d/msgid/openvsp/2dd6adfa-51b5-4b0e-aa2f-4e6d3482b173n%40googlegroups.com.

[Rob McDonald]

Mostly everyday use.  A lot of stuff was touched, but mostly pretty mainline things.

A lot of data structures that were normally cleared and re-created were instead re-used.  This avoided a lot of allocation / free memory churn.

This includes the basic draw object data structure used to send data to the graphics card for 3D rendering - for basic Geom, but also special cases for Blank, Hinge, Human, Engine, Auxiliary, Mesh, NGonMesh, etc.

A bunch of similar changes for surfaces, feature lines, tessellation, etc. were done for Gear based AuxGeoms -- so this one is a bit more esoteric.

The fundamental skinning algorithms -- so how surfaces are formed.  Wings, fuse, stack, custom, conformal, prop, body of revolution, engine, auxiliary were all affected.

Basic surface evaluation was touched, so every tessellation, CFDMesh, etc.

The HumanGeom math was substantially refactored (this is why the executable is about 1/3 smaller).  So, initializing the HumanGeom might be faster, changing anthropometric parameters might be faster.

There were some warning cleanups in the 2D plotting stuff -- so the VSPAERO Results Viewer, the Wave Drag viewer, and a few other things.

If you want to see the performance change, you should try a model that was slow to update as you changed parameters.  The interactive update should be the biggest improvement.

Rob

[Jaime García]

Hi Rob,

I've tested this build with my  Parametric Fuselage Generator  (CustomGeom), and I noticed a clear performance improvement!

Eventhought the behaviour with lots of interior geometries is still slugghish, the interactive updates when moving sliders feel noticeably smoother, and I haven't encountered any broken behavior or unexpected bugs so far.

Thanks for the effort and for sharing the update—great work!

Best regards,

Jaime

[Rob McDonald]

Glad to hear it -- I did use your test case as a stress test during this process.

That said, the biggest gains will still come from you using CloneSurf extensively (start with the windows).  Once you have a version updated to do that, I might be able to take another look to see where it stands.

Rob