Giter Club home page Giter Club logo

sirius's Introduction

GitHub Releases Static Badge GitHub Discussions Documentation Licence Build Verification tests master Verification tests develop

Table of contents

Introduction

SIRIUS is a domain specific library for electronic structure calculations. It implements pseudopotential plane wave (PP-PW) and full potential linearized augmented plane wave (FP-LAPW) methods and is designed for GPU acceleration of popular community codes such as Exciting, Elk and Quantum ESPRESSO. SIRIUS is written in C++17 with MPI, OpenMP and CUDA/ROCm programming models. SIRIUS is organised as a collection of classes that abstract away the different building blocks of DFT self-consistency cycle.

The following functionality is currently implemented in SIRIUS:

  • (PP-PW) Norm-conserving, ultrasoft and PAW pseudopotentials
  • (PP-PW) Spin-orbit coupling
  • (PP-PW) Stress tensor
  • (PP-PW, FP-LAPW) Atomic forces
  • (PP-PW, FP-LAPW) Collinear and non-collinear magnetism
  • (FP-LAPW) APW and LAPW basis sets with arbitrary number of local orbitals
  • (FP-LAPW) ZORA and IORA approximations for valence states; full relativistic Dirac equation for core states
  • Symmetrization of lattice-periodic functions and on-site matrices
  • Generation of irreducible k-meshes
  • Python frontend

Installation

It is recommended to install SIRIUS through Spack. To set it up, use

git clone https://github.com/spack/spack.git
. spack/share/spack/setup-env.sh
spack install sirius

Configuring SIRIUS

SIRIUS has many different configurations to enable specific hardware and library support. Some common setups include:

# Use default BLAS, LAPACK, MPI and FFTW3 implementations, without GPU support, using the latest GCC 9.x
$ spack install sirius %gcc@:9

# Explicitly use the latest 3.x release of MPICH for MPI, OpenBLAS for BLAS and LAPACK, FFTW for FFTW3, without GPU support
$ spack install sirius ^mpich@:3 ^fftw ^openblas

# Enable distributed linear algebra, and use Intel MKL for BLAS, ScaLAPACK and FFTW3, without GPU support
$ spack install sirius +scalapack ^intel-mkl

# Build with CUDA support for NVIDIA GPUs
$ spack install sirius +cuda cuda_arch=75

# Build with ROCm support for AMD GPUs
$ spack install sirius +rocm amdgpu_target=gfx906

# Build with MAGMA
$ spack install sirius +cuda +magma

# Build with ELPA
$ spack install sirius +scalapack +elpa

Language interop with Fortran and Python can be enabled with +fortran and +python respectively.

See spack info sirius for the full list of support variants.

Developing and debugging SIRIUS

The recommended way to install the latest development version of SIRIUS is through spack dev-build.

As an example, the following builds SIRIUS with CUDA support in debug mode:

$ git clone --recursive -b develop https://github.com/electronic-structure/SIRIUS.git
$ cd SIRIUS
$ spack dev-build sirius@develop build_type=Debug +cuda

When more control over the build commands is necessary, use spack build-env [spec] -- [command]:

$ mkdir SIRIUS/build && cd SIRIUS/build
$ export SPEC="sirius@develop build_type=Debug +cuda"
$ spack install --only=dependencies $SPEC
$ spack build-env $SPEC -- cmake ..
$ spack build-env $SPEC -- make -j$(nproc)

Manual installation

When installing SIRIUS without Spack, make sure to install the required dependencies first:

  • CMake ≥ 3.14
  • C++ compiler with C++17 support
  • MPI (OpenMPI or MPICH)
  • BLAS/LAPACK (OpenBLAS or Intel MKL)
  • GSL - GNU scientific library
  • LibXC - library of exchange-correlation potentials
  • HDF5
  • spglib - library for finding and handling crystal symmetries
  • SpFFT - domain-specific FFT library
  • SPLA - domain-specific distributed GEMM library

and optionally any of the additional libraries:

* Only required when SIRIUS_BUILD_APPS=On and your compiler does not support std::filesystem or std::experimental::filesystem.

** Only required when -DSIRIUS_BUILD_TESTING=On

Clone the repository and build as follows:

git clone --recursive https://github.com/electronic-structure/SIRIUS.git
mkdir SIRIUS/build
cd SIRIUS/build
export CXX=mpicxx CC=mpicc FC=mpif90
export CMAKE_PREFIX_PATH="path/to/BLAS;path/to/GSL;path/to/LibXC;path/to/HDF5;..."
cmake -DCMAKE_INSTALL_PREFIX=$PWD/sirius
make -j install

where CMAKE_PREFIX_PATH is a list of installation paths of dependencies installed in non-standard locations.

Adding GPU support

To enable CUDA you need to pass the following options to CMake: -DSIRIUS_USE_CUDA=On -DCMAKE_CUDA_ARCHITECTURES='60;70', where CMAKE_CUDA_ARCHITECTURES is a list of NVIDIA architectures. Use 60, 61, 62 for Pascal; 70, 72 for Volta; 75 for Turing; and 80 for Ampere. If CUDA is installed in a non-standard directory, you have to pass additional parameter to cmake -DCUDA_TOOLKIT_ROOT_DIR=/path/to/cuda.

