CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Running, Solving & CFD

Mesh too big for memory. How to perform decomposition in parallel?

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

Like Tree3Likes
  • 1 Post By t.oliveira
  • 2 Post By Cyp

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   January 9, 2017, 18:08
Default Mesh too big for memory. How to perform decomposition in parallel?
  #1
Senior Member
 
Thomas Oliveira
Join Date: Apr 2015
Posts: 114
Rep Power: 11
t.oliveira is on a distinguished road
Hi,

I need to decompose a case to run it in many nodes because the mesh is too large for the memory of a single node. It is so large that running decomposePar in a single node is not possible.
How can I decompose the case in parallel, using distributed memory? Running decomposePar in parallel, if possible, would be a solution.

Best wishes,
Thomas

P.S.: A question like this was asked nine years ago. I am asking again because things may have changed since then.
t.oliveira is offline   Reply With Quote

Old   January 10, 2017, 04:30
Default
  #2
Senior Member
 
akidess's Avatar
 
Anton Kidess
Join Date: May 2009
Location: Germany
Posts: 1,377
Rep Power: 29
akidess will become famous soon enough
How did you generate the mesh? Can this be less memory consuming than the decomposition?
__________________
*On twitter @akidTwit
*Spend as much time formulating your questions as you expect people to spend on their answer.
akidess is offline   Reply With Quote

Old   January 12, 2017, 07:16
Default
  #3
Senior Member
 
Thomas Oliveira
Join Date: Apr 2015
Posts: 114
Rep Power: 11
t.oliveira is on a distinguished road
Dear Anton,

Indeed, your question makes sense. I have also had problems to generate the mesh using blockMesh. Since my geometry is sufficiently simple, I wrote a program which directly writes down the files points, faces, owner, neighbour and boundary without using OpenFOAM classes.

An alternative would be to write another program that write those files in processor* directories, but this would require investigating how decomposePar does so. Anyway, this alternative would not solve the problem for the cases in which I have had access to a large-memory machine when creating the mesh but that machine is not available anymore for decomposing it.

Best wishes,
Thomas
jeytsav likes this.
t.oliveira is offline   Reply With Quote

Old   January 12, 2017, 22:55
Default
  #4
Senior Member
 
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 1,273
Rep Power: 34
arjun will become famous soon enougharjun will become famous soon enough
Quote:
Originally Posted by t.oliveira View Post
Dear Anton,

Indeed, your question makes sense. I have also had problems to generate the mesh using blockMesh. Since my geometry is sufficiently simple, I wrote a program which directly writes down the files points, faces, owner, neighbour and boundary without using OpenFOAM classes.

An alternative would be to write another program that write those files in processor* directories, but this would require investigating how decomposePar does so. Anyway, this alternative would not solve the problem for the cases in which I have had access to a large-memory machine when creating the mesh but that machine is not available anymore for decomposing it.

Best wishes,
Thomas
I actually wrote an oct tree based mesh generator that uses hard disk memory and generated 150 million cell mesh using only 2GB ram laptop. So mesh generation without partitioning is possible.

I am surprised to learn that openFOAM does not do paritioning in parallel. In FVUS I do parallel partitioning using par metis but when i was porting the solver for windows par metis no longer reliably available and thus had to write partitioner myself. Since I am no expert the partitioner is serial only. I put it there very reluctantly because that was one step that handicapped the solver for large meshes and felt very bad about it.

openfoam is out there for years so its surprising.
arjun is offline   Reply With Quote

Old   January 13, 2017, 03:16
Default
  #5
Senior Member
 
akidess's Avatar
 
Anton Kidess
Join Date: May 2009
Location: Germany
Posts: 1,377
Rep Power: 29
akidess will become famous soon enough
Quote:
Originally Posted by arjun View Post
openfoam is out there for years so its surprising.
Not that surprising. I guess 90% of all users either have relatively small meshes or use parallel meshing (snappyHexMesh). Did any of your FVUS customers complain about your partitioner being serial only?
__________________
*On twitter @akidTwit
*Spend as much time formulating your questions as you expect people to spend on their answer.
akidess is offline   Reply With Quote

