lammps / lammps

Public development project of the LAMMPS MD software package
https://www.lammps.org
GNU General Public License v2.0
2.19k stars 1.7k forks source link

[BUG] _EXTRA-MOLECULE with CMake creates error #3441

Closed hammondkd closed 2 years ago

hammondkd commented 2 years ago

Summary

CMake build of LAMMPS with only the EXTRA-MOLECULE package installed creates an error.

LAMMPS Version and Platform

3Aug2022 / develop branch / checkout version fb9c40d running on Fedora 36.

Expected Behavior

builds without errors

Actual Behavior

.../src/EXTRA-MOLECULE/angle_cosine_delta.h:23:10: fatal error: angle_cosine_squared.h: No such file or directory 23 | #include "angle_cosine_squared.h" | ^~~~~~~~ compilation terminated.

Steps to Reproduce

(1) mkdir BUILD (2) cmake ../cmake (3) [choose "YES" for PKG_EXTRA-MOLECULE] (4) Configure/Generate (5) Make

Further Information You may need to enable testing for this to happen. I have everything at "OFF" except for BUILD_GMOCK, BUILD_MPI, BUILD_OMP, BUILD_TESTING, and ENABLE_TESTING.

hammondkd commented 2 years ago

sheepish expression I don't get the compile error if I include the MOLECULE package as well as EXTRA-MOLECULE (duh...), but I still get unit test errors. Test #34 (MPILoadBalancing) fails, as does Test #41 (LibraryMPI) and Test #398 (FixTimestep:adapt_coul).

Incidentally, I encountered all of this while trying to figure out how to build the tests for the library interface. What are the correct steps to build and use those tests? The documentation describes how to create CMake script code, but what is the right way to include ALL of the library tests, including those for the Python and Fortran libraries?

akohlmey commented 2 years ago

Tests are supposed to be set up so they are either not included or skipped if a requirement is not available. So python tests require a suitable python interpreter, but tests using the LAMMPS python module also require that LAMMPS is built with -DBUILD_SHARED_LIBS=on since it tries to import the LAMMPS library via ctypes. In addition, some python tests depend on NumPy, others require PyYaml and so on. Those are usually configured automatically.

MPI related sometimes give problems with OpenMPI. There may be some warning in CMake, but it may not detect it properly. There are less problems with using -DLAMMPS_EXCEPTIONS=on (e.g. "death tests" require this setting or should otherwise be skipped of OpenMPI is detected).

I have addressed the package dependency and the fix adapt issue in PR #3442