To enable MAGMA (GPU implementation of LAPACK) use -DSIRIUS_USE_MAGMA=On. Append MAGMA's installation directory to CMAKE_PREFIX_PATH if necessary.

Parallel eigensolvers

To compile with ScaLAPACK use -DSIRIUS_USE_SCALAPACK=On. To use ELPA, both -DSIRIUS_USE_SCALAPACK=On and -DSIRIUS_USE_ELPA=On are required, as we need ScaLAPACK functionality to transform the generalized eigenvalue problem to standard form, which can then be solved by ELPA. Append ScaLAPACK's and ELPA's install directory to CMAKE_PREFIX_PATH if necessary. To use DLA-Future use -DSIRIUS_USE_DLAF=ON

Python module

Use -DSIRIUS_CREATE_PYTHON_MODULE=On to build the Python module. The SIRIUS Python module depends on mpi4py and pybind11, which need to be installed on your system.

Additional options

To link against Intel MKL use -DSIRIUS_USE_MKL=On. For Cray libsci use -DSIRIUS_USE_CRAY_LIBSCI=On. Building tests requires -DSIRIUS_BUILD_TESTING=On.

By default example applications are built. This can be turned off via -DSIRIUS_BUILD_APPS=Off, which is recommended when just building Fortran bindings.

Installation on Piz Daint

Please refer to the SIRIUS wiki page and CSCS User portal for detailed instructions.

Accelerating DFT codes

Quantum ESPRESSO

Quantum ESPRESSO is a popular open source suite of computer codes for electronic-structure calculations and materials modeling at the nanoscale. It is based on DFT, plane waves, and pseudopotentials. We maintain the GPU-accelerated version of Quantum ESPRESSO with SIRIUS bindings. This version is frequently synchronised with the develop branch of the official QE repository. A typical example of using SIRIUS inside QE is listed below:

subroutine get_band_energies_from_sirius
  !
  use wvfct,    only : nbnd, et
  use klist,    only : nkstot, nks
  use lsda_mod, only : nspin
  use sirius
  !
  implicit none
  !
  integer, external :: global_kpoint_index
  !
  real(8), allocatable :: band_e(:,:)
  integer :: ik, nk, nb, nfv

  allocate(band_e(nbnd, nkstot))

  ! get band energies
  if (nspin.ne.2) then
    ! non-magnetic or non-collinear case
    do ik = 1, nkstot
      call sirius_get_band_energies(ks_handler, ik, 0, band_e(1, ik))
    end do
  else
    ! collinear magnetic case
    nk = nkstot / 2
    ! get band energies
    do ik = 1, nk
      call sirius_get_band_energies(ks_handler, ik, 0, band_e(1, ik))
      call sirius_get_band_energies(ks_handler, ik, 1, band_e(1, nk + ik))
    end do

  endif

  ! convert to Ry
  do ik = 1, nks
    et(:, ik) = 2.d0 * band_e(:, global_kpoint_index(nkstot, ik))
  enddo

  deallocate(band_e)

end subroutine get_band_energies_from_sirius

To compile Quantum ESPRESSO with SIRIUS it is easiest to use Spack. The following installs a CUDA enabled version:

spack install q-e-sirius ^sirius +shared +scalapack +cuda ~apps ^intel-mkl ^mpich

Now you can load pw.x and MPI related executables:

spack load q-e-sirius

Run pw.x using the same parameters and input files as you would with native QE. Note that you have to explicitly enable SIRIUS through the command-line option -sirius in pw.x. For instance:

# run in default mode
pw.x -i pw.in
# run with SIRIUS enabled
pw.x -i pw.in -sirius

The SIRIUS library is using OpenMP for node-level parallelization. To run QE/SIRIUS efficiently, follow these simple rules:

  • always prefer k-point pool parallelization over band parallelization
  • use as few MPI ranks as possible for band parallelization
  • by default, use one rank per node and many OMP threads; if the calculated system is really small, try to saturate the GPU card by using more MPI ranks (e.g.: on a 12-core node, use 2-3-4 ranks with 6-4-3 OMP threads)

Benchmarks

In the following examples we compare the performance of native and SIRIUS-enabled versions of QE. CPU-only runs are executed on dual-socket multi-core nodes containing two 18-core Intel Broadwell CPUs. GPU runs are executed on hybrid nodes containing a 12-core Intel Haswell CPU and an NVIDIA Tesla P100 card:

Hybrid partition (Cray XC50) Multicore partition (Cray XC40)
Intel Xeon E5-2690 v3 @2.60GHz, 12 cores
NVIDIA Tesla P100 16GB
Two Intel Xeon E5-2695 v4 @2.10GHz (2 x 18 cores)

Ground state calculation (input) of Si511Ge.

Another example is the variable cell relaxation of B6Ni8 (input). The Brillouin zone contains 204 irreducible k-points and only k-pool parallelization is used.

CP2K

CP2K uses the SIRIUS library to enable plane-wave functionality. The detailed description of the input parameters can be found here under the /CP2K_INPUT/FORCE_EVAL/PW_DFT section.

