Switchig from chtMultiRegionSimplefoam to chtMultiRegionFoam
Hello all,
I have a case that is running fine in chtMultiRegionSimpleFoam in steady-state. Now I am trying to run the same case (with steady-state BCs) in transient using chtMultiRegionFoam (I will switch to transient BCs later on). So far this is a desaster. What I did: 1. Use the case without any changes but run "chtMultiRegionFoam" instead of "chtMultiRegionSimpleFoam". This gives me mass conservation for time 1. However, as expected courant numbers are way to high for PISO and the simulation is crashing after a few time steps. 2. Next step was to reduce time-stepping to 1e-4. This gives me max. courant of 0.43. However, this calculation gives significant mass inconsistency between my in- and outlet and massively to high pressure drop after the first time step. It ends up with unphysical high velocities after a few time-steps. I realized that reducing time step further (1e-6) makes everything even worse which I don't really understand. However, larger time steps (1e-2) gives better but not perfect behavior. Has anybody observed similar effects? I have no explanation for this nor an idea what can be done to overcome this to get a stable solution. Regards bastil |
Please post your fvSchemes and fvSolution files.
|
2 Attachment(s)
See attached for both fluid (it's a liquid) and solid.
Inbetween I increased nOuterCorrectors from 1 to 10 to switch from PISO to pimple. This improves the continuity error (seems to improve due to available under-relaxation) but gives me divergence typically when solving velocity. |
While your files are all over the place I can't spot anything obviously wrong in them. There are things in there like a momentumPredictor in a solid, which is not read since there is no flow being solved, but nothing that makes a crash inevitable. Your schemes are fine. You might want to try changing your div(phi,U) scheme to upwind. The celllimited version you are using is fine though. Since you did not change anything in 0 and constant as I understood it is only the start up phase.
How long did it take your steady state solution to converge to reasonable levels? Did you try initializing your transient simulation with the steady state one? When and how does it crash? Can you post a log file of your run? |
Yes, it is the start-up phase that is causing issues.
The steady-state solution took about 2000 Iters to converge. However, it was only the solid temperature that was quite slow. Flow field convergence was notably quicker. I can post a log-file but this will take some time, I am out for a few days now. Mostly the crash happens at the beginning of a new timestep before solving velocities. I have a quite verbose log-file that gives me min and max field values for pressures, temperatures and velocities. After increasing nOuterCorrectors to 10 there is nothing obviously wrong about them before the crash occurs. Before that, mass conservation was not ok. I tried initializing from steady-state without any success. I suspect this has something to do with different pressure levels: I use pressure "0" at the outlet for steady-state which I changed to "1e5" for transient. From my understanding the incompressible solver is pressure-normalized ("0") whereas the transient one requires absolute pressures. |
There is likely your error. You forgot to change the pressure in both files, p and p_rgh to 1e5 in the initial field. You could use the zero in the transient solver as well as in the steady state one 1e5 though. It depends on your settings in thermoPhysicalProperties. If you set rhoConst there you are not solving for density and can hence use the normalized 0 pressure.
|
No I did that. I have p and p_rgh "1e5" for the transient (chtMultiRegionFoam) case. I had "0" for steady-state (chtMultiRegionSimpleFoam). And that is - I guess - why an initialization is causing more troubles than starting from scratch.
|
1 Attachment(s)
Attached is a log-File for a "pimple-like" run. I am currently re-running using 1e-4 timestep and piso and will post this log as well.
|
The obvious thing in your log file is the drastic temperature drop from iteration 1 onwards. A common error with these solvers. Usually due to poor turbulence modelling, here i am not sure though. You can use automatic time step selection in your controlDict.
Code:
maxCo 0.1; |
maxC0 0.1 only makes sence with PISO-like settings otherwise it may take years to run. However, it is also my first aim to get it running PISO-like (nOuterCorrectors=1).
momentumPredictor is off as this is the case in the tutorial es well. I am not really sure what it does but will turn it on. |
Hi guys,
just a few hints:
Good luck. |
1 Attachment(s)
Quote:
Quote:
Attached is a log-file where I did the following changes compared to the previous one:
Edit: so far I tried the following without success: 1. Reduce time-step from 1e-4 to 1e-5: Same behavior, calculation runs 5e-5s instead of 5e-4s 2. Increase nOutercorrectors from 1 to 2 to make use of under-relaxation (factor 0.5): Helps a little but not to much. |
Hi Bastil,
its a bit difficult to get any insight to your case and the physics behind that. The region named - kopf_al (I think its some aluminum block - engine?) and your water has a very low temperature. I guess it is fine right? The error you get is based on the Temperature evaluateion - recalculate T from h. This is based on the fact that some cell makes trouble. You can see it that your Co explodes to > 500 and thus, I think the velocity gets extreme high, the pressure drops and the evaluation in the thermodynamic model fails. What you could do:
|
Quote:
Quote:
Code:
Create polyMesh for time = 0 Quote:
Quote:
Quote:
|
I thought checking the mesh was to obvious of an answer. I am proven wrong once again. A nonOrthogonality of 90 is invalid. Getting a stable solution with a value of 87 is extremely challenging. checkMesh -allTopology -allGeometry will likely fail additional checks. I'd highly recommend creating a mesh that it is worth computing on. Because this is definitely a mesh problem. Changing the version won't do you any good in this case.
Otherwise you might want to increase nOuterCorr to something big like Tobias mentioned and use the same relaxation as in your simple solution. You can afterwards lower it. ResidualControl for automatically ending this loop however was only recently added by him. As he stated PIMPLE uses a Final flag in fvSolution. So relaxationFactors for the last loop would be hFinal for example. |
Ok. I will try to improve the mesh. What are the recommended limited for a transient chtMultiRegionFoam case?
|
All times are GMT -4. The time now is 19:52. |