Ana Gainaru Aparna Sasidharan Babak Behzad Jon Calhoun Collision Detection Ana Gainaru Aparna Sasidharan Babak Behzad Jon Calhoun

Collision Detection

Reference Application - Phdmesh Miniapp from Sandia National Laboratory Provides in-memory support for parallel, heterogeneous, dynamic, unstructured meshes Octree based geometric proximity detection algorithm Application self load balance after each iteration

Openmesh Heterogeneous mesh library Explicit representation of edges, vertices, and faces in the half-edge data structure Proven Efficiency Openmesh

2 Charm++ C O L I D E Phase Algorithm Voxel Based Broad Narrow Maybe add “Charm RTS load balanced” Broad Narrow C O L I D E

Algorithm Generate separate mesh for each gear with two types of mesh elements hexahedrons(volume) quadrilaterals(surface) METIS partitions the elements among chares after converting the meshes into their respective dual graphs. Each chare gets a set of mesh elements The number of elements per chare is almost the same

Algorithm Cont’d Rotate the gears to complete 360 degrees in 120 steps. After each step, perform proximity search using charm collide. The average time taken by charm collide for each iteration is determined. Visualize simulation using LiveViz/Blender

Metis Metis is a software package for partitioning large irregular graphs and partitioning large meshes Based on multilevel graph partitioning METIS can be used to partition based on vertices or on faces

METIS cont’d Input mesh stored in the form of an element node array A n element mesh is stored in a plan text file with n+1 lines describing the mesh’s size, type, and nodes that make up each element First converts the mesh into a dual graph Each element becomes a graph vertex Used METIS_PartMeshDual to partition the mesh into k parts based on the partitioning of the mesh’s dual graph

Visualization

Phdmesh on Taub We could compile and run phdMesh on Taub in order to do comparison Although maybe the comparison is not fair as the contact detection algorithms are different In order to compile phdMesh we needed to compile TPI(Thread Pool Interface) from the Trilinos project of SNL. After compiling TPI we compiled phdMesh and its test programs: Gears In terms of code productivity and how the codes look like, Charm is much better than the MPI. In terms of performance, does it make sense to compare them?

Simulations We measured the performance of our charm++ implementation by increasing the number of gears(input data) and the number of cores proportionately. We chose the number of chares to be four times the number of processors. Each chare gets a certain number of surfaces which are then used by charm collide. Since METIS partitions the surfaces equally, each chare gets approximately the same number of surfaces.

Simulations(contd.)

Simulations(contd.)

Future Work Compare with Octree-based algorithm (used by PhdMesh) Different sized gears and bounding boxes Invoke Charm++ load balancer and compare performance

Impact of CHArm++ Productivity- smaller code size, async reductions New ideas like LiveViz Overdecomposition – Don’t think about the processors Lack of documentation ex: LiveViz3D, Charm Collide

Thank you. Any ?