GPU OpenCL Known Issues and Limitations
Data Saving
All data saved to the EDEM .h5 files is carried out using the CPU. The OpenCL and CUDA solver engines have different ways of handling timesteps that require data saves. Any timesteps that require a data save when the OpenCL solver is the selected engine will be run fully on the CPU. There is no passing simulation data from the GPU to the CPU (unless specified within a GPU-API plugin). The is not the same for the CUDA solver. With the CUDA solver as the selected engine, all timesteps are performed on the GPU and the data is passed back to the CPU for saving the data.
Contact Models
The following Contact Models are not supported on the GPU.
- Bonding (Legacy)
- Tribocharging
- Electrostatics
- Moving Plane (Deprecated, replaced with Geometry Motion > Conveyor Kinematics which are fully supported on GPU)
The following Base Contact Models are fully supported on the EDEM GPU and Multi-GPU:
- Hertz-Mindlin
- Hertz-Mindlin with JKR
- Edinburgh Elasto-Plastic Adhesion Model (EEPA)
- Linear Spring
- Hysteretic Spring
The following Rolling Friction models are fully supported in the EDEM GPU:
- Standard Rolling Friction
- RVD Rolling Friction
The following Additional Models are fully supported in the EDEM GPU:
- Heat Conduction
- Moving Plane
- Archard Wear
- Bonding V2
- Relative Wear
- Linear Cohesion V2
Track Collisions
Track collisions is not supported in EDEM OpenCL GPU.
Dynamic Domain
Dynamic Domain is not supported in the EDEM 2022.3. Multi-GPU. Dynamic Domain is supported when using 1 GPU.
Cylindrical Periodic Boundaries
Cylindrical Periodic Boundaries are not supported in EDEM 2022.3 OpenCL GPU.
Time Integration
Position Verlet and Velocity Verlet time integration methods are not supported in EDEM 2022.3 OpenCL GPU. Only Euler time integration is supported.
Data Export
Exporting data having used EDEM OpenCL GPU may output the columns of the selected queries in a different order than the same simulation run in EDEM CPU.
Factories
The EDEM Open CL GPU uses a smaller, separate domain for the particle factory. This is because new particles are introduced by the CPU and particles within the factory domain need to be tracked to prevent overlapping with new particles. Once the particles leave the factory domain, they will be transferred to the GPU solver engine and are no longer tracked by the CPU factory. If any particles re-enter the factory domain, the CPU will not acknowledge them and this can lead to overlapping particles and ‘explosions’.
If several factories are so close to one another that their particles might pass through each other’s factory domain, you can enable “Use Factory Group” under GPU factory in the GPU Parameters tab on the Simulator. This feature allows you to group several factories together in order to make EDEM deal with them as one factory domain on the CPU solver engine.
The larger the number of particles inside the factory domain (one factory or one group of factories), the more CPU usage there will be and this will have an effect on performance. In extreme cases, where the factory covers the whole domain, all particles would be processed by the CPU solver engine.
To improve performance EDEM will detect when a factory stops generating particles. At this point the corresponding factory domain would become inactive and all the particle information within it will be handed over to the GPU Solver Engine to proceed with the calculations.
Solve Report
When running in GPU, the total particles removed in the solve report shows the incorrect number.
(c) 2023 Altair Engineering Inc. All Rights Reserved.