GithubHelp home page GithubHelp logo

deepmodeling / abacus-develop Goto Github PK

View Code? Open in Web Editor NEW

This project forked from abacusmodeling/abacus-develop

149.0 11.0 120.0 134.67 MB

An electronic structure package based on either plane wave basis or numerical atomic orbitals.

Home Page: http://abacus.ustc.edu.cn/

License: GNU Lesser General Public License v3.0

Shell 1.73% Makefile 0.16% C++ 91.67% C 0.29% Python 1.88% CMake 0.91% Gnuplot 0.01% Batchfile 0.01% Cuda 3.29% Roff 0.03% PureBasic 0.01% HTML 0.01%
ab-initio density-functional-theory dft electronic-structure

abacus-develop's Introduction

About ABACUS

ABACUS (Atomic-orbital Based Ab-initio Computation at UStc) is an open-source package based on density functional theory (DFT). The package utilizes both plane wave and numerical atomic basis sets with the usage of norm-conserving pseudopotentials to describe the interactions between nuclear ions and valence electrons. ABACUS supports LDA, GGA, meta-GGA, and hybrid functionals. Apart from single-point calculations, the package allows geometry optimizations and ab-initio molecular dynamics with various ensembles. The package also provides a variety of advanced functionalities for simulating materials, including the DFT+U, VdW corrections, and implicit solvation model, etc. In addition, ABACUS strives to provide a general infrastructure to facilitate the developments and applications of novel machine-learning-assisted DFT methods (DeePKS, DP-GEN, DeepH, etc.) in molecular and material simulations.

Online Documentation

For detailed documentation, please refer to our documentation website.

abacus-develop's People

Contributors

1041176461 avatar abacus-ustc avatar alcanderian avatar baixiaokuang avatar caic99 avatar darelbeida avatar ddhhss avatar denghuilu avatar dyzheng avatar haozhihan avatar hongritianqi avatar jieli-matrix avatar jinzx10 avatar kirk0830 avatar liu-rx avatar lyb9812 avatar maki49 avatar mohanchen avatar ouqi0711 avatar peizelin avatar pplab avatar pxlxingliang avatar qianruipku avatar sunliang98 avatar tansongchen avatar wenfei-li avatar whuweiqingzhou avatar wszhang avatar xinyangd avatar yuliu98 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

abacus-develop's Issues

Intel OneAPI based Container

Describe Current Status and Possible Solution

Recently I made a patch to ELPA 2016.05.004, enabling it to be compiled with Intel OneAPI (icpc, mpiicpc). Therefore we can make a Intel OneAPI based container. The patch is extremely simple: just delete five lines (7055 ~ 7059) at /ltmain.sh. I attach the patched archive here.

elpa-2016.05.004.zip

Bug of PW stress calculation when npool>1

Describe the Bug

When running PW calculation, stress is wrong if npool>1

To Reproduce

Steps to reproduce the behavior:

  1. Clone the latest code from reconstruction branch
  2. Compile the code with Intel compiler
  3. calculate stress of fcc Al with npool=1
  4. calculate stress of fcc Al with npool>1 (such as 8)

Environment

  • OS: ubuntu 16.04
  • Compiler: Intel Parallel Studio XE 2017
  • Optional Dependencies: Intel MKL; FFTW-3.3.8; boost_1_70_0; elpa-2016.05.004

Additional Context

Add any other context about the problem here.

Invalid abacus_manual.pdf

Describe the bug
The user manual abacus_manual.pdf file is not valid and cannot be opened.

To Reproduce
Steps to reproduce the behavior:

  1. Go to 'ABACUS.develop' folder
  2. GO to "documents" folder
  3. Click on 'abacus_manual.pdf' or download the pdf by right-clicking -->save link as
  4. See error

Expected behavior
A pdf file that can be opened and readable.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

  • OS: e.g. windows 10
  • Browser: Edge
  • Version: not clear

Smartphone (please complete the following information):

  • Device: [e.g. iPhone6]
  • OS: [e.g. iOS8.1]
  • Browser [e.g. stock browser, safari]
  • Version [e.g]

