Couple of Questions Regarding VSPAero 3.1

[Oliver Shih]

So I have been testing on different models, but seem to be getting the same issues:

1) I am constantly getting zero Cd0 values, even with a complex geometry with non-zero wing incidence angles with respect to the fuselage;

2) In the viewer I can only see my last test model. Say I chose 10 different AoA values, only the last one is visible in the viewer. In fact only one result is shown at all.

I'm still new to this, so it is very likely that I have done something wrong. Any comment would be helpful, what I might have toggled off or missed?

[Murat Bronz]

Hello Oliver, and All,

I also have the mentioned issues on a fresh compiled (yesterday in a Linux ubuntu machine) openvsp/vspaero too.

Additionally, when I want to save the image on VSPAero Viewer, the .tiff file is not being saved to anywhere in my computer.

Cheers,

Murat

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Murat BRONZ

[Rob McDonald]

I'm not sure about your zero CD0 values. Hopefully Nick will chime in
-- can you confirm that the solver is returning zero, or is ti a
problem on the OpenVSP side parsing the VSPAERO results?

Your question 2) I can handle... By current default, OpenVSP manages
running the multiple alpha cases by running a loop with VSPAERO. In
this mode, you can see the results displayed in the GUI as they are
completed, but you only get the final results on disk for the VSPAERO
Viewer to display.

Instead, you can select the 'Batch Mode' flag in OpenVSP. This causes
VSPAERO to run all the cases in a single go -- you have to wait to the
end to see any results, but it will run a little faster and you'll be
able to cycle through the different run cases in the Viewer.

Rob

> --
> 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.

[Rob McDonald]

The *.tiff screenshot capability of the viewer is currently disabled.  Instead, you should be able to use your operating system's built-in screenshot capability to grab any images you need.

Rob

[Oliver Shih]

Ah that's why. Thanks a lot regarding the second question!

As for the Cd0 values, a different test produces a non-zero value, but
it was way too large for a simple model that I had. For the model
that I obtained a (likely incorrect) Cd0 value, I added some slight
twist and dihedral to the main wing, and that was the only change
compared to the model that gave me zero Cd0. I used different
computers, however, so I might give it another go to come back to you.

> You received this message because you are subscribed to a topic in the Google Groups "OpenVSP" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/openvsp/pr_7tMUNO9A/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to openvsp+u...@googlegroups.com.

[Nick Brake]

Cd0 values...

The Cd0 values displayed in the Results Manager - VSPAERO plot screen are read in from the *.history file specifically the wake iteration table in this file.

Below is an excerpt of a vspaero VLM solution that I just ran with a basic pod and wing using OpenVSP v3.9.1.  I highlighted in yellow the Cd0 values that are read in by OpenVSP.  This is where I'd start to figure out if the error is in parsing the *.history file.  If the value here in the *.history file is not what you expect see if you can locate which component is contributing to the bad values by looking at the end of the *.history file.  Here you'll find a component Cd0 breakdown, I've highlighted this section in blue.  Can you post (or email me) the *.history file and/or the *.vsp3 file that is giving you issues?

Solver Case: 1 

  Iter      Mach       AoA      Beta       CL         CDo       CDi      CDtot      CS        L/D        E        CFx       CFy       CFz       CMx       CMy       CMz       T/QS 

        1   0.00000  10.00000   0.00000   0.33874   0.00490   0.01098   0.01588  -0.00000  21.33556 332.79220  -0.04801  -0.00000   0.33550  -0.00000  -0.98556  -0.00000   0.00000

        2   0.00000  10.00000   0.00000   0.33874   0.00490   0.01098   0.01588   0.00000  21.33261 332.72506  -0.04801   0.00000   0.33550   0.00000  -0.98564   0.00000   0.00000

        3   0.00000  10.00000   0.00000   0.33875   0.00490   0.01098   0.01588  -0.00000  21.33205 332.71750  -0.04801  -0.00000   0.33551   0.00000  -0.98575  -0.00000   0.00000

        4   0.00000  10.00000   0.00000   0.33876   0.00490   0.01098   0.01588   0.00000  21.33204 332.72072  -0.04801   0.00000   0.33552   0.00000  -0.98585   0.00000   0.00000

        5   0.00000  10.00000   0.00000   0.33877   0.00490   0.01098   0.01588  -0.00000  21.33223 332.72845  -0.04801  -0.00000   0.33553  -0.00000  -0.98592  -0.00000   0.00000

