[doerschlott]

Hey guys,

I'd like to hear your opinion, if using the "steadyState" ddtScheme in transient solvers using the PIMPLE algorithm yields physical results. As far as I know, this simply sets the terms "fvm::ddt(...)" and "fvc::ddt(...)" to zero, which would reflect a proper, steady-state equation, right?

I do know that many transient solvers, e.g. pimpleFoam have a respective steady-state solver (simpleFoam). However not all of them have, for example the chtMultiRegionFoam. It may be noted that there was a steady-state version of this solver, however in the foundation version (I think 6), this one got merged into the transient one. So this behaviour has to be recreated somehow.

I am not 100% sure if the steadyState scheme is sufficient, as the source code of chtMultiRegionSimpleFoam (EEqn.h) lacks more terms than just those mentioned above, with respect to the EEqn.h of the chtMultiRegionFoam.

Any suggestions?


Best regards
doerschlott

[clapointe]

I can't comment directly on using steadyState with transient solvers (perhaps someone can help in that respect), but I've used local time stepping (LTS) with the localEuler scheme in the past to obtain (pseudo) steady solutions using transient solvers -- to me this is preferable because it provides a bit more controls to retain stability. Here's the link to a description : https://openfoam.org/release/2-0-0/steady-state-vof/. If you are having trouble with stability, you might check LTS out.

Caelan

[doerschlott]

Good point, I did read about the local time stepping some time ago, but thought to have in mind that this was not implemented for all the solvers (especially not the one I used). But I'll give it a shot. Lately I've been investigating heated internal flows, where velocity changes mainly normal to the wall and only a little bit axially due to changes in thermophysical properties, so local time stepping should accelerate the solution which is basically coming from the (heated) wall.

However I'm still curious, if someone has made some experience with a steadyState scheme, as this would eliminate the demands on CFL number, rendering the deltaT as an iteration counter rather than a (quasi-)time, as it is in SIMPLE solvers.

Best regards
doerschlott

[Tobermory]

There seems to be VERY little written about using the steadyState ddtScheme with transient solvers, but here's what I have deduced: it should be possible in theory to use them on any transient solver, as you say, but you may find (as I did) that your solvers are incredibly unstable. With that in mind, you need to remember that the ddt term often stabilises the matrix solver, by increasing the diagonal terms - that's why you need relaxation for the steady SIMPLE solver.

So, my tip is to try and mimick a SIMPLE steady solver setup, with sufficient underrelaxation, 1 outer loop (PIMPLE) and one pressure corrector. When I took that approach, I got pretty much the same behaviour as the equivalent steady, SIMPLE based solver ... and the solution converged MUCH more quickly than the LTS pseudo-transient solver.

Beware, though - since Caelan finds that LTS works really well for him, then that last observation is clearly problem dependent, and LTS may be preferable for certain types of problem. For example, I remember having to run pseudo-transient in StarCD when modelling smoke plumes (many years ago!).

[doerschlott]

Hey Tobermory (I like the name by the way), thank you very much for your experience!
I am reassured, that you also mentioned running PIMPLE in PISO mode with one outer corrector. Though the inner (pressure) corrector is most likely case dependent, right?
And thank you for reminding me of the increased diagonality of the matrices due to time derivatives. A nice mathematical explanation for the stability here.

By the way, the localEuler ddtScheme does not seem to be available for chtMultiRegionFoam by default. There are some code adaptions necessary, which I might try at some point. If anyone is interested, you can have a look into reactingTwoPhaseEulerFoam.C. This is a solver capable of local time stepping.

Best regards
doerschlott

[julieng]

Hello,


I am looking for since long weeks a good settings for fvSolution et fvScheme with openFoam8 for CHT steady cases equivalent to the chtMultiRegionSimpleFoam old steady solver of the openFoam 5.
I run a case that converge smoothly with chtMultiRegionSimpleFoam with the new chtMultiRegionFoam. See my residuals below in the fluid domain.








I have try the settings of the tutorial cases but it is worse. Someone can advise something to test?



Attached are my fvSolution and fvScheme files of the fluid domain.

[doerschlott]

The residuals don't look that bad in my oppinion. Sure, the ones for "h" are quite high, but higher residuals in transient calculations is something that I experienced very often, likely due to the ever-changing fields (even if they should converge to a steady-state solution). I would advice you to monitor some physical quantities and based on them you can decide wether your calculation converged physically, if not numerically. For example have a look into min/max temperature which is printed by default. Moreover you can use functionObjects to print out maximum values of any calculated field. If they don't change over several iterations, you're done.

