Giter Club home page Giter Club logo

vasp2wan90_v2_fix's Introduction

VASP2WAN90_v2_fix

This project provides a patch for the VASP code, fixing the VASP2WANNIER90v2 interface with additional abilities.

Abilities

  • Calculate non-collinear Wannier functions.
  • Support spinor projection method (specify spinor channel, quantization axis).
  • New and improved UNK files:
    • Write non-collinear UNK files (UNKxxxxx.NC).
    • Choose the format of the UNK files.
    • Reduce the size of the UNK files.
  • Write .spn files.
    • Choose the format of the .spn files
  • Control which collinear spin channel to compute.
  • Control whether to calculate/write .mmn and .amn files.

Installation

Important

THIS FIX ONLY WORKS WITH VASP v5.4.4.pl2

For this patch to work, you have to recompile VASP. If you are not familiar with VASP's compilation process, click ๐Ÿ”— HERE. Also, you need a compiled libwannier.a. If you don't know what it is, check out wannier90's user guide.

To apply the patch, put the mlwf.patch file in the root directory (not under src) of your VASP distro and type:

$ patch -p0 < mlwf.patch

Then, compile the code with -DVASP2WANNIER90v2 precompile flag alone with the wannier90 library libwannier.a

CPP_OPTIONS+=-DVASP2WANNIER90v2
LLIBS+=/path/to/your/wannier90_distro/libwannier.a

Usage

The VASP2WANNIER90 interface is fully incorporated in the VASP package, this means we don't need another executable to run it. The interface is enabled by specific keywords in the INCAR file.

For full documentation, see wiki.

Keywords

A list of useful keywords:

Tag meaning value default
LWANNIER90 Do we want to use the interface? TRUE/FALSE FALSE
W90_SPIN Which collinear spin channel to compute? 0->all,1->up,2->down 0->all
LCALC_MMN Do we want calculate mmn matrix? TRUE/FALSE TRUE
LCALC_AMN Do we want calculate amn matrix? TRUE/FALSE TRUE
LWRITE_MMN Do we want to write .mmn file? TRUE/FALSE TRUE
LWRITE_AMN Do we want to write .mmn file? TRUE/FALSE TRUE
LWRITE_EIG Do we want to write .eig file? TRUE/FALSE TRUE
LWRITE_UNK Do we want the UNK files? TRUE/FALSE FALSE
LUNK_FMTED Do we want the UNK files be human-readable? TRUE/FALSE FALSE
LREDUCE_UNK Do we want the UNK files be reduced in size? TRUE/FALSE FALSE
LWRITE_SPN Do we want the .spn files? (Serial only) TRUE/FALSE FALSE
LSPN_FMTED Do we want the .spn files be human-readable? TRUE/FALSE FALSE

How to cite

Citation of the code is not mandatory but would be appreciated. A reference to this website using this BibTeX entry will suffice.

Contributing

Issues and pull-requests are welcome, feel free to ask anything E-mail.

vasp2wan90_v2_fix's People

Contributors

chengcheng-xiao 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

Watchers

 avatar  avatar  avatar  avatar  avatar

vasp2wan90_v2_fix's Issues

Regarding VASP2WANNIER Spn file

In the vasp2wannier calculation. I am using vasp6.3 with wannier90-developer code
I am trying to calculate the spin hall conductivity when I am running postw90.x it is showing an error in opening input file wannier90.spn.
But vasp6.3.0 is not generating wannier90.spn file
so I used vasp5.4 with wannier to generate the wannier90.spn file after that I ran vasp6.3 with wannier but it is showing
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Please suggest me, how to resolve this problem.
Thank you in advance

write UNK.NC file?

This seems to be easier than the .spn file.

So, do this first.

WVFN(IND)=WCOLLECT(ISTRIP)%CR(NX+(NC-1)*WP%WDES%GRID%RL%NROW)

By the looks of it, we only need to halve the CR array and output it to two WVFN arrays and then print it out.

Add ability to choose spin channel? (collinear)

By default, we loop over all spin channle:

spin: DO ISP=1,WDES%ISPIN

This could be fixed by just adding a W90_spin tag to choose which channel we want.

Moreover, we should be able to use different projections for different spin channel ( using *.up.win and *.dn.win files ).

For this to work, we need to change seed_name.

MPI issue?

Dear all,

I'd like to share my recent experience in case it may help others facing a similar issue in the future. I successfully resolved the problem by recompiling VASP with the patch available at https://github.com/Chengcheng-Xiao/VASP2WAN90_v2_fix. After recompiling, it's important to note that you should run VASP using only a SINGLE CPU core to generate mmn, amn, and spn. I encountered the same underestimation issue when attempting to generate mmn and amn using multiple CPUs. While I'm not an expert, I suspect this might be related to the use of openmpi or some other factor. Therefore, if you're struggling to obtain correct results, I recommend trying this patch and SINGLE CPU approach (note: reading converged WAVECAR and CHGCAR makes the SINGLE CPU approach affordable). Good luck!

Regards,
Hongyang

Originally posted by @ma455173220 in wannier-berri/wannier-berri#274 (comment)

Plotting MLWFs

Hi Xiao,
Hope you are good.
I want to plot and visualize the spread of maximally localized wannier functions (though I can see the latter in the output file).
If you don't mind sharing what workflow I should follow?
For example,
Step 1: SOC-SCF calculation
Step 2: Reading SOC-SCF with ICHARG=11, LWANNIER90=.TRUE. and generating wannier inputs
Step 3: ..???
I read that I need to set Wannier_plot=.true. but I am not sure at which step I should do this because this needs UNK files.
P.S> I am using vasp5.4.4 compiled with this patch.
Thanks in advance.

