About the INCLUDE_ML variable used in makefile.include for vasp.6.5.0.

[hszhao.cn@gmail.com]

Hi there,

See below:

Code: Select all

werner@x13dai-t:~/Public/hpc/vasp/src/vasp.6.5.0$ ug -r INCLUDE_ML arch/
arch/makefile.include.gnu_ompi_aocl:#INCLUDE_ML  = -I${AMDBLIS_ROOT}/include/blis -I${AMDLIBFLAME_ROOT}/include
arch/makefile.include.aocc_ompi_aocl:#INCLUDE_ML  = -I${AMDBLIS_ROOT}/include/blis -I${AMDLIBFLAME_ROOT}/include
arch/makefile.include.nvhpc_ompi_mkl_omp:#INCLUDE_ML  =
arch/makefile.include.oneapi:#INCLUDE_ML  =
arch/makefile.include.nvhpc:#INCLUDE_ML  =
arch/makefile.include.intel:#INCLUDE_ML  =
arch/makefile.include.oneapi_omp_off:#INCLUDE_ML  =
arch/makefile.include.nec_aurora:#INCLUDE_ML  = -I$(NLC_ROOT)/include
arch/makefile.include.oneapi_omp:#INCLUDE_ML  =
arch/makefile.include.nvhpc_ompi_mkl_omp_acc:#INCLUDE_ML  =
arch/makefile.include.intel_ompi_mkl_omp:#INCLUDE_ML  =
arch/makefile.include.nvhpc_omp:#INCLUDE_ML  =
arch/makefile.include.gnu_omp:#INCLUDE_ML  = -I$(OPENBLAS_ROOT)/include
arch/makefile.include.aocc_ompi_aocl_omp:#INCLUDE_ML  = -I${AMDBLIS_ROOT}/include/blis -I${AMDLIBFLAME_ROOT}/include
arch/makefile.include.nvhpc_omp_acc:#INCLUDE_ML  =
arch/makefile.include.gnu_ompi_mkl_omp:#INCLUDE_ML  =
arch/makefile.include.nvhpc_acc:#INCLUDE_ML  =
arch/makefile.include.gnu_ompi_aocl_omp:#INCLUDE_ML  = -I${AMDBLIS_ROOT}/include/blis -I${AMDLIBFLAME_ROOT}/include
arch/makefile.include.gnu:#INCLUDE_ML  = -I$(OPENBLAS_ROOT)/include
arch/makefile.include.intel_omp:#INCLUDE_ML  =

Why does this variable have an empty value in some of the above files?

Regards,
Zhao

[hszhao.cn@gmail.com]

After a second thought, looking at the patterns in these makefile includes, I can explain why the INCLUDE_ML variable is empty in some cases:

1. The INCLUDE_ML variable appears to be related to the inclusion of specific math library headers:
- For AMD builds (aocl): Points to BLIS and LibFLAME headers
- For GNU with OpenBLAS: Points to OpenBLAS headers
- For NEC Aurora: Points to NLC headers

