dceresoli / qe-gipaw

QE-GIPAW for Quantum-Espresso (official repository)

QE-GIPAW

This is the official Git repository of the GIPAW code for Quantum-Espresso.

Other NMR-, EPR- and GIPAW-related repositories:

• GIPAW pseudopotentials (work in progress)
• List of papers with NMR, EPR and Mössbauer experiments/calculations

Features

• NMR shielding tensors, EFG tensors
• EPR g-tensor, hyperfine couplings
• Mössbauer
• Norm-conserving (g-tensor only), USPP and PAW
• LDA and GGA functionals, +Hubbard U
• isolated and periodic systems
• integration with Quantum-Environment (solvent effects)

Authors and contributors

D. Ceresoli, A. P. Seitsonen, U. Gerstmann, E. Kucukbenli, S. de Gironcoli, P. Giannozzi, N. Varini, M. Calandra, L. Paulatto, C. Cavazzoni, A. Dal Corso, F. Spiga, A. Ferreira

Build instructions:

From Quantum-Espresso distribution

1. Configure and compile QE as usual, then:
2. make gipaw

Stand-alone

1. Configure and compile QE as usual, then:
2. git clone https://github.com/dceresoli/qe-gipaw.git
3. cd qe-gipaw
4. ./configure --with-qe-source="QE folder containing make.inc"
5. make

Source releases

Official source releases are found here.

News

• Jan 18, 2018: added tools/NMR_tensor-convention.py to convert NMR shielding tensors anysotropy in various conventions
• Jan 18, 2018: added tools/EPR_diagonalize_g-tensor to output the principal components and directions of the g-tensor, accordin to Weyl, Bolton, Principles of electron paramagnetic resonance, ch. 4.4
• Jan 18, 2018: fixed bug in symmetrization of g-tensor

qe-gipaw's Issues

Fails to compile with QE 7.3.1

It seems that due to the renaming of the tab variable to tab_beta in uspp_data and successive deletion the compilation of gipaw in qe 7.3.1 fails with the following error

~/Codes/QE/7.3.1-cmake/external/qe-gipaw/src/gipaw_setup.f90:524:36:

  524 |   USE uspp_data,     ONLY : nqx, dq, tab
      |                                    1
Error: Symbol ‘tab’ referenced at (1) not found in module ‘uspp_data’
~/Codes/QE/7.3.1-cmake/external/qe-gipaw/src/gipaw_setup.f90:546:21:

  546 |            d1 = (tab(2,nb,nt) - tab(1,nb,nt)) / dq
      |                     1
Error: Expected a right parenthesis in expression at (1)
~/Codes/QE/7.3.1-cmake/external/qe-gipaw/src/gipaw_setup.f90:547:34:

  547 |            call spline(xdata, tab(:,nb,nt), 0.d0, d1, tab_d2y(:,nb,nt))
      |                                  1
Error: Syntax error in argument list at (1)
~/Codes/QE/7.3.1-cmake/external/qe-gipaw/src/gipaw_setup.f90:536:28:

  536 |   allocate(tab_d2y, mold=tab)
      |                            1
Error: Symbol ‘tab’ at (1) has no IMPLICIT type

Changes since v.7.0

Changes needed to compile qe-gipaw with current QE development version:

1. FFTXlib => FFTXlib/src
2. gen_us_dj and gen_us_dy in module uspp_init

diff -wibr a/qe-gipaw-7.0/makedeps.sh.in b/qe-gipaw-7.0/makedeps.sh.in
8c8
< DEPENDS="${QE_SOURCE}/include ${QE_SOURCE}/FFTXlib/src
---
> DEPENDS="${QE_SOURCE}/include ${QE_SOURCE}/iotk/src
10c10
<          ${QE_SOURCE}/UtilXlib
---
>          ${QE_SOURCE}/FFTXlib ${QE_SOURCE}/UtilXlib
diff -wibr a/qe-gipaw-7.0/src/epr_routines.f90 b/qe-gipaw-7.0/src/epr_routines.f90
292c292
<   USE uspp_init,              ONLY : init_us_2, gen_us_dj, gen_us_dy
---
>   USE uspp_init,              ONLY : init_us_2
diff -wibr a/qe-gipaw-7.0/src/Makefile.in b/qe-gipaw-7.0/src/Makefile.in
11c11
<                $(MOD_FLAG)$(QE_SOURCE)/FFTXlib/src \
---
>                $(MOD_FLAG)$(QE_SOURCE)/FFTXlib \
diff -wibr a/qe-gipaw-7.0/src/nmr_routines.f90 b/qe-gipaw-7.0/src/nmr_routines.f90
240c240
<   USE uspp_init,              ONLY : init_us_2, gen_us_dj, gen_us_dy
---
>   USE uspp_init,              ONLY : init_us_2

