OpenVSP is not deterministic in spanwise distribution of parametric coordinates on blended wings.

[anilyil]

Description

OpenVSP has a bug, where it can give two different spanwise parametric coordinate distributions on blended wings. The code seems to "lock" onto an execution path during initialization, and is consistent with design changes after initialization. However, we run multiple instances of OpenVSP on multiple procs, as a result, it is highly likely that the different instances running on different procs do not agree on the spanwise parametric coordinates. Even though the actual differences are small, this introduces very large errors when we do parallel finite-differencing. Currently, the code avoids this issue by doing the FD computations completely (base and perturbed) on the proc that perturbs the DV, instead of doing the base evaluation on the proc that owns the point, and the perturbed evaluation on the proc that perturbs the DV.

OpenVSP version of at least 3.21.1

I have a test script for this bug. I will check with all versions of OpenVSP and try to see if they ended up fixing it in a recent release. If not, I will contact the dev team (again) and point them towards the issue.

[ramcdona]

I vaguely recall this being brought to my attention many years ago -- but at the time, it could not be duplicated and there was no MWE that could demonstrate the bug. I had essentially nothing to go on to chase this bug.

If you have a minimal test case that can replicate this issue on a recent version, I'm happy to spend some time trying to run this down.

[anilyil]

Hi @ramcdona! Thanks for following up with this issue. This issue has been introducing minor errors in our derivatives; they were large enough for us to notice but small enough so that the students (including me) who needed to graduate did not try to address this issue directly.

Now that you followed up here, I dusted off my test that I created during the 2019 workshop, and then tested it with different OpenVSP versions. It actually looks like 3.27.1 actually fixed it! My heart tells me to just stick with version 4.1.22 but not sure if project managers would like that. Looks like 4.1.22 would have definitely fixed it for good.

Jokes aside, I can recreate the issue up to 3.26.1 on ubuntu-20 using gcc7.5 and python 3.7.7. With the same setup, I could not re-create the issue on 3.27.1 Looking at the extent of the changelog for 3.27, I am not too surprised that this is fixed. Also I did not even try 3.27.0 after seeing the changelog for 3.27.1.

I will follow up with you offline and get you the test I have. We can also use our public docker images to replicate the issue on older VSP versions and if you prefer, we can include this test going into the future. Once we are sure the issue is fixed, I can come back and close this issue and #70. Thanks again for following up!

[ramcdona]

You are correct, 3.27.1 only fixes a GUI issue and will be identical to 3.27.0 from the API.

Looking at the changes between 3.26.1 and 3.27, I don't really see anything that should have influenced this. Most of the things that I thought might have helped should have been in 3.26.1.

I won't look a gift horse in the mouth -- but I also don't quite trust it. Lets keep the test around for a while and I appreciate you sending me a test case if you can.

Just think with 4.1.22 you won't even need sensitivities or an optimizer to find the solution!