Contacts

If you have any questions, feel free to contact us:

Acknowledgements

The development of the SIRIUS library would not be possible without support of the following organizations:

Logo Name URL
ethz Swiss Federal Institute of Technology in Zürich https://www.ethz.ch/
cscs Swiss National Supercomputing Centre https://www.cscs.ch/
pasc Platform for Advanced Scientific Computing https://www.pasc-ch.org/
pasc NCCR MARVEL
Centre on Computational Design and Discovery of Novel Materials
https://nccr-marvel.ch/
pasc MAX (MAterials design at the eXascale)
European Centre of Excellence
http://www.max-centre.eu/
pasc Partnership for Advanced Computing in Europe https://prace-ri.eu/

sirius's People

Contributors

abussy avatar adhocman avatar bonfus avatar borellim avatar bors[bot] avatar christianmeisenbichler avatar ckae95 avatar dev-zero avatar e-kwsm avatar electronic-structure avatar finkandreas avatar fstein93 avatar gcistaro avatar gsavva avatar haampie avatar luthaf avatar manhin321 avatar mtaillefumier avatar rmeli avatar simonpintarelli avatar teonnik avatar toxa81 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

sirius's Issues

Compile fails with 'error: format not a string literal and no format arguments'

Compiling src/Band/band.cpp to CMakeFiles/sirius.dir/Band/band.cpp.o fails with the following:

[ 13%] Building CXX object src/CMakeFiles/sirius.dir/Band/band.cpp.o
cd <builddir>/sirius/obj-x86_64-linux-gnu/src && /usr/bin/c++  -D__PROFILE -D__PROFILE_TIME -D__USE_MEMORY_POOL -D__USE_TIMER -I<builddir>/sirius/obj-x86_64-linux-gnu/src -I<builddir>/sirius/src/SDDK -I<builddir>/sirius/src -I<builddir>/sirius/src/. -isystem /usr/lib/x86_64-linux-gnu/openmpi/include -isystem /usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -isystem /usr/include/hdf5/serial  -g -O2 -fdebug-prefix-map=<builddir>/sirius=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -fPIC -fvisibility=hidden   -fopenmp -std=gnu++14 -o CMakeFiles/sirius.dir/Band/band.cpp.o -c <builddir>/sirius/src/Band/band.cpp
In file included from <builddir>/sirius/src/K_point/k_point_set.hpp:28,
                 from <builddir>/sirius/src/Band/band.cpp:27:
<builddir>/sirius/src/K_point/k_point.hpp: In instantiation of ‘void sirius::K_point::message(int, const char*, Args ...) const [with Args = {const char*}]’:
<builddir>/sirius/src/Band/band.cpp:425:5:   required from ‘void sirius::Band::check_residuals(sirius::Hamiltonian_k&) const [with T = double]’
<builddir>/sirius/src/Band/band.cpp:414:9:   required from ‘void sirius::Band::initialize_subspace(sirius::Hamiltonian_k&, int) const [with T = double]’
<builddir>/sirius/src/Band/band.cpp:154:46:   required from here
<builddir>/sirius/src/K_point/k_point.hpp:746:19: error: format not a string literal and no format arguments [-Werror=format-security]
  746 |             printf(args...);
      |             ~~~~~~^~~~~~~~~
cc1plus: some warnings being treated as errors

Top of cmake output:

-- The C compiler identification is GNU 9.2.1
-- The CXX compiler identification is GNU 9.2.1

CMake tries to copy headers without taking DESTDIR into account

On UNIX systems Makefile variable DESTDIR is usually used to provide root directory for the installation (see DESTDIR documentation for CMake). One of instructions for SIRIUS however does not take DESTDIR into consideration:

cd obj-x86_64-linux-gnu && make -j1 install DESTDIR=<destdir>
...
Install the project...
/usr/bin/cmake -P cmake_install.cmake
-- Install configuration: "None"
-- Installing: <destdir>/usr/lib/x86_64-linux-gnu/libsirius.a
Error copying directory from "sirius/obj-x86_64-linux-gnu/src/mod_files" to "/usr/include/sirius/".

I assume the following instruction in src/CMakeLists.txt is responsible for it:

  INSTALL ( CODE
    "EXECUTE_PROCESS (COMMAND \"${CMAKE_COMMAND}\" -E copy_directory \"${PROJECT_BINARY_DIR}/src/mod_files\" \"${CMAKE_INSTALL_PREFIX}/include/sirius/\")"
    )

I assume the solution would be to use the following instruction instead:

install(FILES ${PROJECT_BINARY_DIR}/src/mod_files "${CMAKE_INSTALL_PREFIX}/include/sirius")

get rid of 10a.u. hack in sirius

This is done to match QE results. Better to check for proper analytical tail of rho_core(r) and vloc(r)

10 a.u. is hardcoded and used as rcut in Modules/read_pseudo.f90

Initial state

Work on exact initialization of ground state like in QE

Remove GSL as a hard dependency or add disclaimer

