[spaceprop]

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:

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

[sita]

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

[a.aralnu]

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?

[sita]

Sorry, no, as far as I recall I didn't find a solution for this (except probably not using renumberMesh, as you're suggesting)

[matejfor]

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.

[sita]

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.

[matejfor]

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?

[a.aralnu]

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.

[matejfor]

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.