CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Meshing & Mesh Conversion

[mesh manipulation] renumberMesh causes solver divergence

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   October 24, 2018, 17:23
Default renumberMesh causes solver divergence
  #1
Member
 
Join Date: Jan 2014
Posts: 32
Rep Power: 10
spaceprop is on a distinguished road
I'm having a problem with the renumberMesh utility. My case is the simpleFoam motorBike benchmark case from this thread, which I've successfully run on about 10 different servers/clusters. However, whenever I try to use renumberMesh, the solver always diverges (floating point exception after ~5 steps). When I comment out the renumberMesh line, the run completes without error.

I use a script, but the basic process is:
Code:
surfaceFeatureExtract
blockMesh
decomposePar
snappyHexMesh -parallel -overwrite
restore0Dir -processor
renumberMesh -parallel -overwrite
checkMesh -parallel
simpleFoam -parallel
I found a few threads about renumberMesh causing poor orthogonality. One of the suggestions was to make the output format binary, but it already is binary, so that isn't it. Another was, if the output format is ascii, to increase the precision. I tried increasing that anyways even though it shouldn't matter for binary, and it didn't help. I also looked through all of the tutorials where renumberMesh is used, but I didn't find anything to suggest I was using it wrong.

np=80: The checkMesh's come out almost identical...only differences between the two logs is time, PID, and a magnitude 1e-17 change in max cell openness, both of which pass, so I don't think it's doing anything to make the cells bad. There is one fail in both: 23 highly skewed cells (max 6.657). My guess is that these are why omega doesn't converge and why the renumberMesh case fails, but if so, then shouldn't they cause the no renumberMesh case to fail, too? The checkMesh report for np=28 is similar.

renumberMesh (renum) and no renumberMesh (norenum) logs are attached for a np=80 case (4 nodes), and np=28 case (single node).

I've spent a few days trying to diagnose this one. Anyone else seeing this or have any ideas? Is there some trick to using renumberMesh? Thanks


System:
OF v1712
CentOS 7.5
MPI 3.1.0
Attached Files
File Type: gz logs80.tar.gz (63.2 KB, 3 views)
File Type: gz logs28.tar.gz (59.7 KB, 2 views)
spaceprop is offline   Reply With Quote

Old   June 26, 2019, 08:34
Default
  #2
Senior Member
 
Sita Drost
Join Date: Mar 2009
Location: Arnhem, The Netherlands
Posts: 223
Rep Power: 16
sita is on a distinguished road
Hiya,

I'm experiencing the same issue, see this post: Case diverges after running renumberMesh in parallel (sorry, I missed your post earlier).

Have you managed to find a solution yet?

Thanks,
Sita
sita is offline   Reply With Quote

Old   October 28, 2021, 21:25
Default
  #3
New Member
 
Arturo Alanís
Join Date: Oct 2021
Posts: 9
Rep Power: 3
a.aralnu is on a distinguished road
I just found out that my high non-orthogonality is due to using renumberMesh command after converting my mesh from fluent to openFoam... I've been struggling with this for a while now and I've the same issue with divergence in the continuity residuals...

Were you able to solve your problem? Should I stop using the renumberMesh utility?
a.aralnu is offline   Reply With Quote

Old   October 29, 2021, 02:19
Default renumberMesh causes solver divergence
  #4
Senior Member
 
Sita Drost
Join Date: Mar 2009
Location: Arnhem, The Netherlands
Posts: 223
Rep Power: 16
sita is on a distinguished road
Sorry, no, as far as I recall I didn't find a solution for this (except probably not using renumberMesh, as you're suggesting)
sita is offline   Reply With Quote

Old   November 22, 2021, 10:12
Default
  #5
Senior Member
 
matej forman
Join Date: Mar 2009
Location: Brno, Czech Republic
Posts: 181
Rep Power: 15
matejfor is on a distinguished road
Hi,

renumber mesh is only manipulating with the IDs of the mesh, it does not change or morph the mesh, so it cannot change the nonorthogonality. The goal of renumberMesh is to take the nonzero coifs in the matrix and reorganise them so they are closer and concentrated around the main diagonal of the matrix. In lame terms. It typically results in a smaller number of iterations of your PCG or GAMG solver on pressure. If it brings crash, it could be linked to some other problems of the mesh.
matejfor is offline   Reply With Quote

Old   November 22, 2021, 10:32
Default renumberMesh causes solver divergence
  #6
Senior Member
 
Sita Drost
Join Date: Mar 2009
Location: Arnhem, The Netherlands
Posts: 223
Rep Power: 16
sita is on a distinguished road
Thanks, yes, I know that in theory this is how renumberMesh is supposed to work. And as spaceprop points out in the initial post in this thread, the results of checkMesh between cases with and without renumberMesh are practically identical indeed. That's exactly why I was so surprised to find that renumberMesh seems to cause solver divergence in some cases, but apparently I'm not the only person having this issue.
sita is offline   Reply With Quote

Old   November 22, 2021, 11:57
Default
  #7
Senior Member
 
matej forman
Join Date: Mar 2009
Location: Brno, Czech Republic
Posts: 181
Rep Power: 15
matejfor is on a distinguished road
Are you still using 1712?
There were some bugs for parallel, but these were fixed before 1712.

Is it happening with 2106? Have you reported it to develop.openfaom.com?
matejfor is offline   Reply With Quote

Old   November 22, 2021, 12:54
Default
  #8
New Member
 
Arturo Alanís
Join Date: Oct 2021
Posts: 9
Rep Power: 3
a.aralnu is on a distinguished road
Yeah the problem I had is that my mesh was very fine near the boundary layer so the coordinates had very small numbers and I was working with ASCII and not binary files, I also had a 6 decimals precision which I increased. It seems that the problem is that if you don't have enough write precision the coordinates of the mesh get rounded off so it creates non orthogonality. After using .bin and more write precision renumberMesh worked correctly without changing the mesh quality.

Still I find that there's divergence in residuals when I use it so I stopped using it at all. It is slower but at least the solution converges.
a.aralnu is offline   Reply With Quote

Old   November 22, 2021, 18:18
Default
  #9
Senior Member
 
matej forman
Join Date: Mar 2009
Location: Brno, Czech Republic
Posts: 181
Rep Power: 15
matejfor is on a distinguished road
Binary is definitely a way to go.
When you do not renumber, the highest IDs will be in the largest refinement. Maybe we are hitting here some interesting point. Could you share the case or at least the details of the case so we could reproduce the error? Ideally can you report it at develop.openfoam.com? Then the developers may review and fix the rare yet occurring trouble and you help others as well. Otherwise it will sit here as a mysterious anecdote.
matejfor is offline   Reply With Quote

Reply

Tags
divergence, mesh, renumbermesh, snappyhexmesh

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Divergence detected in AMG solver: ads-0 Patrino FLUENT 6 May 12, 2022 04:11
Divergence in AMG solver! marina FLUENT 20 August 1, 2020 12:30
Error: Divergence detected in AMG solver siri FLUENT 8 March 12, 2018 18:08
AMG solver divergence; Mike FLUENT 17 December 14, 2015 14:01
Working directory via command line Luiz CFX 4 March 6, 2011 21:02


All times are GMT -4. The time now is 22:27.