wannier-developers / wannier90 Goto Github PK
View Code? Open in Web Editor NEWOfficial repository of the Wannier90 code
Home Page: http://www.wannier.org
License: GNU General Public License v2.0
Official repository of the Wannier90 code
Home Page: http://www.wannier.org
License: GNU General Public License v2.0
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 ... ".
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)
Make a new module that writes files including rmn, r2mn, u_matrix etc.
Make dist doesn't work (at least on my mac).
Make clean / veryclean needs to clean the documentation, test-suite etc
To get the occupation of Wannier functions
See emails on April 3rd, 2013 on mailing list and related emails
We need to update the memory estimate to cope with the new arrays added with preconditioning
At the moment there is no memory estimate for postw90.
num_elec_cell
variable to be real to cope with VCAWe should add more tests (see also the wiki page https://github.com/wannier-developers/wannier90/wiki/TestSuiteIdeas)
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" .
We should have WF-centred grids to reduce disk and memory usage
There are a number of suggestions of missing features of the library mode, improvements and suggestions. Please reply to this issue with your comments.
Minimal and consistent module headers for all modules.
Move to postw90.x and parallelise it
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.
Now, it is not applied while plotting and while printing the actual WF centres on the output
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
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
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).
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:
select_projections
for now) with the same syntax as the projections
block.select_projections
is not given, everything stays as it isselect_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.
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?
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
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)
Check in particular if the adaptive smearing implemented in BotlzWann works properly and then move the code also for the other postw90.x routines.
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.incHowever, the
wannier90-2.0.1/src/Makefile.2file 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 docp ../install/make_wannier90.inc ../W90/make.sys
in the Makefile. That should avoid Lorenzo problem and ensure
compatibility with w90.
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
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?
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
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.
To print:
--dry-run
option to validate the input file-v
and/or --version
option to print the code version and if possible the compilation flagsFrom 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
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
(as merged by PR #81)
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_tolFirst 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 :
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)
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.
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!
Make sure that new developments are reflected in the user guide in advance of release.
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
@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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.