CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Main CFD Forum

Boundary Layer created by Euler Solvers

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   November 13, 2001, 11:43
Default Re: Separated Inviscid Flow - A Reference
  #21
Axel Rohde
Guest
 
Posts: n/a
Kalyan,

Although I agree with most of your theoretical views on the Euler and Navier Stokes equations, there are a few statements you made that do trigger a response in me (although I would eventually like to close this chapter):

As far as I know there are no Euler solvers that actually implement,

DS/Dt = 0

They all have some amount of numerical viscosity, which acts as entropy law enforcement. A certain amount of numerical viscosity is a necessity, otherwise you will end up with phenomena like expansion shocks in perfect gases, which are physically incorrect (see above post). So most Euler solvers (at least the ones I know) do have the entropy law 'built in',

DS/Dt > 0

"Separated flows, unlike ones with shocks, do not form unique solutions for any form of continuous Euler equations."

Steady flows with shocks, I believe, are not always unique, either. If I remember correctly, the supersonic flow over a cone (for certain cone angles) can either form a (strong) detached bow shock, or a (weak) attached oblique shock, depending on the initial conditions present.

"The functional forms of Euler and NS equations are different : NS equations are parabolic and Euler equations are hyperbolic."

As a programmer, I am only interested in the unsteady Euler and NS equations, because they can simply be marched in time (perhaps there was a misunderstanding). The unsteady (compressible) NS equations, I believe, are a mixed set of hyperbolic-parabolic equations (hyperbolic in time and parabolic in space, I believe, but please correct me if I am wrong). From a numerical viewpoint, both sets of equations are very similar, one is the subset of the other.

"If you use Euler equations and predict separation, this separation is aided by numerical viscosity which as we all know depends on grid spacing. As we refine the grid, the numerical viscosity keeps shrinking and the separated solution keeps changing."

According to this statement the unsteady separated inviscid flow over my triangular prism,

www.microcfd.com/prism.htm