Skin Friction Drag Break Out:

Surface                                      CDo 

WingGeom,0                                  0.00182 

WingGeom,1                                  0.00182 

PodGeom                                     0.00032 

PodGeom                                     0.00032 

PodGeom                                     0.00032 

PodGeom                                     0.00032 

[Murat Bronz]

Thanks for the answers !

To unsubscribe from this group and stop receiving emails from it, send an email to openvsp+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Murat BRONZ

[Oliver Shih]

Attached are the two history files I generated using the same model
and conditions but one with VLM and the other with panel method, and
the model I used. The panel method doesn't even generate a list of Cd0
values per component, and it just spits out a zero. I'm not sure
whether this is faulty or a limitation of the method. Also it doesn't
even generate the correct Cdi, returning only negative values.

As for the VLM, the Cdi is also faulty at low AoA, and although the
Cd0 value is not zero, it seems too high. The wing seems to have an
enormous contribution compared to your model. My wing had some
dihedral and twist added to it, which might be the reason, but I
highly suspect it is going to increase the Cd0 by 3 times. That gives
a total Cd0 of 0.024, which is unusually high since I had a simple
geometry.

Thanks a lot for answering my question, and I have attached the files
for you to look into a bit further.

[Oliver Shih]

I've run into yet another problem... I think the mass property tool is
malfunctioning a little bit. Sometimes it assigns a completely
enclosed part zero volume and therefore zero mass even when specified
a density. I know this is faulty because if I isolate the troubling
parts and run CompGeom and MassProp on them, they generate the correct
results, but not when calculated along the whole aircraft. Also the
volume of some part varies drastically with increasing number of
slices, but this is a minor issue compared to the first one since I
can find the 'sweet spot' on the slicing to give correct results.

Another small thing is it seems that MassProp includes point masses in
the calculation, but they don't show up in the output file.

2016-09-08 16:35 GMT+10:00 Nick Brake <nbrak...@gmail.com>:

[Rob McDonald]

Oliver,

When two components overlap, OpenVSP has to choose which component's
density to use for the mass calculations. On the Gen tab, there is a
Priority option that allows you to assign a priority value to the
density of that component.

Lets say you have a Pod that is fully enclosed within a Fuselage. The
Fuselage density is 1.0, the Pod density is 10.0

By default, both have priority 1.0, so OpenVSP will use the density of
the first one in the list. Since this is probably the Fuselage
(assuming you added it to the model first), then the pod won't show up
at all.

However, if you change the Pod's priority to 2, when MassProp reaches
the overlapping regoins, it will choose to use the Pod's density
instead of the Fuselage.

The volume of any part should not vary _drastically_ with the number
of slices. Of course, if you use 20 slices for the entire aircraft --
and you have some very small parts, those 20 slices will spread over
the entire aircraft, and you may miss the small component entirely.
Use your judgement.

Also, the on-screen tessellatoin resolution will also have significant
influence on the MassProp results. Increase the resolution until you
reach a reasonable approximation of your shape.

To your other point -- yes, there are several ways that the MassProp
calculation and output can be improved. There is active work in this
area, so I would expect an update before too long.

Rob

[Oliver Shih]

Thanks for the detailed explanation Rob! I simply assumed that by
turning on the thin shell property the part (ie the fuselage) will not
be interfering with objects it contains. For now I am having
difficulty getting a detailed mass property analysis because I have
included massive but very thin objects (say a bulkhead) in my model. I
cannot increase the number of slices beyond around 80; any higher
setting will crash the VSP as soon as I hit the compute button, but if
I settle with a lower slice number thinner parts are not represented
correctly. Is there a way around this other than me breaking down the
aircraft and analyze the bits separately before manually putting the
numbers back together?

[Rob McDonald]

Good news, bad news...

The good news is, the shell mass properties calculations have nothing
to do with the slicing resolution. You'll get the same shell answer
no matter how fine or coarse the slicing.