Spin–orbit effects in GIPAW?

Dear GIPAW developers,

It is possible to include Spin–orbit effects in GIPAW? How could I do a Spin–orbit included GIPAW caculation? Or will be Spin–orbit effects available in GIPAW ?

Diagonalization methods mixed up?

I noticed that if no diagonalization is set in the input file, the output file says isolve=0 which should mean diagonalization = 'david' since this is the standard. So far ok. However, if I explicitly set diagonalization = 'david' in the input, the output says isolve=1 and for diagonalization = 'cg' in the input, the output says isolve=0. If I'm not mistaken, this should be the other way around, shouldn't it? The respective assignment should come from gipaw_routines.f90 (line 85 ff.). So, did I overlook something or is there a problem?

How to use the calculated results to simulate the EPR spectrum?

Dear authors,

I run the gipaw code and get the g-tensor, hyperfine coupling. I want to know is there any way to use these data to simulate the EPR spectrum?

I find EasySpin can simulate the EPR spectrum, but it doesn't support gipaw.

Thank you.

Fails to compile with QE 6.2

I have tried compiling the latest version with Quantum Espresso 6.2 but fail. The error seems to be in the interface of fft_type_descriptor (see attached log: error.log ). I can't use this new version in any other way, as make gipaw in QE 6.2 gives an error as their GIPAW version is still 6.1, and that version has a bug which causes symmetrized hyperfine tensors to become zero (from the commit messages, I imagine this was fixed in 6.2). Thanks!

source compatible with QE 6.1

Hi,