While SIRIUS is licensed under the FreeBSD-licensed (2-clause BSD), the GSL it needs to build is licensed under the GPL (not the LGPL!), which means that a binary SIRIUS installation must be distributed by the terms of the GPL.
Please note: I do not care either way, but if using the GSL was intentional, you might want to either change the license of SIRIUS to GPL itself or at least add a clarification that while the SIRIUS code itself is licensed as BSD, the resulting binary will be GPL due to this dependency.

Simplify FFT driver

hybrid CPU/GPU is overcomplicated. Implement only pure CPU or pure GPU transformations.

occupation in uspp files

the code ties to read occupations

parser["pseudo_potential"]["atomic_wave_functions"][k]["occupation"] >> occ;

but the upf converters don't write this to json. How this is possible?

Expression templates

A more consistent way to perform operations on the objects without memory reallocation.

For example:

Obj o1(resources);
o1 = transform(o2); // this should write directly to o1

Communicator(Communicator&& src__) possibly invokes undefined behaviour

This move-constructor calls Communicator::free() without setting first mpi_comm_ and need_to_free_.
Valgrind reports this:

==2383== Conditional jump or move depends on uninitialised value(s)
==2383==    at 0x94EFDA: sddk::Communicator::free() (communicator.hpp:192)
==2383==    by 0xA5AEA8: Communicator (communicator.hpp:223)
==2383==    by 0xA5AEA8: split (communicator.hpp:509)
==2383==    by 0xA5AEA8: Gvec (gvec.hpp:455)
==2383==    by 0xA5AEA8: sirius::K_point::generate_gkvec(double) (k_point.h:211)
==2383==    by 0xA5B6F5: sirius::K_point::initialize() (initialize.hpp:53)
==2383==    by 0xA5C7A5: sirius::K_point_set::initialize(std::vector<int, std::allocator<int> >) (k_point_set.h:181)
==2383==    by 0x941332: sirius_create_kset (sirius_api.cpp:185)
==2383==    by 0x53F0AD: setup_sirius_ (setup_sirius.f90:357)
==2383==    by 0x4E742E: run_pwscf_ (run_pwscf.f90:122)
==2383==    by 0x40D980: MAIN__ (pwscf.f90:70)
==2383==    by 0x40DA2C: main (pwscf.f90:37)

I'm not sure what the correct default values for these variables are, though.

this->free();

Spin dimensions

There is num_mag_dims = 0,1,3 ; num_spins=1,2 ; I made also num_mag_comps =1,2,3 (because for non-collinear one needs only 3). So, what the case is used in Atom::d_mtrx_ ?

ROCM version cannot be built

We are using Sirius on the ROCM platform with release v6.3.4.
However, ROCM version doesn't seems to be able to build successfully.
The build fail logs are appended below...
Also, we would like to ask if there is some comprehensive documentation on Sirius that covers
a list of unit tests that needs to be passed, including the hand to hand steps to run them, and what to be expect int the correct output?