Additional context
Add any other context about the problem here.

input parameter 'out_wf'

Is your feature request related to a problem? Please describe.
the 'out_wf' parameter controls the output format of wave functions, and we have more than one option.

Describe the solution you'd like
Add more options

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Numerical error occurs in multi cores calcualtion in LCAO, it is found in Fe2 examples.

Describe the Bug

In principle, different number of core would lead to same total energy, but in the example abacus-develop/tests/integrate/304_NO_GO_AF , the digital error is too large to ignore.
In my test, total energy for two Fe atoms for antiferromagnetic calculation is:

  • 4 core: -6373.574042773125
  • 8 core: -6373.574042694958
    this error occured in tests:
  • gamma_only=1 + nspin=2
  • gamma_only=0 + nspin=2
  • gamma_only=1 + nspin=1
  • gamma_only=0 + nspin=1

I tested the difference of first step Hamiltonian matrix element between 1core-result and 16core-result, both of them has 54*54 matrix.
I found most of them is same in precision 6, but if the matrix element is about to 0 or maybe it is supposed to be 0, digital error occured that :
1 core: (0.710086,0) (2.46566e-17,0) (-7.64671e-17,0) (1.30987e-16,0) (-9.77472e-17,0) (2.37608e-16,0) (4.23795e-18,0) (-5.60824e-17,0) (-2.00249e-16,0)
16 core: (0.710086,0) (1.94918e-17,0) (-2.60598e-17,0) (8.4085e-17,0) (-1.43063e-16,0) (-4.64799e-16,0) (-1.05793e-17,0) (-3.10474e-17,0) (-2.61976e-16,0)

Additional Context

This digital error is from grid integral calculation for local potential part.

reconstruction of PW module in order to make it compatible with GPU

Is your feature request related to a problem? Please describe.
We need to have a clear line for PW that is suitable for both CPU, GPU, or even DCU versions.

Describe the solution you'd like
Reconstruction of some PW codes.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

How to define the starting magnetic moments for each atom?

Is your feature request related to a problem? Please describe.
We need to have a CONVENIENT setup for the starting magnetic moments for each atom.

Describe the solution you'd like
Maybe an array in the input file to setup the starting magnetic moments.

Describe alternatives you've considered
Otherwise, we can specify the magnetic moments in the STRU file.

Additional context
We need someone to implement this feature and related initialization.

temperature bug when using NVT Molecular Dynamics with LCAO

Describe the bug
I ran an MD of a single methane (CH4) in a 10*10*10 Angstrom^3 box with NVT ensemble.
The basis is lcao and functional is LDA.
PBE ONCV pseudopotentials are used.

To Reproduce
Steps to reproduce the behavior:

  1. Go to '1_lcao_md'
  2. View '1.out'
  3. Scroll down to line 75
  4. See error

Expected behavior
The temperature should not be '-nan'.

1_lcao_md.zip

Systematically Build ABACUS with CMake, Starting with GNU Toolkits

Problem Description

ABACUS build relies on the following dependencies:

  • C++ compiler
  • Fortran compiler
  • MPI and MPI C++ compiler
  • math libraries: blas, blacs, lapack, scalapack, fftw
  • Boost
  • ELPA
  • libxc
  • cereal

Currently, these dependencies can be satisfied in two ways:

  1. Using Intel toolkits (including icpc, ifort, mpiicpc, and all math libraries are in MKL), and manually install Boost, ELPA, libxc and cereal;
  2. Using GNU toolkits (g++, gfortran, mpicxx from OpenMPI), and manually install all other dependencies.

However, All the dependencies, together with their (manually installed) directory and compiler flags must be hard-coded in ABACUS.develop/source/Makefile.vars and ABACUS.develop/source/Makefile.system. Furthermore, ABACUS currently must use ELPA 2016.05.004, which cannot be compiled with Intel compiler 2019 or later.

Proposed Solution

