[kin3062]

Hi all,

I ran a simple straight pipe with rhoPimpleFoam, however it doesn't run well, it gives strange flow and stops very soon. The flow seems being blocked at the exit of the pipe. Don't know if anyone came across similar strange behaviour? (Apart from negative initial temperature ...)

Attached "rhoPimpleFoamerror" is the screen capture of the erreous flow calculated by rhoPimpleFoam. The model is a very simple straight pipe with wall at 293K. Media is air at 293K and 1e5 Pa.

The same mesh had been run with pimpleFoam without problem. Anyway, is it possible to run pimpleFoam with temperature? Great if it is a way to do this; rhoPimpleFoam seems too complicated ...

[kin3062]

One more additional information, when I try running with buoyantPimpleFoam with the same model, calculation ran into same problems (negative initial temp., crashes with flow start to "blocked" near the exit).

However, if running with buoyantBoussinesqPimpleFoam, then it can ran to completion without any strange results.

This give me an impression that it seems compressibility causes the problem

I don't have any clue about that strange problem, my "thermophysicalProperties" is just the same as in OpenFoam tutorial except I have the "nMoles" (but without "nMoles" the calculations just won't start, reported as fatal error).

[simrego]

Hi!


Honestly I have no clue what is the problem, but a hint:
In this case try to upload some files if you can (BCs, fvSchemes, fvSolutions, thermophisycalProperties, logs, etc.) These are small txt files but can help a lot for an expert to find the problem, or at least give some suggestions.

[kin3062]

Hi simrego,

Attached are the files for the simulation with rhoPimpleFoam. I am welcome for any suggestions or if any errors are pointed out

[kcjarvis56]

Check your constant directory to see if you have an fvOptions file. Check to make sure there is not a porosity source and delete if there is. With the limited files and information this is my best guess. If you send the whole case I could look at it closer.

Hope this helps.

Kirk

[kin3062]

Hi kcjarvis56,


My case doesn't have porosity source, doesn't even have fvOptions file.


I am now in holiday, I can upload my full case in Wednesday or Thursday, thanks for your help!


Talking about fvOptions file, I also heard that there is a "limitTemperature" fvOptions that can eliminate the negative temperature problem. I also ran the case with this "limitTemperature", and the results was that it just delays the crash of the solver ...

[kin3062]

Hi kcjarvis56,

Just back from holiday, attached is the full case set up.

Thank you again for help

Originally Posted by kin3062

Hi kcjarvis56,


My case doesn't have porosity source, doesn't even have fvOptions file.


I am now in holiday, I can upload my full case in Wednesday or Thursday, thanks for your help!


Talking about fvOptions file, I also heard that there is a "limitTemperature" fvOptions that can eliminate the negative temperature problem. I also ran the case with this "limitTemperature", and the results was that it just delays the crash of the solver ...

[kcjarvis56]

kin3062 Hi,
What turbulence model are you using in your case?

Thanks,

Kirk

[kin3062]

Hi,

I use Spalart Allmaras

Originally Posted by kcjarvis56

kin3062 Hi,
What turbulence model are you using in your case?

Thanks,

Kirk

[kin3062]

Hi kcjarvis56,

I also tried running with RNG k-epsilon model, solver also crashed. It crashed even sooner than with Spalart Allmaras model ...

Attached is the log file for the run with RNG k-epsilon.

Originally Posted by kcjarvis56

kin3062 Hi,
What turbulence model are you using in your case?

Thanks,

Kirk

[cryabroad]

I'm interested in this problem, as I just did some RANS on a jet flow (hot air discharged into cold air). I should say that rhoPimpleFoam runs very well without any problems.

From what I can tell, first thing first, your time step is too large, in your very first time step you have a maximum CFL number of 5, which is not acceptable. Also, when you see messages like "bounding k" and "bounding epsilon" in the log file, it usually indicate that something is wrong with your setup. For internal flow using RANS it mainly comes from boundary conditions.

My suggestion is, start with simple cases and gradually increase the complexity of your set-up. (1). You are doing transient simulations, have you tried steady ones with the same turbulence model? Based on what you described about your case, it should be very easy for OF to handle a steady-state case. (2) Get rid of all the lower/upper bounds of pressures and densities in your fvSolutions, together with the pRefCell and pRefValue stuff. Basically, try to run a simulation with minimum interactions with the solver first. This makes things much cleaner, and as a result easier to debug. (3) You are solving a compressible case, so it's important to correctly set up the thermophysicalProperties, can you also share your constant folder? Or just the thermophysicalProperties file is okay for now I think.