I would like to compile GIPAW with QE 6.1 (from https://gitlab.com/QEF/q-e/-/archive/qe-6.1.0/q-e-qe-6.1.0.tar.gz). This version of QE tries to download gipaw 6.0 from the qe forge which is not available anymore.
I tried to compile it with this release of gipaw: https://github.com/dceresoli/qe-gipaw/archive/old_6.1.tar.gz, but it raises a compatibility error with QE 6.1.
Would you have an idea on how I could find a version of gipaw compatible with QE 6.1 ?

additional information on GIPAW-pseudopotentials

<PP_GIPAW_RECONSTRUCTION_DATA> offers additional AE_ORBITALS and PS_ORBITALS but does not offer additional projectors except those that already existed in traditional PP. Aren't they necessary?

Can we compile GIPAW in QE using NVHPC Toolkit?

I am trying to compile QE 7.2 with CMAKE and adding the -DQE_ENABLE_PLUGINS="gipaw" -DQE_ENABLE_FOX=ON but that fails. My question is, does gipaw plugin compile with NVHPC version 23.5? I can provide more details if that helps in determining what might be causing the issue for me.

CMAKE:
cmake -DCMAKE_C_COMPILER=mpicc -DCMAKE_Fortran_COMPILER=mpif90 -DQE_ENABLE_CUDA=ON -DQE_ENABLE_MPI_GPU_AWARE=ON -DNVFORTRAN_CUDA_CC=80 -DOpenMP_C_FLAGS=-fopenmp=lomp -DOpenMP_C_LIB_NAMES="libomp" -DOpenMP_libomp_LIBRARY="/hpc/software/spack_v20d1/spack/opt/spack/linux-rhel7-x86_64/gcc-10.4.0/nvhpc-23.3-exveznevn5vxtasxdjnusl262dfdamvf/Linux_x86_64/23.3/compilers/lib/libomp.so" -DQE_ENABLE_OPENMP=ON -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO -DQE_ENABLE_OPENACC=ON -DQE_ENABLE_FOX=ON -DQE_ENABLE_PLUGINS="gipaw" -DCMAKE_Fortran_FLAGS="-fast -O3" ../

Thanks,
Sai

Cannot compile with qe 7.2

Hi,

I've got a working version of qe7.2 configured in my system, when following the instructions for standalone installation of gipaw

./configure --with-qe-source "path..." I am returned with the error "configure: error: cannot compile against this version of quantum espresso",

I am just wondering, is this a known issue? I see in the closed issues that users are able to compile with QE 7.3.1, is there a modification required to the configure file or will I need to compile an alternative QE verision?

ANy advice is greatly appreciated.

Errors compiling on gpu cluster

Hello!

I'm trying to compile qe-gipaw on a gpu cluster. After following the instructions for compilation, I get the following errors:

ftn -acc -cuda -gpu=cc80,cuda11.0 -acc -o gipaw.x gipaw_module.o gipaw_main.o paw_gipaw.o stop_code.o gipaw_setup.o gipaw_routines.o gipaw_routines_bands.o greenfunction.o orthoatwfc1.o cgsolve_all.o h_psiq.o cg_psi.o symmetrize_rho.o symmetrize_field.o ch_psi_all.o compute_u_kq.o suscept_crystal.o j_para.o biot_savart.o init_gipaw_1.o init_gipaw_2.o init_us_2_no_phase.o write_tensor_field.o velocity.o nmr_routines.o epr_routines.o efg.o hyperfine.o core_relax.o util.o atomic.o knight_shift.o mossbauer.o gipaw_version.o output_magres.o gipaw_results.o xml_routines.o /global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/PW/src/libpw.a /global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/Modules/libqemod.a /global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/MBD/libmbd.a /global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/KS_Solvers/Davidson/libdavid.a /global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/KS_Solvers/CG/libcg.a /global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/KS_Solvers/PPCG/libppcg.a /global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/KS_Solvers/libks_solvers.a /global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/FFTXlib/libqefft.a /global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/LAXlib/libqela.a /global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/UtilXlib/libutil.a /global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/upflib/libupf.a /global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/dft-d3/libdftd3qe.a /global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/LR_Modules/liblrmod.a /global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/XClib/xc_lib.a /global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/UtilXlib/libutil.a -L/global/common/software/nersc/pm-2021q4/sw/libxc/v5.2.2/pm-gpu/lib -lxcf03 -lxc -cudalib=cufft,cublas,cusolver,curand /global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0//external/devxlib/src/libdevXlib.a /global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0//EIGENSOLVER_GPU/lib_eigsolve/lib_eigsolve.a -L/global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0//external/devxlib/src -ldevXlib -L/opt/cray/libfabric/1.11.0.4.114/lib64 -lopenblas -L/global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0//FoX/lib -lFoX_dom -lFoX_sax -lFoX_wxml -lFoX_common -lFoX_utils -lFoX_fsys -lopenblas
nvlink error : Multiple definition of 'gpu_threaded_backassign_380_gpu' in '/global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/KS_Solvers/libks_solvers.a:generic_cublas.o', first defined in '/global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/KS_Solvers/PPCG/libppcg.a:generic_cublas.o'
nvlink error : Multiple definition of 'gpu_threaded_backassign_371_gpu' in '/global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/KS_Solvers/libks_solvers.a:generic_cublas.o', first defined in '/global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/KS_Solvers/PPCG/libppcg.a:generic_cublas.o'
nvlink error : Multiple definition of 'gpu_threaded_assign_327_gpu' in '/global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/KS_Solvers/libks_solvers.a:generic_cublas.o', first defined in '/global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/KS_Solvers/PPCG/libppcg.a:generic_cublas.o'
nvlink error : Multiple definition of 'gpu_threaded_assign_320_gpu' in '/global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/KS_Solvers/libks_solvers.a:generic_cublas.o', first defined in '/global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/KS_Solvers/PPCG/libppcg.a:generic_cublas.o'
nvlink error : Multiple definition of 'gpu_threaded_memset_272_gpu' in '/global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/KS_Solvers/libks_solvers.a:generic_cublas.o', first defined in '/global/common/software/nersc/pm-2021q4/sw/qe/qe-7.0/KS_Solvers/PPCG/libppcg.a:generic_cublas.o'
nvlink fatal : merge_elf failed
pgacclnk: child process exit status 2: /opt/nvidia/hpc_sdk/Linux_x86_64/21.11/compilers/bin/tools/nvdd
make[1]: *** [Makefile:62: gipaw.x] Error 2
make[1]: Leaving directory '/global/u2/p/punzu001/software/qe-gipaw/src'
make: *** [Makefile:7: build] Error 2

This seems to be related to this post on the nvidia forums: https://forums.developer.nvidia.com/t/nvlink-error-multiple-definition-errors-when-linking-to-the-same-library-twice/62892

Any help to remedy this compilation would be greatly appreciated!

Is conda installation available for qe-gipaw?

Is conda installation available for qe-gipaw?

It seems gipaw.x is not included with default qe conda installation...

Knight shift

When should we expect Knight shift?

More calculation metadata in the .magres file

Hi!

Would it be possible to include more calculation metadata in the [calculation] block of the .magres files?

i.e. here:

qe-gipaw/src/output_magres.f90

Line 127 in 100c4c5

! ... Output <calculation> block and close file

This would be very useful for future entries in e.g. the CCP-NC database, making them more FAIR. As an example, CASTEP outputs the following sort of information:

calc_code CASTEP
calc_code_version  16.1
calc_code_hgversion f8ea1bd8badc+  Tue, 08 Dec 2015 11:54:45 +0000                  
calc_code_platform linux_x86_64_ifort15                                            
calc_name ethanol_crystal
calc_comment                                                                                 
calc_xcfunctional PBE 
calc_cutoffenergy    800.00000000 eV
calc_pspot H 1|0.6|13|15|17|10(qc=8)
calc_pspot C 2|1.4|10|12|13|20:21(qc=7)
calc_pspot O 2|1.1|15|18|20|20:21(qc=7)
calc_kpoint_mp_grid 3 2 2
calc_kpoint_mp_offset       0.00000000      0.00000000      0.00000000

Adding in as much relevant information as possible would be helpful, ideally following a similar naming convention to CASTEP, where possible.

Many thanks!

Source compatible to QE6.4

Dear Sir,

Quantum espresso install/plugins_list have listed the qe-gipaw version as follows,

Package maintainer: Davide Ceresoli

GIPAW=qe-gipaw-6.4
GIPAW_URL=https://github.com/dceresoli/qe-gipaw/archive/6.4.tar.gz

I'm having some issues with the compilation of gipaw with make command.

Is this the write version ?

Preprocessor failure with gfortran in xml_routines.f90 in 7.0

The macros in xml_routines.f90 use the stringification feature #x of the preprocessor which is not available in the "traditional" cpp mode that the GNU toolchain uses to preprocess code.

This leads to several compilation failures like the following as the # is emitted verbatim into the resulting source file:

xml_routines.f90:96:31:

   96 |     _NE(general_info)
      |                               1
Error: Syntax error in argument list at (1)

Manual expansion of the macros that use # (splitting the longer ones into multiple lines due to line lengths) compiles properly.

This is building via EasyBuild and its foss/2021b and intel/2021b toolchains, Intel seems unaffected.

Builds with QE 7.0 with CUDA support

Hi,

I have built QE 7.0 with CUDA support successfully under '/path/to/qe-7.0-src/
./configure --with-cuda=/software/nvhpc-20.11-el8-x86_64/Linux_x86_64/20.11/cuda --with-cuda-cc=70 --with-cuda-runtime=11.1 --prefix=/path/to/qe-7.0-src/install make all -j4 make install
The binaries are generated under install/bin as expected.

Then, I did make gipaw with QE 7.0 and got a bunch of errors at the final linking stage:
mpif90 -cuda -gpu=cc70,cuda11.1 -acc -o gipaw.i gipaw_module.o gipaw_main.o ....

nvlink error : Multiple definition of 'gpu_threaded_backassign_380_gpu' in '/path/to/qe-7.0-src/KS_Solvers/libks_solvers.a:generic_cublas.o', first defined in '/path/to/qe-7.0-src/KS_Solvers/PPCG/libppcg.a:generic_cublas.o' nvlink error : Multiple definition of 'gpu_threaded_backassign_327_gpu' in '/path/to/qe-7.0-src/KS_Solvers/libks_solvers.a:generic_cublas.o', first defined in '/path/to/qe-7.0-src/KS_Solvers/PPCG/libppcg.a:generic_cublas.o'

and the last message was
nvlink fatal : merge_elf failed
It seems that these _gpu symbols are defined in the libraries libks_solvers.a and lib_ppcg.a.

I am wondering if this issue has been raised and resolved before, and if they are due to the upstream QE with CUDA support, and has nothing to do with gipaw. Any suggestions would be highly appreciated.

Thanks,
-Trung

unit of the input geometry

I ran nmr calculations with QE/GIPAW 6.1 and the same input geometries but with different units (one in angstrom and the other in bohr) and the resulting nmr shielding are different (see attached file).

What could be the reason for such discrepancy ?

CILWUP11.zip

Can qe-gipaw calculate zero-field splitting now?

Dear authors,
I am trying to calculate zero-field splitting (zfs) using qe-gipaw. The paper published in 2017 (https://iopscience.iop.org/article/10.1088/1361-648X/aa8f79/meta) said the zfs was being implemented. However, I didn't find any example for the calculation of zfs.
So, can qe-gipaw calculate zero-field splitting now? If so, could you please give me some guidance?
Any suggestions from you will be greatly appreciated.

Yours sincerely
Lin