On the other hand, the calculation is very restricted in numerical terms, which might hinder further convergence. Namely all schemes are bounded and in your fvSolution, pressure and density are capped to certain values. Are you aware of that, or are those remnants from the tutorial case you got the file from? Are the bounded schemes really necessary to maintain stability? An evergreen is to have a second look onto your boundary conditions or the mesh, if the quality is that bad, as the laplacianScheme suggests.

Best regards
doerschlott

[julieng]

Hello,


Thank you for your answer doerschlott.


I admit that I don't catch how the fvSchemes are working exactly, I try only to get a robust settings for CHT in copying tutorial and files that I found everywhere. I know that I have to study to have a better understanding, not a good point for me.

I see that the "corrected" scheme for laplacianSchemes is very bad in my case giving large oscillation in residuals



I have change the fvSchemes (see attached file) and I obtain this residuals. Only the pressure remains high.

I have also monitor variables, patch temperature, inlet pressure and it seems that everything is converged.





Could you suggest me an advise to reduce residual pressure error ?



Best regards


Julien

[doerschlott]

Hey Julien,
residuals do look better now.
In my experience, getting low residuals for pressure is hard. Keep in mind that chtMultiRegionFoam is a compressible solver and thus more complicated than incompressible formulations. Though I have two more ideas:

1) What about your CFL number? Is it larger than one? Although PIMPLE is capable of handling CFL numbers larger than that, reducing it below one also reduces residuals.

2) You can also do another trick in the thermophysicalProperties:

thermoType
{
    type            heRhoThermo;
    mixture         pureMixture;
    transport       polynomial;
    thermo          hPolynomial;
    equationOfState icoPolynomial;
    specie          specie;
    energy          sensibleEnthalpy;
}

dpdt off;

mixture
 {
...

dpdt is a term in the energy equation. Setting it off is reasonable as you have steady-state anyway and for incompressible flow this also holds true. This may or may not reduce the oscillations in the h residuals.

One comment on your new fvSchemes: Did you test the "uncorrected" because they are commented out? uncorrected is only applicable if you have a perfect orthogonal mesh (you can check this out with checkMesh).
However, if you have oscillations with "corrected" scheme you should revise your mesh and aim for a lower average (and max) non-orthogonality.
I know that going through all the theory of fvSchemes is tough, but it is really important, if you want to know what's going on in your calculation.

Best regards
doerschlott

[julieng]

Thank you very much for your very interesting comments.
I will try in the week your suggestion.
I was thinking that the CFL number as only a meaning in transient simulation? I use deltaT =1!! CFL number might be huge >>1.
Yes i have tested uncorrected and it runs close to the same residuals values. I use snappyhexmesh for the grid, with boundary layers, i will check my mesh.

Thank you again

[doerschlott]

Sorry, my bad. I though you'd have Euler as ddt scheme. Then it probably is not important. But actually that is what the thread is about.
I think that "uncorrected" is only applicable to very simple geometries where you are able to have complete orthogonality. For any real problem, "corrected" is the way to go (for a good quality mesh).


Best regards
doerschlott

[julieng]

Hello,


I have tested to add in the fluid thermo properties



dpdt off;


but the residuals are exactly the same, with oscillations in h residuals.


See the checkMesh log of my fluid domain joined.


I am already happy with running PIMPLE in a steady state.

With chtMultiRegionSimpleFoam (OF5) I had fluid-to-solid patch temperature = 412.500357 K, with chtMultiRegionFoam (OF8) fluid-to-solid patch temperature = 412.502112 K


For the inlet pressure

OF5 = 100001.551 Pa

OF8 = 100001.4556 Pa


Best regards

[doerschlott]

A pitty that "dpdt off" didn't help, it often did me good.
The mesh looks ok, although 61 for non-orthogonality is already quite some value. The limited corrected is a good idea here. Maybe 0.5 as a factor is sufficient though.


But anyway, thank you very much for sharing the comparative results for both approaches. That looks indeed very promising.

One more thing, I'd like to correct a former statement of mine: The number of pressure correctors nCorrectors should be set to one and only one, as Tobermory suggested. This is the behaviour of the SIMPLE algorithm, so it is not case dependend like I've said before.

Best regards
doerschlott