Help needed with Unsteady analysis: store dropped

[Jaime García]

Good morning,

First of all, thanks again for this great software.

We are trying to simulate a store drop with the geometry of the paper AEDC-TSR-91-P4 ""CFD Wing/Pylon/Finned Store Mutual Interference. Wind Tunnel Experiment" and compare OpenVSP results to the ones shown in the paper "A Validation of FlightStream for Store-Separation Modeling".

We thought it was possible because we have seen the following video from the 2021 Workshop:
https://youtu.be/5e_crTyH-uM?si=S7yFtkQQBhYLqLZ5

As there was not to much information on how to do it, we checked the threads of this group and found the following, of arround the same time of the workshop, that has a little more information:

https://groups.google.com/g/openvsp/c/3iE6Dk69P4o/m/bwGyJk_NAQAJ

We have manage to get the unsteady analysis working through the command line in OpenVSP 3.49.0 in a windows platform. You can find the .vsp3, .vspgeom, .groups and -vspaero files attached. This files were created following the information mentioned above.

As it was anticipated in the other conversation of the google group, it doesn't seem possible to access the store cg displacement and velocity data, that is probably stored in the .adb file. Nonetheless, looking at the calculation steps, as it can be seen in the left side view video also attached, the store doesn't seem to move afterward, it moves only down, and also it does not change its rotation in time. This was a little surprising for us, as in the reference video it seems to rotate.

We think something is not properly set-up but we haven't been able to find more information so we can correct it. We have try to set a velocity in the fixed component but that does not change anything. Changing the speed of the store group (a positive velocity), moves the store afterwards but at a constant rate, not taking into account drag or changes of drag with speed.

Any help to make the analysis more realistic is really welcome.

Kind regards,

Jaime

[Jaime García]

Good morning,

We have keep trying to make the store drop work. We have found several things that we had improperly set:

- Density value: as the model is set in International System of Units (SI) and the analysis is at sea level, the rho value has been changed to 1.225 kg/m^3

- Vinf: it was close to the one that should be 100 m/s but at SL with Mach 0.3, it should has been 102.09 m/s

- ReCref: adjusted accordingly to 6.99E6

As the values were improperly set, the aerodynamic forces where not enought to produce significant changes in the inertial forces.

Also, the time step was a little high, so we have reduced it to better capture the transition.

The dynamics are better, nonetheless, as the vspaero is a potential solver, the forces along the X axis of the store are sligtly negative (the store does not brake, it is pussed forward!!).

We believe that the 6DOF is doing what it can with the information that it has, but at this moment, could not be more realistic as it is not posible to include a CD0 value for the base area of the store that would move it afterward of the wing.

The updated files with some videos are attached to this message in case anyone wants to take a look at them.

Kind regards,

Jaime

[Rob McDonald]

The groups file has an option to add drag to the group.

DeltaFlatPlateDragArea = 

FlatPlateDragRefReNumber =

You can use these to adjust the drag on the store to a more reasonable value.

Rob

[Jaime García]

Thanks, Rob!

That option is great but it does not seem to be working in the unsteady analysis.

I have tried a couple of things, first, creating a group file in the steady analysis, were I have find that:

- DeltaFlatPlateDragArea adds to the internal Cx0/CD0 value, so the results from the parasite drag tool + excrescence (base drag) has to be adjusted in order to not exceed the expected value.

-  FlatPlateDragRefReNumber changes the  DeltaFlatPlateDragArea but it refers to the global ReCref value. Using the Reynolds number for the store that is different to ReCref will try to change the FlatPlateDrag and the value obtained would not be the expected one.

The addition of DragArea works perfectly fine in the steady case and is really usefull to draw out drag polars with all the contributions taken into account ().

Nonetheless, when I tried running an unsteady case with the group file including  DeltaFlatPlateDragArea, from the first iteration it outputs nan values as it can be seen in the "log-unsteady.txt" contained in the attached file:
"TStep: 1     / 150   ... Time:    0.00500 ... GMRES Iter:     0 ... Red:  -nan(ind) / -1.00000   ...  Max: -nan(ind)  /    1.00898 ..."

If I just errase the lines for the DeltaFlatPlateDragArea it works so it is those lines that are making the analysis fail.

