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

[mesh manipulation] cells ordering influence on solution

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

Like Tree1Likes
  • 1 Post By wyldckat

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   October 27, 2018, 14:55
Default cells ordering influence on solution
  #1
Senior Member
 
Ahmed Khattab's Avatar
 
ahmed
Join Date: Feb 2010
Posts: 182
Blog Entries: 1
Rep Power: 14
Ahmed Khattab is on a distinguished road
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,
Ahmed Khattab is offline   Reply With Quote

Old   October 27, 2018, 18:53
Default
  #2
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,965
Blog Entries: 45
Rep Power: 126
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
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.
Ahmed Khattab likes this.
__________________
wyldckat is offline   Reply With Quote

Old   December 22, 2020, 09:14
Default
  #3
New Member
 
pardoa
Join Date: May 2018
Location: Neuchâtel, Switzerland
Posts: 27
Rep Power: 6
pardoa is on a distinguished road
Quote:
Originally Posted by wyldckat View Post
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
pardoa is offline   Reply With Quote

Old   May 6, 2021, 11:51
Default renumberMesh FATAL ERROR
  #4
New Member
 
Join Date: Apr 2021
Posts: 28
Rep Power: 3
AlxB is on a distinguished road
Hello,
here is my Allrun file:

Code:
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:
Code:
[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
AlxB is offline   Reply With Quote

Old   May 7, 2021, 01:18
Default
  #5
Senior Member
 
M
Join Date: Dec 2017
Posts: 432
Rep Power: 9
AtoHM is on a distinguished road
Leave the -overwrite option out? Maybe it has been deprecated.
AtoHM is offline   Reply With Quote

Old   May 10, 2021, 03:57
Default renumberMesh FATAL ERROR size is not equal to the given value
  #6
New Member
 
Join Date: Apr 2021
Posts: 28
Rep Power: 3
AlxB is on a distinguished road
many thanks AtoHM,

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

Code:
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:

Code:
// 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 ?
AlxB is offline   Reply With Quote

Reply

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
[snappyHexMesh] Snappy creates strange cells far away from boundary vainilreb OpenFOAM Meshing & Mesh Conversion 3 December 16, 2020 05:11
[snappyHexMesh] snappyHexMesh does not create any mesh except one for the reference cell Arman_N OpenFOAM Meshing & Mesh Conversion 1 May 20, 2019 17:16
[snappyHexMesh] sHM layer process keeps getting killed MBttR OpenFOAM Meshing & Mesh Conversion 4 August 15, 2016 03:21
[snappyHexMesh] snappyHexMesh Segmentation Fault avd28 OpenFOAM Meshing & Mesh Conversion 11 May 11, 2015 20:32
snappyHexMesh in parallel - FOAM Fatal IO Error mturcios777 OpenFOAM Running, Solving & CFD 4 August 10, 2012 19:18


All times are GMT -4. The time now is 03:33.