[Jinn]

Hi,

I was trying to implement the Spalart-Allmaras turbulence model into my FVM rotor solver, which can work well with the Baldwin-Lomax model.

The version of the S-A model I used is the "Standard" model on https://turbmodels.larc.nasa.gov/spalart.html#sa. I used the LUSGS scheme for time marching, and convective and viscous fluxes in the S-A model are 1st upwind and 2nd central scheme, respectively. The freestream nut is set to 3*nu as recommended. The case I am running is a hovering state of a 2-bladed rotor.

Now the computation suddenly diverges after 5 revolutions, when the force coefficients seem to have achieved a periodic solution. It is weird to me. Lowering the CFL number helps to delay the divergence but it still crashes finally.

Has anyone encountered similar problems? What are the possible causes of such a sudden divergence? Any ideas are welcomed!

Thanks in advance!!!

[sbaffini]

Originally Posted by Jinn

Hi,

I was trying to implement the Spalart-Allmaras turbulence model into my FVM rotor solver, which can work well with the Baldwin-Lomax model.

The version of the S-A model I used is the "Standard" model on https://turbmodels.larc.nasa.gov/spalart.html#sa. I used the LUSGS scheme for time marching, and convective and viscous fluxes in the S-A model are 1st upwind and 2nd central scheme, respectively. The freestream nut is set to 3*nu as recommended. The case I am running is a hovering state of a 2-bladed rotor.

Now the computation suddenly diverges after 5 revolutions, when the force coefficients seem to have achieved a periodic solution. It is weird to me. Lowering the CFL number helps to delay the divergence but it still crashes finally.

Has anyone encountered similar problems? What are the possible causes of such a sudden divergence? Any ideas are welcomed!

Thanks in advance!!!

You should really first test your model implementation with some canonical test case as, indeed, available on the NASA LaRC site.

[Jinn]

Thanks, prior to the rotor case I have already tested my implementation with some 2D airfoils and 3D wing test cases provided in the NASA validation archive. In these cases my computation results show good agreement with experiments and converge well. When it is applied to this rotor case, the sudden divergence occurs

[sbaffini]

Originally Posted by Jinn

Thanks, prior to the rotor case I have already tested my implementation with some 2D airfoils and 3D wing test cases provided in the NASA validation archive. In these cases my computation results show good agreement with experiments and converge well.

It still seems quite a jump, for me, from a steady 2D case to an unsteady moving mesh 3D case.

Do you have any other equation based turbulence model? Is the model implementation based, say, on previously used components or is it just a whole new implementation?

If you were developing this for a commercial product you should have tens of cases in between so, no, two or three cases is not typically enough to be confident on a model implementation.

One thing that usually requires attention in the SA implementation is the non linear diffusive term, which requires rearrangement to be better implemented in a conservative FV code, but I have doubts it actually is your problem.

My suggestion is to carefully assess what are the elements of your failing case and test the code with intermediate mixes of ingredients.

In the end, SA is among the most stable models around and should not fail if other options don't as well.

[Jinn]

Originally Posted by sbaffini

It still seems quite a jump, for me, from a steady 2D case to an unsteady moving mesh 3D case.

Do you have any other equation based turbulence model? Is the model implementation based, say, on previously used components or is it just a whole new implementation?

If you were developing this for a commercial product you should have tens of cases in between so, no, two or three cases is not typically enough to be confident on a model implementation.

One thing that usually requires attention in the SA implementation is the non linear diffusive term, which requires rearrangement to be better implemented in a conservative FV code, but I have doubts it actually is your problem.

My suggestion is to carefully assess what are the elements of your failing case and test the code with intermediate mixes of ingredients.

In the end, SA is among the most stable models around and should not fail if other options don't as well.

Thanks again for your kind and instructive advice! I agree that this is a huge jump because moving mesh is added in the rotor case.

Actually I am trying a whole new implementation without any other equation-based model, for academic use. And I did rearrange the diffusive term as advised.

I truly need to test the intermediate elements of my code first, before entering the mixed case.

[sbaffini]

Yes, I think so. I mean, you either are very lucky and just spot the error while wandering trough the code, or there is no magic, you do the test in little steps

[FMDenaro]

Just to test your moving mesh, does it works without any turbulence model?

[Jinn]

Originally Posted by FMDenaro

Just to test your moving mesh, does it works without any turbulence model?

Yes, the rotor code works for both inviscid computation and B-L model.

I output the rotor flow fields of several time steps before it diverges, as attached.

The density and pressure contour exhibit some singularities in the wake region(cut boundary), which is the region of large turbulent viscosities. And this is the region where divergence occurs first.

[sbaffini]

Originally Posted by Jinn

Yes, the rotor code works for both inviscid computation and B-L model.

I output the rotor flow fields of several time steps before it diverges, as attached.

The density and pressure contour exhibit some singularities in the wake region(cut boundary), which is the region of large turbulent viscosities. And this is the region where divergence occurs first.

So, you have a mesh cut there which needs a bc? Just saying, have you checked that bc for the SA model?

Also, does the same code and case work when mesh rotation is set to 0?

[Jinn]

Originally Posted by sbaffini

So, you have a mesh cut there which needs a bc? Just saying, have you checked that bc for the SA model?

Also, does the same code and case work when mesh rotation is set to 0?

Yes there's a cut bc, and I am currently examining it. For the SA model the cut bc value is given that of the opposite cell, which works for previous test cases.

And thanks for that hint, I will examine my code setting the rotation to 0, to check if the moving mesh part works well.