The bad news is the shell calculation performs an operation like
CompGeom -- it only keeps the wetted surfaces. It then calculates the
mass properties of the resulting triangles -- as a thin shell.

So, the slicing and priority stuff only impacts the volumetric mass
property calculations.

It shouldn't crash at any level of slicing -- the computation will get
more expensive, but it shouldn't get any more difficult or unstable.
There is the possibility of any slice causing a random crash I suppose
-- and with more slices, you increase the probability, but it really
shouldn't be a problem. The hard-coded number of slices when
DegenGeom does the slicing is 150.

Rob

[Oliver Shih]

I went back and ran MassProp three times on the same model but with
different slicing numbers. Attached are my screenshots. The mass
values changes by quite a bit.

I checked the MassProp txt files and found that it was mainly one
component that was contributing to most of the error. As a design
project we were supposed to come up with an aircraft that is powered
by batteries. The way I modeled my battery was I used the same airfoil
as the wing, trimmed both the LE and the TE, and shoved it into the
wing. Somehow on the 20 and 100 slice MassProp runs, the 2 batteries
(one in each wing) are way too heavy than they should have. I isolated
the battery and did a CompGeom run, and the volume values are correct
(as I put in a specific required volume to begin with), but in the
MassProp calculation the volume is MUCH bigger than what they really
should be.

I also attached my 2 MassProp output files for you to check. I know I
have been bugging you guys with a lot of questions, and I highly
appreciate your help and patience!

[Nick Brake]

Bug away we will try to keep up with responses as best as possible and usually someone posting a question means many people are likely to run into similar issues.

I did notice that the 100slice mass file includes several mesh geoms, possibly from previous calls to mass prop compute?  I opened up you prototype5_hollow.vsp file you attached eariler and did some testing and I found some interesting behavior with successive calls to mass prop compute not related to slicing count.  Note that a mesh geom is added for each call to mass prop compute.  This mesh geom is added to the geometry set and that was selected for the analysis.  If i didn't delete mesh geom and kept making calls to mass prop compute I got a corrupt result likely due to trying to slice the previous mesh geom.  I've attached some pictures showing successive calls.  The first two calls work well, the third shows bad geometry, highlighted in yellow, and very different values for the mass properties.

call 1

call 2

call 3

I was able to get consistent correct results if I deleted the mesh geom and re calculated.  Always make sure the geometry being set to the mass properties analysis is just the geometry you want.  Future releases of OpenVSP might make this a little simpler.

n

[Oliver Shih]

Thanks Nick for your awesome response! I usually would delete the old mesh, but I might have forgotten to do so from time to time. I went back and gave it another try (making sure that I would delete the old mesh before running MassProp again), but the total mass still varies non-linearly with the increasing number of slices. Also I tried doing 150 slices, but it crashes pretty consistently...

One thing that just came to mind was: would it help to generate more accurate results if I were to rotate the whole aircraft for say 45 degrees with respect to the global origin? It might generate better mass calculations especially for the thin components that were parallel to the slices.

To unsubscribe from this group and all its topics, send an email to openvsp+unsubscribe@googlegroups.com.

[Nick Brake]

Yes, rotating the aircraft should help refine thin surfaces that were originally parallel with the slicing plane.

Are you able to email me the model you are working with?  Crashing at 150 slices is interesting and I'd love to get a look at it in debug mode and see if I can recreate the crash and catch the exception. 

n

To unsubscribe from this group and all its topics, send an email to openvsp+u...@googlegroups.com.

[Oliver Shih]

Here you go Nick. The file is not built for VSPAero analysis; instead it has a bunch of weird features drawn into it. For example, I messed around with the tail surfaces and actually drew out the control surfaces for generating pictures.

Also have you been looking into the Cd0 problem?

To unsubscribe from this group and all its topics, send an email to openvsp+unsubscribe@googlegroups.com.

[Nick Brake]

I would expect the total mass to vary non-linearly as it converges on the answer.  As the number of slices gets larger the mass integration catches different parts of the vehicle geometry.  Below is a quick "grid study" on the total mass varying the number of slices.  This is expected behavior and hopefully the same behavior that you are seeing as well.