To improve the build reproducibility of ABACUS, I suggest we should write CMake scripts to specify dependency rules and compiling options. We can start with the GNU toolkits, and later add support for Intel toolkits when we migrate our code to ELPA 2021.

Currently a subset of ABACUS, the orbital module, is included in CMake scripts, see #47 .

Automatic Testing on Pull Requests to "develop" Branch

Summary

Currently, we have some computation examples in directory ABACUS.develop/examples and ABACUS.develop/tests, they can potentially serves as Integration Tests when someone adds a pull request to the develop branch. We are also planning to add some Unit Tests.

Details

Currently, only a subset of ABACUS can be built with standardized build system, which is implemented by @tansongchen with Docker, CMake and GitHub Actions, see #47 . We plan to include all ABACUS code in this system in a couple of weeks. Once this is done, we can start to work on automatic testing.

error for test case 201_NO_KP_DJ_CF_CS_GaAs : scalapack solver error!

Describe the bug

  1. example : tests/integral/201_NO_KP_DJ_CF_CS_GaAs

  2. error output:

    = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
    = PID 23602 RUNNING AT 4ef21388ba08
    = EXIT CODE: 4
    = CLEANING UP REMAINING PROCESSES
    = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES

    YOUR APPLICATION TERMINATED WITH THE EXIT STRING: Illegal instruction (signal 4)
    This typically refers to a problem with your application.
    Please see the FAQ page for debugging suggestions

  3. environment:

    • GNU in docker
    • branch : deepmodeling/abacus-develop/reconstruction
    • commit: c60615b
  4. more information:

    • change "ks_solver" setup in INPUT file:
    • ks_solver = genelpa: error in any cores;
    • ks_solver = scalapack_gvx : correct in 1 core, error in multi cores
    • ks_solver = hpseps: correct in both 1core and multi cores
  5. bug track:

    • stop in function: void Pdiag_Double::diago_complex_begin()
    • stop in line: source/src_pdiag/pdiag_double.cpp: 1055
    • stop in function:: pzSolveEigen2()
    • stop in function:: elpa_solve_evp_complex_2stage()
    • this is a interface in Elpa.

Add unittests for the 'orbital' module

Is your feature request related to a problem? Please describe.
The combination of the 'cell' and 'orbital' modules should have the ability to read in atomic positions and generate overlap matrix S.

Describe the solution you'd like
Wenfei will try to implement this new feature.

problem running LCAO calculation with diago_proc>0 and more than 1 MPI thread

Describe the Bug

When running LCAO calculation with diago_proc > 0 and more than 1 mpi thread, the run halts after the following in running_scf.log:

 SETUP THE DIVISION OF H/S MATRIX
 divide the H&S matrix using 2D block algorithms.
                                     nb2d = 1

To Reproduce

Steps to reproduce the behavior:

  1. Clone the latest code from reconstruction branch
  2. Compile the code with the following flags in Makefile.vars:
FORTRAN       = ifort
CPLUSPLUS      = icpc
CPLUSPLUS_MPI = mpiicpc
LAPACK_DIR    = $(MKLROOT)
FFTW_DIR   = $(your_path_to_fftw3)
BOOST_DIR  = $(your_path_to_boost)
ELPA_DIR = $(your_path_to_elpa)
CEREAL_DIR = $(your_path_to_cereal)
  1. Copy the example 02a_Si_diamond_lcao_scf/ and add one line in the INPUT file : diago_proc= 1 (or any positive integer less than the number of number of MPI threads)
  2. Run the code with more than one MPI thread, for example, mpirun -n 2 ABACUS.mpi

Environment

  • OS: CentOS 7(Core)
  • Compiler: Intel Parallel Studio XE 2018
  • Optional Dependencies: Intel MKL; FFTW-3.3.4; boost_1_66_0; elpa-2016.05.004

Additional Context

Add any other context about the problem here.

Add unit tests for the base module

Is your feature request related to a problem? Please describe.
We need unit tests for the base module.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Calculating kinetic energy density with LCAO

