[Ahmed Khattab]

Dear Foamers,

as far as i know,

1- cells are ordered in OpenFOAM based on axis directions.

i.e. cell number zero is the cell at the origin then number one next to it at x-axis and so on until the end of the mesh in x-axis, then cell ordering continues from the cell next to cell zero in y-axis and along x-axis until finishing of plan xy. another layer is added in z-axis starting from the cell over the cell zero and so on.

2- axes (xyz) are specified by how we order vertices when writing blocks
my questions are:

1- my guess is that solvers starts to solve cell zero then cell one and so on. am i right?

2- has the way we specify our axes (xyz) "and how OpenFOAM order cell consequently" any influence on the results we get from OpenFOAM?

thanks,

[wyldckat]

Quick answer: The way that OpenFOAM handles unstructured meshes is pretty much the same way as a structured mesh generated with blockMesh. This to say that it doesn't matter the ordering of the cells regarding the final solution... or at least it could potentially have a very small difference in the results, given that the way things are solved is by iterating...

However, an incorrectly ordered mesh can have a tremendous impact on CPU time, because of memory accesses. Using renumberMesh is advised to be executed either in serial or parallel mode, but don't forget to use the "-overwrite" option if you want to keep the new organized mesh as the default for the current case.

If you run renumberMesh, you will get a value for the number of cells on the band of the matrices... this value can reduce considerably and will improve performance greatly, possibly from 3-10 times faster run-time.

[pardoa]

Originally Posted by wyldckat

Quick answer: The way that OpenFOAM handles unstructured meshes is pretty much the same way as a structured mesh generated with blockMesh. This to say that it doesn't matter the ordering of the cells regarding the final solution... or at least it could potentially have a very small difference in the results, given that the way things are solved is by iterating...

However, an incorrectly ordered mesh can have a tremendous impact on CPU time, because of memory accesses. Using renumberMesh is advised to be executed either in serial or parallel mode, but don't forget to use the "-overwrite" option if you want to keep the new organized mesh as the default for the current case.

If you run renumberMesh, you will get a value for the number of cells on the band of the matrices... this value can reduce considerably and will improve performance greatly, possibly from 3-10 times faster run-time.

Hello Bruno,

This is an old post but I wonder if you could still help to figure out the impact that the number of blocks that define the mesh has in the CPU time. I wish to simulate a curved channel and, therefore, I cannot define my grid with just one hexahedral block but with several ones along the longitudinal axis, i.e., if my resolution in the longitudinal direction is 0.25 m and total length 10 m, I will define the mesh with 40 hex blocks.

To test the effect that the number of blocks have in the wall time, I generated two straight channel: one formed by one block and another of ten blocks. The first completes the simulation way faster than the second, even using renumberMesh. So it seems that the number of blocks do affects the CPU time. Is there a way to use just one block even when the aim mesh is irregular? Thanks for the help!

Álvaro

[AlxB]

Hello,
here is my Allrun file:

runApplication decomposePar -copyZero

runParallel checkMesh -meshQuality

runParallel renumberMesh –overwrite

runParallel patchSummary

runParallel potentialFoam

runParallel $(getApplication)

runApplication reconstructParMesh -constant
runApplication reconstructPar -latestTime

However the renumberMesh doesn't work in that case. Here an extract of its log:

[0] --> FOAM FATAL ERROR: 
[0] Wrong number of arguments, expected 0 found 1

would anyone have an idea of what is wrong here ?

many thanks in advance for helping

[AtoHM]

Leave the -overwrite option out? Maybe it has been deprecated.

[AlxB]

many thanks AtoHM,

without '-overwrite' it now gives something but it's still not correct:

Create time

Create mesh for time = 0

Mesh size: 3625849
Before renumbering :
    band           : 2153597
    profile        : 1.25091e+11

Renumber according to renumberMeshDict

Selecting renumberMethod CuthillMcKee

Reading geometric fields

Reading volScalarField Co


--> FOAM FATAL IO ERROR: 
size 3657601 is not equal to the given value of 3625849

I have tried to set a local renumberMeshDict file in System in which I have changed writeMaps from true to false:

// Write maps from renumbered back to original mesh
writeMaps	false; // true;

unfortunately this hasn't change anything

do you have any idea where the problem could come from ?