spin component y in .spn output might be wrong

in the .patch file line 1446 we have:

  •                CALL ECCP_NL_SPN(LMDIM,LMMAXC,CMPLX(0._q,1._q,q),CQIJ(1,1,NI,1+1+2*1),W2%CPROJ(NPRO_+1),W1%CPROJ(NPRO+1),CNLy)
    

Should that be:

  •                CALL ECCP_NL_SPN(LMDIM,LMMAXC,CMPLX(0._q,1._q,q),CQIJ(1,1,NI,1+1+2*0),W2%CPROJ(NPRO_+1),W1%CPROJ(NPRO+1),CNLy)
    

Just to be consistent with the Pauli matricies.

collinear spin calculations

Somehow, when doing collinear spin calculations, the code skips "number of bands" or "number of projections" error. If they occur, the whole calculation will just stop. Worth looking into.

write spn files.

Thanks for your excellent code!
As you mentioned in the list of keywords, the spn file can be only written when VASP is exerted in serial. However, it is very time-consuming. Is there any solution that makes VASP is exerted in parallel (or only becomes serial when writing spn file, remaining parallel when doing other parts)?

Does your patch works for VASP 6.12?

Dear Mr. Xiao

May I consult you that does your patch can be applied to VASP 6.12 as well?

My current VASP is version 6.12, and I am also running into projection problems when SOC is included. I would like to know your comments on this regarding using VASP version 6.12. Can you help? Tks!

with regards,
Peter

Spinor projector not done right

With spinor calculation (LNONCOLLINEAR = .TRUE.), the spinor projection (i.e. C:pz(d) for Carbon's pz spin_2 channel orbital) is not done right.

Considering without spinor projection the projection yields correct result, I am thinking the ignored projections are, as a matter of fact, the spin_2 channel.

After checking with parameters.F90 in the WANNIER90 distro, this is exactly the case. A better fix would uses proj_s as the spin channel identifier, may even consider proj_s_qaxis for quantisation axis.

For now, I will only update the fix so that the spin channel in the projection scheme (using (d) or (u) for down and up channel) can work.

Add spin quantisation axis support

The fix now reads in proj_s_qaxis. But all spinor projections are done without rotation of quantisation axis.

If Im not mistaken, the rotated spinor eigenvectors can be dotted directly onto the A_mn when the PAW pseudopotential is used (According to PW2WANNIER90.F90 for pwscf v6.4):

! general routine
! for quantisation axis (a,b,c) 
! 'up'    eigenvector is 1/sqrt(1+c) [c+1,a+ib]
! 'down'  eigenvector is 1/sqrt(1-c) [c-1,a+ib]
if(spin_eig(iw)==1) then
   fac(1)=(1.0_dp/sqrt(1+spin_qaxis(3,iw)))*(spin_qaxis(3,iw)+1)*cmplx(1.0d0,0.0d0,dp)
   fac(2)=(1.0_dp/sqrt(1+spin_qaxis(3,iw)))*cmplx(spin_qaxis(1,iw),spin_qaxis(2,iw),dp)
else
   fac(1)=(1.0_dp/sqrt(1-spin_qaxis(3,iw)))*(spin_qaxis(3,iw)-1)*cmplx(1.0d0,0.0d0,dp)
   fac(2)=(1.0_dp/sqrt(1-spin_qaxis(3,iw)))*cmplx(spin_qaxis(1,iw),spin_qaxis(2,iw),dp)
endif
ibnd1 = 0
DO ibnd = 1,nbnd
   IF (excluded_band(ibnd)) CYCLE
   amn=(0.0_dp,0.0_dp)
   DO ipol=1,npol
      istart = (ipol-1)*npwx + 1
      amn_tmp=(0.0_dp,0.0_dp)
      if (any_uspp) then
        amn_tmp = zdotc(npw,evc(istart,ibnd),1,sgf_spinor(istart,iw),1)
        CALL mp_sum(amn_tmp, intra_pool_comm)
        amn=amn+amn_tmp
      else
        amn_tmp = zdotc(npw,evc(istart,ibnd),1,sgf(1,iw),1)                        
        CALL mp_sum(amn_tmp, intra_pool_comm)
        amn=amn+fac(ipol)*amn_tmp
      endif
   enddo
   ibnd1=ibnd1+1
   IF (wan_mode=='standalone') THEN
      IF (ionode) WRITE(iun_amn,'(3i5,2f18.12)') ibnd1, iw, ik, amn
   ELSEIF (wan_mode=='library') THEN
         a_mat(ibnd1,iw+n_proj*(ipol-1),ik) = amn
      ELSE
         CALL errore('compute_amn',' value of wan_mode not recognised',1)
      ENDIF
   ENDDO
endif

The same could be done in VASP2WANNIER90 interface.

.spn file?

The spn file contains:

  • <\psi_m| S | \psi_n>, where S is the Pauli matrix, the pseudo part.
  • <\psi_m| \sigma_{ij} q_{ij} |\beta_i> <\beta_j| |\psi_n>, the augmentation part.

The pseudo part can be easily obtained. For the augmentation part, refer to pw2wannier90.f90 (line 2469)
and VASP's PEAD_CALC_OVERLAP and CALC_OVERLAP_GN.

Direction of magnetization

Hi Chengcheng,

Thanks for the nice codes. I have a question regarding the direction of magnetization. In your example04 or the example18 from wannier90 tutorial, the magnetization is set to parallel to the minus z direction then the calculated AHC is positive. If we reverse the magnetization, the AHC will become negative. I want to study some other materials. Except for symmetry analysis, is there a better way to study the dependence of magnetization on AHC rather than reconstructing the wannierisation from scratch?

Thanks,
Wuzhang Fang

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.