Old   January 13, 2017, 06:45
Default
  #6
Senior Member
 
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 1,273
Rep Power: 34
arjun will become famous soon enougharjun will become famous soon enough
Quote:
Originally Posted by akidess View Post
Not that surprising. I guess 90% of all users either have relatively small meshes or use parallel meshing (snappyHexMesh). Did any of your FVUS customers complain about your partitioner being serial only?

No so far no-one complained. But all the people who are doing serious work using linux version that is parallel partitioning. Most people using it for VOF and multiphase so big sizes are avoided as much as possible. (There is someone going to try on more than 50 million cell cases but that would be in april).

Even on windows the only step which is serial is the partitioning part so only that graph structure that is used for partitioning is serial (that is collected on root process). Rest of the solver is parallel. That means FVUS loads the mesh into partitions user is running solver on, then partitioning is performed (serial on windows and parallel on linux) and redistribution takes place. Solver then continues.

Because only one graph structure is serial only the size of meshes user can run still be much higher than openFOAM.
arjun is offline   Reply With Quote

Old   January 13, 2017, 17:41
Default
  #7
Cyp
Senior Member
 
Cyprien
Join Date: Feb 2010
Location: Stanford University
Posts: 299
Rep Power: 18
Cyp is on a distinguished road
one solution is to create a coarse background grid (with blockMesh), then to decompose the domain on X CPUs and refine the background grid in parallel with refineMesh. Then you can use snappyHexMesh in parallel.
acgnipper and t.oliveira like this.
Cyp is offline   Reply With Quote

Old   July 20, 2017, 06:42
Default decomposing seperat file after the decomposition process
  #8
Member
 
Mohamed Elghorab
Join Date: May 2016
Location: Coventry, Engalnd
Posts: 41
Rep Power: 9
crazzy.pirate43 is on a distinguished road
Quote:
Originally Posted by arjun View Post
No so far no-one complained. But all the people who are doing serious work using linux version that is parallel partitioning. Most people using it for VOF and multiphase so big sizes are avoided as much as possible. (There is someone going to try on more than 50 million cell cases but that would be in april).

Even on windows the only step which is serial is the partitioning part so only that graph structure that is used for partitioning is serial (that is collected on root process). Rest of the solver is parallel. That means FVUS loads the mesh into partitions user is running solver on, then partitioning is performed (serial on windows and parallel on linux) and redistribution takes place. Solver then continues.

Because only one graph structure is serial only the size of meshes user can run still be much higher than openFOAM.
Hi,

As you are talking about the decomposition process I have a problem here, I'm preparing a new boundary condition but it refuse to be decomposed during the decompsePar so I have to redistribute it manually for all processors , is there any way to use specific command to distribute it directly or I have to paste it in each processor manually:

Thanks in advance
crazzy.pirate43 is offline   Reply With Quote

Reply

Tags
decomposepar, decomposition, mesh, parallel decomposition

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
Reconstruction of the parallel case with dynamic mesh makaveli_lcf OpenFOAM Post-Processing 7 October 18, 2023 11:28
sliding mesh problem in CFX Saima CFX 46 September 11, 2021 07:38
decomposePar problem: Cell 0contains face labels out of range vaina74 OpenFOAM Pre-Processing 37 July 20, 2020 05:38
[snappyHexMesh] snappyHexMesh won't work - zeros everywhere! sc298 OpenFOAM Meshing & Mesh Conversion 2 March 27, 2011 21:11
[snappyHexMesh] external flow with snappyHexMesh chelvistero OpenFOAM Meshing & Mesh Conversion 11 January 15, 2010 19:43


All times are GMT -4. The time now is 23:38.