how to partition the multiblock mesh

ztdep · January 21, 2015, 20:45

Dear friends:
Do we have algorithms to partition the multiblock structured mesh for the parallel computation. During the partition process, we should not destroy the structured property of the grid system.
Regards

mprinkey · January 21, 2015, 23:09

Maintaining the block structure will be hard and will impact your ability to precisely load balance and to minimize/balance the communication overhead among PEs. Your options are limited to subdivision of your existing blocks and (depending on your code) transposition of your coordinate axes.

The easiest approach is to walk through your blocks in order and split them into subblocks along the slowest coordinate axis. I don't know how to describe the algorithm easily. Here is worked example partitioning three blocks of different size across 4 PEs assuming the z-axis is the slowest index:

https://www.dropbox.com/s/e9ez2yvsir...oning.pdf?dl=0

If you have the ability to transpose axes, you should spin them to have the largest dimension along the slowest index direction. That gives you the finest granularity when doing the block subdivision and thus get you the most even per-PE cell counts.

I don't know if there is going to be any gain for you from generating subblocks by slicing in more than one dimension. I guess it will depend on how much overhead and bookkeeping comes with the creation of (many) more blocks. If per-block overhead is not prohibative and since multiblock codes are essentially unstructured with regard to block interfacing, you might be able to cut your blocks into many tiny subblocks and feed that subblock topology into METIS and thereby get a more parallel efficient partitioning.

Good luck.

January 21, 2015, 20:45	how to partition the multiblock mesh	#1
ztdep Senior Member p ding Join Date: Mar 2009 Posts: 427 Rep Power: 19	Dear friends: Do we have algorithms to partition the multiblock structured mesh for the parallel computation. During the partition process, we should not destroy the structured property of the grid system. Regards

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
[snappyHexMesh] Add Mesh Layers doesnt work on the whole surface	Kryo	OpenFOAM Meshing & Mesh Conversion	13	February 17, 2022 07:34
how to set periodic boundary conditions	Ganesh	FLUENT	15	November 18, 2020 06:09
[snappyHexMesh] SnappyHexMesh for internal Flow	vishwa	OpenFOAM Meshing & Mesh Conversion	24	June 27, 2016 08:54
[ICEM] Unstructure Meshing Around Imported Plot3D Structured Mesh ICEM	kawamatt2	ANSYS Meshing & Geometry	17	December 20, 2011 11:45
Icemcfd 11: Loss of mesh from surface mesh option?	Joe	CFX	2	March 26, 2007 18:10

January 21, 2015, 23:09		#2
mprinkey Senior Member Michael Prinkey Join Date: Mar 2009 Location: Pittsburgh PA Posts: 363 Rep Power: 25	Maintaining the block structure will be hard and will impact your ability to precisely load balance and to minimize/balance the communication overhead among PEs. Your options are limited to subdivision of your existing blocks and (depending on your code) transposition of your coordinate axes. The easiest approach is to walk through your blocks in order and split them into subblocks along the slowest coordinate axis. I don't know how to describe the algorithm easily. Here is worked example partitioning three blocks of different size across 4 PEs assuming the z-axis is the slowest index: https://www.dropbox.com/s/e9ez2yvsir...oning.pdf?dl=0 If you have the ability to transpose axes, you should spin them to have the largest dimension along the slowest index direction. That gives you the finest granularity when doing the block subdivision and thus get you the most even per-PE cell counts. I don't know if there is going to be any gain for you from generating subblocks by slicing in more than one dimension. I guess it will depend on how much overhead and bookkeeping comes with the creation of (many) more blocks. If per-block overhead is not prohibative and since multiblock codes are essentially unstructured with regard to block interfacing, you might be able to cut your blocks into many tiny subblocks and feed that subblock topology into METIS and thereby get a more parallel efficient partitioning. Good luck.