Is your feature request related to a problem? Please describe.
In order to implement meta-GGA with LCAO, a subroutine for calculating kinetic energy density with LCAO is required.
The kinetic energy density is defined as:
image
where f(i) is the occupation number of state i, and the index i runs over all bands and k points.

Describe the solution you'd like
It would be nice if there is a subroutine that converts density matrix to tau that is similar to cal_rho which converts density matrix to the electron density rho(r).

Convergence problem with ks_solver = genelpa

Describe the bug
I have recently been working on a Li3Sn system. With ks_solver = genelpa, convergence was achieved for gamma point calculation as well as k point sampling with a 222 mesh. However, k-point mesh 333 becomes problematic and convergence was not achieved after 100 SCF iterations.
Convergence was achieved for 333 after switching to ks_solver = hpseps.

To Reproduce
Relevant input files are attached, along with the output I got.

Environment

  • OS: CentOS 7(Core)
  • Compiler: Intel Parallel Studio XE 2018
  • Optional Dependencies: Intel MKL; FFTW-3.3.4; boost_1_66_0; elpa-2016.05.004

Li3Sn_333.zip

Reconstructions for the 'base', 'cell', 'neighbor' modules

Is your feature request related to a problem? Please describe.
We would like to split the ABACUS code into small modules, each one of which has a unique function. For example, the 'base' module contains several self-defined types of data (matrix, vector, array, etc.), as well as some math functions. The 'cell' module contains all information related to cells and atoms (positions, velocities, etc.). The 'neighbor' module read-in cell information and searches neighboring atoms for each atom with or without periodic boundary conditions under a given radius cutoff.

Describe the solution you'd like
Reconstruction of the code in the summer of 2021.

Describe alternatives you've considered
No alternatives.

Additional context
The modules will be important building blocks of ABACUS in the future.

OpenMP Warning when compiling ABACUS with cmake

Describe the Bug

ABACUS can be compiled successfully.
However, there is a "unrecognized OpenMP #pragma" warning when compiling ABACUS with cmake.

To Reproduce

Steps to reproduce the behavior:

  1. cmake -B build -DCMAKE_CXX_COMPILER=icpc -DMPI_CXX_COMPILER=mpiicpc -DCMAKE_INSTALL_PREFIX=~/intelcompile/testabacus -DELPA_DIR=/home/qianrui/intelcompile/impi_elpa -DCEREAL_INCLUDEDIR=/home/qianrui/intelcompile/cereal/include
  2. cmake --build build/ -j8

Environment

  • OS: [e.g. CentOS 7.6]
  • Compiler: intel 2021.3.0 20210609
  • Optional Dependencies: [e.g. Intel MKL]

Additional Context

Add any other context about the problem here.

Grid integral

Describe Current Status and Possible Solution

Grid integral module in ABACUS need to be optimized for:

  1. it cost so much memory for large systems that more than 32G memory used for GaAs_512_system
  2. the parallel method for this module now is just along z axis, it is not very smart.
  3. we should unify the interface for this module.

ABACUS MD output

Background