[ 33%] Building CXX object src/CMakeFiles/sirius.dir/SDDK/wave_functions.cpp.o [ 33%] Building CXX object src/CMakeFiles/sirius.dir/Hubbard/hubbard_generate_atomic_orbitals.cpp.o [ 32%] Building CXX object src/CMakeFiles/sirius.dir/Band/diag_pseudo_potential.cpp.o [ 33%] Building CXX object src/CMakeFiles/sirius.dir/Potential/xc.cpp.o [ 20%] Building CXX object src/CMakeFiles/sirius.dir/SDDK/wf_trans.cpp.o [ 33%] Building CXX object src/CMakeFiles/sirius.dir/dft_ground_state.cpp.o [ 33%] Built target HIP_TARGET_random.cu In file included from /home/sarahhung/Sirius/SIRIUS/src/SHT/sht.hpp:39:0, from /home/sarahhung/Sirius/SIRIUS/src/Unit_cell/hubbard_orbitals_descriptor.hpp:28, from /home/sarahhung/Sirius/SIRIUS/src/Unit_cell/atom_type.hpp:35, from /home/sarahhung/Sirius/SIRIUS/src/Unit_cell/atom_symmetry_class.hpp:28, from /home/sarahhung/Sirius/SIRIUS/src/Unit_cell/atom.hpp:29, from /home/sarahhung/Sirius/SIRIUS/src/Unit_cell/unit_cell.hpp:29, from /home/sarahhung/Sirius/SIRIUS/src/radial_integrals.hpp:28, from /home/sarahhung/Sirius/SIRIUS/src/radial_integrals.cpp:1: /home/sarahhung/Sirius/SIRIUS/src/SDDK/linalg.hpp: In member function ‘void sddk::linalg2::trmm(char, char, char, ftn_int, ftn_int, const T*, const T*, ftn_int, T*, ftn_int, stream_id) const [with T = double; ftn_int = int]’: /home/sarahhung/Sirius/SIRIUS/src/SDDK/linalg.hpp:214:87: error: too many arguments to function ‘void hipblas::dtrmm(char, char, char, char, int, int, const double*, const double*, int, double*, int)’ gpublas::dtrmm(side, uplo, transa, 'N', m, n, alpha, A, lda, B, ldb, sid()); ^ In file included from /home/sarahhung/Sirius/SIRIUS/src/SDDK/GPU/gpublas_interface.hpp:34:0, from /home/sarahhung/Sirius/SIRIUS/src/SDDK/linalg.hpp:30, from /home/sarahhung/Sirius/SIRIUS/src/SHT/sht.hpp:39, from /home/sarahhung/Sirius/SIRIUS/src/Unit_cell/hubbard_orbitals_descriptor.hpp:28, from /home/sarahhung/Sirius/SIRIUS/src/Unit_cell/atom_type.hpp:35, from /home/sarahhung/Sirius/SIRIUS/src/Unit_cell/atom_symmetry_class.hpp:28, from /home/sarahhung/Sirius/SIRIUS/src/Unit_cell/atom.hpp:29, from /home/sarahhung/Sirius/SIRIUS/src/Unit_cell/unit_cell.hpp:29, from /home/sarahhung/Sirius/SIRIUS/src/radial_integrals.hpp:28, from /home/sarahhung/Sirius/SIRIUS/src/radial_integrals.cpp:1: /home/sarahhung/Sirius/SIRIUS/src/SDDK/GPU/hipblas_interface.hpp:232:13: note: declared here inline void dtrmm(char side, char uplo, char transa, char diag, int m, int n, double const* alpha, ^~~~~ In file included from /home/sarahhung/Sirius/SIRIUS/src/SHT/sht.hpp:39:0, from /home/sarahhung/Sirius/SIRIUS/src/Unit_cell/hubbard_orbitals_descriptor.hpp:28, from /home/sarahhung/Sirius/SIRIUS/src/Unit_cell/atom_type.hpp:35, from /home/sarahhung/Sirius/SIRIUS/src/Unit_cell/atom_symmetry_class.hpp:28, from /home/sarahhung/Sirius/SIRIUS/src/Unit_cell/atom.hpp:29, from /home/sarahhung/Sirius/SIRIUS/src/Unit_cell/unit_cell.hpp:29, from /home/sarahhung/Sirius/SIRIUS/src/radial_integrals.hpp:28, from /home/sarahhung/Sirius/SIRIUS/src/radial_integrals.cpp:1: /home/sarahhung/Sirius/SIRIUS/src/SDDK/linalg.hpp: In member function ‘void sddk::linalg2::trmm(char, char, char, ftn_int, ftn_int, const T*, const T*, ftn_int, T*, ftn_int, stream_id) const [with T = std::complex<double>; ftn_int = int]’: /home/sarahhung/Sirius/SIRIUS/src/SDDK/linalg.hpp:251:81: error: too many arguments to function ‘void hipblas::ztrmm(char, char, char, char, int, int, const hipDoubleComplex*, const hipDoubleComplex*, int, hipDoubleComplex*, int)’ reinterpret_cast<acc_complex_double_t*>(B), ldb, sid());
\

XC functinals

in xc_functional_base.hpp:

#if (XC_MAJOR_VERSION >= 4) && (XC_MINOR_VERSION >= 3)
    {"XC_LDA_X_1D_SOFT", XC_LDA_X_1D_SOFT},
    {"XC_LDA_X_1D_EXPONENTIAL", XC_LDA_X_1D_EXPONENTIAL},
#else
    {"XC_LDA_X_1D", XC_LDA_X_1D}, /* Exchange in 1D */
#endif

I cant find XC_LDA_X_1D_SOFT and XC_LDA_X_1D_EXPONENTIAL definitions in any xc_func.h header. @mtaillefumier where do this guys come from?

API-v2

use valgrind to investigate the crash in c_bands.f90
call sirius_set_parameters(sctx, iter_solver_tol=ethr/2)

Several issues with the generated Fortran API

The Fortran API seems to have a couple of issues.

Looking at sirius_set_atom_type_radial_grid as an example with the following definition:

subroutine sirius_set_atom_type_radial_grid(handler,label,num_radial_points,radial_points)
   implicit none
   type(C_PTR), intent(in) :: handler
   character(C_CHAR), dimension(*), intent(in) :: label
   integer(C_INT), intent(in) :: num_radial_points
   real(C_DOUBLE), intent(in) :: radial_points

   interface
      subroutine sirius_set_atom_type_radial_grid_aux(handler,label,num_radial_points, radial_points) bind(C, name="sirius_set_atom_type_radial_grid")
         use, intrinsic :: ISO_C_BINDING
         type(C_PTR), intent(in) :: handler
         character(C_CHAR), dimension(*), intent(in) :: label
         integer(C_INT), intent(in) :: num_radial_points
         real(C_DOUBLE), intent(in) :: radial_points
      end subroutine
   end interface

   call sirius_set_atom_type_radial_grid_aux(handler,label,num_radial_points,radial_points)
end subroutine sirius_set_atom_type_radial_grid

with the following C/C++ function:

void sirius_set_atom_type_radial_grid(void*  const* handler__,
                                      char   const* label__,
                                      int    const* num_radial_points__,
                                      double const* radial_points__)
{
    GET_SIM_CTX(handler__);

    auto& type = sim_ctx.unit_cell().atom_type(std::string(label__));
    type.set_radial_grid(*num_radial_points__, radial_points__);
}
  1. use, intrinsic :: ISO_C_BINDING is missing in the definition of sirius_set_atom_type_radial_grid. Since you are using types defined by the ISO C Bindings already there, you should be using the use ... already. My guess is that the use ISO_C_BINDING is "leaking in" from somewhere.
  2. The argument radial_points is actually supposed to be an array, not a single element. Since the outer routine is supposed to be a native Fortran subroutine, the parameter should be a Fortran array and this kind of casting should be hidden from the user (but there is even a better solution, see next point).
  3. Fortran does not guarantee for arrays to be contiguous (especially not when using array slicing or subarrays). While this way of addressing arrays works in C/C++, it is conceptually wrong in Fortran. Use an assumed-size specifier instead: real(C_DOUBLE), dimension(*), intent(in) :: radial_points
  4. Simple values like single integers could be passed by value rather than by pointer: integer(C_INT), value, intent(in) :: num_radial_points. Making the respective function declaration in C cleaner and avoiding a pointer dereference.
  5. The applied double wrapping seems to be pointless: you are still "leaking" the ISO C Binding types towards Fortran while not making the function easier to access or hiding some of the design decisions for the interface. This should probably be removed completely.
  6. From the semantics should the handler type be of intent(inout) since every call is also modifying the contents the handler is pointing to and could possibly invalidate it.

For the given example, the functions should rather look like:

   interface
      subroutine sirius_set_atom_type_radial_grid(handler,label,num_radial_points, radial_points) bind(C, name="sirius_set_atom_type_radial_grid_aux")
         use, intrinsic :: ISO_C_BINDING
         type(C_PTR), intent(inout) :: handler
         character(C_CHAR), dimension(*), intent(in) :: label
         integer(C_INT), value, intent(in) :: num_radial_points
         real(C_DOUBLE), dimension(*), intent(in) :: radial_points
      end subroutine
   end interface

with the following C/C++ implementation:

void sirius_set_atom_type_radial_grid(void** handler__,
                                      char   const* label__,
                                      int  num_radial_points__,
                                      double const* radial_points__)
{
    GET_SIM_CTX(handler__);

    auto& type = sim_ctx.unit_cell().atom_type(std::string(label__));
    type.set_radial_grid(num_radial_points__, radial_points__);
}

Better way to create density matrix

something like
auto dmat = density_->generate_density_matrix(kset)

and then use it to augment charge density or construct the PAW potential

Use grid2grid

There are several places where we perform reshuffling of wave-functions

  • for the FFT on a coarse mesh (to apply H_loc)
  • when we pass wave-functions from SIRIUS to QE
  • when we pass plane-wave coefficients between QE and SIRIUS

The idea is to switch to Marko's (@kabicm) grid2grid library. This will introduce another dependency, but reduce the amount of "custom" code in SIRIUS.

Glith in prerequisite.py

prerequisite.py fails on the xc case.

python prerequisite.py $HOME/local xc
Installation prefix: /users/bonfap/local
Traceback (most recent call last):
  File "prerequisite.py", line 140, in <module>
    main()
  File "prerequisite.py", line 137, in main
    configure_package(pkg, prefix)
  File "prerequisite.py", line 76, in configure_package
    tf = tarfile.open("./libs/" + local_file_name)
  File "/usr/lib64/python2.7/tarfile.py", line 1680, in open
    raise ReadError("file could not be opened successfully")
tarfile.ReadError: file could not be opened successfully

Renaming libxc-4.2.3.tar.gz to xc-4.2.3.tar.gz solves the problem.

Initialization flags and pointers return

One needs to

  • add initialization flags in complicate classes if they are initialized not in all cases or not in constructor.
  • return pointers(not references) for those objects, which are allocated not in all cases or not in constructor.
    The reason is to be able to check.

ndm_

fix ndm:

int num_zdmat = (ctx_.num_mag_dims() == 3) ? 3 : (ctx_.num_mag_dims() + 1);

Wrong eigen-value solver when running verification test cases

I tried running the test scripts under the verification folder for both CPU and CUDA.
However, for run_tests_parallel_gpu.x , run_tests_parallel.x, I keep getting the following error, complaining that it cannot find the appropriate eigen value solver....

