[Tobermory]

No problem!

My upStream patch is on the upstream end of the "nozzle" - ie the far left vertical boundary in the plots. The downStream patch is to the right of the edge of the picture (only part of the domain is plotted).

[Oliver Meng]

Thank you again for your answer!

I assume your geometry looks somehow like this?

And do you use a mass flow rate or just a normal velocity bc for the inlet?

I have also seen the T limit method in the aerofoil tutorial, but is there a reason why you limit the temperature not the rho?

To be able to avoid a unsteady solver would be a rescue for me, since i have been trying this for months. So please forgive me if i ask too specifically and too much.

Originally Posted by Tobermory

No problem!

My upStream patch is on the upstream end of the "nozzle" - ie the far left vertical boundary in the plots. The downStream patch is to the right of the edge of the picture (only part of the domain is plotted).

[Tobermory]

Yes - that's right. I am specifying the (total) pressure on the upstream boundary, so I have a zeroGradient BC on U ... you can't specify both p & U since that overconstrains the problem. On the downstream boundary I have a fixed pressure and a pressureInletOutletVelocity for U (i.e. zerogradient).

As for limiting - it's simpler for me to limit T since I know a-priori what the range will be, and keeping a tight control on T stops the Janaf class going nuts with temperature out of range errors (when calculating Cp). I guess there's no reason why you couldn't limit rho instead, although I haven't tried it - you'd need to check that the rho equation in your solver allows for fvOptions.

One other thing - again related to stability - I start by running with basic kEpsilon, and get a converged solution, before changing over to realizableKE, which is much less stable but gives a far better, less diffusive solution.

Again - good luck, and I hope that some of the above helps.

[Oliver Meng]

I have been struggling with this problem for another week and again without success. Supersonic with steady solver is kinda annoying. But since i'm only interested in the force coefficient, it is really not necessary to use a transient solver for any time related values.

My case is 3D but a 2D slice also tells the story and it looks like this.(attachment)

The flow will choke at the “bottleneck” and rise after that.

Since my domain is quite small I used k-omega-SST to also (trying to) get a good result in the near wall region.
My inlet has a velocity condition and outlet fixed pressure.
Inspired by you I’m gonna try to increase my inlet velocity step by step (like you total pressure) from 40 to 100 m/s and see if it helps.

Regards

Originally Posted by Tobermory

Yes - that's right. I am specifying the (total) pressure on the upstream boundary, so I have a zeroGradient BC on U ... you can't specify both p & U since that overconstrains the problem. On the downstream boundary I have a fixed pressure and a pressureInletOutletVelocity for U (i.e. zerogradient).

As for limiting - it's simpler for me to limit T since I know a-priori what the range will be, and keeping a tight control on T stops the Janaf class going nuts with temperature out of range errors (when calculating Cp). I guess there's no reason why you couldn't limit rho instead, although I haven't tried it - you'd need to check that the rho equation in your solver allows for fvOptions.

One other thing - again related to stability - I start by running with basic kEpsilon, and get a converged solution, before changing over to realizableKE, which is much less stable but gives a far better, less diffusive solution.

Again - good luck, and I hope that some of the above helps.

[Oliver Meng]

Hi,

after trying with different tricks and methods, i still did not get it converged.

Do you happen to know, or do you have experience, if the steady state solver for compressible flow in Ansys is more stable for a supersonic flow compared to Openfoam?

Regards

Originally Posted by Tobermory

Yes - that's right. I am specifying the (total) pressure on the upstream boundary, so I have a zeroGradient BC on U ... you can't specify both p & U since that overconstrains the problem. On the downstream boundary I have a fixed pressure and a pressureInletOutletVelocity for U (i.e. zerogradient).

As for limiting - it's simpler for me to limit T since I know a-priori what the range will be, and keeping a tight control on T stops the Janaf class going nuts with temperature out of range errors (when calculating Cp). I guess there's no reason why you couldn't limit rho instead, although I haven't tried it - you'd need to check that the rho equation in your solver allows for fvOptions.

One other thing - again related to stability - I start by running with basic kEpsilon, and get a converged solution, before changing over to realizableKE, which is much less stable but gives a far better, less diffusive solution.

Again - good luck, and I hope that some of the above helps.

[Tobermory]

That must be really frustrating. I don't have any recent experience with Ansys Fluent or CFX ... my recollection is that StarCCM+ was more stable, but I do not have access to that at the moment.

[ander]

Originally Posted by arjun

the idea that if the solver is unstable than it must be more accurate compared to stable solver is completely not true.

It is more so not true when you compare OF against StarCCM. CCM does not add sort of artifical dissipation to make it stable and not only that its descretization is actually more accurate.

I personally have never found a case where starccm and of are compared and starccm came out to be less accurate.

Mostly if you benchmark you will find that starccm does better than OF.

I even have a study where most scheme of OF for convection terms were compared in a validation case and starccm was also one of the solver. Guess what there was hardly any scheme that was as good as starccm and around 40 scheme were compared.

Give me email i will send you the results.

Dear Arjun,

This was suprising to me as well as I've long had the impression that commercial solvers use artificial diffusion or similar techniques to increase robustness. This is for instance championed by this post: https://www.linkedin.com/pulse/accur...s-lubos-pirkl/

Could you eloborate on what starccm+ does to be both robust and accurate at the same time. Or is the idea that comemrcial solvers are more robust simply a myth?

[Tobermory]

It's not a myth - they really are more robust (at least StarCCM+ is), and the article/blog that you linked (a really good read - thanks!) explains why - commercial reality in essence.

It's still possible to make a StarCCM+ simulation explode (I am running various cases at the moment) ... but usually only if you make a big mistake with the boundary condition or initial field setup. Sadly, that's not the case with OpenFOAM.

There are a bunch of limiters and the like in StarCCM+ - many of which you can adjust or turn off (eg rough wall limiter, turb viscosity limiter), but I suspect that some of the magic (ie source of robustness) is in the boundary condition coding, which of course is not open for scrutiny or adjustment in a commercial code.

[ander]

I think there is a slight mismatch between what that linkedinpost conveyed (that you can have either robustness or accuracy) and what Arjun reported (that you can have both).

If starccm+ is indeed accurate and robust and the same time, it really is superior compared to opensource. A shame that the methods used by these companies to increase robustness aren’t public knowledge.