I haven't looked at the Cd0 much and when I looked at it initialy I saw a Cd0 of 0.  My recommendation would be to use VSPAERO for induced drag, Cdi, and do your own parasite drag build up that way you can control things like % laminar flow, surface roughness, and interference factors explicitly.  You'll end up with a much better representation of the overall vehicle drag for your performance estimates.

n

To unsubscribe from this group and all its topics, send an email to openvsp+u...@googlegroups.com.

[Oliver Shih]

That looks about right! I had a spreadsheet to keep track of all the area, volume and density values and it summed up to be around 6280. So are you having any crashing issues at all? Is it a random thing or do I need to use a better computer?

To unsubscribe from this group and all its topics, send an email to openvsp+unsubscribe@googlegroups.com.

[Oliver Shih]

Hi Nick,

I have another problem here... I did some simple VSPAero to find the neutral point of my modified aircraft, but I got this weird result from the viewer. Attached is a screenshot of the result I obtained. Any idea as to why deltaCP appears to be constant everywhere?

Also on a possibly related note, I cannot create the geometry of this model when using the panel method but I can successfully run CompGeom. Would you please have a look into it? I have also attached my model. I really appreciate you tirelessly helping me out!

Sincerely yours,

Oliver

To unsubscribe from this group and all its topics, send an email to openvsp+unsubscribe@googlegroups.com.

[Nick Brake]

I've had some crashing on my home laptop which is about 6 years old.  I'm not too sure what's going on here, it doesn't seem to happen 100% repeatedly and the crash probability is loosley associated with the number of slices.  Other, more powerful, machines that I've opened the model on have done much better.

This one will take some investigating, either way I think something is going on that shouldn't be.  I never got a corrupt vsp file so saving often seems to be an "ok" workaround (albeit not a great one).

n

To unsubscribe from this group and all its topics, send an email to openvsp+u...@googlegroups.com.

[Nick Brake]

Constant deltaCP colors - 

The contour max/min levels are automatically set to capture the entire range of CP within the solution.  If there are CP spikes in the data you will see the majority of your model show up as a single color.  

Show the legend by: Legend --> Contours Legend

Adjust the levels in the viewer by: Options --> Set Contour Levels

Errors when creating panel geometry - 

I did not get any errors when creating the panel geometry from your stock model but i did have some trouble getting it into VSPAERO.  Looking at the Solver Console I noticed that VSPAERO had output warning messages about the geometry and when i attempted to solve the solution resulted in nans.  The warning messages from VSPAERO related to "wing 10" and "wing 3" in the degen file.  These wing indices correspond to the main wing and vertical tail wings in your vsp3 model.  I was able to get a solution for the panel method by lowering the main wing by 0.1 units and extending the fuselage length by 0.1 units.  I also increased the tessellation on the empenage to get more triangles near the trailing edge of the vertical tail.

The OpenVSP geometry generation and VSPAERO solvers are fairly robust however it's difficult to account to for all situations.  It looks like this is a case where the geometry needed to be adjusted slightly to get a solution.  I attached the modified vsp model.  Take a look at the wing/body intersection and vertical tail and fuselage intersection

note increased tessellation and offset between vertical TE and fuselage end.

note highlighted section where triangles are between old wing and fuselage. new wing has improved intersection with fuselage.

Here's a pic of the panel solution i ran to make sure it would get all the way through.

To unsubscribe from this group and all its topics, send an email to openvsp+u...@googlegroups.com.

[Oliver Shih]

Wow Nick, thanks for doing all of these for me! I have, however, figured out most of the problem in the meantime. I think the wing was faulty for at least two different reasons. The one that I am certain was I used an X-rotation instead of the dihedral setting to tilt up the wing. The reasoning behind this is I had other components in the wing, and doing dihedral does not rotate any of the children components with it. The other reason was somewhat more peculiar: sometimes if I remove the wing and then redraw another one that is completely identical, it just miraculously works. I have had this problem before with a fuselage, and I would certainly want to know more about the cause behind this.

As for the vertical tail, I suspected that CFD might not like end part very much, so I moved the tail forward a little instead of increasing the length of the fuselage. It works as well. 

I will almost definitely come back to you if I run into further problems, but still I appreciate all the help you have provided!