The problems are encountered when I was adding ABACUS MD interface in dpdata (https://github.com/deepmodeling/dpdata).

Problems

(1) The index number of output cif file containing atomic coordinates does NOT match the ion iteration index written in running_md.log.
For example, file md_pos_1.cif actually corresponds to atomic coordinates of ION= 2 iteration, rather than ION= 1 iteration. ION= 1 iteration actually corresponds to the atomic coordinates in input STRU file.
(2) The output atomic positions are in direct coordinates, but the output forces and stresses are in Cartesian coordinates. They don't match each other.
One has to either convert atomic positions to Cartesian coordinates or convert forces, stresses to direct coordinates if he/she wishes to use positions, stresses and forces at the same time.
If the output level is turned to ie, the Cartesian coordinates of atomic positions will be output, but loads of other useless information of electron iterations will also be output.
The lattice vector of each iteration should also be output, if NpT ensemble is to be implemented.

ABACUS IO needs keeping updating!

Describe Current Status and Possible Solution

  1. Output for LCAO and PW should be unified.
  2. All INPUT parameters should output in OUT.suffix/INPUT.
  3. Useless output and input should be deleted.
  4. Other updates.

Please comment here!

Bugs for TDDFT

Describe the Bug

The forces of AlH system are different for different core numbers after scf calculation in reconstruction branch.

To Reproduce

Relevant files are in the attachment. Run scf.sh to calculate and then run_result_scf.sh to see the result.

Environment

  • OS: CentOS Linux release 7.6.1810
  • Compiler: intel2018
  • Optional Dependencies: fftw-3.3.8 boost_1_64_0 elpa-2016.05.004

Additional Context

The z length of the lattice in AlH_1.tar.gz is half of the one in AlH_2.tar.gz. For different core numbers, results in AlH_1.tar.gz are the same, while results in AlH_2.tar.gz are different.
AlH_1.tar.gz
AlH_2.tar.gz

Electronic scf convergence problem during cell relax

Describe the Bug

I run cell-relax in a fcc Al system, containing 21 atoms arranged along fcc[111] direction. With force_thr_ev = 0.000001, electronic convergence cannot be achieved after 100 scf, while it can be achieved when force_thr_ev=0.01.
Then, I test the cell-relax of fcc Al primitive cell. There is no problem in electronic scf, but the program wouldn't stop even if force = 0, with force_thr_ev = 1.

To Reproduce

I have attached relevant input files.

Environment

We can add a linear algorithm for calculating Structure Factor

Describe Current Status and Possible Solution

Now, our algorithm for structure factor scales O(N^2). It will affect most the efficiency for large systems.
We can use a interpolation algorithm to calculate Structure Factor.

Additional Context

Add any other context or screenshots about the enhancement here.

Some issues regarding several input variables

First of all, we will need some short explanation or (preferably) some documentation on the input variables regarding:
DFT+U
Hybrid functional
Spectrum
TDDFT

Secondly, there are a few variables that seems are either not implemented yet or already obsolete:

mlwf_flag
diago_cg_prec
restart_mode
restart_save
restart_load
input_error
mdoutputpath

Also, the variable lmaxmax sets an upper bound for l channels in atomic orbital basis set, is there a particular reason for doing so?

PBE single shot from LDA charge density

Describe the Bug

Input charge density file from convergent LDA result, and then to PBE scf for only one step, the eigenvalue is lower than the PBE convergence charge density. This phenomenon occurs both in PW code and LCAO code.

Environment

Branch develop or ABACUS_2.2.0_beta before 2021/11/08
pbe_single_shot.zip

Additional Context

QE is normal, we should compare our PW result and QE's.

ABACUS relaxation error on HPC platform

Describe the Bug

A clear and concise description of what the bug is.
I bumped into this error when I was testing abacus 2.2.0 beta relax on Beijixing HPC. The bug can be repeatedly performed on cn-large nodes, but on cn_nl nodes everything works fine. I don't know what happens on cn-large nodes.

To Reproduce

Steps to reproduce the behavior:

  1. Clone the source code from abacus_2.2.0_beta branch.
  2. Build ABACUS with Makefile and Intel 2019 compiler.
  3. Run ABACUS.

Environment

  • OS: CentOS Linux release 7.6.1810
  • Compiler: Intel 2019
  • Optional Dependencies: Intel MKL

Additional Contex

屏幕快照 2021-11-07 下午2 36 24
Info in out file.
屏幕快照 2021-11-07 下午2 37 10
Info in warning.log file.

Document development

Hello everyone, we implement new document of ABACUS in README.md and doc/ on reconstruction branch, please try and leave your suggests about:
1, Not convenient;
2, Lack of some features;
3, Details wrong.

input checks

Is your feature request related to a problem? Please describe.

The input check is not very comprehensive. Sometimes the user will not be notified of problematic input, and the calculation will proceed to give wrong results.
For example, if there are two types of elements in the system, while in INPUT, ntype is supplied as 1, then the program will proceed after reading information regarding the first element from STRU file, without notifying the user that ntype is wrong.
Also, it is possible to run the calculation without supplying lattice vectors in STRU file. It seems that a simple cubic lattice will be assumed in this case, and the user is not notified about this either.

Describe the solution you'd like
To implement more checks when reading input.
Regarding the ntype problem, maybe we could end the atoms session from STRU file with some special character, and keep reading till that special character. In this way, if there are more elements in the STRU file than specified by ntype parameter, we can raise an error message.
Regarding the lattice vector problem, I can try to add a simple check there.

Additional context
It would be nice to know if anyone has some other input checks in mind, so that we could start to improve them.

Autotest updates

Describe Current Status and Possible Solution

We should update our autotest cases for:

  1. small molecular cases such as CH4.
  2. error cases reported in other issues.

Additional Context

We also need to add more check items to existed cases, such as eigenvalues or band gaps.

Improved CMake Support

Developers should be able to configure the project with

cmake -D [variable lists] -B build cmake

where variable lists either contains

CMAKE_CXX_COMPILER=/path/to/icpc
CMAKE_Fortran_COMPILER=/path/to/ifort
MPI_CXX_COMPILER=/path/to/mpiicpc
MKL_DIR=/path/to/mkl
ELPA_DIR=/path/to/elpa
BOOST_INCLUDEDIR=/path/to/boost-headers
CEREAL_INCLUDEDIR /path/to/cereal-headers

or

CMAKE_CXX_COMPILER=/path/to/gcc
CMAKE_Fortran_COMPILER=/path/to/gfortran
MPI_CXX_COMPILER=/path/to/mpicxx
LAPACK_DIR=/path/to/blas-and-lapack
SCALAPACK_DIR=/path/to/blacs-and-scalapack
FFTW_DIR=/path/to/fftw
ELPA_DIR=/path/to/elpa
BOOST_INCLUDEDIR=/path/to/boost-headers
CEREAL_INCLUDEDIR /path/to/cereal-headers

Potential Problems Detected by Compiler Warnings

Describe the Bug

Intel LLVM compiler (icpx) generates some advanced warnings which may potentially be a bug. Examples include: confusing between = and ==, operator precedence, unwanted conversions, etc.

icpx.txt

To Reproduce

Steps to reproduce the behavior:

  1. Clone the source code from deepks branch
  2. Configure CMake with options cmake -B buildicpx -DCMAKE_INSTALL_PREFIX=~/.local -DCMAKE_CXX_COMPILER=icpx -DMPI_CXX_COMPILER=mpiicpc -DMKL_DIR=$MKLROOT -DELPA_DIR=~/software/elpa-intel-new -DBOOST_INCLUDEDIR=~/.local/src/boost-1.75.0 -DCEREAL_INCLUDEDIR=~/.local/src/cereal-1.3.0/include -DENABLE_DEEPKS=1 -DCMAKE_PREFIX_PATH=~/software/libtorch
  3. Build ABACUS with cmake --build buildicpx -j8

Environment

  • OS: CentOS 7.6
  • Compiler: Intel LLVM 2021.1
  • Optional Dependencies: Intel MKL

Additional Context

Add any other context about the problem here.

Add unit tests (UT) for MD module using the LJ potential

Is your feature request related to a problem? Please describe.
We have a stand-alone MD module in ABACUS now, we need unit tests to ensure the MD module is correct.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

We need a clear DeePKS+ABACUS workflow

Is your feature request related to a problem? Please describe.
The DeePKS feature implemented in ABACUS should be correct, should be parallelled, and the workflow and related documents are needed.

Describe the solution you'd like
Add more new features in ABACUS-DeePKS, more tests for different systems.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

A example for grid integral error!

Describe the Bug

There is a bug occured when calculating this example
501_NO_neighboring_GaAs512.zip

To Reproduce

Steps to reproduce the behavior:

  1. Newelpa branch.
  2. Different bug information for gamma_only option on and off, but both these bugs occured during calculating Hamiltonian local part.

Build a Docker Image with GNU Toolkits for Both Development Environment and Testing Environment

Prerequisites

Problem Description

After CMake script is done, we can build a docker image which contains all required dependencies (but don't contain ABACUS itself). This docker image can serve for two purposes:

  1. To provide ABACUS developers, especially who are not so familiar with computer science, a clean and reproducible environment to develop new features without wasting time in these configurations;
  2. To enable automatic testing on servers.

Proposed Solution

see /Dockerfile for an example which is introduced in #47 .

Error of the new VNL calculation method

Describe the Bug

I test the AlH system by running AIMD with LCAO in reconstruction branch.
In the first MD step, everything is OK, but something goes wrong in the second MD step.
It seems that the function build_Nonlocal_mu_new in src_lcao/LCAO_gen_fixedH.cpp has some problems.

To Reproduce

Relevant input files are attached, along with the output I got.

Environment

  • OS: Ubuntu18.04
  • Compiler: Intel oneAPI
  • Optional Dependencies: Intel MKL; FFTW-3.3.8; elpa-2016.05.004

Additional Context

Add any other context about the problem here.
AlH.tar.gz

AIMD stops at 75-th MD step

Describe the Bug

I've been running some AIMD calculations on CH4, starting from slightly different configurations. All of the calculations stop in the middle of the 75-th MD step with errors.

To Reproduce

Steps to reproduce the behavior:

  1. Code : the latest newelpa branch
  2. Compile : on Lebesgue, follow the steps in Dockerfile.intel
  3. Running : I used 4 MPI threads to run the job
  4. Example : see attached
    md_example.zip

force or stress output error : garbage characters

Describe the bug
If test_force and test_stress option off, the screen output and output in running.log are both correct.
But if test_force or test_stress option on, the screen output would be garbage characters while running.log output is still correct.

To Reproduce
Steps to reproduce the behavior:

  1. Go to any example in path tests/integral/, then set "stress" and "test_stress" as value 1 in file INPUT;
  2. run ABACUS program and compare screen output and running.log output.
  3. Scroll down to 'STRESS';
  4. See error.

Expected behavior
1, string output is correct and double value output would be garbage characters only in screen output;
2, only "test_stress" or "test_force" opened, this error would occur.
3, output format for screen output and running output are same.

Screenshots
If applicable, add screenshots to help explain your problem.

**other information

  • Device: [docker image environment with GNU compiler]
  • branch [deepmodeling/abacus-develop/reconstruction]
  • Version commit "c60615bc9b76d47eba7461d2bf2d6e767b3bcb1e"
  • Code location: source/src_pw/stress_func_print.cpp and source/src_pw/stress_pw.cpp

Additional context
1, intel compiler has similar error
2, if the code "cout << setiosflags(ios::fixed);" is banned, the error will disappear, why?
3, if the stress calculating function is banned, the error is still appear,

Test parallel efficiency of some larger-scale examples monthly

Summary

Test the parallel efficiency of the examples which have larger computation overhead.
This test needs not trigger too frequently. For example, we only do it once a month.

Related tasks

Confirm and construct a platform for such tests.

Details

We are bringing in more tests. We expect that the total number of tests are going to be around 200.

Update HPSEPS solver

Background

There are three matrix solver in ABACUS lcao code: (parameter: ks_solver)

  1. scalapack_gvx, seems good now, no extra installation request.
  2. genelpa, most efficient, not robust enough for small systems, not convenience for installing.
  3. hpseps, only suitable for gamma_only=0, need to update to the latest version.

Describe the solution you'd like

We plan to keep working with Dr. Zhao's group to update our HPSEPS interface.

Additional context

We need to do:

  1. figure out the reason that why gamma_only=1 with HPSEPS solver can't work now;
  2. test the latest HPSEPS interface to know which input and output format we need to prepare;
  3. unified interface for three solver in ABACUS code.

Had deepks been merged to abacus?

Background

Had deepks been merged to abacus to calculate solid?
Is there any examples for solid?
what are the labels to train deepks? such as the plane wave for CCSD?

close symmetry when exx is used

Describe Current Status and Possible Solution

So far, the symmetry option is unsupported when exx is on;
it had better close symmetry automatically if exx is on.

Additional Context

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.