## 2.4. Parallelization of Contact Interactions

To understand how contact interactions are parallelized, we must first understand how the algorithm works in serial calculations.

Contact logic is used when one surface element of a part attempts to penetrate another surface element of the same or a different part. This requires a global search of Cartesian space to find possible contacts. Using the same sub-domain decomposition used for the grid calculation is not an efficient way to parallelize contact interactions. This is because the contact surfaces that need to be processed come from elements that lie on the surface of a part and thus make up only a subset of the total elements in the part. It is easy to see that some sub-domains might contain many surface elements, while others none at all. Moreover, if a calculation allows the erosion or removal of elements as penetration occurs, the actual surface elements of a part will change as the calculation proceeds. We are therefore forced to use a second, dynamic domain decomposition of Cartesian space for the contact calculations.

Generally, any two surface elements anywhere in the simulation can come in contact with each other during some time step, even those that belong to the same object (self-interaction). Checking for all such contacts requires a global search in Cartesian space that in practice can take up to 50% of the overall CPU time. For efficiency, the contact nodes and faces are spatially sorted to speed this computation and to avoid unnecessary tests of distant elements. Thus, the contact algorithm used in Autodyn can be considered in two parts. Firstly, a calculation is performed to identify neighboring nodes/faces that require to be checked for interaction. Secondly, a detailed interaction calculation is performed for all these identified nodes/faces.

Determining which nodes/faces require to be checked for interactions is achieved with a bucket-sort. A grid of virtual work units is defined in Cartesian space. Each work unit is a cube, with sides twice the smallest face dimension of all interacting faces. In tests, this cube size was found to not only yield the most efficient computing times (due to the fine sort), but also to generate sufficient work units to allow efficient load-balancing for the parallelization. These work units are virtual because storage for a particular work unit is only allocated when it is determined that the work unit contains nodes/faces that are to be tested for interaction.

The bucket-sort loops over all the surface nodes and faces of a problem, and constructs a list of the actual work units required for a particular analysis. The sort is performed in two passes, in which all the nodes are sorted, and then the faces are sorted. First, each surface node is added to the work unit, which contains it. Next, each surface face is added to all work units, which contain nodes that might interact with the face. This is determined by checking each node of the face to see if it is contained within, or is in close proximity to, a work unit’s domain. At this stage, only work units that already contain surface nodes are considered. The proximity test is based on the size of the contact detection zone used for the interaction logic and the amount of “slack” allowed enabling the calculations described here to be performed less frequently than every cycle.

Finally, the node and face tables built for each work unit in the list are examined to determine the total number of node/face interactions that will be required to be computed for the work unit (this number is used to facilitate load-balancing in the parallel version). In general, this will equal the total number of nodes in the work unit times the total number of faces. However, this can be reduced if, for example, self-interaction of a part with itself is not permitted, or two parts have been specified not to interact with each other. If the total number of interactions required to be computed for a work unit is found to be zero, then the work unit is removed from the list.

At the end of this procedure a compact group of work units has been generated, each containing a list of surface nodes and faces that require testing for interaction. Each node has been uniquely assigned to a particular work unit. Faces have been assigned to multiple work units, as required. These lists may be valid for a number of computational cycles, depending on the proximity test used to determine potential node-face interactions and on changes in surface definitions (if an element is eroded or removed, surfaces need to be redefined).

Within each work unit, detailed interaction calculations are performed between the nodes and faces in each work unit list. The calculation is very robust in that every impact is detected and dealt with correctly regardless of the deformation and relative movement of bodies or changes in surface definitions

Parallelization of the contact algorithm described above is fairly straightforward. Once the work units containing the node and face lists to be tested for impact have been generated, a load-balancing algorithm efficiently distributes them among the available CPUs, assuming each CPU has either the same speed or a pre-determined relative speed provided by the user. The data decomposition used for the contact interaction calculation is different from the one used for the grid calculation, so the load-balancing algorithm attempts to minimize the inter-CPU communications required between these two decompositions. Although a static decomposition is used for the grid calculation, a dynamic decomposition has to be used for the contact calculation. Consequently, load balancing of the newly formed work units is performed for each cycle on which a sort is carried out. This allows contact calculations to remain well load-balanced even when surfaces are reconfigured as the simulation progresses, or during the erosion (removal) of elements.

Results have shown that the contact algorithm generates sufficient work units during the sort phase to allow efficient load balancing for parallel processing. Furthermore, the scheme uses simpler communication patterns than those that rely on recursive coordinate bisection (RCB) to assign equal amounts of nodes to all CPUs, and adapts well to heterogeneous systems where CPUs may have different speeds and workloads that may vary with time.

Release 18.2 - © ANSYS, Inc. All rights reserved.