|
[Sponsors] |
simpleFoam: divergence after resuming a converged job |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
January 13, 2016, 08:37 |
simpleFoam: divergence after resuming a converged job
|
#1 |
Member
Pascal Balz
Join Date: Feb 2015
Location: Germany
Posts: 44
Rep Power: 11 |
Hi,
I'm simulating a rather complex geometry with four inlets and three outlets. The mesh consists of four separate regions connected via ACMI interfaces to couple them. The reason for this is that snappy couldn't mesh the whole region all in one (I tried a lot!) so I had to mesh separate regions and connect them. Anyway, as the geometry is complex the mesh is not the best but OK and it should run quite good. For the steady solution I use simpleFoam. With low velocity boundary conditions (< 10 m/s) it converges and yields physical results. With high BC (which I need) simpleFoam diverges which seems OK... I didn't expect a converged solution straight away. So my idea was to get an initial converged solution and stepwise increase the boundary condtions, then resume the calculation and repeat, up to the desired values until I get a fully converged solution. Well, it turned out to be slightly harder than that... The main problem is the following: When I just resume the converged simulation without any changes, the simulation will blow up within the next few timesteps. Always. I never got such a weird behavior on other cases, so my initial guess is that something with the ACMI Patches is not working as intended. Is this a known bug or does anybody have an idea on how to solve this problem? A workaround would also work as I really need to get this simulation running. Unfortunately, I can't upload the case or give you detailed information because of a non-disclosure agreement. But I can surely provide several logs if this is beneficial for solving my problem. Any help would be greatly appreciated! Thanks!
__________________
Regards, Pascal |
|
January 14, 2016, 03:28 |
|
#2 |
Senior Member
Anton Kidess
Join Date: May 2009
Location: Germany
Posts: 1,377
Rep Power: 30 |
Can you use mergeMeshes to produce a single region instead of ACMI?
__________________
*On twitter @akidTwit *Spend as much time formulating your questions as you expect people to spend on their answer. |
|
January 14, 2016, 06:18 |
|
#3 |
Member
Pascal Balz
Join Date: Feb 2015
Location: Germany
Posts: 44
Rep Power: 11 |
I've tried that and unfortunately it's not possible. The main reason is that snappyHexMesh really isn't that accurate when it comes to catching feature edges+surfaces. So the "interfaces" are not 100% coincident and have different resolutions.
It's just a pain in the ass to achieve perfect matching interfaces with snappy for complex geometries (I would say it's impossible). So that's the reason why I'm using ACMIs, because "normal" AMIs don't account for unconnected faces. Btw, I've attached the checkMesh log so that you get a rough idea of the mesh. [I had to rename the patches, sorry!].
__________________
Regards, Pascal |
|
January 14, 2016, 08:56 |
|
#4 | |
Senior Member
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 1,290
Rep Power: 34 |
Quote:
To check this issue create a simple case, converge it and resume. If you see jump in continuity residual then this might be the main issue causing problem. |
||
January 19, 2016, 09:53 |
|
#5 |
Member
gereksiz
Join Date: Mar 2015
Posts: 42
Rep Power: 11 |
Actually it happened to my cases a couple of times. I was running some cases and they were killed because I didn't have enough disk space. Then I resubmit the case from the latest iteration I had, but meanwhile I kept the log file for the older one. Anyway then I let it run for a while, and killed it because it diverged.
Then I compared two log files for the residuals and I saw that after I resubmit the case residuals started to increase while in the older case kept decreasing at the same iterations. Afterwards I tried to see if I did something wrong, then it happened in exactly same way, residuals started to increase when I resubmit the case. Anyway I didn't think about it a lot, maybe I did something wrong and I didn't notice, though I have no idea what I can do wrong, it's the same case, same folders etc. But in my case there wasn't anything comples, it was just a simple flat surface with simpleFoam. From that day if something happens and my case is killed, I always restart it from zero, but I have literally no idea. |
|
January 19, 2016, 10:11 |
|
#6 | ||
Member
Pascal Balz
Join Date: Feb 2015
Location: Germany
Posts: 44
Rep Power: 11 |
Hi,
Quote:
It appears to happen with some cases but not all, i.e. interDyMFoam cases (just to test other solvers as well) work quite good. Quote:
For sure this issue is well known to the developers too but maybe there is some reason why it's not that simple to fix... Does anyone have a clue?
__________________
Regards, Pascal |
|||
January 19, 2016, 10:26 |
|
#7 |
Member
gereksiz
Join Date: Mar 2015
Posts: 42
Rep Power: 11 |
I don't think it's a general problem, because even in some tutorials first you get a solution from potentialFoam to convergence your case easier. It's more or less the same thing. Actually until I read this, I was quite sure that I did something stupid and didn't notice.
I know it sounds quite silly, but did you try to change your folder's name from #latestiteration to zero. |
|
January 19, 2016, 13:23 |
|
#8 | |
Senior Member
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 1,290
Rep Power: 34 |
The issue is that there are two component to flux.
One due to velocitz and density. Second due to rhie and chow. First part could be constructed from given data, second part however requires you to know Ap of velocity and pressure gradient. This part is mainly omitted in many solvers because in theory in a converged case goes to 0. In practice it is not zero but small. My suggestion would be to run first very few iterations with very small pressure urf. Say 0.01 or so. (Dont touch momentum urf , keep as it is). If it is a transient case, increase number of inner iterations and use very small pressure urf. This should give solver time to recover and make fluxes better. Quote:
|
||
January 22, 2016, 07:14 |
|
#9 |
Member
Pascal Balz
Join Date: Feb 2015
Location: Germany
Posts: 44
Rep Power: 11 |
Hi Arjun,
thanks for your reply! I will try as you suggested.
__________________
Regards, Pascal |
|
September 7, 2016, 04:43 |
rhie and chow unreconstructable flux component
|
#10 | |
Member
Giovanni Caramia
Join Date: Mar 2009
Location: Bari, ITALY
Posts: 58
Rep Power: 17 |
Hi Arjun,
could you better explain what you mean when you say that there is a part of the flux due to Rie and Chow not reconstructable? Eventually suggesting references. Thank you! Quote:
|
||
September 8, 2016, 10:17 |
|
#11 | |
Member
Giovanni Caramia
Join Date: Mar 2009
Location: Bari, ITALY
Posts: 58
Rep Power: 17 |
I also tried to reduce pressure urf modifying fvSolution file but I did not notice any change.
So I would like to ask you what file and how you would change it to reduce the pressure urf. Thank you. Quote:
|
||
September 20, 2016, 02:10 |
|
#12 | |
Senior Member
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 1,290
Rep Power: 34 |
Quote:
My advice was for trying to construct flux without disturbing pressure. Someone from openfoam shall really look into it. |
||
September 20, 2016, 02:15 |
|
#13 | |
Senior Member
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 1,290
Rep Power: 34 |
Quote:
For construction of flux you will need velocity, pressure gradient and Ap var (diagonal of velocity matrix). Usually Ap variable is not stored. So even if it is stored one need to construct the fluxes after file is restored. But if fluxes are saved and restored then there shall be no problem. |
||
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[ANSYS Meshing] Help with element size | sandri_92 | ANSYS Meshing & Geometry | 14 | November 14, 2018 08:54 |
Unable to get converged solution using SimpleFoam | jr33 | OpenFOAM Running, Solving & CFD | 6 | December 12, 2016 05:48 |
SimpleFoam converged but results not acceptable | MartinBlx | OpenFOAM Running, Solving & CFD | 7 | September 2, 2015 13:18 |
Divergence problem | Smaras | FLUENT | 13 | February 21, 2013 06:03 |
Divergence in simpleFoam | LB_K | OpenFOAM Running, Solving & CFD | 3 | December 14, 2011 21:01 |