Configuring GPU for PhysicsAI model training

Hello PhysicsAI users,

As you are already aware that the GPU can be leveraged for model training in PhysicsAI, however, there are a few important points which should be considered to make sure that the GPU gets utilized by PhysicsAI for the same.

First consideration :  required software architecture for supporting GPU usage

1. Checking CUDA/CUDNN libraries compatibility with PhysicsAI : Make sure that the CUDA Toolkit 11.8 & CUDNN 8.7 version are installed on the machine.
2. Kindly refer to the ‘Appendix’ section to check for the download links on the same.

Note: No other versions of CUDA Toolkit are supported as of now due to dependencies of the other HyperWorks products on the CUDA Toolkit 11.8 & CUDNN 8.7 version.

To cross-check, if the Window’s machine has the required CUDA libraries installed, follow the below mentioned steps:

• Checking CUDA Toolkit version: Open Windows Command Line/PowerShell & write the command nvcc --version to get the CUDA version information (as shown in Figure 1).

Note: If one is performing a new installation of CUDA Toolkit 11.8 from the link mentioned in point 2 above, NVIDIA might prompt to install the latest CUDA Version. Kindly install it as it is & verify the version (as shown in Figure 1).

Figure 1 :  Checking CUDA Toolkit version using nvcc --version in the Windows PowerShell

Second consideration :  required hardware architecture for supporting GPU usage

1. Checking GPU compatibility with PhysicsAI: Make sure that the GPU being considered has the correct specifications in terms of the ‘Compute Capability’.
2. PhysicsAI supports oldest Compute Capability as 6.0.
3. To do so, in HyperMesh under the Python console (View>Python Window), write the below commands to check the GPU specifications & ‘Compute Capability’ (as shown in Figure 2).

from tensorflow.python.client import device_lib

print(device_lib.list_local_devices())

Figure 2 : GPU Specifications & Compute Capability using the Python Window in HyperMesh

FAQ’s related to using GPU in PhysicsAI:

• Checking GPU usage for model training:

1. Traditionally, GPU usage (CUDA graphs) can be checked using Windows Task Manager. However, there have been instances of GPU usage (CUDA graphs) not being shown in the Windows Task Manager & hence, the above-mentioned suggestions can serve useful to check if GPU/CPU is being used for the PhysicsAI model training.
2. Once GPU has the Compute Capability of greater than 6.0, CUDA Toolkit 11.8 & CUDNN 8.7 version are installed, then PhysicsAI would automatically use the GPU for the model training & the log file under ‘PhysicsAI>Model training>Show Log’  will have the GPU memory usage displayed (as shown in Figure 3) at the end of the training log.

Figure 3 : GPU usage by PhysicsAI for the model training indicated by the ‘Model Training Log’

• Disabling GPU usage for PhysicsAI model training

Once GPU is detected by PhysicsAI, it will automatically be used for the model training. If in certain scenarios, CPU usage is required instead, set the environmental variable as shown below:

CUDA_VISIBLE_DEVICES=-1

This would serve useful in scenarios where the GPU does not have enough memory to train the model due to various reasons related to the number of elements/nodes in the model, model hyper-parameters such as width/depth/epochs & gives the PhysicsAI error as ‘Resources exhausted during training - Try reducing width, depth or size of the mesh’.

• Memory consumption by GPU for the PhysicsAI model training:

1. During model training, one training batch is moved from the CPU to GPU at a time. For example: if a batch size of 1 is used, only one model (mesh) resides on the GPU at a time & hence, the peak memory usage is governed by the largest model (mesh) in the training data & not on the number of training meshes in total used for the model training.
2. To increase the GPU peak memory usage, the batch size can be increased (as shown in Figure 4) & each epoch would be faster. However, increasing the model size can affect the model accuracy & also might require adjustment of the learning rate when batch size has been increased.
3. PhysicsAI 2024.0 version supports mini batch size feature & can be fine-tuned as per the requirement.

Figure 4 : Batch size configuration in PhysicsAI (based on Altair internal content)

Other relevant blogs on PhysicsAI:

To understand other details related to PhysicsAI, kindly refer the blog (13 Frequently Asked Questions About Altair physicsAI) using the below link: https://community.altair.com/community?id=community_blog&sys_id=5e76d67f1b7c7510c4dfdbd9dc4bcba6

Appendix:

• CUDA Toolkit 11.8 https://developer.nvidia.com/cuda-11-8-0-download-archive
• CUDNN 8.7 https://developer.download.nvidia.com/compute/redist/cudnn/v8.7.0/local_installers/11.8/

