|
|
|
|
|
|
|
|
|
|
|
|
| |
| |
| |
| |
| |
FAQ's |
| |
| |
|||||
|
|
||||||||||||
|
Answers to Frequently Asked
Questions (FAQ's) |
|
General CFD or
aerodynamics questions: Q1: Is there supposed to be a gap at the trailing edge of the
NACA 4-digit airfoil sections? |
|
Specific STARS CFD
questions: Q1: What is the STARS CFD surface geometry file, case.sur,
and how is it formatted? Q2: What is the STARS CFD background grid file, case.bac,
and how is it formatted? Q3: What is the STARS CFD boundary conditions file, case.bco,
and how is it formatted? Q4: What do all of the parameters in the STARS CFD steady
control file, case.cons, actually do? Q5: How are time steps calculated in the STARS CFD solver, and
how do I compute a true non-dimensional time step for my problem? Q6: What is the difference between the low and high order
solutions used by STARS, and which one should I use? Q7: The SETBOUND2 module is terminating abnormally when
executed. How do I correct the following error: MG1-err > subprogram fgsurf (u,v) - out of bounds
Q8: How does
STARS calculate generalized forces, and how do they relate to real
aerodynamic forces such as lift? Q9: What do
the angles Q10: How
do I analyze a testcase with Euler3d? Q11: How does
Euler3d Relate to STARS steady/unsteady? Q12: I have
any Euler3d Solution that is time step and grid converged. How do I find the Q13: The smooth surface I created from
Q14: Q15: Forces and motions appear aliased in the coupled aero-structural response. |
|
Q1: Is
there supposed to be a gap at the trailing edge of the NACA 4-digit airfoil
sections? A1: This is a question that comes up
a lot when defining the ordinates for an airfoil in a CFD geometry file.
Arguably, the bible for airfoil sections is Abbott and Von Doenhoff's Theory
of Wing Sections (TOWS), but the equations for NACA 4-digit
airfoils given in this reference define a small gap at the trailing edge of
the airfoil, i.e. the upper and lower curves defining the airfoil do not meet
at a point. Now, I've seen several
different versions of this equation through out the aerodynamic and CFD
literature, all of which seem to have been developed to close this trailing
edge gap because it is inconvenient. In fact, it has even been suggested to
me that the equation in TOWS is wrong! So, we went back to the
original NACA reports that define the ordinates for several 4-digit series,
symmetric airfoils to see what the correct definition really is. It turns out
that there really is a gap at the trailing edge of these airfoil sections as
they were originally tested, and the TOWS equation does seem to be
correct. You might still want to close the gap for numerical modeling
purposes, but at least now we know who is right and can proceed from there. The original NACA
reference for the 4-digit series, symmetric airfoils can be found online at: http://naca.larc.nasa.gov/reports/1931/naca-tn-385/index.cgi?page0013.gif. |
|
Q1:
What is the STARS CFD surface geometry file, case.sur, and how is it
formatted? A1: According to our original CFD
manual: case.sur contains the definition of the curve components,
surface components, curve segments, and surface regions required for the
geometrical description of the boundary of the computational domain to be
discretized. This data is generated by the user either manually or with the
help of a CAD system. It forms input for the module SURFACE. The curves and
surfaces in this file can be visualized with the module XPLT. Additional information,
including the correct format for the file, is given in STARS_sur.pdf. |
|
Q2:
What is the STARS CFD background grid file, case.bac, and how is it
formatted? A2: According to our original CFD
manual:case.bac contains the definition of the background mesh and the
source locations which provides the spatial distribution of the mesh
parameters. This data is provided by the user. It forms input for the modules
SURFACE and VOLUME. Additional information,
including the correct format for the file, is given in STARS_bac.pdf. |
|
Q3:
What is the STARS CFD boundary conditions file, case.bco, and how is
it formatted? A3: According to our original CFD
manual:case.bco assigns flags associated to different boundary
condition types for the curves and surfaces which form the boundary of the
computational domain and which will be passed to the flow solver. This data
is provided by the user. It forms input for the module SETBND2. Additional information,
including the correct format for the file, is given in STARS_bco.pdf. |
|
Q4:
What do all of the parameters in the STARS CFD steady control file, case.cons,
actually do? A4: According to our original CFD
manual:case.cons contains the NAMELIST used to specify the flow
conditions and coefficients (if they differ from the built in defaults)
required by the steady flow solver. This data is provided by the user. It
forms input for the module STEADY. Additional information
including definitions for all of the parameters and recommendations on how to
use the parameters, is given in STARS_cons.pdf.
This is sort of the STARS CFD bible with information about how to make the
solver do its job. |
|
Q5:
How are time steps calculated in the STARS CFD solver, and how do I compute a
true non-dimensional time step for my problem? A5: The non-dimensional time step, dt*,
used by the STARS unsteady CFD solver is computed using the freq and nstpe,
parameters defined in the control file, case.conu. Furthermore, the
dimensional time step, dt, used for the time advancement of the
structural equations of motion is computed using the Mach number, M,
and sonic speed, a, defined in the case.scalars file. The
equations defining dt* and dt are as follows: Note that the dt* defined
above is not a true non-dimensional time step since it is non-dimensionalized
by a length of unity, rather than some appropriate reference dimension based
on the geometry of the problem. To convert dt* to a true
non-dimensional time step that is more meaningful to aerodynamicists, one
would simply divide by an appropriate reference dimension such as the chord
of a wing. |
|
Q6: What is the difference between
the low and high order solutions used by STARS, and which one should I use? A6: The difference between the low
and high order solutions is the type of dissipation model which is used to
stabilize the numerical algorithm. The low and high order solutions use a
so-called low order and high order dissipation model respectively. The STARS
default is low = .false., or a high order solution, unless you specify
otherwise in the solver control file, case.cons or case.conu.
The low and high order dissipation models are both based on the same
fundamental set of equations. The difference between the two models is that
the high order dissipation utilizes gradient limiters to compute a set of
modified unknowns before it computes the dissipation. The idea being to
reduce the amount of dissipation that is added to the solution in regions
where there are real flow discontinuities. Other parameters that play a
significant role in the two dissipation schemes are the diss1 and diss2
parameters. The default value for both of these parameters is 1.0 unless you
specify otherwise in the solver control file, case.cons or case.conu.
These parameters are linear scaling factors for the dissipation models, with diss2
being the primary scaling factor for both the low and high order dissipation
models and diss1 controlling the low order dissipation for multigrid
problems only. In terms of performance, the low
order solution is much faster than the high order solution. Specifically, the
high order dissipation model takes about twice as long to evaluate with its
gradient limiters. Furthermore, the rate of convergence for the low order
solution is much higher. The result is that a low order solution will
converge in nearly half the CPU time of a similar high order solution.
Unfortunately, the low order dissipation is much too dissipative for most
problems. The default value of 1.0 for the diss2 parameter is much too high
for the low order dissipation. Shocks will be excessively smeared, and
gradients in subsonic flows will not develop fully. However, decreasing the
value of diss2 too low will often result in unstable solutions because there
is not enough dissipation being added. This leads me to a set of general but
somewhat vague guidelines on the use of the two dissipation models. For subsonic flows, you will
almost always need to use the high order solution. There are a set of
well-behaved problems that the low order dissipation works well for, but the
dissipation parameter must be set to around 0.4 or 0.5. If your solution will
run stable with that small amount of low order dissipation, then you might be
able to use the low order solution and save a lot of CPU time. However,
subsonic solutions with any sort of vortices will not develop using the low
order solution. Vortex gradients are completely smeared out for all stable
values of diss2 when using the low order solution. For supersonic flows, the
low order solution starts to regain its superiority. Vortex flows will
develop for supersonic flows with the low order dissipation. Also, the high
order solution quickly becomes unstable as you increase Mach number beyond
about 2.0, while the low order solution remains stable well beyond Mach 6.0.
Some experimentation will probably be required for each specific problem, but
hopefully this will give you some insight on how to proceed. |
|
Q7: The SETBOUND2 module is
terminating abnormally when executed. How do I correct the following error: MG1-err > subprogram fgsurf (u,v) - out of bounds
A7: This error message is probably an
indication that your case.bco file has the incorrect number of curves
specified in the header, and hence contains the wrong number of curve types. Make
sure the number of curves in the case.sur and case.bco files
are in agreement. See Question #3 for the correct
formatting of the case.bco file. |
|
Q8: How does STARS calculate generalized
forces, and how do they relate to real aerodynamic forces such as lift? A8: Generalized forces are computed
by the STARS unsteady CFD solver for each structural mode, Φ, defined
in the case.arrays file. They are computed in two stages. First, nodal
force vectors for every surface node in the domain are computed as F =
(P·A)·n, where P is a pressure, A is an
area, and n is the local normal vector. Next, the nodal force vectors
are converted to a scalar generalized force by summing the dot product of the
nodal force vectors with the nodal displacement vectors for a particular mode
shape, G = Σ(F·Φ). Based on the above discussion, we
can now determine the units for a generalized force. The nodal force vectors
are true dimensional forces with units that are consistent with those defined
in the case.scalars file. The nodal displacement vector for a mode
shape has units of displacement, which are again consistent with the units
defined in the case.scalars file. So, a generalized force has units of
force times displacement, similar to the units of a moment. Unfortunately a generalized force
does not relate directly to any of the fundamental aerodynamics forces unless
our structural mode shapes are defined in a very specific way. Let's say we
wanted STARS to calculate aerodynamic lift for a simple wing geometry as a
generalized force. In this case, we would need to manually define a
structural mode vector that applies a unit displacement in the z-direction
(or whatever direction is "up" for your wing) for every node on the
surface of the wing. All other nodes on farfield and symmetry walls (or any
other surfaces you don't want to include in the lift calculation) should have
a displacement vector that is identically zero. Now, the generalized force
associated with this mode shape will be a true aerodynamic lift for our wing.
Let's also assume that our case.scalars file uses metric units, kg and
m. In this case, the generalized force will have units of N m, so we will
need to divide by the size of our mode shape to get the correctly scaled
aerodynamic lift. Since our mode shape was defined as a unit displacement, we
divide by 1.0 m (a trivial coorection factor) to get an aerodynamic lift with
units of N. If aerodynamic moments are also of
interest, this procedure will be slightly more complicated. Let's say we
wanted STARS to calculate pitch moment for a simple wing geometry as a
generalized force. In this case, we would need to manually define a
structural mode vector that applies a one degree rotation about the y-axis
(or whatever axis is the pitch axis for your wing) for every node on the
surface of the wing. All other nodes on farfield and symmetry walls (or any
other surfaces you don't want to include in the moment calculation) should
have a displacement vector that is identically zero. Note that the
displacement of a rotational mode should be kept "small" since
STARS uses linearized dynamics to represent deformations. Since rotations are
inherently nonlinear, this means our rotational mode and its generalized
force will only be accurate for small angles. Let's again assume that our case.scalars
file uses metric units, kg and m. In this case, the mode shape we have
defined represents the displacement of every node in meters for one degree of
rotation, or we could say it has units of m/deg (this is not technically
precise, but it works out correctly if we think of it this way). If the mode
shape has units of m/deg, then the generalized force for this mode shape will
have units of (N m)/deg. To convert this generalized force to a true pitch
moment, we simply convert the degrees to radians by multiplying by 180°/π. In
this case, we do not need to divide by a length scale since we are computing
a moment that should have units of N m. If you want more hard-core technical
details of how this is done, check-out moments.pdf. |
|
Q9: What do the angles A9: The angles
Following the above sequence of
rotations, the free stream velocity vector now points down the positive x2-axis.
Having defined the orientation angles In the above expression, the
following shorthand notation is used: Cα = cosα, Sβ
= sinβ, etc. With the free stream velocity
vector now defined, it is fairly straightforward to verify that the angle |
|
Q10: How do I analyze a testcase with
Euler3d? A10: Refer to the basic operations
manual Euler3dbasics.pdf |
|
Q11: How does Euler3d Relate to STARS
steady/unsteady? A11: This document and accompanying
excel worksheet are a comparison between STARS and Euler3d. This is not an
instruction manual and assumes familiarity with STARS. |
|
Q12: I have any Euler3d Solution that
is time step and grid converged. How do I find the A12: This Mathcad document
automatically finds the correct NOTE: This assumes that you are
using a version of Euler3d that can read in an integer value for the |
|
Q13: The smooth surface I created from A13: Make sure that you are not defining
the contour lines of the surface as EXAMPLE: Half of an ellipsoid was
generated by defining 21 lines along the surface from one end of the major
axis to the other. These are the red lines in the contours link; the blue
lines are the grid lines of the flat surface. Each contour line was defined in the |
|
Q14: Euler3d and singular mass matrix errors: A14: Add a non-zero rhoinf and ainf to the .con file. The mass matrix is nondimensionalized by ainf and rhoinf for generalized force scaling. << Back to Top >> |
|
Q15: Forces and motions appear aliased in your coupled aero-structural response when using euler3d.
A15: Your modeshapes are corrupted. You should fix and then visually confirm all modeshapes in the .vec. file. << Back to Top >> |
|
|
||
|
|
URL: http://www.caselab.okstate.edu/research/faqs/index.html |
|