The reason why your case runs with pimpleFoam sounds very strange, unless you have set up the density and viscosity for your fluid, otherwise what density and viscosity are being used? For compressible cases the density and viscosity are calculated with various models (perfectGas, sutherland etc.) so you don't have to tell OF what is the density of the fluid.

[kin3062]

Hi cryabroad,


Thank you for your advice first


First of all, my model is a simple round straight pipe, no fancy stuff or geometry. And as usual, flow speed defined at inlet, pressure (of 100000) defined at outlet. Secondly the use of relatively large CFL number is because a larger delta time is chosen, we want a faster calculation.



We have tried not to include pressure or density lower/upper bounds and those "pRef" stuffs, the results were that the solver crashes more quickly.


I am not in office hours. Once I back to work I can share you the thermophysical Properties file for you to see. For those incompressible solvers we input density and viscosity as usual, in transport Properties.



The background is:
This model is actually used to test out the rhoPimpleFoam, we plan to run compressible solver for some motor car parts, which temperature differences exist in different areas. We had run SimpleFoam, PimpleFoam and buoyantBoussinesqPimpleFoam with such CFL numbers without problems. But as temperature differences are relatively large, few decades, we think it would be more appropriate to use rhoPimpleFoam.


We are a supplier, our Customers and Sales Dept. only allows short analysis time. We know that with such "as fast as possible" approach we are not as professional as those CFD consultancies, but we are not able to push back; you know, people who pays are always the Kings or Queens ... Consultancies could ask for 10 working days for a single run with maybe $8000USD, but this is not the case for us. For us, asking for more than 3 days, people almost immediately kill us ...



Anyway if the steady-state one can do better (or at least not as problematic) maybe I will try that out later.



Again, thanks for your advice

Originally Posted by cryabroad

I'm interested in this problem, as I just did some RANS on a jet flow (hot air discharged into cold air). I should say that rhoPimpleFoam runs very well without any problems.

From what I can tell, first thing first, your time step is too large, in your very first time step you have a maximum CFL number of 5, which is not acceptable. Also, when you see messages like "bounding k" and "bounding epsilon" in the log file, it usually indicate that something is wrong with your setup. For internal flow using RANS it mainly comes from boundary conditions.

My suggestion is, start with simple cases and gradually increase the complexity of your set-up. (1). You are doing transient simulations, have you tried steady ones with the same turbulence model? Based on what you described about your case, it should be very easy for OF to handle a steady-state case. (2) Get rid of all the lower/upper bounds of pressures and densities in your fvSolutions, together with the pRefCell and pRefValue stuff. Basically, try to run a simulation with minimum interactions with the solver first. This makes things much cleaner, and as a result easier to debug. (3) You are solving a compressible case, so it's important to correctly set up the thermophysicalProperties, can you also share your constant folder? Or just the thermophysicalProperties file is okay for now I think.

The reason why your case runs with pimpleFoam sounds very strange, unless you have set up the density and viscosity for your fluid, otherwise what density and viscosity are being used? For compressible cases the density and viscosity are calculated with various models (perfectGas, sutherland etc.) so you don't have to tell OF what is the density of the fluid.

[kin3062]

Hi cryabroad,

Back to work, and you can find my attached "constant" folders.

Originally Posted by cryabroad

I'm interested in this problem, as I just did some RANS on a jet flow (hot air discharged into cold air). I should say that rhoPimpleFoam runs very well without any problems.

From what I can tell, first thing first, your time step is too large, in your very first time step you have a maximum CFL number of 5, which is not acceptable. Also, when you see messages like "bounding k" and "bounding epsilon" in the log file, it usually indicate that something is wrong with your setup. For internal flow using RANS it mainly comes from boundary conditions.

My suggestion is, start with simple cases and gradually increase the complexity of your set-up. (1). You are doing transient simulations, have you tried steady ones with the same turbulence model? Based on what you described about your case, it should be very easy for OF to handle a steady-state case. (2) Get rid of all the lower/upper bounds of pressures and densities in your fvSolutions, together with the pRefCell and pRefValue stuff. Basically, try to run a simulation with minimum interactions with the solver first. This makes things much cleaner, and as a result easier to debug. (3) You are solving a compressible case, so it's important to correctly set up the thermophysicalProperties, can you also share your constant folder? Or just the thermophysicalProperties file is okay for now I think.

The reason why your case runs with pimpleFoam sounds very strange, unless you have set up the density and viscosity for your fluid, otherwise what density and viscosity are being used? For compressible cases the density and viscosity are calculated with various models (perfectGas, sutherland etc.) so you don't have to tell OF what is the density of the fluid.

[cryabroad]

