Pages 1 | 2 » 
Figure 1: Parallel processing divides a model into small domains. Here, the colored regions are subdomains that are distributed among the individual cores of the cluster for analysis. A single domain or many domains can be placed on individual cores, depending on the application. To be effective, the domains must be solvable as individual pieces. (Image courtesy of ANSYS Inc.) | Parallel processing — the simultaneous use of more than one CPU on a single application — is one of the key advantages of cluster-based high-performance computing (HPC) systems. In theory, the more processors in a cluster, the faster the system can solve a problem. To take advantage of this feature, CAE software must be able to scale. In other words, the software must be able to break the problem down into smaller and smaller pieces and then distribute those application components among the individual computing processors (see Figure 1, right). Parallel processing on these systems has enabled engineers to take on bigger problems and do more detailed simulations than they could in the past, so the potential of this functionality has become a driving force in the software community. “Multi-core systems have upped the ante,” says Barbara Hutchings, director of partner relations at ANSYS. “It’s made parallel processing more available to our customers and increased the pressure on software vendors to ensure that we’re doing everything we can to keep the scaling story improving over time.” At this stage of the technologies’ development, however, it’s important to keep in mind that not all types of CAE software scale equally well. The ability of the various flavors of software to scale is determined by a number of factors, such as the mathematical formulations used, complexity of the application, and level of interprocessor communications. Doing the Math
The numerical solution schemes of CAE software fall into two categories: implicit and explicit. When dependent variables are defined by coupled sets of equations and either a matrix or an iterative approach is required, the numerical solution is implicit. When the variables are defined in terms of known quantities, the approach is considered explicit. 
Figure 2: The equation matrix for implicit structure analysis is a sparse matrix (it is populated primarily with zero coefficients). However, the remaining terms are not diagonal, which therefore require a form of Gaussian elimination or direct method to solve. The explicit form does not require Gaussian elimination and is easier to implement. (Image courtesy of ANSYS Inc.) | For example, finite element analysis (FEA) software uses both mathematical approaches. In an implicit solution scheme, you build a large finite element model represented by large matrices, which can consist of tens of millions of rows and columns. These matrices represent the behavior of parts and assemblies of the parts in an operating environment. If you have a complete aircraft structure, its parts are represented mathematically by large matrices. If you apply a load or any kind of operating condition on a part, the mathematical formulation can determine the response to the operating conditions. Explicit technology uses different mathematics. In this type of solution scheme, you have small-element, localized matrix problems that you have to solve as you go along (see Figure 2, left). This type of software is used primarily to describe short-duration events, such as those found in impact or crash analysis. Most mainstream FEA software relies on implicit mathematics, but in some cases, when you’re solving time-dependent, nonlinear problems, you use explicit methods. By and large, FEA software is built on implicit codes, which do not scale as well as software using the explicit approach. “Generally speaking, the algorithms and mathematics used in explicit software scale somewhat better than implicit software,” says Peter Mendoza, director of solutions marketing at MSC.Software. The mathematics used by a CAE software program has a definite effect on its scalability. It is, however, neither the sole determining factor nor the primary influence. Even more important is the complexity of the application. Degrees of Freedom
Not all types of CAE software scale equally well. One reason for this is the fact that the physics involved in each discipline do not have the same degree of difficulty. This can be seen in the meshing process, when the software discretizes a continuous domain into a set of discrete sub-domains, called elements. 
Figure 3: This normal mode analysis (natural frequency calculation) of a car body model with ~268,000 nodes was performed on a 64 dual core (1.85GHz) CPU cluster. The graphs show computation time and natural frequencies. The finite element model included ~275,000 finite elements and 1.6 million degrees of freedom. The results indicate that the analysis scales reasonably well (20x speedup) up to 64 processors. (Image courtesy of Siemens PLM Software) | During this process, the software transfers or converts continuous models and equations into discrete counterparts. It approximates the solution of a continuous problem by representing discrete solution quantities. An example of this would be the representation of a continuous fluid volume with a set of grid points representing a sum of basic functions. At this point, the software describes the individual components, or finite elements — basically defining the physics of each element. It’s here that the disparity of complexity of the various CAE disciplines becomes apparent, with widely varying degrees of freedom coming into play. A degree of freedom represents an independent variable in an element. The independent variables allow for changes, and the number of degrees of freedom in an element is determined by the number of components and their interactions. This is where the ability of the various CAE disciplines to scale diverges. Consider the ability of structural, or FEA, software (see Figure 3, above) and that of computational fluid dynamics (CFD) programs (see Figure 4, below). “Describing the physics in CFD solutions is simpler than describing the physics in a structural solution,” says Louis Komzsik, chief numerical analyst in the office of architecture and technology at Siemens PLM Software. “The physical phenomenon is simpler to describe in numerical terms. With FEA, the physical phenomenon you analyze requires multiple degrees of freedom in each node of the mesh. When you analyze a fluid phenomenon, you may have only a single degree of freedom in the fluid mesh, and that is pressure. So you have a single degree of freedom per node, or maybe multiple degrees of freedom per node, which makes a big difference in these analyses.” Pages 1 | 2 »
|