Any ideas? Is it a bug? (I'm still using version 3.49, but if needed I can change to 3.50.1)

Jaime

[Rob McDonald]

Nothing you're doing should change between 3.49 and 3.50.1.  It won't hurt, but it won't help with any of this.

I haven't ever actually used any of this stuff, so I'm not really any help.  If I were doing it, I would read the source to try to make sure I was using the options correctly and go from there.

I would also start with a super simple case, see if I could get that working and then build up from there.

Rob

[Jaime García]

Thanks for your help, Rob. I have been combing through the code, trying to understand what is happening and where and how the DeltaFlatPlateDrag is used, and I think I have found it.

In the OpenVSP/src/vsp_aero/Solver/VSP_Solver.C file (https://github.com/OpenVSP/OpenVSP/blob/main/src/vsp_aero/Solver/VSP_Solver.C) the DeltaFlatPlateDrag is added starting line 30006 (// Add in any flat plate drag areas) and ending in line 30034 now. It is the last of the changes in the forces that it is made and comparing to other forces it lacks a condition for TimeAccurate_ analysis.

For instance, in the viscous forces, the condition is now between lines 29990 and 29998 of the code, and I believe that after line 30028 something like this should be added:

              if ( TimeAccurate_ ) 
                 
                VSPGeom().ComponentGroupList(c).CFox(Time_) += DeltaFxo;
                VSPGeom().ComponentGroupList(c).CFoy(Time_) += Delta Fyo;
                VSPGeom().ComponentGroupList(c).CFoz(Time_) += Delta Fzo;

             }    

If the DeltaFlatPlateDrag is set in the groups file, it is added to the steady forces but it isn't added to the TimeAccurate forces, so this gives problems in the unsteady cases where you are not being coherent with the calculations.

Rob, how should I proceed in order to have the code changed?

Thanks again,

Jaime

[Rob McDonald]

I will forward this to the VSPAERO developer.

There are a bunch of changes going on right now, so I don't know that this change will apply 1:1 with everything that is being done, but I'll try to make sure this is resolved going forward.

To fix it for your own purposes, you can make a public fork the GitHub repository, then make the changes to your local branch and push those up.

If you are already set up to build locally, you can build a fixed version for yourself and move on.

If you aren't, the easiest way to build with changes is to name a branch 'build' on your fork, and push that up to GitHub.  You'll need GitHub Actions enabled on your fork.  When you push up 'build', it will automatically build everything for you -- in about 30 minutes, you'll be able to download the *.zip files.

If you don't want to build for every platform (say you know that you only want this on Windows), then you can edit the build.yml file to remove the builds you don't want.  You only have to remove them from the build matrix stuff at the top.

strategy:
fail-fast: false
matrix:
python-version: [3.11, 3.13]
os: [ windows-2022, ubuntu-24.04, macos-15-intel, macos-14 ]
exclude:
- os: ubuntu-24.04
python-version: 3.11
include:
- os: ubuntu-24.04
gcc-version: 13
- os: macos-15-intel
llvm-version: 16 # AngelScript won't build on Intel Macs with llvm@17 or newer.
- os: macos-14
llvm-version: 18
steps:
- name: Checkout
uses: actions/checkout@v4

Remove whatever operating systems you don't care about from the 'os:' line.  Also, remove whatever Python you don't want from the line above that.

Remove the include / exclude lines that don't pertain to your target.  An extra 'include' down there will actually add something to the build matrix that you didn't expect.

Rob

[Jaime García]

Thanks, Rob!

I've build the software with the change and it still doesn't work. It must be another thing that I've not find. I'll keep looking through the code and doing some trials. If I find something I will let you know.

Kind regards,

Jaime

[Jaime García]

Hi Rob,

I wanted to follow up and share that I’ve managed to resolve the issue!

It turned out to be a combination of a couple of things:

1. A typo/bug in the force assignments: Besides missing the TimeAccurate_ condition I mentioned before, there was a copy-paste bug in VSP_Solver.C where CFoy_ and CFoz_ were accidentally being assigned DeltaFyo and DeltaFzo incorrectly (modifying CFox_ and CFoy_ instead).

2. Order in the .groups file: The placement of DeltaFlatPlateDragArea and FlatPlateDragRefReNumber parameters inside the .groups file is crucial. They must be placed after the inertia parameters, otherwise the solver fails to read the mass or inertia properly.

Additionally, I thought it would be useful to record position and rotations over time during the run, so I implemented the necessary changes for that as well.

I’ve submitted all these fixes and additions in Pull Request #380 on GitHub: https://github.com/OpenVSP/OpenVSP/pull/380

(I've also attached the video and .group.2 file to this email for quick reference).

Thanks again for your guidance!

Kind regards,

Jaime