number of magnetic dimensions : 0
lmax_apw : -1
lmax_rho : 4
lmax_pot : 4
lmax_rf : 2
smearing width : 0.025000
cyclic block size : 16
|G+k| cutoff : 6.000000
valence relativity : zora
core relativity : Dirac
terminate called after throwing an instance of 'std::runtime_error'
what(): wrong eigen-value solver: standard eigen-value solver :
[ubuntu:16467] *** Process received signal ***
[ubuntu:16467] Signal: Aborted (6)
[ubuntu:16467] Signal code: (-6)
[ubuntu:16467] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f182a841890]
[ubuntu:16467] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f1826d5ae97]
[ubuntu:16467] [ 2] /lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f1826d5c801]
[ubuntu:16467] [ 3] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x8c957)[0x7f182774f957]
[ubuntu:16467] [ 4] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x92ab6)[0x7f1827755ab6]
[ubuntu:16467] [ 5] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x92af1)[0x7f1827755af1]
[ubuntu:16467] [ 6] /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x92d24)[0x7f1827755d24]
[ubuntu:16467] [ 7] /home/sarahhung/Sirius/SIRIUS/verification/../build/apps/dft_loop/sirius.scf(+0x2197da)[0x56177f16d7da]
[ubuntu:16467] [ 8] /home/sarahhung/Sirius/SIRIUS/verification/../build/apps/dft_loop/sirius.scf(+0x21ed28)[0x56177f172d28]
[ubuntu:16467] [ 9] /home/sarahhung/Sirius/SIRIUS/verification/../build/apps/dft_loop/sirius.scf(+0xe08f5) [0x56177f0348f5]
[ubuntu:16467] [10] /home/sarahhung/Sirius/SIRIUS/verification/../build/apps/dft_loop/sirius.scf(+0x1b0a6)[0x56177ef6f0a6]
[ubuntu:16467] [11] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f1826d3db97]
[ubuntu:16467] [12] /home/sarahhung/Sirius/SIRIUS/verification/../build/apps/dft_loop/sirius.scf(+0xdb39a)[0x56177f02f39a]
[ubuntu:16467] *** End of error message ***
`mpirun noticed that process rank 0 with PID 0 on node ubuntu exited on signal 6 (Aborted).`
./test1 failed

While running run_tests_gpu.x and run_tests.x, it seems to behave normally as the following...

lmax_pot : 4
lmax_rf : 2
smearing width : 0.025000
cyclic block size : 32
|G+k| cutoff : 6.000000
valence relativity : zora
core relativity : Dirac
standard eigen-value solver : LAPACK
generalized eigen-value solver : LAPACK
processing unit : CPU

Is this some environmental setup issue? Or am I missing anything crucial here?

keep master branch only

@simonpintarelli @mtaillefumier @AdhocMan

Guys! How about keeping master branch only. It will be updated only through pull requests. On your local git clone you will do

git checkout -b feature_xyz
git push -u upstream feature_xyz

and here you will open a pull-request from feature_xyz branch to master. The master branch will always be up-to-date with recent developments.

Issue with symmetrization of the hubbard occupation matrix

If we symmetrize the hubbard occupation matrix n_s, then the solver becomes crazy after few iterations and electrons fly away (wrong unsymmetrized density warning). This happened before the my wfc refactoring but we leave this work to QE so it was simply forgotten with time.

This does not occur if we do not explicitly symmetrize n_s. The symmetries procedure is identical to the procedure for the density matrix since it is the same function.

const correctness everywhere

Not good that input parameters are often non constant (f.e. xc calc for paw). Constant parameters are impossible because one need to get a pointer and pass to constructor of Spheric_function

Adapt SIRIUS to current ELPA API

Since some time ELPA features a new API. In their most recent version 2019.05.001 the developers stopped providing the legacy API by default (needs to be enabled manually in ELPA using configure --enable-legacy-interface), which leads to the following error when trying to link SIRIUS:

/data/tiziano/cp2k/tools/toolchain/build/SIRIUS-6.1.5/src/eigenproblem.hpp:654: undefined reference to `elpa_solve_evp_complex_2stage_double_precision'
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: /data/tiziano/cp2k/tools/toolchain/build/SIRIUS-6.1.5/src/eigenproblem.hpp:650: undefined reference to `elpa_solve_evp_complex_1stage_double_precision'
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: /data/tiziano/cp2k/tools/toolchain/install/sirius-6.1.5/lib/libsirius_f.a(sirius_api.cpp.o): in function `Eigensolver_elpa::solve(int, int, sddk::dmatrix<double>&, double*, sddk::dmatrix<double>&)':
/data/tiziano/cp2k/tools/toolchain/build/SIRIUS-6.1.5/src/eigenproblem.hpp:615: undefined reference to `elpa_solve_evp_real_2stage_double_precision'
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: /data/tiziano/cp2k/tools/toolchain/build/SIRIUS-6.1.5/src/eigenproblem.hpp:611: undefined reference to `elpa_solve_evp_real_1stage_double_precision'

Invalid write cusolverDnDsyevd

Bisecting a memory issue with git leads to a bug introduced in one of these commits:

There are only 'skip'ped commits left to test.
The first bad commit could be any of:
2fcbf37
44c4cc4
fe17fbc
We cannot bisect more!

srun -N1 -n1 -C gpu -c 12 cuda-memcheck $SCRATCH/SIRIUS_dev-build/apps/tests/test_eigen_v2 --N=10 --n=10 --nev=10 --name=cusolver
========= CUDA-MEMCHECK
========= Invalid __global__ write of size 4
=========     at 0x00000030 in copy_info_kernel(int, int*)
=========     by thread (0,0,0) in block (0,0,0)
=========     Address 0x1e0a5c40 is out of bounds
=========     Saved host backtrace up to driver entry point at kernel launch time
=========     Host Frame:/opt/cray/nvidia/default/lib64/libcuda.so.1 (cuLaunchKernel + 0x2c5) [0x269e85]
=========     Host Frame:/opt/nvidia/cudatoolkit10/10.1.105_3.27-7.0.1.1_4.1__ga311ce7/lib64/libcusolver.so.10 [0x109c879]
=========     Host Frame:/opt/nvidia/cudatoolkit10/10.1.105_3.27-7.0.1.1_4.1__ga311ce7/lib64/libcusolver.so.10 [0x109c907]
=========     Host Frame:/opt/nvidia/cudatoolkit10/10.1.105_3.27-7.0.1.1_4.1__ga311ce7/lib64/libcusolver.so.10 [0x10d2c55]
=========     Host Frame:/opt/nvidia/cudatoolkit10/10.1.105_3.27-7.0.1.1_4.1__ga311ce7/lib64/libcusolver.so.10 [0x2ead13]
=========     Host Frame:/opt/nvidia/cudatoolkit10/10.1.105_3.27-7.0.1.1_4.1__ga311ce7/lib64/libcusolver.so.10 [0x2eadde]
=========     Host Frame:/opt/nvidia/cudatoolkit10/10.1.105_3.27-7.0.1.1_4.1__ga311ce7/lib64/libcusolver.so.10 (cusolverDnDsyevd + 0x3ce) [0x23e2ce]
=========     Host Frame:/scratch/snx3000/hstoppel/SIRIUS_dev-build/apps/tests/test_eigen_v2 (_ZN16Eigensolver_cuda5solveEiiRN4sddk7dmatrixIdEEPdS3_ + 0x2c0) [0xda922]
=========     Host Frame:/scratch/snx3000/hstoppel/SIRIUS_dev-build/apps/tests/test_eigen_v2 (_ZN16Eigensolver_cuda5solveEiRN4sddk7dmatrixIdEEPdS3_ + 0x41) [0xdab45]
=========     Host Frame:/scratch/snx3000/hstoppel/SIRIUS_dev-build/apps/tests/test_eigen_v2 [0xe3303]
=========     Host Frame:/scratch/snx3000/hstoppel/SIRIUS_dev-build/apps/tests/test_eigen_v2 [0xb9de8]
=========     Host Frame:/scratch/snx3000/hstoppel/SIRIUS_dev-build/apps/tests/test_eigen_v2 [0xbadb1]
=========     Host Frame:/lib64/libc.so.6 (__libc_start_main + 0xea) [0x20f8a]
=========     Host Frame:/scratch/snx3000/hstoppel/SIRIUS_dev-build/apps/tests/test_eigen_v2 [0x8c0ea]
=========

When just malloc'ing instead of using the memory pool the issue disappears.

Symmetrize density matrix in LAPW

If the density matrix is symmetrized, the correct charge density in MT can be computed directly without a need of symmetrization. Then the array of muffin-tin radial functions can be made local (distributed over mpi ranks).

calculation of band structure is wrong

QE+SIRIUS Bug, calculation of band structure is wrong. It seems that people from QE changed indexation of k-points. (New function global_kpoint_index() appeared) There is difference in one-electron energies between QE and QE+SIRIUS

Please allow verskion to be passed through cmake variables, instead of calling git

--- CMakeFiles/generate_version_hpp.dir/all ---
Traceback (most recent call last):
  File "/wrkdirs/usr/ports/science/sirius/work/SIRIUS-6.3.0/make_version_hpp.py", line 105, in <module>
    main()
  File "/wrkdirs/usr/ports/science/sirius/work/SIRIUS-6.3.0/make_version_hpp.py", line 96, in main
    branch_name = get_branch(sha_str, version_str)
  File "/wrkdirs/usr/ports/science/sirius/work/SIRIUS-6.3.0/make_version_hpp.py", line 69, in get_branch
    stderr=subprocess.PIPE)
  File "/usr/local/lib/python3.6/subprocess.py", line 729, in __init__
    restore_signals, start_new_session)
  File "/usr/local/lib/python3.6/subprocess.py", line 1364, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'git': 'git'

When package is built, it builds from the tarball provided by GitHub. These tarballs don't contain .git directories.

Collection of Spheric_functions

A collection of spheric functions (for MT spheres) is required for LAPW and PAW. It will be used to store MT-related functions and used to access f_{lm}(r) components

Some problems with Atom::d_mtrx in parallel mode

When I use grid [2] for example, then calculations give wrong gap. By checking hashes of the data I found, that PAW data is the same as in serial, but Atom::d_mtrx is not (which is calculated before PAW).

Communicator leakage

Using LSAN, I discovered that SIRIUS + CP2K is leaking memory at the following locations:

sddk::Communicator::cart_sub(int const*) const SIRIUS-6.4.3/src/SDDK/communicator.hpp:364
sddk::Communicator::split(int) const SIRIUS-6.4.3/src/SDDK/communicator.hpp:373
sddk::Communicator::cart_create(int, int const*, int const*) const SIRIUS-6.4.3/src/SDDK/communicator.hpp:355
spfft::MPICommunicatorHandle::MPICommunicatorHandle(int const&) SpFFT-0.9.8/src/mpi_util/mpi_communicator_handle.hpp:50

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.