2. The variable is empty (#INCLUDE_ML =) in cases where:
- Intel/OneAPI builds are used (they use MKL which typically doesn't require explicit include paths)
- NVIDIA HPC SDK builds (nvhpc) are used (likely using their built-in math libraries)

The empty value makes sense in these cases because:
- These builds are using math libraries that are either:
- Integrated into the compiler suite itself
- Accessible through default include paths
- Handled through different mechanisms (like linking flags)

So the empty value isn't an oversight - it's intentional based on the specific build configuration and how each compiler/platform handles its math library dependencies.

Regards,
Zhao

[andreas.singraber]

Hello Zhao!

Sorry for the late reply! Your assessment of the specific INCLUDE_ML contents is correct. For some compiler/library combinations additional paths are required and hence the field is sometimes empty and sometimes pre-filled with example paths.

Please note that the whole block

Code: Select all

# For machine learning library vaspml (experimental)
#CPP_OPTIONS += -Dlibvaspml
...
...
#INCLUDE_ML =

is only used for compiling the experimental C++ machine learning library in src/vaspml which is not yet enabled by default. In the future this will allow to compile an additional library libvaspml which, if linked to LAMMPS, allows to run VASP machine learning force fields directly from LAMMPS. In principle this is already possible in VASP.6.5.0, however, it is not well-tested and hence was not yet advertised. Instructions on how to preview this feature will follow soon (and I will make a note of it in this topic as well). Anyway, for now and for normal VASP usage it is neither required nor recommended to enable this section in the makefile.include templates.

All the best,
Andreas Singraber

[jelle_lagerweij]

Dear Andreas,

I was also wondering about the commented out vaspml parts in all compiler instructions for vasp 6.5.0. Do you already have an expected timeline for the vasp forcefield in lammps?
My research group is at least very much looking foward to this as lammps is our main tool and we use vasp for smaller side projects (and to understand interatomic forces a bit better).

Besides that, I had a small question regarding openmpi/openmp. I would like to test my install of vasp.6.5.0 with the gnu/omp makefile. It completed without any error (including hdf5 and the advised fftlib compiler settings. Overal at least that seems good. I however want to test the openmp setup a bit. Is there one of example/instruction scripts on the vasp website a good testcase for openmpi/openpm scaleup? We have AMD EPYC nodes with over 100 cores so optimizing this might be worth it.

Jelle

PS: this is how I was planning to run multiple combinations of openMP/openMPI sets (it is mostly based on the instructions on the vasp website and can switch between a DFT and an MLFF runcase):

Code: Select all

#!/bin/bash

# Check input parameters
# Assign the arguments to variables
type="$1"
ncores="$2"
nthreads="$3"

# Validate the type input (either DFT or MLMD)
if ! [[ "$type" == "DFT" || "$type" == "MLFF" ]]; then
  echo "Error: Invalid type '$type'. This code requires the option 'DFT' or 'MLFF'."
  exit 1
fi

# Validate the ncores input (must be a non-negative integer)
if ! [[ "$ncores" =~ ^[0-9]+$ ]]; then
  echo "Error: Invalid number of cores '$ncores'. Please provide a non-negative integer."
  exit 1
fi

# Validate the nthreads input (must be a non-negative integer)
if ! [[ "$nthreads" =~ ^[0-9]+$ ]]; then
  echo "Error: Invalid number of threads '$nthreads'. Please provide a non-negative integer."
  exit 1
fi

# Remove old output files only if input checks have been performed
rm -f vaspout.h5 INCAR POSCAR CHG* CONTCAR DOSCAR EIGENVAL IBZKPT OSZICAR OUTCAR PCDAT REPORT vasprun.xml WAVECAR XDATCAR


# Copy the correct INCAR and POSCAR
cp "INCAR_$type" "INCAR"
cp "POSCAR_$type" "POSCAR"

# Output the simulation type and number of cores
echo "Starting $type calculation with $ncores core(s)."

# Run the appropriate command based on the number of cores
if [ "$ncores" -eq 0 ]; then
    export OMP_NUM_THREADS="$nthreads"
    ../bin/vasp_gam
else
    mpirun -np "$ncores" --map-by ppr:"$ncores":socket:PE="$nthreads" --bind-to core -x OMP_NUM_THREADS="$nthreads" -x OMP_STACKSIZE=512m -x OMP_PLACES=cores -x OMP_PROC_BIND=close --report-bindings ../bin/vasp_gam
fi

tail -n 27 OUTCAR

[andreas.singraber]

Dear Zhao and Jelle,

last week I updated our Wiki with some instructions on how to use VASP machine-learned force fields in LAMMPS:

https://www.vasp.at/wiki/index.php/Runn ... _in_LAMMPS

Although it has not been advertised yet this is possible as of VASP 6.5.0 (albeit with some restrictions). As I already mentioned there was no extensive testing yet, however, the few beta-testers did not report any issues. If you find problems please report them here on the forum, so we can fix bugs as quickly as possible. Also, let us know if you have any issues during the build process. Thank you!

@Jelle: I asked my colleague who did some OpenMP/MPI-hybrid parallelization testing in the past and I already have some hints for you. However, I would like to ask you to start a new forum thread on this topic (just copy the related text from your last post). I will answer your question under the new topic. This makes it much easier for other user who may search this forum in the future. Thanks!

All the best,
Andreas Singraber