Non-linear springs find applications in various industries. These springs exhibit non-linear force-displacement characteristics, making their modelling a crucial aspect of structural analysis. OptiStruct offers a range of element types to simulate complex structures accurately. When dealing with non-linear springs, one possible approach is using the CBUSH element with the PBUSH property and PBUSHT table options to accurately represent the behaviour of these components.

In this article, we will check how to work with such elements and validate the results of modelling a non-linear spring using PBUSH property and PBUSHT in OptiStruct.

Format and Definition

Once the CBUSH element is created and the PBUSH property is assigned to it. Keep in mind that is always necessary to assign the CBUSH element to a local coordinate system through CID field under card edit. If setting CID = 0, the CBUSH will be assigned to the global coordinate system:

Under the K_LINE option in PBUSH property, you will input the stiffness value of the linear spring. This value will not be considered for the non-linear application. In this case, it is always overwritten by the force x deflection curve.

To model a non-linear spring, we need to activate the PBUSHT field and then the KN option, which represents the force versus deflection table for dofs 1 through 6, respectively.

Some important aspects to be considered:

• TYPE=KN is allowed only for nonlinear analysis.
  
  
• For TYPE=KN, Tension is U > 0 and Compression is U < 0 where U = U(GB) - U(GA) in CBUSH element coordinate system: GA/GB are grid points on CBUSH.

