From Arash:
With the benzene example, if I run a wannierisation, and then do a second run setting "restart = wannierise” (or indeed plot) I get an error

forrtl: severe (24): end-of-file during read, unit 11, file /export111/work/aam/w90-examples/example12-val/benzene.chk

Or:
example01, example02 etc: instead of the end-of-file error on reading .chk files, I sometimes get the following error on the first cycle of the restart:

Cycle:      1
 wann_main: ZHEEV in internal_new_u_and_m failed, info=            3
            trying Schur decomposition instead
 wann_main: SCHUR failed, info=            4
 Exiting.......
 wann_main: problem computing schur form 1

Now, it is not applied while plotting and while printing the actual WF centres on the output

• Add correct contributors (README.txt and docs)
• There are lots of on_root check in param_read. This should only be called on the root node, so remove this and add a check at the beginning. (Fixed in #185)
• Move comms.F90 in the main src folder rather than in src/postw90? (Fixed in #185)

Change the code so it becomes F2003 compliant.
The issue should be in the my_ICOPY routine in postw90/comms.F90 (we should probably move it into the module, and make an interface for arrays of different shape).

Hi all,

I got a strange error while playing around with the postproc_setup mode: When I set spinors = true in an input file for Bi, I get an IEEE_denormal exception. The program doesn't crash, but instead the .nnkp file contains invalid output (*** instead of a number).

I can look into where the exception comes from, but I'd be glad if you could tell me if there's something obviously wrong with my input file. In that case we should just add some test to the input parsing section and throw a nicer error.

wannier.nnkp.txt
wannier.win.txt
wannier.wout.txt

In both postw90 and the main routines we have an issue when there are fewer k-points than nodes. We need to re-write some of the MPI calls to handle this in a way that avoids accessing unallocated data

Make a new module that writes files including rmn, r2mn, u_matrix etc.

There are a number of suggestions of missing features of the library mode, improvements and suggestions. Please reply to this issue with your comments.

We need to update the memory estimate to cope with the new arrays added with preconditioning

Because some mail programs etc. delete the attachement if one of the files has extension .sys (also if zipped).
This has been done in QE, should be done also in W90

Dear Paolo and Lorenzo,

I've also modify the make.sys from EPW to make.inc.

There is however a bug with Wannier90.

From a thread of the QE developers (about the EPW code):

You changed the line
cp ../install/make_wannier90.sys ../W90/make.inc

However, the
wannier90-2.0.1/src/Makefile.2

file that is shipped with the wannier tar file, still contain "make.sys"
inside. Therefore Wannier90 does not compile.

The easiest solution seems to be to rename /install/make_wannier90.sys into
/install/make_wannier90.inc and then to do

cp ../install/make_wannier90.inc ../W90/make.sys

in the Makefile. That should avoid Lorenzo problem and ensure
compatibility with w90.

• plotting WFs for calculations with spin-orbit interaction

What follows is valid and tested for ifort, but I guess this is what most people use...
When dealing with large systems (hence large matrices), wannier90 can crash in segmentation fault without giving hints to what happened (actually a memory issue).
Compiling with the -heap-arrays option solves it (it puts arrays on the heap instead of the stack), but I guess "inexperienced" users would struggle a lot before finding this out.
I was thinking to put a comment line in the config/make.inc.ifort suggesting to try -heap-arrays if the code crashes in segmentation fault when dealing with large matrices. I would not make -heap-arrays default, as it usually slows down a bit the calculations.
What do you think?
Antimo

Make dist doesn't work (at least on my mac).
Make clean / veryclean needs to clean the documentation, test-suite etc

• Review, feedback and finalise
• Add link to the BuildBot test farm, URL: http://130.186.13.169:8010/#/builders
• Add updated FORD docs

Hello
I can't get wannier90.amn file from VASP. I tried LWRITE_MMN_AMN but it didn't work.
I use the Wannier90 1.2 version.
Anyone knows why?

Dear all,

The full buildbot test-farm should now be passing except "WAN-farmer_intel13".
http://129.67.86.21:8010/builders/WAN-farmer_intel13/builds/21/steps/test_wannier/logs/stdio

I looked into it but could not solve it.

The bot uses intel 13.1.3 with openmpi 1.8.8.

The make.inc used can be found in wannier90/test-suite/config/EPW_testfarm/farmer_intel13.inc

When run in parallel with 4 mpi I do not get any error but the silicon_geninterp.dat contain mostly 0 ...

# Written on 19Sep2016 at 18:59:49 
# Input file comment: Sample points for testing implementation
#  Kpt_idx  K_x (1/ang)       K_y (1/ang)        K_z (1/ang)       Energy (eV)      EnergyDer_x       EnergyDer_y       EnergyDer_z
         1  0.2328140398      0.2328140398      0.2328140398       0.000000000       0.000000000       0.000000000       0.000000000
         1  0.2328140398      0.2328140398      0.2328140398       0.000000000       0.000000000       0.000000000       0.000000000
         1  0.2328140398      0.2328140398      0.2328140398       0.000000000       0.000000000       0.000000000       0.000000000
         1  0.2328140398      0.2328140398      0.2328140398       0.000000000       0.000000000       0.000000000       0.000000000
         1  0.2328140398      0.2328140398      0.2328140398       0.000000000       0.000000000       0.000000000       0.000000000
         1  0.2328140398      0.2328140398      0.2328140398       0.000000000       0.000000000       0.000000000       0.000000000
         1  0.2328140398      0.2328140398      0.2328140398       0.000000000       0.000000000       0.000000000       0.000000000
         1  0.2328140398      0.2328140398      0.2328140398       0.000000000       0.000000000       0.000000000       0.000000000
         2 -0.1746105299      0.1746105299      0.1746105299       0.000000000       0.000000000       0.000000000       0.000000000
         2 -0.1746105299      0.1746105299      0.1746105299       0.000000000       0.000000000       0.000000000       0.000000000
         2 -0.1746105299      0.1746105299      0.1746105299       0.000000000       0.000000000       0.000000000       0.000000000
         2 -0.1746105299      0.1746105299      0.1746105299       0.000000000       0.000000000       0.000000000       0.000000000
         2 -0.1746105299      0.1746105299      0.1746105299       0.000000000       0.000000000       0.000000000       0.000000000
         2 -0.1746105299      0.1746105299      0.1746105299       0.000000000       0.000000000       0.000000000       0.000000000
         2 -0.1746105299      0.1746105299      0.1746105299       0.000000000       0.000000000       0.000000000       0.000000000
         2 -0.1746105299      0.1746105299      0.1746105299       0.000000000       0.000000000       0.000000000       0.000000000
         3   0.000000000       2.048763551       0.000000000       0.000000000       0.000000000       0.000000000       0.000000000
         3   0.000000000       2.048763551       0.000000000       0.000000000       0.000000000       0.000000000       0.000000000
         3   0.000000000       2.048763551       0.000000000       0.000000000       0.000000000       0.000000000       0.000000000
         3   0.000000000       2.048763551       0.000000000       0.000000000       0.000000000       0.000000000       0.000000000
         3   0.000000000       2.048763551       0.000000000       0.000000000       0.000000000       0.000000000       0.000000000
         3   0.000000000       2.048763551       0.000000000       0.000000000       0.000000000       0.000000000       0.000000000
         3   0.000000000       2.048763551       0.000000000       0.000000000       0.000000000       0.000000000       0.000000000
         3   0.000000000       2.048763551       0.000000000       0.000000000       0.000000000       0.000000000       0.000000000

PS: It seems I cannot add "labels" .

• Add the missing information so that that already at step zero one can get all the necessary information, in particular e.g. the contributions to the spread (that are currently printed only from iteration 1).
• Add an example to show how to use it

E.g. in the band interpolation and in BoltzWann as well (maybe scissors_shift already works properly in all the code of postw90.x, but this needs to be checked).

Hello,

Currently it does not compile with NAG:

Error: ../postw90/comms.F90: Argument ZX (no. 2) in reference to MY_ICOPY from COMMS_SCATTERV_INT is not an array
Error: ../postw90/comms.F90: Argument ZY (no. 4) in reference to MY_ICOPY from COMMS_SCATTERV_INT is not an array
[NAG Fortran Compiler error termination, 2 errors, 62 warnings]

The way I solved it (not necessarily the prettiest ...

command=["sed","-i","s/    integer :: iargc/!    integer :: iargc/g","wannier90-2.0.1/src/io.F90" ],
command=["sed","-i","s/#ifdef NAG/!#ifdef NAG/g","wannier90-2.0.1/src/io.F90" ], 
command=["sed","-i","s/#endif/!#endif/g","wannier90-2.0.1/src/io.F90" ],
command=["sed","-i","s/#ifndef NAG/!#ifndef NAG/g","wannier90-2.0.1/src/io.F90" ],
command=["sed","-i","s/integer, intent(inout)                    :: array/integer, dimension(:), intent(inout)      :: array/g","wannier90-2.0.1/src/postw90/comms.F90" ],
command=["sed","-i","s/integer, intent(inout)                    :: rootglobalarray/integer, dimension(:), intent(inout)      :: rootglobalarray/g","wannier90-2.0.1/src/postw90/comms.F90" ], 
command=["sed","-i","s/comms_scatterv(localkpointidx(1),counts(my_node_id),kpointidx(1)/comms_scatterv(localkpointidx(:),counts(my_node_id),kpointidx(:)/g","wannier90-2.0.1/src/postw90/geninterp.F90" ]

If you apply the seds above (from the EPW buildbot test-farm) it should work.

Best,

Samuel

Make sure that new developments are reflected in the user guide in advance of release.

Email conversation:
On Thursday, February 16, 2017 1:34:42 PM CET Dominik Gresch wrote:

Thank you very much for your reply. Indeed, increasing the tolerance (in
my case, to about 7.d-4) fixes this issue. I changed the code such that
the tolerance can be given as an input parameter, see here:
https://github.com/greschd/wannier90/tree/irdist_ws_tol

First of all, do you think this is useful / necessary in general? If
yes, are there other places in ws_distance.F90 where the tolerance
should be changed accordingly? From glancing over the code I would guess
maybe eps = 10 * irdist_ws_tol would make sense. Of course we could also
let the user set eps and use irdist_ws_tol = eps / 10 . Please let me
know what you think about this.

@paulatz wrote:

All the thresholds are inside ws_distance, there should be nothing outside of
this file, which is good.

You are right that the various thresholds should be consistent, although I'm
not sure it is trivial to do because some are measured in direct lattice
units, other in fractional units.

In particular :

1. in R_ws_sc_equiv, line 235, we are accepting a relative error of 10^-5 in
   cartesian coordinates (coordinate system is important for anisotropic
   lattices)

2. in ws_translated_dist, line 157 we require an absolute precision of 10^-6
   in fractional coordinates.

If I remember correctly, I put this second check in order to spot bugs in the
code, but now I think the check in ws_translate_dist could just be removed.

I think it could be a good idea to have the threshold value in R_ws_sc_equiv
be an input parameter, and maybe default to something larger than 1.d-5

Also, I'm not sure that using a relative threshold, instead of an absolute
value is justified, because it would require the centres of the WFs to be less
accurately equivalent when using finer grids of k-points.

When running the testcase test_si_geninterp_wsdistance in parallel, i.e.

make run-custom-test-parallel testdir=test_si_geninterp_wsdistance

postw90.x crashes with a segmentation fault. This issue already applies to 3fea97a, where the test case was initially added.

Stack trace (line numbers and code based on 3fea97a):

ws_distance.F90:122
postw90/postw90_common.F90:654
postw90/wan_ham.F90:353
geninterp.F90:220

Code (ws_distance.F90):

   109      do ir =1,nrpts
   110      do jw=1,num_wann
   111          do iw=1,num_wann
   112              call utility_frac_to_cart(DBLE(irvec(:,ir)),irvec_cart,real_lattice)
   113              ! function IW translated in the Wigner-Size around function JW
   114              wdist_wssc_frac(:,iw,jw,ir) = R_wz_sc( -wannier_centres(:,iw)&
   115                          +(irvec_cart+wannier_centres(:,jw)), (/0._dp,0._dp,0._dp/) )
   116              !find its degeneracy
   117              CALL R_wz_sc_equiv(wdist_wssc_frac(:,iw,jw,ir), (/0._dp,0._dp,0._dp/), &
   118                              wdist_ndeg(iw,jw,ir), crdist_ws(:,:,iw,jw,ir))
   119              IF(wdist_ndeg(iw,jw,ir)>ndegenx) call io_error('surprising ndeg')
   120              do ideg = 1,wdist_ndeg(iw,jw,ir)
   121              crdist_ws(:,ideg,iw,jw,ir) = crdist_ws(:,ideg,iw,jw,ir)&
   122                              +wannier_centres(:,iw)-wannier_centres(:,jw)
   123              !
   124              call utility_cart_to_frac(crdist_ws(:,ideg,iw,jw,ir),&
   125                              irdist_real(:,ideg,iw,jw,ir),recip_lattice)
   126              enddo
   127          enddo
   128      enddo
   129      enddo

• Implement constrained centres approach of Marianetti et al.

@yusukenomura , do you have a version of pw2wannier90 that writes the .dmb file?

I had the idea of using the D matrix to calculate symmetry protected topological invariants (e.g. mirror chern numbers) -- so I would like to try this. Since I need to be able to compute it on a non-symmetric k-mesh, I might have to add a flag to compute only the D matrix, without the indices specifying how the k-mesh transforms.

From the discussion a proposal is to keep the user guide up to date - as a list of input parameters, functionality, specification of input and output files.

It was suggested to use FORD to document modules and subroutines (useful for coders)
https://pypi.python.org/pypi/FORD

We should have WF-centred grids to reduce disk and memory usage

Some variable names need to be renamed, including:
pos_plot -> write_rmn
hr_plot -> write_hr
u_matrices_plot -> write_u_matrices
plus corresponding changes in documentation.

• Check and, if necessary, improve #108
• Add a test (maybe based on the Fe example)

Hi,

I posted this on the mailing list twice but somehow it doesn't show up. So I post it here since it may be a bug.

I notice that seedname_r.dat produced by Wannier90 2.1.0 seems to be inconsistent with seedname.wout.

For example, in one calculation, I get:

WF centre and spread 1 ( -0.000000, 1.829682, 7.132059 ) 1.94972060
WF centre and spread 2 ( 0.000000, 1.879503, 7.132054 ) 2.15240925
WF centre and spread 3 ( -0.000000, 1.796575, 7.132054 ) 2.15077501
WF centre and spread 4 ( -0.000000, 1.988540, 7.132058 ) 2.07926155
WF centre and spread 5 ( 0.000000, 1.698986, 7.132058 ) 2.09870481
WF centre and spread 6 ( -0.000000, -0.015018, 5.461046 ) 1.82823341
WF centre and spread 7 ( 0.000000, -0.026356, 5.623278 ) 1.77493050
WF centre and spread 8 ( -0.000000, 0.040588, 5.621861 ) 1.77620874
WF centre and spread 9 ( -0.000000, -0.015018, 8.803075 ) 1.82822697
WF centre and spread 10 ( 0.000000, -0.026358, 8.640822 ) 1.77493079
WF centre and spread 11 ( -0.000000, 0.040590, 8.642238 ) 1.77620887
Sum of centres and spreads ( -0.000000, 9.191713, 78.452604 ) 21.18961050

in seedname.wout. However, I get the following lines in seedname_r.dat:
0 0 0 1 1 -0.000000 0.000000 1.784722 0.000000 2.435314 -0.000000
0 0 0 2 2 0.000000 0.000000 1.830178 -0.000000 2.426941 -0.000000
0 0 0 3 3 -0.000000 -0.000000 1.745147 0.000000 2.426974 -0.000000
...
0 0 0 7 7 0.000000 -0.000000 -0.026103 -0.000000 3.080720 0.000000
...
0 0 0 9 9 -0.000000 -0.000000 -0.014892 0.000000 1.152574 -0.000000
...
I assume that WF centres should be <n|r|n+(0,0,0)> but they are not. Am I missing anything?

Does anyone know with what criteria i choose the Energy Windows' dimensions in Wannier90 input? Because i cant find the right, either i get " More states in the frozen window than target WFs" or "Less ... ".

To print:

• basic information on what are the possible command line options
• print some help when wannier is run without options
• add a --dry-run option to validate the input file
• add a -v and/or --version option to print the code version and if possible the compilation flags

• If possible use latest stable release of test-suite
• define exactly what we want to test for each test in the suite
• If possible make parsing script more robust

There is some problem when calculating band derivatives with the new interpolation method use_ws_distance = True

Probably, we are still using the old 'r' in the computation of the gradient?

See also results of geninterp for the two interpolation methods below (last three columns are the velocity)

new.txt
old.txt

(as merged by PR #81)

Move to postw90.x and parallelise it

We should add more tests (see also the wiki page https://github.com/wannier-developers/wannier90/wiki/TestSuiteIdeas)

Dear all,

As far as I know, it's not currently possible to 're-use' the .amn file when changing the projections -- which means the first-principles code needs to be re-run. Since this can take a lot of time, I propose the following syntax to allow re-using the files:

• Add an optional input block (let's call it select_projections for now) with the same syntax as the projections block.
• If select_projections is not given, everything stays as it is
• If select_projections is given, the projections block is used to determine which projections are in the .amn file, and the select_projections block tells us which of these are actually to be used.

This means that select_projections could be an arbitrary subset of projections without changing the .amn file.

Please let me know what you think about this.

In src/wannierise.F90, lines 2482 and 2506, utility_zgemm is used in a strange way:

The matrices u0 and u_matrix are of dimension (num_wann,num_wann,num_kpts), however utility_zgemm assumes a shape of (num_wann,num_wann).

The computation thus effects only the first k-point (i.e. the matrices u0(:,:,1) or u_matrix(:,:,1)). Is this intended?

  2480         if (ldump) then
  2481            uc_rot(:,:)=cmplx(ur_rot(:,:),0.0_dp,dp)
  2482            call  utility_zgemm(u_matrix,u0,'N',uc_rot,'N',num_wann)
  2483            call param_write_chkpt('postdis')
  2484         endif
  2485
  2486         if (conv_window.gt.1) call internal_test_convergence_gamma()
  2487
  2488         if (lconverged) then
  2489            write(stdout,'(/13x,a,es10.3,a,i2,a)') &
  2490                 '<<<     Delta <',conv_tol,&
  2491                 '  over ',conv_window,' iterations     >>>'
  2492            write(stdout,'(13x,a/)')  '<<< Wannierisation convergence criteria satisfied >>>'
  2493            exit
  2494         endif
  2495
  2496      enddo
  2497      ! end of the minimization loop
  2498
  2499      ! update M
  2500      do nn = 1, nntot
  2501         sqwb=1.0_dp/sqrt(wb(nn))
  2502         m_matrix(:,:,nn,1)=sqwb*cmplx(m_w(:,:,2*nn-1),m_w(:,:,2*nn),dp)
  2503      end do
  2504      ! update U
  2505      uc_rot(:,:)=cmplx(ur_rot(:,:),0.0_dp,dp)
  2506      call  utility_zgemm(u_matrix,u0,'N',uc_rot,'N',num_wann)

When compiling with debugging flags, I get the following error when I run Wannier90:

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:
#0  0x7F58FEC07E08
#1  0x7F58FEC06F90
#2  0x7F58FE54F4AF
#3  0x42635C in __w90_parameters_MOD_param_read at parameters.F90:1669
#4  0x40223E in MAIN__ at wannier_prog.F90:85
Floating point exception (core dumped)

I managed to trace the error to when kubo_freq_max is set, with a fermi_energy_list that has not been initialized before, which triggers the floating point exception. The offending line of code is this:

if(frozen_states) then
   kubo_freq_max        = dis_froz_max-fermi_energy_list(1)+0.6667_dp

My question is this: What would the correct behaviour in this case be? Right now (without the debugging flags) it probably just creates a NaN.

Compilation flags:
make.inc.txt

Minimal and consistent module headers for all modules.

At the moment there is no memory estimate for postw90.

If mp_grid is not used if postproc_setup = .true., we should change the code in parameters.F90 (from line 598) to not raise an error in that case.

Note: you can assign me to this issue.

Hello
For surface states or edge states (for 2D materials) the frozen window should be located around the fermi level?
For better approximation from what energy it must start and end?
Thanks and sorry for my english!

• Add a troubleshooting section
• Move FAQ and troubleshooting to a webpage, rather than in the User Guide
• Make an HTML version of User Guide and Tutorial

To get the occupation of Wannier functions
See emails on April 3rd, 2013 on mailing list and related emails

• Reintroduce it (it might be there but commented)
• make num_elec_cell variable to be real to cope with VCA

• Parallelise the core disentanglement and wannierisation subroutines based on #76

Check in particular if the adaptive smearing implemented in BotlzWann works properly and then move the code also for the other postw90.x routines.