How do I get started with Euler3d?
A basic operations manual: Euler3dOverview.pdf
Introduction to Euler3d: IntroductionToEuler3d.pdf
In-depth Euler3d Reference manual: Euler3DReference.pdf
Can I get the source code?
Probably not, unless you work for/with us. For more details contact email@example.com.
If you are interested in the euler3d cfd benchmark source code, an earlier one-dimensional version exists here. Warning: The 1D code does not contain the complexity inherent in the 3D euler3d code.
Is there supposed to be a gap at the trailing edge of the NACA 4-digit airfoil sections?
This is a question that comes up a lot when defining the ordinates for an airfoil in a CFD geometry file. Arguably, the canonical reference 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 on page 13 of NACA-TN-385.
What is the STARS CFD surface geometry file, case.sur, and how is it formatted?
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.
What is the STARS CFD background grid file, case.bac, and how is it formatted?
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.
What is the STARS CFD boundary conditions file, case.bco, and how is it formatted?
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.
What is the difference between the low and high order dissipation used by STARS, and which one should I use?
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 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.
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.
The SETBOUND2 module is terminating abnormally when executed. How do I correct the following error:MG1-err > subprogram fgsurf(u,v) - out of bounds
This error message is probably an indication that your case.bco file has an 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.
How does STARS calculate generalized forces, and how do they relate to real aerodynamic forces such as lift?
Generalized forces are computed by the STARS unsteady CFD solver for each structural mode, Φ, defined in the case.vec file (or .arrays for mg codes). 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 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 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.
What do the angles
betaspecified in the case.con file represent, and how do they relate to the Euler angles?
betaare orientation angles that define the direction of the free stream velocity vector with respect to the body's local coordinate system. These two angles define two consecutive rotations, whose order is extremely important. Initially, the free stream velocity vector is positioned such that it points along the positive x-axis. We then apply the following rotations to our coordinate system, which includes the free stream velocity vector pointing down the positive x-axis:
- Rotate the x, y, z frame about the z-axis through the angle
betato the new frame x1, y1, z1.
- Rotate the x1, y1, z1 frame about the y1-axis through the angle
alphato the new frame x2, y2, z2.
Following the above sequence of rotations, the free stream velocity vector now points down the positive x2-axis. Having defined the orientation angles
beta, the components of the free stream velocity vector in terms of the original x, y, z frame are computed as follows:
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
alphais NOT the aerodynamic angle of attack unless Cβ = 1. In fact, the angles
betaare defined identically to the Euler pitch and yaw angles respectively for the case of zero roll angle. Nevertheless, the case of nonzero roll angle can be represented by the two STARS orientation angles, but the mathematics is too complicated to present here. If you want to read more details about the relationship between the two STARS orientation angles and the three Euler angles, check-out angles.pdf. Once you've read that, we have a program that will automate this calculation for you. Check-out our codes page to download it.
How does Euler3d Relate to STARS steady/unsteady?
I have an Euler3d Solution that is time step and grid converged. How do I find the
isizevalue for the multistep training signal?
The smooth surface I created from
volumeis a chaotic mess after running
makeg3d. What is causing the distortion of my surface?
Make sure that you are not defining the contour lines of the surface as
curve components. Only boundary lines should be defined as
curve components. Points on the interior of a surface that define its shape should only appear in the
surface componentsection of the
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
curve componentssection of the
.surfile as well as the
surface componentsection. The resulting surface was extremely distorted as seen in the bad ellipse link. The program
makeg3dtried to make each curve in the
curve segmentsportion of the
.surfile a boundary curve resulting in the contorted figure instead of the smooth ellipsoid.
Euler3d fails with singular mass matrix errors:
Add a non-zero rhoinf and ainf to the .con file. The mass matrix is nondimensionalized by ainf and rhoinf for generalized force scaling.
Forces and motions appear aliased in your coupled aero-structural response when using
euler3d. Reducing the timestep does not help.
Your modeshapes are probably corrupted or not smooth. You should visually confirm all modeshapes in the .vec.
Surface says that all angles are not too small. Volume immediately warns that small angles exist. How can this happen?
Surface reports 2D angles. Volume reports 3D angles. Your triangles in 2D are well formed, but the surface in 3D is wrinkled. This could be an indication of poor surface splines.
Investigate all grid warnings!
I have overlapping triangles. My surface .fro is wrinkled. Volume reports intersecting faces. Adding more or tighter grid sources (.bac) does not converge surface wrinkles. How can I fix the .sur file?
In extreme cases, poor splines cause overlapping surfaces, wrinkled surfaces, and intersecting faces. The SR-71 image below shows a spline problem in the nozzle area. The blue triangles are the overlapped triangles with forward pointing normals.
The best solution is to reform the surface definition. Try removing or reducing the number of points in the surface component. Try spacing the points evenly. Try fitting a 1D spline to the known points and compare the curves.
Visualization and colorization of surface normals helps to spot these surface problems.
Historical FAQs are at Historical FAQs.
Your question could and should be here!