It is well known that VASP has several optional features that interface with several third-party libraries, some of which also support/require Intel MKL for more efficient computing and data processing, for example, wannier90.
So, I want to know, in these situations, should I use the exactly same Intel MKL link line and compiler options to compile vasp and its 3rd interfaced libraries?
Regards,
HZ
The MKL link line advisor relates only to linking, so it won’t affect code you compile. Similarly, if you are linking against precompiled libraries that use MKL, the MKL options are not relevant until you link the executable. You will want to add those options for linking the application, but not for compiling.
Still not so clear. Let me describe it in more detail as follows as an example.
vasp compiles with the following MKL settings:
FCL += -qmkl=parallel
LLIBS += -L${MKLROOT}/lib/intel64 -lmkl_scalapack_lp64 -lmkl_blacs_intelmpi_lp64 -liomp5 -lpthread -lm -ldl
INCS =-I$(MKLROOT)/include/fftw
[...]
# For the VASP-2-Wannier90 interface (optional)
CPP_OPTIONS += -DVASP2WANNIER90
WANNIER90_ROOT ?= /path/to/your/wannier90/installation
LLIBS += -L$(WANNIER90_ROOT)/lib -lwannier
Here, the Wannier90 interface linked above is a static library created with different MKL link line settings:
$ ldd ~/Public/repo/github.com/wannier-developers/wannier90/develop/lib/libwannier.a
not a dynamic executable
In this case, can I always obtain an ultimate working interface combined into vasp?
Regards,
HZ
Regarding MKL, what matters is which set of MKL routines is being called (and things such as ilp64, etc.) Wannier90 might require some additional MKL libraries, but you haven’t shown anything MKL-specific for Wannier90, so I have no advice for you.
If the application builds without ld errors, it’s likely that the MKL settings are correct.
In this situation, Wannier90 uses the following MKL-specific settings:
$ cat make.inc
#=====================================================
# For Linux with intel version 11/12 on 64bit machines
#=====================================================
F90 = ifort
COMMS=mpi
MPIF90=mpiifort
FCOPTS=-O2
LDOPTS=-O2
#========================================================
# Intel mkl libraries. Set LIBPATH if not in default path
#========================================================
LIBDIR = ${MKLROOT}/lib/intel64
LIBS = -L$(LIBDIR) -lmkl_core -lmkl_intel_lp64 -lmkl_sequential -lpthread
#=======================
# ATLAS Blas and LAPACK
#=======================
#LIBDIR = /usr/local/lib
#LIBS = -L$(LIBDIR) -llapack -lf77blas -lcblas -latlas
Yes. vasp compiles smoothly with the above configuration, and I noticed the following information in the final stage of vasp compilation:
make DEPS=1 -j 44 all
[...]
mpiifort -qmkl=parallel -o vasp c2f_interface.o nccl2for.o simd.o base.o profiling.o string.o tutor.o version.o command_line.o vhdf5_base.o incar_reader.o reader_base.o openmp.o openacc_struct.o mpi.o mpi_shmem.o mathtools.o hamil_struct.o radial_struct.o pseudo_struct.o mgrid_struct.o wave_struct.o nl_struct.o mkpoints_struct.o poscar_struct.o afqmc_struct.o fock_glb.o chi_glb.o smart_allocate.o xml.o extpot_glb.o constant.o ml_ff_c2f_interface.o ml_ff_prec.o ml_ff_constant.o ml_ff_taglist.o ml_ff_struct.o ml_ff_mpi_help.o ml_ff_mpi_shmem.o vdwforcefield_glb.o jacobi.o main_mpi.o openacc.o scala.o asa.o lattice.o poscar.o ini.o mgrid.o ml_ff_error.o ml_ff_mpi.o ml_ff_helper.o ml_ff_logfile.o ml_ff_math.o ml_ff_iohandle.o ml_ff_memory.o ml_ff_abinitio.o ml_ff_ff.o ml_ff_mlff.o setex_struct.o xclib.o vdw_nl.o xclib_grad.o setex.o radial.o pseudo.o gridq.o ebs.o symlib.o mkpoints.o random.o wave.o wave_mpi.o wave_high.o bext.o spinsym.o symmetry.o lattlib.o nonl.o nonlr.o nonl_high.o dfast.o choleski2.o mix.o hamil.o xcgrad.o xcspin.o potex1.o potex2.o constrmag.o cl_shift.o relativistic.o LDApU.o paw_base.o metagga.o egrad.o pawsym.o pawfock.o pawlhf.o diis.o rhfatm.o hyperfine.o fock_ace.o paw.o mkpoints_full.o charge.o Lebedev-Laikov.o stockholder.o dipol.o solvation.o scpc.o pot.o tet.o dos.o elf.o hamil_rot.o chain.o dyna.o fileio.o vhdf5.o sphpro.o us.o core_rel.o aedens.o wavpre.o wavpre_noio.o broyden.o dynbr.o reader.o writer.o xml_writer.o brent.o stufak.o opergrid.o stepver.o chgloc.o fast_aug.o fock_multipole.o fock.o fock_dbl.o fock_frc.o mkpoints_change.o subrot_cluster.o sym_grad.o mymath.o npt_dynamics.o subdftd3.o subdftd4.o internals.o dynconstr.o dimer_heyden.o dvvtrajectory.o vdwforcefield.o nmr.o pead.o k-proj.o subrot.o subrot_scf.o paircorrection.o rpa_force.o ml_interface.o force.o pwlhf.o gw_model.o optreal.o steep.o rmm-diis.o davidson.o david_inner.o root_find.o lcao_bare.o locproj.o electron_common.o electron.o rot.o electron_all.o shm.o pardens.o optics.o constr_cell_relax.o stm.o finite_diff.o elpol.o hamil_lr.o rmm-diis_lr.o subrot_lr.o lr_helper.o hamil_lrf.o elinear_response.o ilinear_response.o linear_optics.o setlocalpp.o wannier.o electron_OEP.o electron_lhf.o twoelectron4o.o gauss_quad.o m_unirnk.o minimax_ini.o minimax_dependence.o minimax_functions1D.o minimax_functions2D.o minimax_struct.o minimax_varpro.o minimax.o umco.o mlwf.o ratpol.o pade_fit.o screened_2e.o wave_cacher.o crpa.o chi_base.o wpot.o local_field.o ump2.o ump2kpar.o fcidump.o ump2no.o bse_te.o bse.o time_propagation.o acfdt.o afqmc.o rpax.o chi.o acfdt_GG.o dmft.o GG_base.o greens_orbital.o lt_mp2.o rnd_orb_mp2.o greens_real_space.o chi_GG.o chi_super.o sydmat.o rmm-diis_mlr.o linear_response_NMR.o wannier_interpol.o wave_interpolate.o linear_response.o auger.o dmatrix.o phonon.o wannier_mats.o elphon.o core_con_mat.o embed.o extpot.o rpa_high.o fftmpiw.o fftmpi_map.o fftw3d.o fft3dlib.o main.o -Llib -ldmy -Lparser -lparser -lstdc++ -L/opt/intel/oneapi/mkl/2022.0.2/lib/intel64 -lmkl_scalapack_lp64 -lmkl_blacs_intelmpi_lp64 -liomp5 -lpthread -lm -ldl -L/home/werner/Public/repo/github.com/wannier-developers/wannier90/develop/lib -lwannier
make[2]: Leaving directory '/home/werner/Public/hpc/vasp/vasp.6.3.0/build/ncl'
make[1]: Leaving directory '/home/werner/Public/hpc/vasp/vasp.6.3.0/build/ncl'
make[2]: Leaving directory '/home/werner/Public/hpc/vasp/vasp.6.3.0/build/std'
make[1]: Leaving directory '/home/werner/Public/hpc/vasp/vasp.6.3.0/build/std'
make[2]: Leaving directory '/home/werner/Public/hpc/vasp/vasp.6.3.0/build/gam'
make[1]: Leaving directory '/home/werner/Public/hpc/vasp/vasp.6.3.0/build/gam'
If I understand correctly, the static library libwannier.a will be linked as is into vasp, and the MKL settings of vasp will only affect the stuff in vasp itself. This will also be the behavior of the MKL subroutine, which will be used for subsequent calls of these third-party libraries from within vasp. To summarize: In terms of the MKL feature invoked, merging a static library into another program with different MKL link settings does not interfere with each other.
Regards,
HZ