[martyn88]

Hi everyone,

I am modelling a supersonic turbulent free jet but am struggling to get a stable run, and I think it may be a BC problem.
I was just wondering if anyone has had any problem using the flowrateinletvelocity BC? I am using a ramped inlet flow rate and am starting it very slow and can only get it to run when it has a very slight ramp and it still only gets to 400 iterations or so before the enthalpy equation crashes. The more I try to increase the velocity ramp the sooner the enthalpy equation blows up (max number of iterations exceeded etc.). Also, the density seems to be blowing up also, rho min max is beyond 3, 0.1.
It appears to be crashing when the flow reaches the nozzle exit where a vortex is forming at the nozzle lip. Why would the enthalpy be crashing?

The pressure inlet BC is zero gradient.

I am using a pressureinletoutletvelocity for the outlet velocity BC (the outlet is the entire freestream) and no slip (fixed value =0) conditions for the nozzle wall.

Could anyone please help me with this?

[martyn88]

Any help would really be appreciated

Thanks

[Ofc]

Hi Martyn,

some more information about your net would be great. As far as I understood, your outlet is directly after the nozzle? This might be one reason why it crashes. As the solver crashes exactly after reaching the outlet, you could try another outlet BC (e.g. fixed pressure). Also steady state simulations are sensitive to vortices.

best regards

[Jet_Power]

hallo. Because I'm not familiar with your work, I cannot understand your problem well. Maybe you can set a better initial field for your running. For example, try to set a lower total pressure (if you are not using this parameter, just set a equivalent one) for the inlet boundary, run it , get the result and save it as initial field. After that you can increased the inlet pressure.
If the inlet pressure is too high, a (numerical) shock may come out just like a shock tube problem and the computation may crash.
Hope you can understand my words, my english is not good.

[martyn88]

Hi, I'm sorry for the confusion, I did not really explain my problem very well

I am doing an LES simulation (unsteady obviously) of a turbulent supersonic free jet using the rhoPimpleFoam solver.

My solution domain is a converging diverging nozzle with the free-stream extending 30 nozzle exit diameters. and 10 diameters high. There is also a section of free-stream above the nozzle to capture the flow behavior at the nozzle lip. The computational domain is only a 1/8th section using cyclic side boundaries.

I have included pictures below.

meshpic.jpg

velocity contour at exit.jpg

velocity contour at crash.jpg

This mesh is very coarse for LES but at this stage I am just trying to establish my BC's and get a stable run.


I am using the flowRateInletVelocity BC so the simulation is driven by a mass flow not a pressure difference (using zeroGradient pressure BC at inlet).
I understand the idea of the 'numerical shock' so I am currently ramping this inlet BC but it is way too gradual, the table is:
(0 0.05496
(3000 5.496)

Even at this very slight ramp the simulation is still crashing after only 0.003sec so it has a long way to go to reach full speed!

I also fear that my outlet is poorly defined. At this stage I have my inlet boundary, the nozzle wall, then all other boundaries are effectively an 'outlet', which I have named freestream. Is it OK to have more than one outlet or do I need to define an actual outlet (perhaps the rightmost face) and then the freestream separately using some far-field condition?

At the moment I am using a totalPressure condition for all the free-stream boundaries but will use waveTransmissive when I perform the actual run to dissipate the shocks.

Basically I keep getting this error message when I run the case (rho is diverging, enthalpy equation is crashing):


--> FOAM FATAL ERROR:
Maximum number of iterations exceeded

From function specieThermo<Thermo>::T(scalar f, scalar T0, scalar (specieThermo<Thermo>::*F)(const scalar) const, scalar (specieThermo<Thermo>::*dFdT)(const scalar) const) const
in file /home/opencfd/OpenFOAM/OpenFOAM-2.1.0/src/thermophysicalModels/specie/lnInclude/specieThermoI.H at line 69.

FOAM aborting

#0 Foam::error:rintStack(Foam::Ostream&) in "/opt/openfoam210/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#1 Foam::error::abort() in "/opt/openfoam210/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#2 Foam::specieThermo<Foam::hConstThermo<Foam:erfec tGas> >::T(double, double, double (Foam::specieThermo<Foam::hConstThermo<Foam:erfe ctGas> >::*)(double) const, double (Foam::specieThermo<Foam::hConstThermo<Foam:erfe ctGas> >::*)(double) const, double (Foam::specieThermo<Foam::hConstThermo<Foam:erfe ctGas> >::*)(double) const) const in "/opt/openfoam210/platforms/linuxGccDPOpt/lib/libbasicThermophysicalModels.so"
#3 Foam::hPsiThermo<Foam:ureMixture<Foam::constTran sport<Foam::specieThermo<Foam::hConstThermo<Foam:: perfectGas> > > > >::calculate() in "/opt/openfoam210/platforms/linuxGccDPOpt/lib/libbasicThermophysicalModels.so"
#4 Foam::hPsiThermo<Foam:ureMixture<Foam::constTran sport<Foam::specieThermo<Foam::hConstThermo<Foam:: perfectGas> > > > >::correct() in "/opt/openfoam210/platforms/linuxGccDPOpt/lib/libbasicThermophysicalModels.so"
#5
in "/opt/openfoam210/platforms/linuxGccDPOpt/bin/rhoPimpleFoam"
#6 __libc_start_main in "/lib/i386-linux-gnu/libc.so.6"
#7
in "/opt/openfoam210/platforms/linuxGccDPOpt/bin/rhoPimpleFoam"
Aborted



I have done the following with no success:
Running it in PISO mode with nOuterCorrectors = 3
using backward ddt scheme
have increased all rel tol by 10 times (kept rel tol final = 0)
have decreased the relaxation factors to 0.7 (plan to increase it when flow is developed)

Does anyone have any ideas on how to increase the stability of my run?

A lot of info I know but any help would be really appreciated.

Thankyou

[Rami]

You will have more help if you post it in the FOAM forum.

[Jet_Power]

Hi, thanks for the detailed description. LES and Openfoam are beyond my knowledge field. I can not give suggestion about them. sorry!
A question, what about the initial field for the unsteady computation? Would the problem also come out in RANS computation?