2D nozzle in rhoSimpleFoam
1 Attachment(s)
Hello all,
I'm loosing patient with OF. I'm trying to calculate simple nozzle like in attachment. Inlet at left outlet at right, front and back empty, rest are wall. I use HELYX OS to prepare case. I want to use compressible SST model. At bottom I paste the "0" files. For k Code:
/*--------------------------------*- C++ -*----------------------------------*\ Code:
/*--------------------------------*- C++ -*----------------------------------*\ Code:
/*--------------------------------*- C++ -*----------------------------------*\ Code:
/*--------------------------------*- C++ -*----------------------------------*\ Code:
****************** Please help me because I'm sick of OF right now. |
Your boundary conditions don't make any sense. Why do k and omega have inlet conditions specified for the outlet? Is it really reasonable to initialize omega as zero everywhere?
From the error the problem is clearly in the turbulence model. Have you tried disabling it and seeing if the case runs to check if everything else is OK? Does it make sense to specify total pressure on the inlet and outlet? I think it only makes sense to do so on the inlet. The outlet should be a static pressure. |
5 Attachment(s)
Thank you for your respond.
I tried lamina flow which worked fine, even Spalart-Allamaras seams to be stable and give good results. But for k-epsilon and SST it is very hard to run calculation. It usually collapsed after few iteration. In previous post is only an example of of BC. As you said I tried total pressure at inlet and fixedValue at outlet for velocity both was zeroGradient. Is it good to use zeroGradient for velocity with totalPressure? Or should I use pressureInletVelocity? I also tried different initialization. I affect in one or few iteration more but no more than six to seven. I changed mesh for hexa and tried calculation by rhoPimpleFoam with adaptive deltaT and courant number < 0.8. It also collapsed but give results (find in attachment). How to initialize k and omega while it has very different value in different place in model? The nozzle is very simple model, I can't image problem with more complex one with multiple inlet and outlet. I'm new in FOAM I used to work with fluent. One more question, I use openFOAM on virtualBox Ubuntu. Could it produce errors in calculation? |
Ok, i manage to run with different boundary condition. I used fixed velocity at inlet. With totalPressure it didn't work.
U Code:
/*--------------------------------*- C++ -*----------------------------------*\ Code:
/*--------------------------------*- C++ -*----------------------------------*\ Code:
/*--------------------------------*- C++ -*----------------------------------*\ Code:
/*--------------------------------*- C++ -*----------------------------------*\ https://www.cfd-online.com/Wiki/Turb...ary_conditions but with the same strategy for different inlet velocity the problem with starting occurred again. It is impossible to run calculation. How can I estimate the value for k and omega as I don't know anything about outlet condition? And how to estimate initial value? By the way in fluent it almost doesn't matter what initial value you set. It usually works perfect for initialize all with 0 values. Why openFOAM is so sensitive for initialization? me3840 What boundary condition will you suggest for this calculation? |
|
Quote:
Quote:
Quote:
In reality many flows do not see great changes from changes in turbulence initial conditions, OpenFOAM doesn't change that. We have not established that OpenFOAM is being sensitive to these values, there can be lots of other things wrong with your simulation. Just because something 'works' in another code doesn't make it right. The whole point of an initial solution is to be somewhat close to the final one. Making everything 0 everywhere just makes your life harder, but it probably won't change the answer if the model converges. Quote:
rhoSimpleFoam is not very stable for these kinds of simulations in the first place. You will probably have to start with low pressure ratios and work your way up. This may only be runnable with a transient solver, or rhoCentralFoam. |
Thank you all for respond.
Quote:
Quote:
|
I think the last post of this thread could help.
|
Quote:
Quote:
|
Hi all,
I have the same problem with rhoSimpleFoam using OpenFoam and not Helyx. I described my case here Surely your case will generally work also for me @johny0688 Could you share the working boundary conditions you set to start your simulation. Thanks |
karamiag
Thank you for good advice. Now I'm further with simulation, I'm calculating different model (I don't have access to computer at work, when I do I will paste the pictures). I manage to increase the velocity and pressure at BC during the calculation by table depends on time. I also initialize domain with different values by setFieldsDict. I realized that after some timesteps the temperature grows to enormous value. By analyzing step by step I found that it occurred wherever inside the domain even if the flow is very slow. So I bounded the temperature in fvOptions. Now the case works but only with rhoPimpleFoam (transient). Still the Courant number is very high over 3 with timeStep 2e-8 so the simulation take very long to reaches steady flow. At the end of this week I will try to run case with rhoSimpleFoam including yours advice. Will find out if it helps :) Quote:
Quote:
I will post all my cases when I get acces to computer at work. All the best, |
Quote:
I have seen openFOAM's code too and it is nowhere near in terms of following things for accuracy. I carried the same attitude for FVUS, that is accuracy first, then stability and it has to be stable for industrial cases. PS: Samir muzaferija once told me that let the solver diverge and then user fix the mesh then to give it stable and inaccurate results. This he said when i was showing him how I can make a very difficult case stable that has near zero or negative cell volumes. He also said that lot of money riding on it so inaccurate results are big No No. |
All times are GMT -4. The time now is 21:45. |