I cannot reproduce the MPILoadBalancing and LibraryMPI failures (please note that the text numbers are changing as CMake is adapting to the build environment and enabled packages. Please run ctest -R MPI -V and provide the output here.

One possible reason for a failure could be lack of available processors. If I remember correctly, OpenMPI requires a command line flag to oversubscribe CPUs. The two MPI based tests require to run on 4 CPUs (only).

hammondkd commented 2 years ago

@akohlmey You are exactly right about the MPI failures: the OpenMPI 4 implementation I'm using (the one that ships with Fedora 36) associates "cores" with physical cores; to get the 4 CPUs the kernel recognizes, I need to use MPIEXEC_PREFLAGS="--use-hwthread-cpus" ("--oversubscribe" would also work), and if I do that, it works fine.

I get the following message in the CMake log when configuring: "Skipping Tests for the LAMMPS Fortran Module: cannot identify Fortran compiler"

The variable CMAKE_Fortran_COMPILER is being set to "/usr/bin/f95", which is a symbolic link to /usr/bin/gfortran. Setting CMAKE_Fortran_COMPILER="/usr/bin/gfortran" gives the same error message.

akohlmey commented 2 years ago

I get the following message in the CMake log when configuring: "Skipping Tests for the LAMMPS Fortran Module: cannot identify Fortran compiler"

The variable CMAKE_Fortran_COMPILER is being set to "/usr/bin/f95", which is a symbolic link to /usr/bin/gfortran. Setting CMAKE_Fortran_COMPILER="/usr/bin/gfortran" gives the same error message.

There must be something not complete with your Fortran compiler installation or your CMake installation. Here is the corresponding CMake script code in unittest/fortran/CMakeLists.txt:

include(CheckLanguage)
check_language(Fortran)
if(NOT CMAKE_Fortran_COMPILER_ID)
  message(STATUS "Skipping Tests for the LAMMPS Fortran Module: cannot identify Fortran compiler")
  return()
endif()

I am using Fedora 36 on multiple machines and there is no problem recognizing the Fortran compiler. Here is the corresponding CMake run summary output:

-- <<< Build configuration >>>
   LAMMPS Version:   20220803
   Operating System: Linux Fedora Linux 36
   Build type:       RelWithDebInfo
   Install path:     /home/akohlmey/.local
   Generator:        Unix Makefiles using /usr/bin/gmake
-- Enabled packages: ADIOS;AMOEBA;ASPHERE;ATC;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;GRANULAR;H5MD;INTERLAYER;KIM;KOKKOS;KSPACE;LATBOLTZ;MACHDYN;MANIFOLD;MANYBODY;MC;MDI;MEAM;MESONT;MGPT;MISC;ML-HDNNP;ML-IAP;ML-PACE;ML-QUIP;ML-RANN;ML-SNAP;MOFFF;MOLECULE;MOLFILE;MPIIO;MSCG;NETCDF;OPENMP;OPT;ORIENT;PERI;PHONON;PLUGIN;POEMS;PTM;PYTHON;QEQ;QTB;REACTION;REAXFF;REPLICA;RIGID;SHOCK;SMTBQ;SPH;SPIN;SRD;TALLY;UEF;VORONOI;YAFF
-- <<< Compilers and Flags: >>>
-- C++ Compiler:     /usr/lib64/ccache/c++
      Type:          GNU
      Version:       12.2.1
      C++ Flags:     -O2 -g -DNDEBUG
      Defines:       LAMMPS_SMALLBIG;LAMMPS_MEMALIGN=64;LAMMPS_EXCEPTIONS;LAMMPS_OMP_COMPAT=4;LAMMPS_JPEG;LAMMPS_PNG;LAMMPS_GZIP;LAMMPS_FFMPEG;FFT_FFTW3;FFT_FFTW_THREADS;LMP_PYTHON;LMP_MDI;LMP_HAS_NETCDF;LMP_HAS_PNETCDF;NC_64BIT_DATA=0x0020;EIGEN_NO_CUDA;LMP_KIM_CURL;LAMMPS_ZSTD;LMP_MPIIO;LMP_OPENMP;$<BUILD_INTERFACE:LMP_KOKKOS>;LMP_PLUGIN
-- Fortran Compiler: /usr/bin/f95
      Type:          GNU
      Version:       12.2.1
      Fortran Flags: -O2 -g -DNDEBUG
-- C compiler:       /usr/lib64/ccache/cc
      Type:          GNU
      Version:       12.2.1
      C Flags:       -O2 -g -DNDEBUG
-- <<< Linker flags: >>>
-- Executable name:  lmp
-- Shared library flags:    
-- <<< MPI flags >>>
-- MPI_defines:      MPICH_SKIP_MPICXX;OMPI_SKIP_MPICXX;_MPICC_H
-- MPI includes:     /usr/include/mpich-x86_64
-- MPI libraries:    /usr/lib64/mpich/lib/libmpicxx.so;/usr/lib64/mpich/lib/libmpi.so;
-- Kokkos Arch: 
-- <<< FFT settings >>>
-- Primary FFT lib:  FFTW3
-- Using double precision FFTs
-- Using threaded FFTs
-- Kokkos FFT: FFTW3
-- <<< Building Tools >>>
-- <<< Building LAMMPS Shell >>>
-- <<< Building Unit Tests >>>
-- Configuring done
-- Generating done

And for me the Fortran tests are compiled and executed:

$ ctest -R Fortran
Test project /home/akohlmey/compile/lammps/build-test
    Start 58: FortranOpen
1/2 Test #58: FortranOpen ......................   Passed    0.07 sec
    Start 59: FortranCommands
2/2 Test #59: FortranCommands ..................   Passed    0.06 sec

100% tests passed, 0 tests failed out of 2

Total Test time (real) =   0.15 sec

You can try to comment out the check in the unittest/fortran/CMakeLists.txt file and see if the tests are created.

If you want to see which packages are required to compile LAMMPS with as many options (including cross-compilation to Windows) as possible, you can look at the singularity container definition file in tools/singularity/fedora36_mingw.def

hammondkd commented 2 years ago

@akohlmey I found the problem (and it was not in my configuration): when one builds LAMMPS with any of the packages ATC, MSCG, AWPMD, ML-QUIP, LATTE, or ELECTRODE included, CMake gets "enable_language(Fortran)" on line 427 of cmake/CMakeLists.txt, which has the side effect of setting CMAKE_Fortran_COMPILER_ID, which is then found on line 9 of unittest/fortran/CMakeLists.txt.

If I rebuild with ATC enabled, the Fortran tests build. I have confirmed that CMAKE_Fortran_COMPILER_ID is not set until "enable_language(Fortran)" is called.

akohlmey commented 2 years ago

OK. Please check, if the following change remedies the situation then:

  diff --git a/unittest/fortran/CMakeLists.txt
b/unittest/fortran/CMakeLists.txt
  index c7174d8e6e..7aa2177918 100644
  --- a/unittest/fortran/CMakeLists.txt
  +++ b/unittest/fortran/CMakeLists.txt
  @@ -6,14 +6,14 @@ endif()

   include(CheckLanguage)
   check_language(Fortran)
  -if(NOT CMAKE_Fortran_COMPILER_ID)
  -  message(STATUS "Skipping Tests for the LAMMPS Fortran Module: cannot
identify Fortran compiler")
  -  return()
  -endif()

   if(CMAKE_Fortran_COMPILER)
     enable_language(C)
     enable_language(Fortran)
  +  if(NOT CMAKE_Fortran_COMPILER_ID)
  +    message(STATUS "Skipping Tests for the LAMMPS Fortran Module: cannot
identify Fortran compiler")
  +    return()
  +  endif()
     get_filename_component(LAMMPS_FORTRAN_MODULE
${LAMMPS_SOURCE_DIR}/../fortran/lammps.f90 ABSOLUTE)
     if(BUILD_MPI)
       find_package(MPI REQUIRED)

On Tue, Sep 13, 2022 at 11:05 AM hammondkd @.***> wrote:

@akohlmey https://github.com/akohlmey I found the problem (and it was not in my configuration): when one builds LAMMPS with any of the packages ATC, MSCG, AWPMD, ML-QUIP, LATTE, or ELECTRODE included, CMake gets "enable_language(Fortran)" on line 427 of cmake/CMakeLists.txt, which has the side effect of setting CMAKE_Fortran_COMPILER_ID, which is then found on line 9 of unittest/fortran/CMakeLists.txt.

If I rebuild with ATC enabled, the Fortran tests build. I have confirmed that CMAKE_Fortran_COMPILER_ID is not set until "enable_language(Fortran)" is called.

— Reply to this email directly, view it on GitHub https://github.com/lammps/lammps/issues/3441#issuecomment-1245548944, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACGTY5MLTZS5ZHP5QRV5WDV6CJ2LANCNFSM6AAAAAAQJFAPGE . You are receiving this because you were mentioned.Message ID: @.***>

-- Dr. Axel Kohlmeyer @.*** http://goo.gl/1wk0 College of Science & Technology, Temple University, Philadelphia PA, USA International Centre for Theoretical Physics, Trieste. Italy.

hammondkd commented 2 years ago

@akohlmey Worked perfectly with that change. Thank you!