To unsubscribe from this group and all its topics, send an email to openvsp+unsubscribe@googlegroups.com.

[Oliver Shih]

So I'm back...

Can I get some quick intuition about why my VSPAero model is stuck at Creating Interaction Lists? Is it caused by bad geometries? I basically had the same tail as before with two sections, but this time it seems like there is a problem with it. I can already see that the problem is caused by the interaction between the vertical tail and wing since if I move them apart it works fine. I have already set different priorities to them, is there anything else I should do?

To unsubscribe from this group and all its topics, send an email to openvsp+unsubscribe@googlegroups.com.

[Oliver Shih]

I have been getting into a serious problem. My team has decided to go with the T-tail aircraft for our design project, and the next step for us is to locate the neutral point. However it seems like as long as it is a T-tail, the neutral point almost always falls somewhere extremely close to the aerodynamic center of the main wing, which is highly problematic. I have tried many different things: changing the distance between the wing and the tail, adjusting the tail surface area, taking out the rotors, etc. Nothing has really moved the neutral point by much, but as soon as I lowered the horizontal tail and made it a more conventional layout, the neutral point ends up in a much more reasonable location. Is there any insight I can pick up? Do I seem to be doing anything wrong here?

The lecturer showed a method in class of setting x_ref at two arbitrary locations, and do stability calculation to find out d(CMy)/d(alpha). With the two values found at two lcoations, he makes the assumption that d(CMy)/d(alpha) varies linearly with x and does a linear interpolation to find the neutral point (at where d(CMy)/d(alpha) is zero). The result is pretty accurate (usually with an error of less than 0.05), and it is the method that I'm using. I don't see why changing the altitude of the horizontal tail would have any significant impact at all; I would assume that as long as the lift moment arm is fixed then there shouldn't be much change in where the neutral point is. My guess would be that somehow drag has become more dominant and was rotating the aircraft the other direction?

I am really stuck here, but since we still have a lot to do with the project I have to move on and settle for now. However I am still very eager to find out what was done wrong or ill-considered. 

To unsubscribe from this group and all its topics, send an email to openvsp+unsubscribe@googlegroups.com.

[Brandon Litherland]

Oliver,

If you want the child components to remain attached to a certain region of the wing and rotate as the body changes (Dihedral, twist, span, etc...) you should attach with UW.  This will fix the part to a certain location ON the body instead of the body origin.  If, for example, you want your engines to remain aligned with freestream but to stay at some % span location on the wing and translate w/ dihedral, you simply attach translation in UW and leave rotation to NONE.  In this case, the engines will remain attached at the wing but never rotate out of the freestream-vertical plane.

Hope this helps in your design.

[Oliver Shih]

Hi Brandon,

Thanks for the tips! May I say I began learning how to use OpenVSP by
watching your videos on Youtube, and it was incredibly helpful for a
beginner like myself!

I have, however, gotten myself into another peculiar problem. I will
attach the model I am working on. The problem I am having is with
MassProp. VSP crashes every time I try to run MassProp. I have already
found out the problematic part: it is the skin of the wing. If I take
it out and run MassProp it works perfectly, but with it included it
just doesn't.

What's really strange is I can't seem to figure out why it is. The
wing I drew has many sections because I trimmed two sections of it to
draw out the flaps and ailerons for pictorial purposes. I thought it
was because doing so gives discontinuity problems, but even deleting
all sections and leaving one behind does not solve the problem for me.
What did fix the issue was I changed my CST airfoil for all sections
to a standard NACA four series, but that doesn't make any sense
because I have other components with the same CST airfoil, and they
show up correctly in MassProp.

Of course while running MassProp I can always leave out the skin of
the wing and still get a pretty accurate result (since it is pretty
light compared to other components), but I would be reluctant to do
that, and I would really like to figure out exactly what is causing
the problem so I can fix it once and for all. Any help or suggestions
appreciated!

Sincerely yours,

Oliver

[Rob McDonald]

Oliver

That is quite a model you have there -- it doesn't look like you're a
beginner by any means.

When MassProp (and similar CompGeom, PlanarSlice, WaveDrag) operations
run, they start from the wireframe you see on screen and insert
diagonals to make triangles, so, if the wireframe is generated OK,
then it really doesn't matter whether the surfaces were generated
using CST, NACA, Ellipse, etc.

