LAMMPS produce memory error with ReaxFF and OpenMP – LAMMPS Development

When I try to run attached LAMMPS input with:
lmp -sf omp -pk omp 12 -in input.dat
I get a segmentation fault (LAMMPS 28Mar2023). Without OpenMP or on a GPU the calculation runs.


There is nothing attached to your message.

Please try the KOKKOS package instead of the OPENMP package for OpenMP threading.
If it worked for a GPU, it will likely also work for threads.

You can put the files on Dropbox, Google Drive, Microsoft OneDrive or similar and provide a link.

If there is a bug in the OpenMP ReaxFF then we certainly want to fix it. That said, you may get better performance and have more stability with the Kokkos version of ReaxFF on CPUs, using either the OpenMP or Serial backend.

Thanks for the posting the input.

Unfortunately, I cannot reproduce any segfaults with this input deck.
I’ve run on two different machines with varying numbers of threads between 1 and 20 and all runs completed without a segfault.

What are your compilation settings? Can you post the first part of the output from lmp -h?

Here is what I have tested with:

Large-scale Atomic/Molecular Massively Parallel Simulator - 28 Mar 2023 - Development
Git info (develop / patch_28Mar2023-226-g76afaef)

Usage example: /tmp/akohlmey/build-lammps/lmp -var t 300 -echo screen -in in.alloy

[...]

OS: Linux "CentOS Linux 7 (Core)" 3.10.0-1160.53.1.el7.x86_64 x86_64

Compiler: GNU C++ 11.2.0 with OpenMP 4.5
C++ standard: C++11
MPI v1.0: LAMMPS MPI STUBS for LAMMPS version 28 Mar 2023

Accelerator configuration:

OPENMP package API: OpenMP
OPENMP package precision: double

Active compile time flags:

-DLAMMPS_GZIP
-DLAMMPS_PNG
-DLAMMPS_JPEG
-DLAMMPS_SMALLBIG
sizeof(smallint): 32-bit
sizeof(imageint): 32-bit
sizeof(tagint):   32-bit
sizeof(bigint):   64-bit

Available compression formats:

Extension: .gz     Command: gzip
Extension: .bz2    Command: bzip2
Extension: .zst    Command: zstd
Extension: .xz     Command: xz
Extension: .lzma   Command: xz
Extension: .lz4    Command: lz4


Installed packages:

KSPACE MANYBODY MOLECULE OPENMP REAXFF RIGID 

And:


Large-scale Atomic/Molecular Massively Parallel Simulator - 28 Mar 2023 - Development
Git info (develop / patch_28Mar2023-226-g76afaefe45-modified)

Usage example: ../lmp -var t 300 -echo screen -in in.alloy

[...]

OS: Linux "Fedora Linux 36 (Thirty Six)" 6.2.8-100.fc36.x86_64 x86_64

Compiler: GNU C++ 12.2.1 20221121 (Red Hat 12.2.1-4) with OpenMP 4.5
C++ standard: C++11
MPI v3.1: MPICH Version:	3.4.3
MPICH Release date:	Thu Dec 16 11:20:57 CST 2021
MPICH ABI:	13:12:1

Accelerator configuration:

GPU package API: CUDA
GPU package precision: double
OPENMP package API: OpenMP
OPENMP package precision: double

Compatible GPU present: yes

Active compile time flags:

-DLAMMPS_GZIP
-DLAMMPS_PNG
-DLAMMPS_JPEG
-DLAMMPS_FFMPEG
-DLAMMPS_EXCEPTIONS
-DLAMMPS_SMALLBIG
sizeof(smallint): 32-bit
sizeof(imageint): 32-bit
sizeof(tagint):   32-bit
sizeof(bigint):   64-bit

Available compression formats:

Extension: .gz     Command: gzip
Extension: .bz2    Command: bzip2
Extension: .zst    Command: zstd
Extension: .xz     Command: xz
Extension: .lzma   Command: xz
Extension: .lz4    Command: lz4

Installed packages:

AMOEBA ASPHERE AWPMD BOCS BODY BPM BROWNIAN CG-DNA CG-SPICA CLASS2 COLLOID 
COLVARS COMPRESS CORESHELL DIELECTRIC DIFFRACTION DIPOLE DPD-BASIC DPD-MESO 
DPD-REACT DPD-SMOOTH DRUDE EFF ELECTRODE EXTRA-COMPUTE EXTRA-DUMP EXTRA-FIX 
EXTRA-MOLECULE EXTRA-PAIR FEP GPU GRANULAR INTERLAYER KSPACE LATBOLTZ LEPTON 
MACHDYN MANYBODY MC MDI MEAM MESONT MISC ML-HDNNP ML-IAP ML-PACE ML-POD 
ML-RANN ML-SNAP MOFFF MOLECULE MOLFILE MPIIO MSCG OPENMP OPT ORIENT PERI 
PHONON PLUGIN PLUMED POEMS PTM PYTHON QEQ QTB REACTION REAXFF REPLICA RIGID 
SHOCK SMTBQ SPH SPIN SRD TALLY UEF VORONOI YAFF 

As Stan was already mentioning, the KOKKOS version is often a better choice for ReaxFF. This is particularly true when using a larger number of threads. the OPENMP package was developed at a time when CPUs had few (1-6) cores per socket and it is optimized for that. The KOKKOS acceleration offers more choices in how the work is distributed across threads and some of those are a big improvement with a larger number of threads.

Read more here: Source link