[jnanabrao]

Dear all,


I am trying to run a supersonic jet case with rhoCentralFoam where I need to resolve the turbulence in the jet. But the only way to get any sort of stable solution with rhoCentralFoam requires use of either the vanLeer, gamma or vanAlbada limiters for the reconstruct(U/rho/T) option. However, this leads to loss of all turbulent structures present in the flow(which I am initializing with a rhoPimpleFoam solution). Has anyone manged to resolve turbulent structures with rhoCentralFoam? Is there a way to run the linear option for the reconstruct option in fvSchemes? Is there a reason why the solver cannot work without limiters for the reconstruction process (as it appears to be just wave velocity weighted property calculation at face centre)?



P.S: rhoPimpleFoam/sonicFoam does not provide the accurate value of mean flow features.

[shock77]

Its because high order schemes produce heavy oscialltions when resolving shocks. Every solver needs them to go back to first order schemes when facing sharp gradients (e.g. shocks). Ofc there are schemes which are more diffusive than others.


What kind of turbulence do you want to resolve in the jet? Do you mean the shear layer? The inner of the jet is called "zone of silence" for a reason.

[jnanabrao]

What kind of turbulence do you want to resolve in the jet? Do you mean  the shear layer? The inner of the jet is called "zone of silence" for a  reason.

Yes. I need to resolve the shear layers but downstream of the potential core, I need to capture the structures in the fully turbulent jet as well for a few diameter lengths. The final goal is to calculate noise from underexpanded jets. But I know that that may not be possible with second order schemes. Nonetheless, I still need to study the effect of the inlet conditions on the turbulence of the exit jet conditions.

[jnanabrao]

I thought a couple of images would be helpful. With rhoPimpleFoam/(sonicFoam in OF6 and earlier), I could get turbulence as shown but the centreline data indicates a shorter potential core length. With rhoCentralFoam i get a reasonably accurate potential core length but there is no turbulence in the initial few diameter lengths of the jet.


The first two images are solution states of sonicFoam and rhoCentralFoam respectively. The next two are centreline comparison of the two solvers in same order. I have some noise calculations as well which I can't share but the turbulent jet noise seems to have the correct Sound Pressure Levels (SPL) while the rhoCentralFoam result has extremely high (higher than experimental by 5-10 dB ) SPL.

[shock77]

I would not rely on pressure based solvers for supersonic calculations. RhoCentralFoam is the better solver for that. On the other hand rhoCentralFoam is rather diffusive, since there is a constant diffusity term added, I guess for stability.


What kind of turbulence model do you use btw?


Also there are other solvers based on rhoCentralFoam like rhoEnergyFoam, which should be less diffusive rhoEnergyFoam-Compressible Low-Dissipative solver. I didnt try it though.

[jnanabrao]

What kind of turbulence model do you use btw?

I've run the rhoCentralFoam case with dynamic k equation but in the sonicFoam case, there is no model. It literally runs on the original NV equations with the 'laminar' setting. I've seen some works where this was preferred. In any case so far I've not seen any significant effect of the sub-grid scale model.

 I would not rely on pressure based solvers for supersonic calculations.

I've read this in a few places but don't understand why clearly. In any case, the newer versions of OF have removed sonicFoam. Having said that, in my case the turbulence is key as without it the flow structures are too large and in phase in terms of noise generation which leads to high values. In the fully turbulent flow cancelations of out of phase sources reduce the overall sound. I will take a look at rhoEnergyFoam. Thanks for the help.

[shock77]

This is interesting, maybe your LES-Model is too diffusive. I have good experience with the kOmegaSSTDES, it works properly in term of letting turbulent structures evolve when the grid is fine enaugh. To test that, you can set rhoCentralFoam to laminar aswell and check wether you see resolved turbulence.


On the pressure based solver:


For compressible flow the pressure is directly calculated by the used gas law (i.e. perfect gas) using the density calculated from mass conservation and the temperature from energy conservation. Since the gas is compressible, pressure is a function of density AND temperature. This makes perfect sense.


For incompressible flow however, pressure is calcuated by using those pressure correction loops like simple, pimple, piso. Here the influence of temperature is secondary. Actually I dont know how those loops work for compressible solvers. Actually I have never used those, because the state of the art for supersonic or compressible solvers are density based solvers. As far as I know the pressuer based solver have the advantage to be more effective in terms of computation time and stability for incompressible flow. They are definitly perfectly fine to use for incompressible flow!

[jnanabrao]

I don't see any change by running rhoCentralFoam with the 'laminar' setting. My grid was quite fine around d/120 spacing with nearly isotropic cells. The pressure based solvers seems to show turbulence on very coarse grids but only when all schemes are linear, bar the div(phid,p) term for which I used MUSCL. The simulation crashes without it. I also need to use 5-7 outer correctors along with 2 correctors in the PIMPLE loop.



Based on the strong dependence on the scheme, I am not surprised that rhoCentralFoam which is designed to run with a limiter does not show the same kind of structures. The problem seems to be well known to the authors of rhoEnergyFoam. But the AUSM scheme they have used is not part of any native openfoam distribution so I want to understand it better before using it.



I was thinking a bit more about the pressure based solvers for compressible flows. I could only come up with one reason why it may be badly suited for supersonic cases. It is to do with the fact that pressure waves become highly directional in a supersonic flow as they can't propagate upstream. The way sonicFoam seems to calculate the transport does not seem to take this into account in any way. In rhoCentralFoam, the transport seems to be governed entirey by wave velocity. The coefficient/contribution seems to change significantly in interpolating face centre values when considering if the cell in question is upstream or downstream (from my understading of the code). Nonetheless, sonicFoam does seem capable of showing shocklines in the flow and its equations look like the simplest possible compressible flow implementation. The implementation in rhoPimpleFoam is also similar as it also appears to solve the equations in the same pressure-velocity coupling manner as sonicFoam.