would change its character (not only its amount of detail) each time I double the resolution. Yet I do not find this to be the case. I used to run this test a few years ago at a 200x150 resolution and I got a steady wake (due to heavy numerical damping). When I doubled the resolution to 400x300, the wake became unsteady and its character (in shape and time evolution) looks identical to the current 800x600 resolution. I will soon run this test at 1200x900 (1.08 million cells) resolution, and I will bet you the overall picture will look the same. So I am led to believe that the amount of numerical dissipation within each cell approaches a constant level once the grid has reached a certain fineness. I consider it the 'Kolmogorov microscale of inviscid dissipation' (quite an oxymoron...

Also, I have run quite a few inviscid codes over slender surfaces (airfoils) with a NO-SLIP condition in place to test the amount of numerical viscosity present in the solver. There is a point where the 'numerical' boundary layer thickness stays the same, no matter how much you refine the mesh. A good Euler code (like TVD) will exhibit virtually no numerical boundary layer or confine it within the first layer of cells. Ideally, an Euler solver should come up with the same solution, regardless of whether you implement a slip or no-slip condition. The same concept applies to shear layers. I have run Euler (TVD) simulations with supersonic jets exiting into a subsonic free-stream where this was actually the case. There was perfect slippage with no detectable shear layer (not one intermediate layer of cells). For an FVS solver (like MicroTunnel) this is not the case, but on the other the code is very robust.

Anyway, these are just some of my observations I have made over the years, and I am not sure how they fit in with more classical theory. Again, I am mainly a 'number cruncher', and not much of a theoretician.

Axel

P.S. By the way, I only use the conservative form of the equations when writing my code, for both Euler and Navier Stokes solvers.
  Reply With Quote

Old   November 13, 2001, 14:08
Default Re: Separated Inviscid Flow - A Reference
  #22
kalyan
Guest
 
Posts: n/a
Axel,

I agree that it was found necessary in some of the Euler solvers (in Roe's scheme atleast that I am aware of) to explicitly enforce the entropy condition to prevent unphysical expansion fans. In the early days (when I started in CFD with Euler solvers), I was wasn't too afraid of numerical viscosity. However, once you switch to Navier-Stokes solvers, it is hard to digest an explicit entropy condition since real viscosity is supposed to take care of it automatically. Hence, a lot of research has been devoted to developing solvers (mostly incompressible for use in DNS and LES) with minimal numerical dissipation.

On the other hand, I agree that the need for kinetic energy preserving schemes (zero effective numerical viscosity schemes) may have been overstated in the context of compressible flows (given the additional problems in dealing with shocks/shocklets, expansion fans etc.). Entropy fix might very well be needed even in DNS or LES, I can't say since I haven't worked on compressible solvers for atleast 7 years. Perhaps it is worth looking into schemes that do not need such fixes (since LES community would be all over it).

Regarding you observations about simulations of flows around triangular prisms, it is hard to conclude that numerical dissipation reaches a constant level by using this problem. You have to realize that the prism has sharp edges and the flow always would separates at these sharp edges thus making the solution look grid independent. Try the same procedure on flow around an ellipse and I bet that grid independence is hard to achieve (since there is no point where one can say apriori the flow would separate). Better yet, try the problem that Adrin always seems to recommend, the flow around a circular cylinder.

You can not run Euler solvers with a no-slip condition because by adding this condition you are overspecifying your BCs. I am not sure what the results mean. It has been a long time since I have read up on Euler/compressible solvers. Can you suggest a recent review that I can read so that we do not talk past each other in the future.
  Reply With Quote

Old   November 13, 2001, 14:55
Default Check your Post processor software!
  #23
kp
Guest
 
Posts: n/a
Your software may be interpolating wall values which assumes them as zero at wall to cell center values.


  Reply With Quote

Old   November 13, 2001, 15:13
Default Re: Separated Inviscid Flow - A Reference
  #24
Adrin Gharakhani
Guest
 
Posts: n/a
Axel,

I find myself in agreement with Kalyan, yet again.

I think we are talking about two issues. One is whether theoretically, it is possible or even permissible to get an effectively viscous solution out of the Euler equation (even applying "no-slip" BC). The other is whether we can actually get "A" viscous solution out of the Euler equations at the implementation level.

In the ideal case, a good implementation combined with infinite precision should agree with theory. But ...

Having said that, just because you can get "a" separated solution that "appears" even to have converged it doesn't mean that you should trust the results or, worse, to argue that you can get separation in an inviscid flow.

The idea behind CFD, hopefully, is not just to get nice color moving pictures (and I'm just as guilty I guess ), but hopefully to learn more about the physics of the flow. But if the code cannot reproduce what we already know to be true theoretically, how can we ever trust anything else that the code spits out? This may sound a purely philosophical argument, but it really isn't.

IF by doubling your grids you have reached a "grid-independent" solution then you need to be very concerned about the methodology you are using. You might have actually stumbled on something really significant and you should not casually shrug it off. The method that you are using must have some accompanying theoretical convergence analysis that should show convergence towards the Euler solution. IF that is not what you are getting, it is entirely possible that the theoretical analysis is wrong and convergence really should be something like O(h^n + constant) instead of just O(h^n). This is very significant as it also helps out with the NS solutions. It may also imply that the algorithm is incorrect or at best poor. What I mean by this is that your discrete solution may/is NOT consistent with the differential equation.

Finally, one thing you can check is single vs. double precision. It is also possible that you have "saturated" your solution due to insufficient precision of the computations.

Bottom line, in your triangle case, as Kalyan mentioned, the "singularity" helps your solution to create the illusion that you can get separation with an Euler code. But I'll go one step further (and I've talked about this before), if you have a true singularity (especially with an Euler code) you cannot even get a converged solution. That is, as you make your grids finer and finer your solution near the corner will become more and more singular and the code will have even more hard time to converge (if it doesn't actually blow up). The only reason you are getting something is because you have "numerical" roundness at the edge. So, you are not solving what you claim you are or you would get garbage as you refine your grids!

As Kalyan mentioned, I like the "simple" cylinder benchmark case because it has no sharp edges and if you should get any physically correct separation, then let's see us your code capture the primary, secondary and tertiary vortical structures.

Your arguments are very much along the lines of what people do these days with the vorticity confinement algorithm. In the latter, by switching a "knob" you can get a range of solutions from attached to separated flow using an "Euler" code!

Adrin Gharakhani
  Reply With Quote

Old   November 13, 2001, 20:17
Default Re: Separated Inviscid Flow - A Reference
  #25
xyz
Guest
 
Posts: n/a
Please note:

we only use the Euler Equations to describe the flow when the boundary layer is very thin with no separation. If this is not true, you can not it at all, at least not in the separation zone and the boundary layer.

  Reply With Quote

Old   November 13, 2001, 22:14
Default Re: Boundary Layer created by Euler Solvers
  #26
Jim
Guest
 
Posts: n/a
Thanks, but that's exactly what I do.
  Reply With Quote

Old   November 13, 2001, 22:41
Default Re: Boundary Layer created by Euler Solvers
  #27
Jim
Guest
 
Posts: n/a
I'll be happy to let you know if I should make it.

Well now, I heard from my colleague that he'd seen the same kind of result at some conference, but the speaker mentioned only just that it was due to a "singularity" (the nonsmoothness at the ends of the circular arc). He suggested me to try a smooth bump. I'm working on it.

Well, as someone mentioned, maybe we just need to smooth every corner on the boundaries in order to obtain healthy Euler solutions. If that's the case, I think I've learned a very important tip from this exercise.

But then again, should we look for a way to overcome it? Well, of course, we can round off every object in real life instead of its computational boundary. And it sounds more practical........
  Reply With Quote

Old   November 14, 2001, 13:03
Default Re: Separated Inviscid Flow - A Reference
  #28
Axel Rohde
Guest
 
Posts: n/a
Kalyan,

First, let me say that as an M.S. and Ph.D. student (about 7 years total) I studied almost exclusively compressible flow solvers for both the Euler and Navier Stokes equations: FVS, ROE, TVD, TVD/AC (artificial compression) or 'ULT', ENO, you name it! I am also familiar with compressible LES (using Favre or mass averaging) as I once wrote a code to study the transient character of a 3-D compressible jet. Being based on 'plain' central differences, I was not too impressed with the method, because it neglects the wave character of the NS equations (i.e. the eigensystem of the underlying Euler equations). Also, I don't really believe in filtering and 'averaging' because you only throw valuable information away in the process that took you time to compute in the first place. But let's not get into that. - For a quick review and comparison of some of these inviscid schemes (ROE, TVD, TVD/AC) and their implementation into a full NS solver, let me refer you to my dissertation, which also includes a number of references for further study. The PDF can be downloaded from my server,

www.microcfd.com/papers.htm

I think we have reached an impasse here on whether the inviscid flow over a triangular prism should separate or not, and if so for what reason. Obviously this is a very special case, and I think we should pick something more 'simple' to continue our discussion. You made an excellent suggestion with the cylinder, so let's talk about that instead. At a certain critical free-stream Mach number (around M = 0.5) the flow over a cylinder will be locally supersonic, followed by a shock wave. It has been my observation that the flow behind such a transonic shock also separates. So for the sake of simplicity, let's only discuss fully subsonic (i.e. shock free) flow, say at a Mach number of M = 0.4, which is well in the compressible range.

You stated earlier that for a subsonic, shock-free Euler flow over a 'smooth' surface there should be no increase in entropy within the flow (Ds/Dt = 0), correct? - Well, over the years I have run many inviscid solutions over (numerically smooth) cylinders. Although the flow was fully subsonic AND attached, the drag was never zero unless the Mach number approached zero. Even with an Euler solver that is virtually free of numerical viscosity (e.g. Harten's 2nd order TVD with numerical viscosity parameter epsilon = 0), the drag at M = 0.4 was clearly positive, no matter how much I refined my grid. - How would you explain that? And I pose the same question to Adrin. - I have an intuitive explanation for this, without any rigorous proof, but I want you to think about it first. (If I tell you my answer upfront, it may 'contaminate' your thinking..

I believe, if we can explain the phenomenon of inviscid drag at non-zero Mach numbers (which I have never seen addressed in any textbook), we have the answer to our earlier question, whether or not inviscid flow around a sharp corner should separate or not - at least from my point of view.

Axel

P.S. I only ran my Euler solvers with a no-slip condition in place in order to get an idea of the amount of numerical viscosity present in the code, NOT to obtain a 'sensible' solution to a particular flow problem.
  Reply With Quote

Old   November 14, 2001, 13:05
Default Re: Separated Inviscid Flow - A Reference
  #29
Axel Rohde
Guest
 
Posts: n/a
Adrin,

Please read my response to Kalyan, which answers some of the issues you brought up in your recent response. Also, I think it was time we shifted our focus from the special case of a sharp cornered triangular prism to a more 'general' smooth cylinder, as our discussion has reached an impasse (neither party is willing to back down...

Let me still go over a few of your remarks, before we (hopefully) shift our discussion to the phenomenon of inviscid drag at non-zero Mach numbers:

"The idea behind CFD, hopefully, is not just to get nice color moving pictures (and I'm just as guilty I guess ), but hopefully to learn more about the physics of the flow."

That is a very good point! Personally, I have learned more about fluid mechanics by looking at CFD solutions than through all the (theoretical) textbooks I have read over the years.

"But if the code cannot reproduce what we already know to be true theoretically, how can we ever trust anything else that the code spits out?"

I think there are lots of things we don't already know. So let's not dismiss a result just because it does not fit into our educated minds. Otherwise why would people run DNS computations to get a better understanding of turbulent flow. This is part of the beauty of CFD, that an inherently dumb machine can help us in the discoveries of unpredicted phenomena for which we don't have any theoretical explanations yet.

"If that is not what you are getting, it is entirely possible that the theoretical analysis is wrong and convergence really should be something like O(h^n + constant) instead of just O(h^n). This is very significant as it also helps out with the NS solutions. It may also imply that the algorithm is incorrect or at best poor. What I mean by this is that your discrete solution may/is NOT consistent with the differential equation."

Well, I am using a very popular algorithm, Van Leer's original flux vector split scheme (for your review, the equations are on my website). Over the last two decades FVS has been thoroughly studied by many researchers, and although the code includes a considerable amount of numerical viscosity (compared to a TVD solver), I don't think the method is poor or incorrect.

"Finally, one thing you can check is single vs. double precision. It is also possible that you have "saturated" your solution due to insufficient precision of the computations."

Other than my array indices, which are 32-bit integers, all floating point numbers are stored in 64-bit (double precision) format. The actual flow solver is written in assembly language, and intermediate results are kept on the math coprocessor which uses 80-bit registers (Pentium). Considering the amount of numerical viscosity inherent in the FVS code, I don't think that floating point precision is an issue here.

"As Kalyan mentioned, I like the "simple" cylinder benchmark case because it has no sharp edges and if you should get any physically correct separation, then let's see us your code capture the primary, secondary and tertiary vortical structures."

No, I don't get separated flow over a cylinder (fully subsonic) if the surface is smooth. MicroTunnel V1.0 - 1.2 used a staircase approximation of the surface (truly Cartesian), which did result in separation where you normally observe it (without the fine vortical structure, of course, which gets washed out by numerical viscosity). MicroTunnel V1.3 uses a cut-cell representation of the surface which makes the flow over the surface smooth, and thus there is no separation. Also, I ran the same code on a body fitted grid, and I do not get separation either, but I DO get drag!

Axel

P.S. You attended the 15th AIAA CFD conference this summer in Anaheim, CA, right? I am sorry I did not run into you there. Would have liked to make your acquaintance.
  Reply With Quote

Old   November 14, 2001, 13:59
Default Re: Separated Inviscid Flow - A Reference
  #30
kalyan
Guest
 
Posts: n/a
There are only two kinds of drag that I know of as inviscid drag components, the transonic drag (resulting from shock like phenomena which invariable result only in the presence of viscosity but can be captured using Euler equations) and induced drag associated with finite wings (which result once again from Kutta condition that is once again facilitated by viscosity even if inviscid equations are used). So, theoretically there is no such thing as inviscid drag.

If you get drag in inviscid flows, I think the energy conservation would be violated. If inviscid flow around a cylinder causes drag, then consider the case where the air/medium is stationary and the cylinder is moving. Since the drag is non-zero, a finite amount of work needs to be done to move the cylinder at finite speed. This is irreversible work and indicates the presence of a non-conservative force field (i.e., dissipation in the system) which would violate the inviscid energy conservation equation. If there is no viscosity in the system (real or numerical), where is the work going ?

I am not an expert on TVD schemes, but my impression was that TVD schemes are pretty dissipative. Is there such a thing as a TVD scheme that is free of numerical viscosity (TVNI maybe).
  Reply With Quote

Old   November 14, 2001, 14:12
Default Re: Separated Inviscid Flow - A Reference
  #31
kalyan
Guest
 
Posts: n/a
Axel,

CFD is indeed a great learning tool. But before we claim that it has predicted a phenomena yet undiscovered or paradoxical, isn't it incumbent on us to see whether the predictions are real or numerical. In order to judge the CFD predictions, ones needs good knowledge of fluid mechanics first. Once the CFD solutions are verified and validated, then I agree that they can be pretty educational.

DNS does provide a window into the physics of turbulence. However, some in the LES community have learnt the hard way not to base their model development on DNS results (an approach called apriori analysis). Models based on such analysis are no longer accepted in the current day unless they are validated by other independent means.
  Reply With Quote

Old   November 18, 2001, 00:18
Default Re: Boundary Layer created by Euler Solvers
  #32
Jim
Guest
 
Posts: n/a
Hi,

My colleague was right. I use a smooth bump (A*sin(pi*x)), then that funny wake disappeared. I have nice symmetric Mach contours now.

Jim
  Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to set boundary layer of a moving body in GAMBIT to a mesh zone for dynamic mesh tomyangbath FLUENT 17 March 25, 2016 05:36
Import problem ARC Open Source Meshers: Gmsh, Netgen, CGNS, ... 0 February 27, 2010 11:56
To thin boundary layer? Luk CFX 3 February 27, 2009 04:22
Trimmed cell and embedded refinement mesh conversion issues michele OpenFOAM Other Meshers: ICEM, Star, Ansys, Pointwise, GridPro, Ansa, ... 2 July 15, 2005 04:15
Boundary Layer Flow Paradox Wen Long Main CFD Forum 3 September 24, 2002 08:47


All times are GMT -4. The time now is 23:15.