(Image source: https://www.coursehero.com/study-guides/boundless-physics/hookes-law/)

Example and Validation

As an example, we will use the following model, which can be found in the following link:

• Model Download

The model consists of a plate fixed on one side and an enforced displacement curve will be applied on the other end. The load will compress the plate in the first moment and then tension it. In the middle of the plate, there is a non-linear spring, which we will monitor the force and displacement of it. The load and spring curves are, respectively:

Load Curve

Spring curve

To validate the results, we need to calculate the incremental distance between the spring’s GA and GB and the spring force. With these results, we can access the spring curve and check if they are matching.

For the maximum negative displacement at t=0.25:

And for the maximum positive displacement at t=1.00:

Bringing these values back to the force versus displacement curve, we can validate the PBUSHT results:

Altair commitments

As a starter, some of the modifications changed the way we write the inp file.

Our choices for the format of the inp file are driven by development decisions, considering not only Abaqus, but also the consistency and the ease of conversion with other solvers supported in HyperMesh.

As Abaqus supports multiple ways for modeling some entities, starting with sets, our internal Q&A process focus on ensuring that the modifications we brought to Abaqus:

• still produces a valid inp file (the inp file runs fine with Abaqus)
• and that the results obtained with the new inp file are the same as for the former one, as soon as both inp are run with the same version of Abaqus.

That said, we do not commit to preserve the ascii structure/organization of the inp file.

Please report to our support team asap if one (or multiple) of your models is not running anymore with Abaqus or returns different results.

In case you authored some automation on Abaqus pre and/or post-processing, please contact us so that we can provide you guidance about how to adjust your automations to consider the new model structure.

What changed?

Please review the video below for having a first glance at the main changes introduced between 2019 and 2022:

https://www.youtube.com/watch?v=_F5owJKw5r4

About the main changes:

Some of the changes shown in the video require some in-depth explanations. The links below explain what changed for some of the entities detailed in the introduction video.

• Contact (from 2019)
• New model organization (from 2022)
• Couplings managed as constraints (from 2022)
• Non-structural mass managed as Solver Mass (from 2022)
• HyperMesh for Abaqus 2022 Release notes

Use case

Two of the main tests required by most vibration test specifications to confirm product qualification, durability, and reliability are the half-sine shock and the sine sweep test.

A shock test is a short duration and non-periodic acceleration impulse defined by a certain shape, duration and amplitude, used to test a system’s capability to survive transient vibrations. These pulses do not necessarily represent real field environments, but they are still used throughout industry to test equipment robustness for convenience.

A simple but useful card to create these types of time-dependent dynamic loads is TLOAD2.

Format and definition

The excitation generated by TLOAD2 follows the following formula:

Which is represented in OptiStruct by the following fields:

Where,

f(t) - Time-dependent dynamic load.
A - Amplitude of the dynamic excitation referenced by the EXCITEID field.
τ -Time delay defined in the DELAY field.
T1 and T2 - Time constants defined in the T1 and T2 fields.
f – Frequency in cycles per unit time defined in F field.
φ – Phase angle in degrees defined in P field.
C - Exponential coefficient defined in C field.
B - Growth coefficient defined in B field.

Examples

Below you can find a few examples of loading curves created by TLOAD2. Attached to this article, there is a simple model with all the loads as well.

20ms half-sine pulse:

A 20ms half-sine is equivalent to a 40ms full sine, thus:

F = 1/0.04s = 25 Hz

The OptiStruct definition will be:

20ms half-sine pulse with delay

or

One cycle sine pulse

Single tone sine at 100Hz

Related Topics

TLOAD2 in OptiStruct Documentation

Response Spectrum Analysis Overview

Fatigue is the most common failure mode of mechanical components. Any structure subjected to repetitive loading may fail due to fatigue. Today, there are well established numerical method to calculate fatigue life based on damage accumulation.

Main steps of Fatigue Life calculation:

The first input of a fatigue analysis is fluctuating stress response from a previous analysis (FEA most of the time). From that point, it is possible to count the number of cycles per stress amplitude level and mean stress respectively (named commonly Rainflow Matrix). Using this information, we can correct the stress amplitude to take into account the effect of the mean stress on the fatigue life, and above all, accumulate the damage from the different cycles using the material data (SN or EN curve) to get the final the life of the part. The process can be summarized like the chart below:

Fatigue loading:

The nature of the loading causing the fluctuating stress depends on the source where excitation comes from. It can be:

• Deterministic, that is to say we assume the complete loading profile as know at any point of time (e.g. periodic loads from rotating machinary).
• Random: This is the case of most of the loading from the nature (Wind, road/rail imperfections

Fatigue analysis in the Time Domain:

When the cyclic loading is simple enough like constant amplitude (simple sine wave for example), the use of Time domain fatigue analysis is obvious. In general, when the loading is deterministic, the fatigue analysis can always be done in the Time domain. The computation cost may increase drastically in case of long variable amplitude loading.

When applied to time domain, the fatigue analysis process looks like below:

Basically, the fluctuating stress here is the Stress Time History from a pseudo static (Static analysis + time dependent scale factors) or a transient FEA analysis. Also, the Rainflow technic is used to count the cycles in the stress time history. Rest the of the process remains unchanged.

Fatigue analysis in the Frequency Domain:

When the variable amplitude loadings are too long and complex, or simply if it is completely a random process, we can transform them into Power Spectral Density (PSD) and perform the fatigue analysis in the Frequency Domain (Random fatigue). This will require an intermediate Random response analysis to get the PSD stress response (see KB0117481 or the online documentation for further details on Random Response analysis).

When applied to frequency domain for PSD, the fatigue analysis process looks like below:

The fluctuating stress is represented by the PSD Stress response. To count the cycles here, we use the PSD moments obtained from PSD Stress response and the probability of getting a certain stress range obtained from the Probability Density Function (PDF). Rest the of the process remains unchanged.

Cycle counting analogy:

As we can see from the damage computation process above, one of the most important step is the counting of stress range cycles. As we are mostly familiar with time series, let’s see how analogous the cycle counting in random fatigue (frequency domain) is with respect to the “equivalent” time domain signal represented by the PSD stresses. As a reminder, a PSD is a representation of the signal’s power distribution over a spectrum of frequency.

A convenient way to know the characteristics of a time domain signal is to determine some typical statistical properties, also known as statistical moments, which tell us about the distribution of the signal.

Given a random process, the spectral moments (PSD moments) are used to measure the statistical properties.

The commonly used moments are:

• M₀: Square of the RMS
• M₁: Mean (the Average)
• M₂: Variance (or the square of the standard deviation)
• M₃: Skewness (asymmetry of a distribution about its peak)
• M₄: Kurtosis (measures the peakedness or flatness of a distribution)

In random fatigue analysis, number of peaks or number of zero crossing are commonly used for the cycle counting:

The number of peaks per second is defined as:       

The number of zero crossing per second is defined as:   

Using the exposure time , we can deduce the total number of cycles from  or :

Finally, we can calculate the number of cycles for any given stress range using one of the well known Probability Density Fucntion (PDF). The PDF typically defines the probability distribution of the Stress range.

Both HyperLife™, SimSolid™ and OptiStruct™ proposes the the following PDF:

Dirlik:

With    ; ; ;

; ;  (irregularity factor); ; S = Stress range

Lalanne:

Narrow band:

Steinberg’s THREE band methods (directly provides the probabilities).

The probability is multiplied by the total number of cycles to get the number of cycles for a given stress range S_i:

We can then build the cycle counting matrix (number of cycles vs stress range) used in the damage calculation:

The final step of the process consists of calculating the damage using the Material curve (i.e. SN curve) and accumulate the damage using Miner’s rule. The total Life will be calculated as the reciprocal of the total damage. Please refer to our documentation for further details on damage calculation.