Thank you for sharing the file. I completely understand your situation, I worked with some industrial people during my phd on two-phase problems, and they wanted results in like a week. And that was during my first year when I was not familiar with the software (I used FLUENT).

Based on your file, I have two suggestions. First, try changing the type of thermoType to hePsiThermo, I myself find heRhoThermo type hard to use. The difference between these two is the way density is calculated, hePsiThermo updates density based on the equation of state (in your case perfectGas, so rho = P/(RT)) while heRhoThermo solves the continuity equation to get density. Second, try play with the energy keyword in the thermoType, you can use sensibleInternalEnergy instead. This one I'm not so sure though, sometimes it doesn't make any difference but sometimes it does.

A quick question, why do you use const in your transport tab in thermoType, I thought things like sutherland would be more realistic.

All these settings are basically the same as the tutorial case OF provides, https://github.com/OpenFOAM/OpenFOAM...ras/angledDuct

Anyway, I would start with a steady-state case, based on the number of cells in your domain and your computer hardware, you can have results in just several minutes (and show them to your colleagues). For steady-state case you should use rhoSimpleFoam, which is a steady-state solver instead of a transient one.

For transient cases the CFL number has to be small, if you are really serious about doing transient simulations, it should be even below 0.5 or so. The underlying physics of CFL number being less than 1.0 (a typical criterion) is that a fluid element does not flow past one cell during the time step, a high CFL number just means you are missing too much information. Sometimes you can relax the criterion a little bit but there's no way around it.

[kin3062]

Hi cryabroad,


Thank you again for your advice


I am now working on other things, on some molding simulations and other mechanical calculations (yes we have to be an immortal superman ... ). Will try things you suggested later.


One more thing out of my curiosity, as what I know about Pimple is that one can use higher CFL. Yes using CFL of 5 maybe a bit too extreme, but I think we should at least can go with something more than 1 I think?



Or maybe compressible solvers have a more strict requirement on CFL? I know that with CFL more than 1 there will be risk in missing something, the car parts we do simulation does not have fancy features or any special BCs, flows are usually simple, can show how the flow evolves is already good enough for us.

Originally Posted by cryabroad

Thank you for sharing the file. I completely understand your situation, I worked with some industrial people during my phd on two-phase problems, and they wanted results in like a week. And that was during my first year when I was not familiar with the software (I used FLUENT).

Based on your file, I have two suggestions. First, try changing the type of thermoType to hePsiThermo, I myself find heRhoThermo type hard to use. The difference between these two is the way density is calculated, hePsiThermo updates density based on the equation of state (in your case perfectGas, so rho = P/(RT)) while heRhoThermo solves the continuity equation to get density. Second, try play with the energy keyword in the thermoType, you can use sensibleInternalEnergy instead. This one I'm not so sure though, sometimes it doesn't make any difference but sometimes it does.

A quick question, why do you use const in your transport tab in thermoType, I thought things like sutherland would be more realistic.

All these settings are basically the same as the tutorial case OF provides, https://github.com/OpenFOAM/OpenFOAM...ras/angledDuct

Anyway, I would start with a steady-state case, based on the number of cells in your domain and your computer hardware, you can have results in just several minutes (and show them to your colleagues). For steady-state case you should use rhoSimpleFoam, which is a steady-state solver instead of a transient one.

For transient cases the CFL number has to be small, if you are really serious about doing transient simulations, it should be even below 0.5 or so. The underlying physics of CFL number being less than 1.0 (a typical criterion) is that a fluid element does not flow past one cell during the time step, a high CFL number just means you are missing too much information. Sometimes you can relax the criterion a little bit but there's no way around it.

[cryabroad]

Hi kin3062,

You are right, it has been said the PIMPLE is designed to actually overcome the CFL < 1 criterion. The thing is, at least as far as I know, I see people still imposing this criterion when using PIMPLE, regardless of what it is designed for.

I don't know if compressibility imposes more strict CFL requirements or not. Maybe for some cases CFL ~ 5 gives good results, maybe not. I think this may be one of the reasons people stick to the CFL < 1 criterion. Either way I think steady-state simulations are a good starting point I think, even RANS results can tell you something about the flow characteristics.

Good luck to whatever you are working right now! Seems like the boss is pushing kind of hard, but that's what the boss does

[kin3062]

Hi cryabroad,


Finally had some time to try things out, but it didn't go well ; the calculation still crashes very soon after start. And same as before, before it crashes, pressure goes up and down wildly like crazy.


I remember in my previous run, even I used CFL of 1 the solver still crash. But as you mentioned, now with hePsiThermo the density is no longer calculated by continuity, maybe I will try to use CFL of 1 together with your suggestions.

If things still doesn't get right I will try steady-stae as you also suggested.