Solver for transonic flow?
Does someone have recommendations for a solver to use for transonic steady state flow over an airfoil. Both Euler and RANS (using a turbulence model). I would also to be able to converge the results to machine zero.
I gather from literature, and my own work, that rhoSimplecFoam will not converge. I also did not have much luck with rhoCentralFoam for an Euler case. But, I haven't been able to confirm the rhoCentralFoam behavior with literature. So it could be my problem. Also, can someone point out documented OpenFOAM success stories for transonic steady state flow over an airfoil which uses one of the solvers provided with OpenFOAM? 
Hello Martin,
I hope you had a nice weekend. Did you try sonicFoam ? kind regards, Jan 
No, I did not try sonicFoam. The description mentions that it is a transient solver. Therefore, it is not clear that it can converge to a valid steady state answer. I guess it also might not have a local time stepping methodology implemented. The 2008 openFoam workshop presentation on AeroFoam, http://www.aero.polimi.it/freecase/?...esentation.pdf, shows poor results for rhoSonicFoam, rhopSonicFoam, and sonicFoam.
Another coupled solver was presented at 2010 workshop http://web.student.chalmers.se/group...SlidesOFW5.pdf. For this presentation a converged NACA 0012 was not obtained for the segregated solver (SIMPLE?). RhoCentralFoam was not mentioned. So it seems that, maybe, the standard suite of OpenFOAM solvers do not adequately handle transonic flow. Otherwise, why would this effort exist? Also, when digging around, I can not find explicit well documented solutions for transonic steady state flow using one of the standard solvers. Unfortunately, I can't seem to find documentation that explicitly says that none of the solvers should be used. Unfortunately, the best practices for OpenFOAM is so poorly documented, in my opinion, that I jump at shadows and have a high level of skepticism. Which is too bad since this makes it difficult to justify putting effort into using and improving the code. For example, there is no information for the compressible solvers at the openfoam wiki page http://openfoamwiki.net/index.php/Main_ContribSolvers 
Hello Martin,
a very talented student of our university tried all of the solvers on our HPC Cluster and gave a (much too short) description/ overview of each solver, that`s why I though, I could help you giving you a hint. I know some Professors in our university, who are also very interested on using and improving the code, so the only thing I can offer is asking for some research work (as Bachelor or Masterthesises) if there`s no further response on this thread. This could of course give us some answers and would help us using and improving the code, but it will take some time to find a talented student to do this work. with kind regards, Jan 
Hi,
there is no steady state solver for transonic compressible flows in OpenFoam. The only compressible steady state solver converges poorly at high velocity. So, if you need a steady state solver, you have to write your own solver. Such a solver must be coupled (velocity, density + pressure eqn.) to get good results. Another possibility as stated above might be to use a transient (rhoPisofoam, sonicFoam) or pseudo transient solvers (rhoPimpleFoam). Kind Regards, Christian 
Quote:
Thanks. Can the transient or pseudo transient solver be run out to steady state? I assume, if they are, the answers are invalid. Of course that brings up the next question. When do the transient solvers go from being valid to invalid? Maybe that question is best left to another thread. 
Quote:
Unfortunately I don't consider myself a knowledgeable OpenFoam user. So my input decks may be incorrect and misleading. But, maybe something is better than nothing... 
Quote:
I don't know if I misunderstood the question, but of course can transient solvers be used for steady state calculations. This might not be an optimal choice (steady state solvers usually are more cost effective), but sometimes stability issues require such choices. Actually time marching techniques aren't uncommon in compressible flows and there are many ways to accelerate the simulations. Local time stepping or implicit time schemes with large courant number limits, to name a few. I can't think of a case where a (to a steady state) converged solution using a transient solver is invalid  it usually is the other way around, i.e. there may be invalid steady state solutions for actually transient cases (think of periodic vortex shedding). My experience with compressible flows in OF is quite limited, but you might want to give rhoPimpleFoam a try  as far as I know it allows fairly large time steps. Greetings Felix 
That's why I'm confused too. If a transient solver works correctly it should be able to get to a steady state solution. Granted not efficiently. But, once the residuals are in the vicinity of machine zero, the steady state solution is independent of how, i.e. constant or local time stepping, one gets to the solution (well, not always true since the problem is nonlinear, but different story)
As far as I know, and my knowledge is limited, an uncoupled solver can not converge on a steady state transonic solution. Unfortunately, I can not back that up with math and not sure if that holds true for all the different flavors of uncoupled solvers. However, the standard solvers page for OpenFoam, http://www.openfoam.com/features/standardsolvers.php, explicitly says for sonicFoam "Transient solver for transsonic/supersonic, laminar or turbulent flow of a compressible gas" Yet I believe sonicFoam is uncoupled, as are all the standard solvers. Yet, if sonicFoam works, which is counter to AeroFoam work http://www.aero.polimi.it/freecase/?...esentation.pdf then it should be able to achieve a correct steady state solution. And if it does not work, then the transient solution must eventually become bad. Of course the AeroFoam work could have used incorrect settings. If sonicFoam can achieve a valid steady state solution, then, in principle, it should be adaptable to local time stepping. After all the major different between the step size of constant and local time stepping is due to the grid. A constant cell size grid used with a local time stepping method is close to a constant time stepping approach. Granted, one doesn't want to do that, but theoretically... Therefore, I am confused about solving any type of transonic flow with an OpenFoam standard solver. 
rhoPimpleFoam Deck labyrinth seal with rotating shaft
Hello Everyone,
I would also give rhoPimpleFoam a try. In a Masterthesis, a student calculated a labyrinth seal with a rotating shaft and different flow velocities with rhoSimpleFoam and detected digergence for the pressure equation for higher velocities. But talking about posting/ exchanging decks (and with the decks experience), I think it's a good idea to post decks here. I would also post interesting thesises or research results I've got from the university, but unfortunately most of it is in german :( greetz and have anice day, Jan 
Hi
Quote:
Quote:
About areoFoam. I'm not really familiar with this solver, but I think it is a density based compressible solver. If this is true, this is the main difference between areoFoam and e.g. sonicFoam. The question is, is your velocity high enough for a density based solver? About rhoPimpleFoam. Yes, rhoPimpleFoam can run at higher Courant numbers (not always). If you use rhoPimpleFoam, have a good look at the continuity. Kind regards, Christian 
Hi Martin,
If you are familiar with the OpenFOAMExtend project, there are a few new densitybased solvers that are being developed there. I am not a developer but I would suggest you take a look at them. http://openfoamextend.git.sourcefor...urbo;a=summary There is a solver there called transonicSteadySRFFoam which you may be interested in. I assume that it should work fine for an airfoil as long as you set rotation in the SRFdictionary to zero. Best Regards, Nathan 
Quote:
Two main questions are presented below in the discussion section: 1) As the under relaxation factor for the steady state solvers (or whatever controls the convergence rate) is dropped, does the convergence history of the flow values from the steady state solvers begin to match the convergence history of the flow values from the transient solvers? In other words, does the steady state solver turn into a transient solver? It sounds like the answer here is no. 2) If the answer above is yes, are the steady state answers for the transient and steady state solvers different? Discussion I think the understanding of the terms between us is different, and my usage may not be inline with OpenFOAM. For me, in this case, the residual is a metric (such as L2 norm) of the right hand side (RHS defined as a function of the fluxes and viscous forces etc. ) before it is multiplied by the time step. Once the RHS is zero, dU/dt is zero (in this case U is the state vector and not velocity) and steady state has been reached. Your statement seems to refer to the solution vector. As an extreme, if the dt is zero then the solution vector is zero and a steady state solution will never be reached. I agree with that. If a value is small, it does not mean that it is close to machine zero. For example, your residual may be 1.0e9 because it was scaled by a small time step, but the machine zero for that value may be 1.0e20. I think my point still holds, regardless of the size of the time step (except if it is zero) a transient solver should be able to eventually reach steady state, if a steady state solution exists. Once steady state is reached, how one successfully gets there is immaterial (dt=1.0e9, or dt=1.0e8, CFL=0.5, or CFL=1.0e4). The solutions are the same. Assuming that multiple steady state solutions do not exist. So maybe my next question is my main big question! As the under relaxation factor for the steady state solvers (or whatever controls the convergence rate) is dropped, does the convergence history of the flow values from the steady state solvers begin to match the convergence history of the flow values from the transient solvers? I.e. the steady state solver turns into a transient solver? It sounds like the answer here is no. If the answer is yes, then I am really confused! Or are the steady state answers for the transient and steady state solvers different? In regards monitoring convergence, from a debugging and quality assurance point of view, monitoring specific flow values for convergence can be misleading. For example, if a boundary condition is bad, or the grid is bad, or the methodology is bad, or coding is done incorrectly, the residuals can asymptote to a value far from machine zero and the solution (depending on methodology, i.e. implicit vs. explicit, etc.) can reach a point where the solution does not change. Also, when looking at flow values, it is sometimes easy to say steady state has been reached, when, in fact, the metrics being monitored are a temporary plateau. I've seen enough strange things regarding non linear solution convergence of complex real world geometries to insist, for those types of flow physics and geometries, that a few solutions are driven to machine zero. This is why I don't like to depend only on flow value convergence. For example, I am not sure if the different solutions for the 2D oblique shock reflection in http://www.aero.polimi.it/freecase/?...esentation.pdf, are due to the results not being converged to machine zero or that the right hand side, so to speak, are different. Please do not use a term like "Incorrect". It is a turn off. Even without using that term, I would have understood your message. And, in the end, I'm not sure what I am "incorrect" about, other than maybe I did not express myself well enough, or that I do not fully understand what is being dumped into OpenFOAMs log file for each different solver, or that I don't understand the behavior of the steady state solvers as the convergence rate is slowed down. 
OK, I'm going to change my position on the machine zero topic. If the L2 norm of the solution vector is at 1.0e9 because it has been multiplied by a small dt, then yes, the solution vector is close to machine zero since it will be added to the state vector. However, I don't think the solution has converged since the RHS (before multiplying by dt) is not small. So maybe the solution algorithm is not appropriate. One would need an algorithm (implicit?) which would allow for a larger time step.