Instead, the thing that will make MassProp crash is having truly
degenerate geometry. We handle a lot of these cases, but we are far
from perfect. Triangles that perfectly overlap is one example of a
problem.

MassProp runs in two stages, first it runs CompGeom. Then it runs
PlanarSlice (x-direction). After those operations, it does its
calculations. Though not tremendously useful, you can run those two
operations independently to see if it gives any clues where the
problem occurs. Yours will crash both/either in the early stages.

I can see that your model is crashing at an early stage where it tries
to merge open meshes into a single closed mesh. Nominally, this code
would recognize that a simple wing component meets perfectly at the
center line and it would merge them into a single component before
proceeding.

If I delete everything but your main wing -- and turn off symmetry, it
succeeds in running CompGeom. but still fails in MassProp... Not sure
why...

I can use your file as a test case for some debugging, but that won't
help you find a solution in the short term.

My main suspect would be the airfoil sections you place on top of one
another to simulate the flap cutout. You may try putting a finite
span to those areas.

Rob

> 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.

[Oliver Shih]

Dear Rob,

I am really flattered! I have been learning how to use OpenVSP for
about two months now; I can see its great potential of becoming an
extemely powerful tool, and I am still learning new things everyday
from the software and you guys. I feel somewhat guilty for bringing up
so many problems, but also really excited that I am actively
participating in the process of development. I hope it is okay with
you because surely there will be more questions on the way!

As for now, I am not entirely sure it was the flap cutout that is
causing the problem. Firstly I have ensured that all sections would
have a small but finite span (0.002 to be precise). What I did that
actually fixed the problem was that I changed all of the airfoils on
the wing to a regular build-in airfoil, and it just worked. This made
no logical sense to me since there are other components using the same
airfoil, so I suspect the problem is slighhtly more complicated than
the airfoil itself. However for now I can't seem to figure out what
other factor is kicking in; I would very much like some insight if you
find out the cause some day.

Other issues that I have been having are:

1) not only does VSPAero generates 0 Cd0, but it also gives negative
Cdi at low AoA (I usually use 1 to 2 degrees to simulate level flight)
2) MassProp seems to be ignoring the point masses while computing (it
appears to be unrelated to the # of slices; even at 200+ slices the
point masses do not show up in the output file)

Once again thanks to all of you for your awesome help!

Sincerely yours,

Oliver

[Nick Brake]

The priorities shouldn't affect the VSPAERO solution, the priority values are primarily use in the calculation of mass properties where one component is overlapping the other and the calculation has to decide which density to use.

One approach you can take is to eliminate the vertical if your focus of the aerodynamic solution is to look at longitudinal characteristics.  This will reduce the complexity of the problem and speed up the computation.  When looking at lateral stability the connection between the vertical tail ad horizontal stabilizer may become important however on a first look lateral analysis you may consider keeping the the gap to get a computed solution.

You can also look at running both the panel method and vlm solutions.  The internal solver is the same but the geometries use in each method are different and one may give you more insight into the solution.

I also tend to always back up my analysis with multiple methods and if one method is running into issues or suspect results I'll go use another tool to see if I can get consistent results.  AVL or XFLR5 are tools I have used in the past to check my analysis, they work well but have their own limitations.

n 

To unsubscribe from this group and all its topics, send an email to openvsp+u...@googlegroups.com.

[Nick Brake]

Regarding the height of the horizontal tail affecting the neutral point of the aircraft - 

The lower conventional tail will be closer to the wake of the main wing.  The influence of the wake on your tail may be significant.  I would test your geometry in another tool and see if you get similar results.  If you see a similar trend of the neutral point then you may be seeing a real physical phenomenon.  If a different trend appears then you may try adjusting the number of wake iterations in VSPAERO to see if you can get a consistent set of results.

Keep in mind that the location of the neutral point with respect to the aerodynamic center of the wing is not inherently problematic.  The main concern in early design is the location of the aircraft CG with respect to the neutral point due to their impact on the stability characteristics of the vehicle.

n

To unsubscribe from this group and all its topics, send an email to openvsp+u...@googlegroups.com.