Manual Abaqus

[Pavan Outlaw]

Bydefault, load balancing of the three failover members is performed automatically by the licensing client (Abaqus). At startup, Abaqus selects randomly the failover member to contact from the three members declared. If the first selected member is down, the second member is randomly selected, and so forth. This ensures that the three members are statistically contacted by the same number of clients and results in automatic load balancing on the three members.

However, it is also possible to specify the order of priority in which failover members are contacted by Abaqus, replacing randomization by an explicit order defined by the administrator. This can be useful in the following cases, for example if: one member is more (or less) powerful than the others one member is located much closer to (or further from) thelicensing clients than the others one member cannot be reached due to proxy constraints one member is temporarily down.

Note:You cannot mix automatic and manual configurations; inother words, the three failover members are either randomly accessed or areaccessed through the specified order. So you cannot, for example, declare thefirst member then set random access to the remaining two members.

In this context, when Abaqus requests a license and this license is not already granted by one of the declared logical servers, then the order in which the logical license servers is declared is observed. If a license is available on the first declared logical server, this one is taken; if not, if a license is available on the second declared logical server, then this one is taken, and so forth.

Having the right Abaqus system can be the difference between design validation taking hours or days, and that very quickly translates into money. Unfortunately, Abaqus system performance (and pricing) can be very sensitive to exactly what you plan to simulate.

For this reason, we highly recommend talking to your Abaqus VAR and system builder before buying anything. But if you'd like to go into that conversation well-informed, are nevertheless planning to build for yourself, or are an IT professional building Abaqus systems, this guide is for you. Based on our experience as an Abaqus-based FEA consulting company since 2005 and an Abaqus partner since 2011, we will share with you how Abaqus responds to the various components in a computer build, tell you what quirks to look out for, and set some expectations.

While not a hardware issue, what operating system is best for Abaqus is a common question. Linux has less overhead and is preferred if you need every last drop of performance, but both Linux and Windows are perfectly capable. Your choice of operating system between Linux and Windows will play less of a factor than the actual hardware.

Linux, Windows 10, and Windows 11 will all work fine for Abaqus, and that machine is best left undisturbed during a solve. Do not use it for other demanding tasks (like operating SOLIDWORKS or preprocessing another large FEA model) while Abaqus is running. At Dassault Systmes's advice, we recommend Windows 11 for Intel's 12 th and 13 th generation Core CPUs due to their big.LITTLE-style core architecture.

Abaqus can solve on just one CPU core, but you will immediately see large speed increases by allowing more cores to contribute. This rate of increase will diminish as the core count rises due to parallel processing overhead. The rate of diminishing returns will also depend on the specifics of the simulation, with explicit simulations scaling better. Core speed (frequency) is also important to Abaqus. Higher core speeds can increase performance in a more linear fashion, without adding multi-core overhead.

A processor's amount of L3 cache can also affect the performance of Abaqus/Explicit. The uplift is significant in single-socket workstations, but especially notable in distributed computing situations. AMD has begun shipping processors with extreme amounts of cache (which they call "3D V-Cache") for purposes such as this. In the slide below, a high-cache multi-node system solving the e13 and e14 Abaqus/Explicit benchmarks scales more linearly than usual as nodes are added:

Upgrading a processor choice for Abaqus may have two costs associated with it: the cost of the better processor and the cost of the additional Abaqus core compute licensing. With business-class machines starting around eight-core CPUs, it's highly likely that a beginning Abaqus user has more cores than they have licenses to compute on, so adding processor performance would only require that additional licensing to fully utilize the CPU they already have. Once an intentional processor purchase is on the table, you can be much more deliberate about what you're getting and why. At that point, it is best to consult your VAR.

Processor core count and core clock speed have (theoretically) an inverse relationship, so if you buy a processor with substantially more cores than you intend to use for Abaqus, you may be buying an inferior processor for your purposes. Compare the 6444Y to the 6442Y below: 16 cores at 3.60 GHz vs. 24 cores at 2.60 GHz.