3 Attachment(s)
OK, I took nacaAirfoil test case under the compressible/sonicFoam test directory and created a new test case. What I did was to change the Mach number to 1.1, set the case to laminar, set the inlet b.c. to the freestream velocity (i.e. fixed), set the airfoil boundary condition to the freestream velocity (i.e. flow through), set the inlet pressure to the freestream pressure (i.e. fixed to 100000), then initialized the internal field to an initial pressure of 101000. Ran the code for a long wall clock time (final time=0.06) and got the answer shown below.
OK, if the world was perfect, the answer should converge so that all the internal points have freestream values. Assuming I understand the boundary conditions correctly. Hey, I've messed that up before. Also the cd, cl, and cm should converge to zero. And, just to add to my comfort zone, I did run a case where the pressure field was initialized to 100000. For that case the pressure remained at 100000 up to my final time of 0.02 and the aero coefficients stayed at zero. So, having all the internal points at freestream is a steady steady state solution for sonicFoam. OK, back to the case initialized to p=101000. It did not converge to freestream values. I don't know if this is because it found a valid solution or if the algorithm itself is making the case run in circles. The residuals don't seem to have converged to machine zero, but I'm not sure what to expect for a machine zero value either. Or it could be the boundary condition interacting with the solution methodology, which, IMO, it seems to be. My personal code, which uses a implicit time marching approach, does converge to freestream. Of course this case took a lot of resources. So I'm going to wait pursuing this further until I get a better idea of how SGI acquiring OpenCFD changes the landscape. Why work on something that, in the end, SGI might not want to support. Anyway, here is my last entry in my log.sonicFoam file. Time = 0.06 Courant Number mean: 0.000109323 max: 0.661641 diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0 DILUPBiCG: Solving for Ux, Initial residual = 1.33111e06, Final residual = 3.80694e12, No Iterations 1 DILUPBiCG: Solving for Uy, Initial residual = 1.11498e06, Final residual = 7.32638e13, No Iterations 1 DILUPBiCG: Solving for e, Initial residual = 1.24729e05, Final residual = 1.42741e11, No Iterations 1 DILUPBiCG: Solving for p, Initial residual = 1.39299e05, Final residual = 1.49248e14, No Iterations 2 DILUPBiCG: Solving for p, Initial residual = 4.3643e08, Final residual = 1.13504e13, No Iterations 1 DILUPBiCG: Solving for p, Initial residual = 1.20992e09, Final residual = 3.09695e14, No Iterations 1 diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0 time step continuity errors : sum local = 1.41226e15, global = 2.77899e18, cumulative = 9.46552e13 DILUPBiCG: Solving for p, Initial residual = 3.46734e09, Final residual = 5.0522e14, No Iterations 1 DILUPBiCG: Solving for p, Initial residual = 1.09507e10, Final residual = 5.96846e14, No Iterations 1 DILUPBiCG: Solving for p, Initial residual = 7.85442e12, Final residual = 3.67244e15, No Iterations 1 diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0 time step continuity errors : sum local = 3.04948e16, global = 1.25528e17, cumulative = 9.46539e13 ExecutionTime = 184720 s ClockTime = 184812 s forceCoeffs output: Cd = 0.000763497 Cl = 0.00105474 Cm = 0.000517097 End I've also attached snapshots of the pressure fields and one of the velocity magnitude. The freestream velocity magnitude is 388.17. So, from the velocity magnitude plot you can see that the inflow is about 388.17 (orange). For some reason, even though the outer boundary is fixedvalue, a disturbance occurs at the top and bottom shoulder on the outer boundary. This disturbance, or maybe something different, causes a transition to occur upstream of the airfoil. The velocity magnitude transitions from orange to yellow. However, the flow is supersonic, so I have no idea why this transition occurs ahead of the airfoil or corner disturbance. Somehow, information is propagating forward. The orange wake behind the airfoil is due to the surface velocity of the airfoil being set to freestream value. 
Two hints:
1. I would recheck rhoCentralFoam, since it's probably the best currently available in OF for compressible flows. If you can't reproduce literature results, it is most likely a problem in your setup. Try following the test cases. 2. It would be useful not to make comments on the SGI acquisition in a completely unrelated thread. Best, 
Quote:
BTW, this case was for Mach 1.1. So will rhoCentralFoam work? Also, in the end, I'm interested in a solver with a turbulence model, which I believe rhoCentralFoam does not have. But, at your personal request, I'll give it a run, just to see what happens. I assume you have first hand experience with the solver, otherwise you would not have recommended it. However, when I look at the solution posted above, it seems like it could be a b.c. issue also. Quote:
Quote:
Quote:

Quote:
Quote:
I have indirect experience: some colleague in aerospace tried it on airfoils and obtained good results. Quote:
Quote:
Best, 
Quote:

Quote:

All times are GMT 4. The time now is 13:19. 