[firev1]

So I'm relatively new to OpenFoam and been trawling the site for answers. I'm using the NASA grids for NACA0012 (10 degs AOA) and while 0 degree angle of attack works, I have been unable to get the problem working with anything other than the 113x33 grids.

Unless I use some sort of pressure relaxation, I'm unable to do even the 113x33 grid problem which doesn't make sense since I'm using SIMPLEC.

I have also done the Zero Gradient Flat plate and have used totalPressure,totalTemperature and pressuredirectedvelocity well there and wonder if there is any way to do something similar for this case. Right now for the airfoil, I'm using freestream and freestreamPressure for all conditions since it allows me to vector U for 10 degrees AOA.

Specifying pressuredirectedinletvelocity's inlet direction doesn't seem to provide the freestream angle vectoring effect for 10 degrees.

Error I'm getting,

Maximum number of iterations exceeded

    From function Foam::scalar Foam::species::thermo<Thermo, Type>::T(Foam::scalar, Foam::scalar, Foam::scalar, Foam::scalar (Foam::species::thermo<Thermo, Type>::*)(Foam::scalar, Foam::scalar) const, Foam::scalar (Foam::species::thermo<Thermo, Type>::*)(Foam::scalar, Foam::scalar) const, Foam::scalar (Foam::species::thermo<Thermo, Type>::*)(Foam::scalar) const) const [with Thermo = Foam::hConstThermo<Foam::perfectGas<Foam::specie> >; Type = Foam::sensibleInternalEnergy; Foam::scalar = double; Foam::species::thermo<Thermo, Type> = Foam::species::thermo<Foam::hConstThermo<Foam::perfectGas<Foam::specie> >, Foam::sensibleInternalEnergy>]
    in file /opt/OpenFOAM/OpenFOAM-3.0.x/src/thermophysicalModels/specie/lnInclude/thermoI.H at line 66.

Case attached here
https://drive.google.com/open?id=0B4...EEyOU9lSkgwV0k

[PeterShi]

Hello Joshua,

Actually, I came across the same problem of you. After searching the relevant threads in this forum, I realized that this error resulted from many many factors.

The reason it occurs is that the solver iterates to get T from the correlation of h (enthalpy) and T. However, it fails to obtain the temperature even the maximum iteration is exceeded. As a result, the error information pops up.

Please see following threads to solve your problems:
1. FOAM FATAL ERROR Maximum number of iterations exceeded
2. Maximum number of iterations exceeded

I have to mention that the discussions above do not necessarily eliminate your problem. For me, the poor quality of grid is to be blamed. And NACA0012 is running well in my computer (the mesh was generated by myself).

Hope this will help.

Best regards,
Peter

[firev1]

Hello Peter, thanks for your reply. I'm about to try using my own generated meshes but its strange that the mesh quality would be poor(since it looks really good) with the exception of the extremely high aspect ratio.

May I just ask how are you defining your boundaries for the problem? Is using velocity conditions on the farfield okay with rhosimplefoam? Thanks for listening!

[PeterShi]

Originally Posted by firev1

Hello Peter, thanks for your reply. I'm about to try using my own generated meshes but its strange that the mesh quality would be poor(since it looks really good) with the exception of the extremely high aspect ratio.

May I just ask how are you defining your boundaries for the problem? Is using velocity conditions on the farfield okay with rhosimplefoam? Thanks for listening!

Hi Joshua,

The attachment is my setting for rhoSimpleFoam. At least, it runs well using my own grid. As a remainder, I did not employ any of wall functions, since my y+ is around 5. Certainly, you can use wall function when your y+ is larger than 30.

High-aspect ratio cell is not a good news, I suggest you re-generate your mesh until everything is fine.

Actually, I am struggling with rhoSimpleFoam either, however at least my program can run for simple case of NACA0012, while I am calculating high-lift devices.

Best,
Peter

[firev1]

A quick update. I successfully got the case running with your files and it turns out its the numerics schemes in fvschemes that are the culprit in my case. Implemented cellLimited schemes to get it to be pretty stable. Hope that helps someone!

[PeterShi]

Originally Posted by firev1

A quick update. I successfully got the case running with your files and it turns out its the numerics schemes in fvschemes that are the culprit in my case. Implemented cellLimited schemes to get it to be pretty stable. Hope that helps someone!

Glad to hear that. However, CellLimited scheme will reduce the accuracy while do increase the stability, at least according to my experience. Have you compare your result with the experimental data?

Best,
Peter

[firev1]

Originally Posted by PeterShi

Glad to hear that. However, CellLimited scheme will reduce the accuracy while do increase the stability, at least according to my experience. Have you compare your result with the experimental data?

Best,
Peter

Indeed it does but it appears to have limited effect with my case since mesh error seems to be the more dominant source of error.

On 2 levels of refinement of the same mesh I posted earlier, my drag error is about a 2.5% currently and is on track compared to my solution on simpleFoam(which is using no limiters). Just to add, I'm using FaceLimited as well for finer meshes but I get non-physical results on the converged solution, the fix is to switch to CellLimited after for a valid solution.

[khanhrovip]

Originally Posted by firev1

Indeed it does but it appears to have limited effect with my case since mesh error seems to be the more dominant source of error.

On 2 levels of refinement of the same mesh I posted earlier, my drag error is about a 2.5% currently and is on track compared to my solution on simpleFoam(which is using no limiters). Just to add, I'm using FaceLimited as well for finer meshes but I get non-physical results on the converged solution, the fix is to switch to CellLimited after for a valid solution.

Hi Joshua, can you share your case? Thank you!