Keep in mind that we are talking about physical processor cores, not the doubled thread count that arises from simultaneous multithreading. This feature, called Hyperthreading by Intel and SMT by AMD, does not benefit Abaqus, and must be manually deactivated in BIOS on any new machine.

The best processor for your Abaqus is a balance between what will benefit your specific simulations and what your hardware and Abaqus licensing budgets will permit. Explain your simulation intentions to your Abaqus VAR and they can make an individualized recommendation (including the necessary license structuring) through their Abaqus knowledge and perhaps even benchmarking. They may even recommend a cloud or hybrid on-cloud/on-premise compute solution.

To set expectations (and not as a recommendation), an 8-16 core CPU with high per-core clock speed is often a comfortable choice for a medium-duty CAE workstation. Intel Core, Intel Xeon, AMD Ryzen, AMD Threadripper, and AMD EPYC are all viable processor lines, but as enterprise solutions that also provide superior memory options (read on for more on this), Xeon and EPYC are the most reliable and performant options.

GPU acceleration can make Abaqus run several times faster than it otherwise would. However, there are important rules. Only some solvers (such as the implicit solver and the AMS eigensolver) are appropriate for GPU acceleration, and the model to be solved must be large. Also, Abaqus requires a "double precision" GPU, meaning only a select few SKUs from each manufacturer (NVIDIA and AMD) will be up to the task.

Abaqus/CAE, the Abaqus preprocessor, is not very demanding of the GPU. Any CAD workstation GPU will be more than enough, and while we cannot officially recommend it, many even make do with gaming GPUs.

The list of graphics cards that have the necessary double precision (FP64) capability is very short. It includes the NVIDIA H100 (formerly the Tesla series) and the NVIDIA Quadro GV100, for example. FP64 capability is typically restricted to one or two flagship products per generation. Most of these cards cost in the five figures and most (but not all) are passively cooled, meaning they're made for the server room.

Due to the size of the purchase and the rarity of the need, consult with your VAR before you invest in a GPU for Abaqus. It may very well be worth it, but it's important to be sure that the need is real and that the right GPU is purchased.

A GPU can generally be added to a system at any time after its purchase, so it could become a newly viable option as your use of Abaqus becomes more sophisticated. Our consulting business, which frequently runs very large implicit analyses, has gotten great value out of GPU acceleration over the years (the benchmark above is one such real-world example).

The most important thing about memory is to just have enough capacity. If you do, Abaqus will run great. If you don't, the explicit solver won't run at all, or the implicit solver will start writing temporary files to disk, which will greatly slow down the simulation (and wear out the disk over time). How much memory you need can be seen in the diagnostics when you launch an Abaqus job.

Your system's memory channel count is a property of the CPU, but those memory channels are populated, naturally, with memory modules (called DIMMs). Each channel has two DIMM slots. Consumer-class CPUs provide two channels (and thus four DIMM slots), while workstation- and server-class CPUs (the Xeon, Threadripper, and EPYC lines) can go up into the double digits. Four channels is common for workstations. Our preliminary testing suggests that more memory bandwidth (i.e. channels) can provide significant benefit to the Abaqus explicit solver, but not the implicit one. We can't say how this benefit would or wouldn't scale to very high (10+) channel counts, however.

Error correction code (ECC) on memory is a system capability that is restricted to professional solutions, and it will require ECC memory modules. ECC won't appreciably affect performance. If you don't have error correcting, a numerical error is possible, but unlikely to cause issues for the vast majority of Abaqus users. Professional workstations will almost certainly include ECC.

Having excess memory capacity is important to safeguard yourself against slowdown if one of your analyses is a memory hog, but more excess won't translate to more speed. In other words, if Abaqus is only going to use 27 GB of RAM, it will run the same whether the system has 32 GB or 192 GB capacity.

3a8082e126