[shock77]

That is really weird, I never had any troubles with that. Can you share your fcSchemes, fvSolution and controldict?


Yes, pressure based solvers sometimes do not take into account, that information is also transported by waves, not only flow.


Let's focus on the problem that you dont see turbulence in your flow with rhoCentralFoam. I think we can solve that, if you share your dicts. Also images of the flow fields would be helpful, if you cannot share them thats ok.

[jnanabrao]

I have attached the controlDict, fvSchemes, fvSolution, the boundary files and turbulence and thermophysical files. The FREE_STREAM_WALL is a short surface upstream of the nozzle exit which is hard to see, the remaining boundaries are straightforward, I think. But feel free to ask if there's any confusion. There are a lot of commented options that I have for the other solver and in many cases I have not used default option which may have been easier to read, so I apologize for that.

[shock77]

On first glance, your simulation result looks totally fine to me. What would you expect or what does sonicFoam calculate?


Your dicts are a mix of dicts for density based solvers and pressure based solvers. You have to clear those.


1. Your timestep is rather big, those upcoming suggestions might need a smaller time step like Co = 0.1 - 0.3.


2. fvSchemes


Acutally I dont know what $cLimit means, but this seams odd to me. Also you are limiting basically everthing, that might be the issue. Usually, I take a dicts from the tutoral and modify it. It would suggest you to try this first, this is not as diffusive:

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  4.1                                   |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "system";
    object      fvSchemes;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

fluxScheme      Kurganov;

ddtSchemes
{
    default         backward;
}

gradSchemes
{
    default         cellLimited Gauss linear 1;
}

divSchemes
{
    default          Gauss linear;
    div(tauMC)       Gauss linear;
}

laplacianSchemes
{
    default         Gauss linear corrected;
}

interpolationSchemes
{
    default          linear;
    reconstruct(rho) vanLeer;
    reconstruct(U)   vanLeerV;
    reconstruct(T)   vanLeer;
}

snGradSchemes
{
    default         corrected;
}

wallDist
{
    method meshWave;
}

3. fvSolution


That dict is a mess, why would you use GAMG in first place and second why for rho? Also you need no numerical solver for p. I suppose this is a relict from sonicFoam. Please always look into the tutorials first, they are of big help!


It may look like this:

solvers
{
    "rho.*"
    {
        solver          diagonal;
    }

    "U.*"
    {
        solver          smoothSolver;
        smoother        GaussSeidel;
        nSweeps         2;
        tolerance       1e-9;
        relTol          0.0;
    }

    h
    {
        $U;
        tolerance       1e-9;
        relTol          0.00;
    }
    
}

Try that and see if any change occures. You have to add the entries for the schemes for your turbulence model ofc.

[jnanabrao]

On first glance, your simulation result looks totally fine to me.

The noise results are way off. Even in terms of flow, there is a very high velocity gradient in the shear layers at jet exit (the Re is around 3e+6). I'm expecting to see some turbulent structures develop much earlier in the shear layers than they do. In my result I only see turbulence beyond the potential core.

Your timestep is rather big, those upcoming suggestions might need a smaller time step like Co = 0.1 - 0.3

To start the simulation, I maintained Co at around 0.1-0.05 but once it was more developed I progressively kept increasing it. But I will run it with smaller values.

That dict is a mess, why would you use GAMG in first place and second why for rho? Also you need no numerical solver for p. I suppose this is a relict from sonicFoam. Please always look into the tutorials first, they are of big help!

Yes I agree that its a mess. I was trying to understand the effect of the solver so I was running a case to a developed stage using one solver and then just changing the solver to see how the flow changed.

h
    {
        $U;
        tolerance       1e-9;
        relTol          0.00;
    }

I am running it with sensibleInternalEnergy. Do you think that will change much?

Acutally I dont know what $cLimit means

Its the same as cellLimited Gauss linear 1. I just set a variable to avoid writing the long name. I was trying to play around with cell and face limiting for gradients so I didn't set the default grad scheme and hence had to write each grad term out. It was easier to shorten the name with a variable.

Try that and see if any change occures. You have to add the entries for the schemes for your turbulence model ofc.

Let me run a case and share the image once its done.

[shock77]

Hi again,


I missed somehow the images of sonicFoam and rhoCentralFoam. It is indeed strange, that rhoCentralFoam seems not to resolve turbulence in early stages. It might be truly to diffusive.


I have seen a related work: https://www.researchgate.net/publica...onic_free_jets
and they are getting more or less the same results as you do. So I suppose your only solution is either to try another solver or to modify rhoCentralFoam in a manner, that its not as diffusive.


This is the orignal paper of rhoCentralFoam: https://www.researchgate.net/publica..._viscous_flows. Maybe eliminating the diffusity term in equation 7 will lead to more resolved turbulence. On the other hand the solver will propably be less stable.

[jnanabrao]

I got the rhoCentralFoam solver to give me some sort of turbulence. The results are worse but more turbulent(See image). What I had to change was the reconstruct(rho/U/T) options to "Gamma" with a blending coefficient of 0.2. I think the reconstruct algorithm is the source of the dissipation. Although I couldn't understand where it is called in the solver.

[shock77]

Its ofc one source of dissipation, since you decide how much of your domain is first or second order. I had only bad experiences with gamma, therefore I am not using it.


If you want your domain be rather compressive than dissipative, you can try SuperBee and see if it works.