next up previous
Next: Submitting jobs to the Up: latex2html_globus Previous: MecaGRID efficiency using 64

Mesh partitioners for Grid calculations

The AERO-F and the AEDIF codes both use MPI to parallelize the calculation over partitions (or domains), one processor for each partition. Therefore the mesh partitioner is an integral part of the parallel method. This study uses the mesh partitioner developed at the CEMEF by Digonnet [#!hugues!#] with recent developments by Lanrivain [#!rodolphe!#] accomplished during a 2003 internship in the SMASH project at INRIA. These developments included an heterogeneous partitioning option and file formats directly readable by the AEDIF and AERO-F codes. The CEMEF Mesh Partitioner is executed on the INRIA cluster with the following command:

./MeshPartitionerSTD.lsf sinus.mtc ncpu

where sinus.mtc is the mesh to be partitioned and ncpu the number of processors (equals the number of partitions). STD denotes the standard script (1 CPU/Partition). The mesh partitioner input file is of the type ".mtc." The sinus.mtc is created using a SINUS2MTC interface (./SINUS2MTC fluid.sinus) where fluid.sinus is the mesh to be partitioned written in the "sinus" format.

Partitioning using the MeshPartitionerSTD.lsf script is satisfactory as long as the number of partitions is small. If the number of partitions is large, long wait times may occur before obtaining say 64 processors. For partitions > 70 this form of the mesh partitioner cannot be used as the maximum number of processors available at INRIA is 70 (1 CPU/partition). Two forms of the standard MeshPartitionerSTD.lsf script are shown below:

bsub -n $2 -m "linux-nina linux-pf" mpijob meshmig_homo $1

bsub -n $2 -m "linux-nina linux-pf" mpijob meshmig_grille $1

where $1 is the sinus.mtc file and $2 the number of processors. The script using the meshmig_homo executable returns partitions of equal size (homogeneous) whereas the script using the meshmig_grille creates partitions based on the speed of the processors (heterogeneous), thus partitions using nina processors would be two times larger than INRIA-pf partitions reflecting the fact that the processor speeds for nina and INRIA-pf are 2 Ghz and 1 Ghz respectively. The heterogeneous partitions result in load balancing with respect to processor speed and should increase the overall performance.

In order to create a large number of partitions (superior > 70 processors) and/or not encounter large wait times, an alternative script was written.

./MeshPartitioner_II.lsf ncpu npartitions

where ncpu is the number of processors to be used, and npartitions the number of partitions. The MeshPartitioner_II.lsf submit script looks like:

bsub -m "linux-nina linux-pf" -n $1 mpijob MeshInterface.x $2

where $1 is the ncpus to be used and $2 the number of partitions. The MeshPartition_II.lsf script submits a job using ncpu processors. MeshInterface.x determines the hostnames of the processors, writes a mymachinefile.LINUX file to be used by the mesh partitioner and executes the actual partitioning script. Each processor appears in the mymachinefile.LINUX file npartitions/ncpu times (thus it is important that npartitions be a multiple of the ncpus). The partitioning script is:

mpirun -machinefile mymachinefile.LINUX -np $1 meshmig_homo fluid.mtc

Table 22 shows some of the Mesh Partitioner results using both methods to partition meshes. The mesh partitioner performs iterations until equal size partitions (homogeneous) or heterogeneous (optimized) partitions are obtained.



Table 22: 1.03M mesh: Mesh Partitioner homogeneous results
Partitions script Machines CPUs time Iterations
16 MeshPartioner_II.lsf 4-nina 4 0:43 13
24 MeshPartionerSTD.lsf 24-pf 24 1:03 18
48 MeshPartioner_II.lsf 16-nina 16 0:43 20
60 MeshPartioner_II.lsf 18-nina 2-pf 20 0:53 22
62 MeshPartioner_II.lsf 20-nina 11-pf 31 0:59 28
64 MeshPartioner_II.lsf 32-nina 32 1:02 30



next up previous
Next: Submitting jobs to the Up: latex2html_globus Previous: MecaGRID efficiency using 64
Stephen Wornom 2004-09-10