[Martin Hegedus]

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?

[jango]

Hello Martin,

I hope you had a nice weekend. Did you try sonicFoam ?

kind regards,

Jan

[Martin Hegedus]

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

[jango]

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

[Chris Lucas]

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

[Martin Hegedus]

Originally Posted by Chris Lucas

Another possibility as stated above might be to use a transient (rhoPisofoam, sonicFoam) or pseudo transient solvers (rhoPimpleFoam).

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.

[Martin Hegedus]

Originally Posted by jango

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

If individuals, including me, could pin down cases that either worked or didn't work for a solver and post them (along with as many input decks as possible) on this forum, that would be great. I know it is already done to a degree by asking questions. But frequently these posts do not have closure, i.e. was the question successfully answered. The posts with closure, both new and existing, could be used as references in the OpenFoam wiki.

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

[FelixL]

Originally Posted by Martin Hegedus

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.

Hi Martin,


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

[Martin Hegedus]

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/standard-solvers.php, explicitly says for sonicFoam "Transient solver for trans-sonic/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.

[jango]

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

[Chris Lucas]

Hi

Originally Posted by Martin Hegedus

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)

Incorrect, if your time step is very small, the change in the flow field is small, so the residials are small. I run simulations with residuals around 1e-9 and the flow is far from steady state. You should monitor the inlets and outlets and possibly some sample point within the grid.

Originally Posted by Martin Hegedus

Yet I believe sonicFoam is uncoupled,

Correct, there is no coupled solver (for your application) in OpenFoam yet. But for a transient solver, this isn't a problem (at least no stability problem as for a steady state solver)

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

[nathan]

Hi Martin,

If you are familiar with the OpenFOAM-Extend project, there are a few new density-based solvers that are being developed there. I am not a developer but I would suggest you take a look at them.

http://openfoam-extend.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 SRF-dictionary to zero.

Best Regards,
Nathan

[Martin Hegedus]

Originally Posted by Chris Lucas

Hi



Incorrect, if your time step is very small, the change in the flow field is small, so the residials are small. I run simulations with residuals around 1e-9 and the flow is far from steady state. You should monitor the inlets and outlets and possibly some sample point within the grid.

Overview:

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.0e-9 because it was scaled by a small time step, but the machine zero for that value may be 1.0e-20.

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.0e-9, or dt=1.0e-8, CFL=0.5, or CFL=1.0e-4). 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.

[Martin Hegedus]

OK, I'm going to change my position on the machine zero topic. If the L2 norm of the solution vector is at 1.0e-9 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.

[Martin Hegedus]

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.33111e-06, Final residual = 3.80694e-12, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 1.11498e-06, Final residual = 7.32638e-13, No Iterations 1
DILUPBiCG: Solving for e, Initial residual = 1.24729e-05, Final residual = 1.42741e-11, No Iterations 1
DILUPBiCG: Solving for p, Initial residual = 1.39299e-05, Final residual = 1.49248e-14, No Iterations 2
DILUPBiCG: Solving for p, Initial residual = 4.3643e-08, Final residual = 1.13504e-13, No Iterations 1
DILUPBiCG: Solving for p, Initial residual = 1.20992e-09, Final residual = 3.09695e-14, No Iterations 1
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 1.41226e-15, global = 2.77899e-18, cumulative = 9.46552e-13
DILUPBiCG: Solving for p, Initial residual = 3.46734e-09, Final residual = 5.0522e-14, No Iterations 1
DILUPBiCG: Solving for p, Initial residual = 1.09507e-10, Final residual = 5.96846e-14, No Iterations 1
DILUPBiCG: Solving for p, Initial residual = 7.85442e-12, Final residual = 3.67244e-15, No Iterations 1
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 3.04948e-16, global = -1.25528e-17, cumulative = 9.46539e-13
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.

[alberto]

Two hints:

1. I would re-check 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,

[Martin Hegedus]

Originally Posted by alberto

Two hints:

1. I would re-check rhoCentralFoam, since it's probably the best currently available in OF for compressible flows.

Sure, I'll give it a shot. But earlier you mentioned that "There is rhoCentralFoam, which is suitable for viscid/inviscid flows with high Mach number, but it is unsteady. Similarly, sonicFoam is fine for transonic/supersonic turbulent unsteady flows." http://www.cfd-online.com/Forums/ope...tml#post288596

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.

If you can't reproduce literature results, it is most likely a problem in your setup.

Are there any literature results for something like I'm trying to do? That is, make the boundaries flow through and initialize the interior field to something other than freestream and see if the solver can get to freestream. It does not seem like the type of thing people put out in liturature. I haven't found any. If one exists, please give me a reference.

Try following the test cases.

I have tried following them for other solvers, but they can be misleading. For example, some of the test cases under the incompressible directory use the "freestream" B.C. Unfortunately, for whatever reason, if the freestream velocity vector is parallel to the cell outer face, the b.c. does not converge. It will converge if there is a slight angle. For me, when I run my steady state test cases, I like to see that the residuals converge to machine zero.

2. It would be useful not to make comments on the SGI acquisition in a completely unrelated thread.

Running the transient solver to steady took quite a bit of CPU time. Or I should say memory bus resources. The comment reflected my feelings towards dedicating such resources to this specific problem under these set of circumstances.

[alberto]

Originally Posted by Martin Hegedus

Sure, I'll give it a shot. But earlier you mentioned that "There is rhoCentralFoam, which is suitable for viscid/inviscid flows with high Mach number, but it is unsteady. Similarly, sonicFoam is fine for transonic/supersonic turbulent unsteady flows." http://www.cfd-online.com/Forums/ope...tml#post288596

BTW, this case was for Mach 1.1. So will rhoCentralFoam work?

Yes, it should.

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.

Turbulence was added to rhoCentralFoam in OF 2.0.x.
I have indirect experience: some colleague in aerospace tried it on airfoils and obtained good results.

Are there any literature results for something like I'm trying to do? That is, make the boundaries flow through and initialize the interior field to something other than freestream and see if the solver can get to freestream. It does not seem like the type of thing people put out in liturature. I haven't found any. If one exists, please give me a reference.

I have tried following them for other solvers, but they can be misleading. For example, some of the test cases under the incompressible directory use the "freestream" B.C. Unfortunately, for whatever reason, if the freestream velocity vector is parallel to the cell outer face, the b.c. does not converge. It will converge if there is a slight angle. For me, when I run my steady state test cases, I like to see that the residuals converge to machine zero.

You might try to reproduce the test cases in Kurganov and Tadmor papers just to become familiar with the solver. Aerospace applications do not belong to my area, so I cannot be of much help with the literature.

Running the transient solver to steady took quite a bit of CPU time. Or I should say memory bus resources. The comment reflected my feelings towards dedicating such resources to this specific problem under these set of circumstances.

Yes, I understand. But as we discussed elsewhere, I doubt things are going to change in a negative direction.

Best,

[Martin Hegedus]

Originally Posted by alberto

Yes, I understand. But as we discussed elsewhere, I doubt things are going to change in a negative direction.

Lets hope you are right.

[JBeilke]

Originally Posted by Martin Hegedus

Lets hope you are right.

Come on Martin, complaining is not in your job description, it is up to us germans. And if we don't find anything to complain, everything should be fine .