From giovanni.cantele at spin.cnr.it Fri Feb 3 11:20:45 2017 From: giovanni.cantele at spin.cnr.it (Giovanni Cantele) Date: Fri, 3 Feb 2017 11:20:45 +0100 Subject: [Wannier] plot of Wannier functions in the presence of spin-orbit coupling Message-ID: <2C12D611-1AF9-426F-9600-A22EAAE08E7A@spin.cnr.it> Dear developers, in the present version the possibility of plotting Wannier functions in the presence of spin-orbit coupling is not implemented (specifically, it is not possible to generate *.unk files with pw2wannier90.x). I would like just to know if there is any ongoing work on this, and/or some beta version containing such a feature . Thanks a lot, Giovanni -- Giovanni Cantele, PhD CNR-SPIN c/o Dipartimento di Fisica Universita' di Napoli "Federico II" Complesso Universitario M. S. Angelo - Ed. 6 Via Cintia, I-80126, Napoli, Italy e-mail: giovanni.cantele at spin.cnr.it Phone: +39 081 676910 Skype contact: giocan74 ResearcherID: http://www.researcherid.com/rid/A-1951-2009 Web page: http://people.na.infn.it/~cantele From kevin60105 at gmail.com Mon Feb 6 16:40:44 2017 From: kevin60105 at gmail.com (KuangChung Wang) Date: Mon, 6 Feb 2017 10:40:44 -0500 Subject: [Wannier] Wannier Digest, Vol 108, Issue 7 In-Reply-To: References: Message-ID: Hi I have a question with the hybrid orbitals for the projection process. 1. for trigonal prismatic structure, a sd5 hybrid orbital is needed. However, I checked online, with almost no info found for the coefficient to linearly combine sd5 orbitals. There are some rules like sum(row^2)=1 sum(col^2)=1 or orthogonal. And some suggest group theory needed for the coefficient. Does anyone know the coefficient? https://en.wikipedia.org/wiki/Trigonal_prismatic_molecular_geometry 2. After finding out the coef, it should be implemented in wannier90-2.0.1/pwscf/v5.0/pw2wannier90.f90 ? However, this seems to be working only with Quantum espresso? On Tue, Jan 24, 2017 at 6:00 AM, wrote: > Send Wannier mailing list submissions to > wannier at quantum-espresso.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier > or, via email, send a message with subject or body 'help' to > wannier-request at quantum-espresso.org > > You can reach the person managing the list at > wannier-owner at quantum-espresso.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Wannier digest..." > > > Today's Topics: > > 1. Why we use kmesh.pl in NSCF calculation? (fateme sadat Tabatabaei) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 24 Jan 2017 11:34:08 +0330 > From: fateme sadat Tabatabaei > To: wannier at quantum-espresso.org > Subject: [Wannier] Why we use kmesh.pl in NSCF calculation? > Message-ID: > AA at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > I think in QUANTUM-ESPRESSO the Monkhorest-Pack scheme of kpoint > sampling is used for integration over the first Brillouin zone. Why we > use kmesh.pl in NSCF calculation? > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Wannier mailing list > Wannier at quantum-espresso.org > http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier > > > ------------------------------ > > End of Wannier Digest, Vol 108, Issue 7 > *************************************** > -- Sincerely, Kuang-Chung Wang Ph.D. Student||Electrical Engineering | Purdue U. M.S. EE | NTU & UC Santa Barbara B.S. Electrical Engineering| Nation Taiwan University -------------- next part -------------- An HTML attachment was scrubbed... URL: From oarcelus at hotmail.com Wed Feb 8 13:00:36 2017 From: oarcelus at hotmail.com (Oier Arcelus) Date: Wed, 8 Feb 2017 12:00:36 +0000 Subject: [Wannier] Wannier functions in real space. Message-ID: Hi forum, I am trying to calculate the matrix elements of a LDA xc-potential in the wannier basis. The thing that comes to my mind is to take the wannier functions in a real grid that spans all the unit cell W(r), then get the xc-potential in that same grid and compute the values W(r1)* x V(r1) x W'(r1) for all r1 grid points in the unit cell. This would give me the matrix elements. However I encounter somre problems, the first one is obtaining the W(r). For this I just get W(r) with the seedname_00*.xsf XCrysDen files. But there are some problems, for some reason the centering of the real cell with the ones that contain the volumetric data is quite odd, looks like the lattice parameters are not totally the same, and when changin the file by hand the wannier functions get a bit shifted from the atomic centers. Another problem is that those files chop the wannier functions at the borders of the cell, and do not allow to those functions appear in the opposite site of the unit cell (due to periodic boundary conditions). Is there any way to solve this? Or avoid using it? Help would be much appreciated, Best wishes, Oier. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.yates at materials.ox.ac.uk Wed Feb 8 14:25:27 2017 From: jonathan.yates at materials.ox.ac.uk (Jonathan Yates) Date: Wed, 8 Feb 2017 13:25:27 +0000 Subject: [Wannier] plot of Wannier functions in the presence of spin-orbit coupling In-Reply-To: <2C12D611-1AF9-426F-9600-A22EAAE08E7A@spin.cnr.it> References: <2C12D611-1AF9-426F-9600-A22EAAE08E7A@spin.cnr.it> Message-ID: <9872E233-D589-4A40-A9C3-3D850AB79A12@materials.ox.ac.uk> On 3 Feb 2017, at 10:20, Giovanni Cantele wrote: > Dear developers, > > in the present version the possibility of plotting Wannier functions in the presence of spin-orbit coupling is not implemented > (specifically, it is not possible to generate *.unk files with pw2wannier90.x). > > I would like just to know if there is any ongoing work on this, and/or some beta version containing such a feature . Giovanni, I am not aware of anyone working on this. The current list of project known to the developers is at https://github.com/wannier-developers/wannier90/wiki/CurrentDevelEfforts It would mean changes to pw2wannier90 and a generalisation of the unk files. You would need to make similar changes to the plotting routines inside wannier90. It should not be too difficult. You do have to make a decision about exactly what you want to plot - remember that the in the presence of spin-orbit coupling your MLWF might be complex valued. I have a memory that the Wien2k interface handles this already, so you might look at what options they provide. Yours Jonathan -- Department of Materials, University of Oxford, Parks Road, Oxford, OX1 3PH, UK tel: +44 (0)1865 612797 http://users.ox.ac.uk/~oums0549/ From jonathan.yates at materials.ox.ac.uk Wed Feb 8 14:38:31 2017 From: jonathan.yates at materials.ox.ac.uk (Jonathan Yates) Date: Wed, 8 Feb 2017 13:38:31 +0000 Subject: [Wannier] Wannier Digest, Vol 108, Issue 7 In-Reply-To: References:

Message-ID: <35FA07F0-1C9A-44CC-8C9C-6548194BAAEE@materials.ox.ac.uk> On 6 Feb 2017, at 15:40, KuangChung Wang wrote: > Hi > > I have a question with the hybrid orbitals for the projection process. > 1. for trigonal prismatic structure, a sd5 hybrid orbital is needed. However, I checked online, with almost no info found for the coefficient to linearly combine sd5 orbitals. There are some rules like sum(row^2)=1 sum(col^2)=1 or orthogonal. And some suggest group theory needed for the coefficient. Does anyone know the coefficient? > https://en.wikipedia.org/wiki/Trigonal_prismatic_molecular_geometry > 2. After finding out the coef, it should be implemented in wannier90-2.0.1/pwscf/v5.0/pw2wannier90.f90 ? However, this seems to be working only with Quantum espresso? pw2wannier90 is the interface to PWSCF. So if you are using PWSCF you need to modify that routine - if you are using another code then you would need to modify the corresponding interface. If you add new types of projection there are some changes needed to Wannier90, however, these are trivial book keeping. I don?t know the coefficients you need - I?d have to work them out. However, I think that you first want to prove that you do need this projection. In the pre-wannier90 days we wanted to find the WF for bcc iron. At that time we could only project onto s,p,d orbitals. So I did this - and found that when I left the minimiser go for a few iterations it always lowered the spread by hybridising the orbitals to a set of sp3d2 and 3 dxy orbitals. Having realised this we then implemented the projection onto the sp3d2 hybrid orbitals. Have you done something similar for your system? Do you know that the MLWF will have this sd5 symmetry? I would check before going through the effort of coding up the projections. Jonathan -- Department of Materials, University of Oxford, Parks Road, Oxford, OX1 3PH, UK tel: +44 (0)1865 612797 http://users.ox.ac.uk/~oums0549/ From jonathan.yates at materials.ox.ac.uk Wed Feb 8 19:14:31 2017 From: jonathan.yates at materials.ox.ac.uk (Jonathan Yates) Date: Wed, 8 Feb 2017 18:14:31 +0000 Subject: [Wannier] Wannier functions in real space. In-Reply-To: References: Message-ID: <0077644D-5086-4C7B-8488-A12049631D46@materials.ox.ac.uk> On 8 Feb 2017, at 12:00, Oier Arcelus wrote: > Hi forum, > > I am trying to calculate the matrix elements of a LDA xc-potential in the wannier basis. The thing that comes to my mind is to take the wannier functions in a real grid that spans all the unit cell W(r), then get the xc-potential in that same grid and compute the values W(r1)* x V(r1) x W'(r1) for all r1 grid points in the unit cell. This would give me the matrix elements. However I encounter somre problems, the first one is obtaining the W(r). > > For this I just get W(r) with the seedname_00*.xsf XCrysDen files. But there are some problems, for some reason the centering of the real cell with the ones that contain the volumetric data is quite odd, looks like the lattice parameters are not totally the same, and when changin the file by hand the wannier functions get a bit shifted from the atomic centers. Another problem is that those files chop the wannier functions at the borders of the cell, and do not allow to those functions appear in the opposite site of the unit cell (due to periodic boundary conditions). Oier, Plotting isn?t perhaps the most elegant feature of Wannier90. In part because we initially hoped the plotting would be done in the parent electronic structure code. If you haven?t already, look at the xsf spec http://www.xcrysden.org/doc/XSF.html One potential source of confusion is that xsf uses ?General? grids, rather than periodic grids - so the first data point is repeated at the end. Also look at the keyword wannier_plot_supercell which controls the size of the supercell in which the unit cell is plotted. Wannier90 can also plot cube files - and this might make more sense for you. Look at the wannier_plot_radius keyword. One issue is that the code will only allow you to use cube format for orthorhombic unit cells. (I think because most cube readers don?t handle non-orthorhombic grids). However, given you just want the data you could try removing the check in parameters.F90 (c. line 1960) and see what happens. It also shouldn?t be difficult to adapt the code in plot.F90 to write out the WF in a format that suits you. I hope that gives you a few things to investigate, and come back to us if something is still puzzling Jonathan -- Department of Materials, University of Oxford, Parks Road, Oxford, OX1 3PH, UK tel: +44 (0)1865 612797 http://users.ox.ac.uk/~oums0549/ From greschd at phys.ethz.ch Tue Feb 14 21:51:50 2017 From: greschd at phys.ethz.ch (Dominik Gresch) Date: Tue, 14 Feb 2017 21:51:50 +0100 Subject: [Wannier] Problem with use_ws_distance Message-ID: <4740a479-665e-a544-f107-d17d4df0eba3@phys.ethz.ch> Dear Wannier90 community, While running Wannier90 with the 'use_ws_distance = .TRUE.' flag, I encounter the error 'wrong irdist_ws'. Does anyone know the nature of this error? Important things to note: - The error seems to appear also for 'use_ws_distance = .FALSE.', but in that case the output files are still written - My input files were generated with VASP (meaning, for Wannier90 v.1), which could be the source of the problem Best regards, Dominik Gresch From lorenzo.paulatto at impmc.upmc.fr Wed Feb 15 13:32:29 2017 From: lorenzo.paulatto at impmc.upmc.fr (Lorenzo Paulatto) Date: Wed, 15 Feb 2017 13:32:29 +0100 Subject: [Wannier] Problem with use_ws_distance In-Reply-To: <4740a479-665e-a544-f107-d17d4df0eba3@phys.ethz.ch> References: <4740a479-665e-a544-f107-d17d4df0eba3@phys.ethz.ch> Message-ID: <1770694.DC6128LFjS@naquite> On Tuesday, February 14, 2017 9:51:50 PM CET Dominik Gresch wrote: > Dear Wannier90 community, > > While running Wannier90 with the 'use_ws_distance = .TRUE.' flag, I > encounter the error 'wrong irdist_ws'. Does anyone know the nature of > this error? This error should never happen, although if the position of the centres of the WFs are very noisy it may pop up. It is difficult to tell without having the slightest detail about your calculation. Could you please provide us the files necessary to reproduce you calculation (ie. all the file seedname.*, except the UNK files). As a quick workaround, you can go in the file src/ws_distance.F90 and around line 156 change this check: IF(ANY(ABS(DBLE(irdist_ws)-irdist_real)>1.d-6)) & call io_error('wrong irdist_ws') allowing for a larger tolerance, something like 1.d-4 or 1.d-3. If then the code runs to the end, it is just a problem of numerical noise/minimisation not being tight enough. If this does not help, we definitely need to reproduce the calculation in order to be able to help. > Important things to note: > - The error seems to appear also for 'use_ws_distance = .FALSE.', > but in that case the output files are still written Yes, there is a place where the subroutine causing the error is called even when that option is false. This occurence arrives later in the code, hence I can see how the output files are written in this case. To avoid this problem, you can change src/plot.F90 around line 80, from if ( write_hr.or.write_rmn.or.write_tb ) then if (.not.done_ws_distance) call ws_translate_dist(nrpts,irvec) call ws_write_vec(nrpts,irvec) end if to if ( (write_hr.or.write_rmn.or.write_tb) .and. use_ws_distance) then if (.not.done_ws_distance) call ws_translate_dist(nrpts,irvec) call ws_write_vec(nrpts,irvec) end if And, of course, recompile (I have not tested this, but it should work). > - My input files were generated with VASP (meaning, for Wannier90 > v.1), which could be the source of the problem I do not think this makes any difference. hth -- Dr. Lorenzo Paulatto IdR @ IMPMC -- CNRS & Universit? Paris 6 phone: +33 (0)1 442 79822 / skype: paulatz www: http://www-int.impmc.upmc.fr/~paulatto/ mail: 23-24/423 Bo?te courrier 115, 4 place Jussieu 75252 Paris C?dex 05 -------------- next part -------------- An HTML attachment was scrubbed... URL: From oarcelus at hotmail.com Wed Feb 15 15:05:10 2017 From: oarcelus at hotmail.com (Oier Arcelus) Date: Wed, 15 Feb 2017 14:05:10 +0000 Subject: [Wannier] Wannier functions in real space. (Jonathan Yates) Message-ID: >> Hi forum, >> >> I am trying to calculate the matrix elements of a LDA xc-potential in the wannier basis. The thing that comes to my mind is to take the wannier functions in a real grid that spans all the unit cell W(r), then get the xc-potential in that same grid and compute the values W(r1)* x V(r1) x W'(r1) for all r1 grid points in the unit cell. This would give me the matrix elements. However I encounter somre problems, the first one is obtaining the W(r). >> >> For this I just get W(r) with the seedname_00*.xsf XCrysDen files. But there are some problems, for some reason the centering of the real cell with the ones that contain the volumetric data is quite odd, looks like the lattice parameters are not totally the same, and when changin the file by hand the wannier functions get a bit shifted from the atomic centers. Another problem is that those files chop the wannier functions at the borders of the cell, and do not allow to those functions appear in the opposite site of the unit cell (due to periodic boundary conditions). >>Oier, >Plotting isn?t perhaps the most elegant feature of Wannier90. In part because we initially hoped the plotting would be done in the parent electronic structure code. >If you haven?t already, look at the xsf spec >http://www.xcrysden.org/doc/XSF.html [http://www.xcrysden.org/doc/img/xcrysden-picture-small-new.jpg] XCrySDen - (X-Window) Crystalline Structures and Densities www.xcrysden.org Specification of the XSF Format Introduction to XSF format The XSF format is internal XCrySDen structure format. XSF stands for XCrySDen Structure File. >One potential source of confusion is that xsf uses ?General? grids, rather than periodic grids - so the first data point is repeated at the end. >Also look at the keyword wannier_plot_supercell which controls the size of the supercell in which the unit cell is plotted. >Wannier90 can also plot cube files - and this might make more sense for you. Look at the wannier_plot_radius keyword. One issue is that the code will only allow you to use cube format for orthorhombic unit cells. (I think >because most cube readers don?t handle non-orthorhombic grids). However, given you just want the data you could try removing the check in parameters.F90 (c. line 1960) and see what happens. It also shouldn?t be >difficult to adapt the code in plot.F90 to write out the WF in a format that suits you. >I hope that gives you a few things to investigate, and come back to us if something is still puzzling >Jonathan Hi again, As you told me, Jonathan, I modified the code a little bit to plot the wannier functions in the format I needed. I keep getting the same problem, the wannier functions in a real-space grid don't take into account the periodic boundary conditions needed to make the tails of the wannier functions that 'escape' from the home unit cell re-appear on the oppossite sides of the cell. I'm particularly referring to the variable wann_func(:,:,:,:) as it get's out from the computation in line 1037 in the module plot.F90. Is there a way of doing this? Maybe I am missing some other grid representation of wannier functions with PBC's that appear somewhere else in the program. At this point I'm affraid I will have to get a 3x3x3 supercell, center my home cell in the middle unit cell and translate any point that escapes from certain boundaries back to the middle cell. But of course I would like to avoid this and make it more elegant. Any suggestion would be pretty much appreciated, Best wishes, Oier. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ch-wang at outlook.com Thu Feb 16 04:00:30 2017 From: ch-wang at outlook.com (Chong Wang) Date: Thu, 16 Feb 2017 03:00:30 +0000 Subject: [Wannier] Is it possible to have extra states in frozen window? Message-ID: Hi everyone, In my opinion, when a frozen window is set, every states in that window is taken into account in the calculation. However, this does not forbid that some extra states would enter frozen window in disentanglement. Thus, if band structures in frozen window is well reproduced except for some extra bands, it can still be considered a good Wannier interpolation. Is this correct? Best! Chong Wang Institute for Advanced Study, Tsinghua Univeristy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.yates at materials.ox.ac.uk Thu Feb 16 11:56:45 2017 From: jonathan.yates at materials.ox.ac.uk (Jonathan Yates) Date: Thu, 16 Feb 2017 10:56:45 +0000 Subject: [Wannier] Wannier functions in real space. (Jonathan Yates) In-Reply-To: References: Message-ID: <9A0D69E2-91C3-40B1-8309-07B8DDB85D4D@materials.ox.ac.uk> > > As you told me, Jonathan, I modified the code a little bit to plot the wannier functions in the format I needed. I keep getting the same problem, the wannier functions in a real-space grid don't take into account the periodic boundary conditions needed to make the tails of the wannier functions that 'escape' from the home unit cell re-appear on the oppossite sides of the cell. I'm particularly referring to the variable wann_func(:,:,:,:) as it get's out from the computation in line 1037 in the module plot.F90. Oier, In reading this I?m wondering if you have missed something fundamental about wannier functions: The WF are not periodic in the crystallographic unit cell. In the limit of infinite k-point sampling they are isolated - and if we sample the Brillouin Zone with a NxNxN mesh then the WF are periodic in a NxNxN supercell of the unit cell. There is a practical illustration of this in example01 (GaAs) such has a very coarse sampling the BZ, and hence you see the periodic images of the WF appear in the plots, if the plotting supercell is large enough. Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From oarcelus at hotmail.com Thu Feb 16 12:37:59 2017 From: oarcelus at hotmail.com (Oier Arcelus) Date: Thu, 16 Feb 2017 11:37:59 +0000 Subject: [Wannier] Re_ Wannier functions in real space Message-ID: >Oier, >In reading this I?m wondering if you have missed something fundamental about wannier functions: The WF are not periodic in the crystallographic unit cell. In the limit of infinite k-point sampling they are isolated - and if >we sample the Brillouin Zone with a NxNxN mesh then the WF are periodic in a NxNxN supercell of the unit cell. >There is a practical illustration of this in example01 (GaAs) such has a very coarse sampling the BZ, and hence you see the periodic images of the WF appear in the plots, if the plotting supercell is large enough. >Jonathan Oh, thats a big mistake from my part. So I guess It is sufficiente to consider a supercell sufficiently big so that the Wannier functions are small enough by the time they arrive to the supercell border, and then just consider the exchange correlation potential in that supercell. Oier. -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.mostofi at imperial.ac.uk Thu Feb 16 13:30:00 2017 From: a.mostofi at imperial.ac.uk (Mostofi, Arash) Date: Thu, 16 Feb 2017 12:30:00 +0000 Subject: [Wannier] Is it possible to have extra states in frozen window? In-Reply-To: References: Message-ID: <5EDCDC5D-18EB-4A56-8D30-71AD004A7B6A@ic.ac.uk> Dear Chong Wang, I?m not sure that I?ve fully understood your question but your first statement is correct: all the states included in the frozen energy window are automatically included in the disentangled subspace. At each k-point there should always be n_k .le. num_wann such states. The remaining (num_wann - n_k) states needed to complete the subspace at each k-point are disentangled from the states outside the frozen window. The wannier functions are then constructed out of the num_wann-dimensional subspace at each k-point. You would expect the Wannier-interpolated bandstructure to give a very good representation of the states in the frozen window. If other interpolated bands are present that do not seem to correspond to bands in the original bandstructure, then you have to ask yourself the question of whether you have obtained a good WF representation for your problem, eg, one that accurately reproduces the bandstructure in a particular range of energy. Hope this helps, Arash ? Arash Mostofi ? www.mostofigroup.org Director, CDT in Theory and Simulation of Materials Imperial College London On 16 Feb 2017, at 03:00, Chong Wang > wrote: Hi everyone, In my opinion, when a frozen window is set, every states in that window is taken into account in the calculation. However, this does not forbid that some extra states would enter frozen window in disentanglement. Thus, if band structures in frozen window is well reproduced except for some extra bands, it can still be considered a good Wannier interpolation. Is this correct? Best! Chong Wang Institute for Advanced Study, Tsinghua Univeristy _______________________________________________ Wannier mailing list Wannier at quantum-espresso.org http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier -------------- next part -------------- An HTML attachment was scrubbed... URL: From greschd at phys.ethz.ch Thu Feb 16 13:34:42 2017 From: greschd at phys.ethz.ch (Dominik Gresch) Date: Thu, 16 Feb 2017 13:34:42 +0100 Subject: [Wannier] Problem with use_ws_distance In-Reply-To: <1770694.DC6128LFjS@naquite> References: <4740a479-665e-a544-f107-d17d4df0eba3@phys.ethz.ch> <1770694.DC6128LFjS@naquite> Message-ID: <46e3decf-cbf4-e5c4-74dd-82b0d8906758@phys.ethz.ch> Dear Lorenzo, 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. Best regards, Dominik P.S.: I uploaded my input files here: http://z2pack.ethz.ch/54dcaf52-9c86-4cd6-b5dc-1fe2714ca45d/input.tar.bz2 However, the files are very large (500MB compressed, about 1.2 GB uncompressed), so they might not be worth downloading. Also, I'm not especially interested in getting this particular example to run, I was just playing around with parameters to see how they affect the result. On 15.02.2017 13:32, Lorenzo Paulatto wrote: > > On Tuesday, February 14, 2017 9:51:50 PM CET Dominik Gresch wrote: > > > Dear Wannier90 community, > > > > > > While running Wannier90 with the 'use_ws_distance = .TRUE.' flag, I > > > encounter the error 'wrong irdist_ws'. Does anyone know the nature of > > > this error? > > This error should never happen, although if the position of the > centres of the WFs are very noisy it may pop up. It is difficult to > tell without having the slightest detail about your calculation. > > Could you please provide us the files necessary to reproduce you > calculation (ie. all the file seedname.*, except the UNK files). > > As a quick workaround, you can go in the file src/ws_distance.F90 and > around line 156 change this check: > > IF(ANY(ABS(DBLE(irdist_ws)-irdist_real)>1.d-6)) &callio_error('wrong > irdist_ws')allowing for a larger tolerance, something like 1.d-4 or > 1.d-3. If then the code runs to the end, it is just a problem of > numerical noise/minimisation not being tight enough. > > If this does not help, we definitely need to reproduce the calculation > in order to be able to help. > > > Important things to note: > > > - The error seems to appear also for 'use_ws_distance = .FALSE.', > > > but in that case the output files are still written > > Yes, there is a place where the subroutine causing the error is called > even when that option is false. This occurence arrives later in the > code, hence I can see how the output files are written in this case. > To avoid this problem, you can change src/plot.F90 around line 80, from > > if( write_hr.or.write_rmn.or.write_tb ) thenif(.not.done_ws_distance) > callws_translate_dist(nrpts,irvec) callws_write_vec(nrpts,irvec) end if > > to > > if( (write_hr.or.write_rmn.or.write_tb) .and.use_ws_distance) > thenif(.not.done_ws_distance) callws_translate_dist(nrpts,irvec) > callws_write_vec(nrpts,irvec) end if > > And, of course, recompile (I have not tested this, but it should work). > > > - My input files were generated with VASP (meaning, for Wannier90 > > > v.1), which could be the source of the problem > > I do not think this makes any difference. > > hth > > -- > > Dr. Lorenzo Paulatto > > IdR @ IMPMC -- CNRS & Universit? Paris 6 > > phone: +33 (0)1 442 79822 / skype: paulatz > > www: http://www-int.impmc.upmc.fr/~paulatto/ > > mail: 23-24/423 Bo?te courrier 115, 4 place Jussieu 75252 Paris C?dex 05 > > > > _______________________________________________ > Wannier mailing list > Wannier at quantum-espresso.org > http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorenzo.paulatto at impmc.upmc.fr Thu Feb 16 15:48:03 2017 From: lorenzo.paulatto at impmc.upmc.fr (Lorenzo Paulatto) Date: Thu, 16 Feb 2017 15:48:03 +0100 Subject: [Wannier] Problem with use_ws_distance In-Reply-To: <46e3decf-cbf4-e5c4-74dd-82b0d8906758@phys.ethz.ch> References: <4740a479-665e-a544-f107-d17d4df0eba3@phys.ethz.ch> <1770694.DC6128LFjS@naquite> <46e3decf-cbf4-e5c4-74dd-82b0d8906758@phys.ethz.ch> Message-ID: <13919769.BDgIo31UvS@naquite> 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. 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. -- Dr. Lorenzo Paulatto IdR @ IMPMC -- CNRS & Universit? Paris 6 phone: +33 (0)1 442 79822 / skype: paulatz www: http://www-int.impmc.upmc.fr/~paulatto/ mail: 23-24/423 Bo?te courrier 115, 4 place Jussieu 75252 Paris C?dex 05 From greschd at phys.ethz.ch Thu Feb 16 16:46:03 2017 From: greschd at phys.ethz.ch (Dominik Gresch) Date: Thu, 16 Feb 2017 16:46:03 +0100 Subject: [Wannier] Problem with use_ws_distance In-Reply-To: <13919769.BDgIo31UvS@naquite> References: <4740a479-665e-a544-f107-d17d4df0eba3@phys.ethz.ch> <1770694.DC6128LFjS@naquite> <46e3decf-cbf4-e5c4-74dd-82b0d8906758@phys.ethz.ch> <13919769.BDgIo31UvS@naquite> Message-ID: <209ccd2c-b036-24b3-c3ae-4b35a0896ca5@phys.ethz.ch> Hi Lorenzo, I opened an issue on GitHub for this, and I'd suggest we continue the discussion there. Best, Dominik On 16.02.2017 15:48, Lorenzo Paulatto wrote: > 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. > > 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. > From ch-wang at outlook.com Thu Feb 16 16:49:01 2017 From: ch-wang at outlook.com (Chong Wang) Date: Thu, 16 Feb 2017 15:49:01 +0000 Subject: [Wannier] Is it possible to have extra states in frozen window? In-Reply-To: <5EDCDC5D-18EB-4A56-8D30-71AD004A7B6A@ic.ac.uk> References: , <5EDCDC5D-18EB-4A56-8D30-71AD004A7B6A@ic.ac.uk> Message-ID: Hi Mostofi, Thanks for the reply. If I understand the original papers correctly, although all the states included in the frozen energy window are automatically included in the disentangled subspace, other states are chosen to minimize \Omega_i. These states are mixture of states out of frozen window and thus I think it is possible that somehow after diagonalization of hr these states enter frozen window unexpectedly. I guess you think these states should never appear in the frozen window. Do you have a good reason for that? Best! Chong Wang ________________________________ From: Wannier on behalf of Mostofi, Arash Sent: Thursday, February 16, 2017 8:30:00 PM To: wannier at quantum-espresso.org Subject: Re: [Wannier] Is it possible to have extra states in frozen window? Dear Chong Wang, I?m not sure that I?ve fully understood your question but your first statement is correct: all the states included in the frozen energy window are automatically included in the disentangled subspace. At each k-point there should always be n_k .le. num_wann such states. The remaining (num_wann - n_k) states needed to complete the subspace at each k-point are disentangled from the states outside the frozen window. The wannier functions are then constructed out of the num_wann-dimensional subspace at each k-point. You would expect the Wannier-interpolated bandstructure to give a very good representation of the states in the frozen window. If other interpolated bands are present that do not seem to correspond to bands in the original bandstructure, then you have to ask yourself the question of whether you have obtained a good WF representation for your problem, eg, one that accurately reproduces the bandstructure in a particular range of energy. Hope this helps, Arash ? Arash Mostofi ? www.mostofigroup.org Director, CDT in Theory and Simulation of Materials Imperial College London On 16 Feb 2017, at 03:00, Chong Wang > wrote: Hi everyone, In my opinion, when a frozen window is set, every states in that window is taken into account in the calculation. However, this does not forbid that some extra states would enter frozen window in disentanglement. Thus, if band structures in frozen window is well reproduced except for some extra bands, it can still be considered a good Wannier interpolation. Is this correct? Best! Chong Wang Institute for Advanced Study, Tsinghua Univeristy _______________________________________________ Wannier mailing list Wannier at quantum-espresso.org http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier -------------- next part -------------- An HTML attachment was scrubbed... URL: From ch-wang at outlook.com Fri Feb 17 14:42:02 2017 From: ch-wang at outlook.com (Chong Wang) Date: Fri, 17 Feb 2017 13:42:02 +0000 Subject: [Wannier] Is it possible to have extra states in frozen window? In-Reply-To: References: , <5EDCDC5D-18EB-4A56-8D30-71AD004A7B6A@ic.ac.uk> , Message-ID: Dear Ivo, You mentioned that hr eigenvalues always lie between the lowest and highest eigenvalues of the mixed ab initio states. But if the states above frozen window and states below frozen window are mixed in disentanglement, then I guess the eigenvalue could end up in frozen window. Thanks! Chong Wang ________________________________ From: Ivo Souza Sent: Friday, February 17, 2017 12:33:52 AM To: Chong Wang Cc: wannier at quantum-espresso.org Subject: Re: [Wannier] Is it possible to have extra states in frozen window? Dear Cheong, On Thu, 16 Feb 2017, Chong Wang wrote: > Hi Mostofi, > > Thanks for the reply. > > If I understand the original papers correctly, although all the states > included in the frozen energy window are automatically included in the > disentangled subspace, other states are chosen to minimize \Omega_i. > These states are mixture of states out of frozen window and thus I > think it is possible that somehow after diagonalization of hr these > states enter frozen window unexpectedly. I suspect that for the block of the hr matrix corresponding to states that are linear combinations of eigenstates lying outside the frozen window, the hr eigenvalues will always lie between the lowest and highest eigenvalues of those ab initio states, and therefore also lie outside the frozen window. (Strictly speaking this is only guaranteed for points k belonging to the ab initio mesh used in the wannierization. But for a sufficiently smooth interpolation it should also be the case at generic interpolation points.) Best, Ivo > > > I guess you think these states should never appear in the frozen window. Do you have a good reason for that? > > > Best! > > > Chong Wang > > ________________________________ > From: Wannier on behalf of Mostofi, Arash > Sent: Thursday, February 16, 2017 8:30:00 PM > To: wannier at quantum-espresso.org > Subject: Re: [Wannier] Is it possible to have extra states in frozen window? > > Dear Chong Wang, > > I?m not sure that I?ve fully understood your question but your first statement is correct: all the states included in the frozen energy window are automatically included in the disentangled subspace. At each k-point there should always be n_k .le. num_wann such states. The remaining (num_wann - n_k) states needed to complete the subspace at each k-point are disentangled from the states outside the frozen window. The wannier functions are then constructed out of the num_wann-dimensional subspace at each k-point. You would expect the Wannier-interpolated bandstructure to give a very good representation of the states in the frozen window. > > If other interpolated bands are present that do not seem to correspond to bands in the original bandstructure, then you have to ask yourself the question of whether you have obtained a good WF representation for your problem, eg, one that accurately reproduces the bandstructure in a particular range of energy. > > Hope this helps, > > Arash > > ? > Arash Mostofi ? www.mostofigroup.org> > Director, CDT in Theory and Simulation of Materials > Imperial College London > > > > On 16 Feb 2017, at 03:00, Chong Wang > wrote: > > Hi everyone, > > In my opinion, when a frozen window is set, every states in that window is taken into account in the calculation. However, this does not forbid that some extra states would enter frozen window in disentanglement. Thus, if band structures in frozen window is well reproduced except for some extra bands, it can still be considered a good Wannier interpolation. Is this correct? > > Best! > > Chong Wang > Institute for Advanced Study, Tsinghua Univeristy > _______________________________________________ > Wannier mailing list > Wannier at quantum-espresso.org > http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sangkookchoi at gmail.com Fri Feb 24 19:18:00 2017 From: sangkookchoi at gmail.com (Sangkook Choi) Date: Fri, 24 Feb 2017 13:18:00 -0500 Subject: [Wannier] [Sang] symmetry adapted wannier function and initial projectors Message-ID: Dear Wannier90 community. I have two questions on the symmetry adapted wannier functions. 1) When we use this feature, should initial WFs in wannier.amn preserve the symmetry of the materials? (what if the initial wannier function is from random projection) 2) What does it mean by "site_symmetry option cannot be used in conjunction with the inner (frozen) energy window"? With regards, Sang. -------------- next part -------------- An HTML attachment was scrubbed... URL: From a3almuta at uwaterloo.ca Mon Feb 27 16:46:58 2017 From: a3almuta at uwaterloo.ca (a3almuta at uwaterloo.ca) Date: Mon, 27 Feb 2017 10:46:58 -0500 Subject: [Wannier] Issues with pw2wannier90 Message-ID: <20170227104658.47195ifqb9947qia@www.nexusmail.uwaterloo.ca> Hello wannier90 developers and users First thanks for the recent update to Wannier90 and introducing the symmetry adoptive feature. However, since I have updated my Wannier90 (including updating the pw2wannier90.x in my QE). I have been having an issue with the software. To try the new version I tried to do the MoS2 wannierization again this time with the symmetry adaptive option on. This is the input file to the pw2wannier90: &inputpp outdir='./' prefix='MoS2', seedname = 'MoS2' write_unk = .true. reduce_unk = .true. write_amn = .true. write_mmn = .true. write_unkg = .false. write_dmn = .true. / While it was working before the update, now I am getting this error: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Error in routine pw2wannier90 (1): reading inputpp namelist STOP 1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% so I decided to test the software with the examples provided. I chose the example21 with As_sp. When I ran the pw2wannier90, I got this error during computing DMN: ---------------- *** Compute DMN ---------------- Number of symmetry operators = 24 1-th symmetry operators is 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 . . . DMN(d_matrix_wann): nir = 10 1 2 3 4 5 6 7 8 9 10 DMN(d_matrix_wann) calculated DMN(d_matrix_band): nir = 10 1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Error in routine gather_grid (1): do not use in serial execution %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% stopping ... STOP 1 so I decided to comment the dmn calculation but I got another error when computing A: --------------- *** Compute A --------------- AMN: iknum = 64 1 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x100f9aa69 #1 0x100f99e35 #2 0x7fff92aa6529 #3 0x7fff95a89b06 #4 0x10096d4f6 #5 0x10096dd6f #6 0x10098478d #7 0x100cb841e I tried the Cu example but I still got the same two errors. I am running it on macbook pro machine (v.10.6) May you please help me fixing this issues, mainly the MoS2 one. thanks, AbdulAziz AlMutairi The University of Waterloo From giovanni.pizzi at epfl.ch Tue Feb 28 21:47:51 2017 From: giovanni.pizzi at epfl.ch (Giovanni Pizzi) Date: Tue, 28 Feb 2017 20:47:51 +0000 Subject: [Wannier] Issues with pw2wannier90 In-Reply-To: <20170227104658.47195ifqb9947qia@www.nexusmail.uwaterloo.ca> References: <20170227104658.47195ifqb9947qia@www.nexusmail.uwaterloo.ca> Message-ID: <7B631C91-817B-4580-9745-288AE9755245@epfl.ch> Hi, Which version of Quantum Espresso are you using? Giovanni -- Giovanni Pizzi Theory and Simulation of Materials and MARVEL, EPFL http://people.epfl.ch/giovanni.pizzi http://nccr-marvel.ch/en/people/profile/giovanni-pizzi On 27 Feb 2017, at 16:46, a3almuta at uwaterloo.ca wrote: Hello wannier90 developers and users First thanks for the recent update to Wannier90 and introducing the symmetry adoptive feature. However, since I have updated my Wannier90 (including updating the pw2wannier90.x in my QE). I have been having an issue with the software. To try the new version I tried to do the MoS2 wannierization again this time with the symmetry adaptive option on. This is the input file to the pw2wannier90: &inputpp outdir='./' prefix='MoS2', seedname = 'MoS2' write_unk = .true. reduce_unk = .true. write_amn = .true. write_mmn = .true. write_unkg = .false. write_dmn = .true. / While it was working before the update, now I am getting this error: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Error in routine pw2wannier90 (1): reading inputpp namelist STOP 1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% so I decided to test the software with the examples provided. I chose the example21 with As_sp. When I ran the pw2wannier90, I got this error during computing DMN: ---------------- *** Compute DMN ---------------- Number of symmetry operators = 24 1-th symmetry operators is 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 . . . DMN(d_matrix_wann): nir = 10 1 2 3 4 5 6 7 8 9 10 DMN(d_matrix_wann) calculated DMN(d_matrix_band): nir = 10 1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Error in routine gather_grid (1): do not use in serial execution %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% stopping ... STOP 1 so I decided to comment the dmn calculation but I got another error when computing A: --------------- *** Compute A --------------- AMN: iknum = 64 1 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x100f9aa69 #1 0x100f99e35 #2 0x7fff92aa6529 #3 0x7fff95a89b06 #4 0x10096d4f6 #5 0x10096dd6f #6 0x10098478d #7 0x100cb841e I tried the Cu example but I still got the same two errors. I am running it on macbook pro machine (v.10.6) May you please help me fixing this issues, mainly the MoS2 one. thanks, AbdulAziz AlMutairi The University of Waterloo _______________________________________________ Wannier mailing list Wannier at quantum-espresso.org http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier -------------- next part -------------- An HTML attachment was scrubbed... URL: From a3almuta at uwaterloo.ca Tue Feb 28 22:26:59 2017 From: a3almuta at uwaterloo.ca (a3almuta at uwaterloo.ca) Date: Tue, 28 Feb 2017 16:26:59 -0500 Subject: [Wannier] Issues with pw2wannier90 In-Reply-To: <7B631C91-817B-4580-9745-288AE9755245@epfl.ch> References: <20170227104658.47195ifqb9947qia@www.nexusmail.uwaterloo.ca> <7B631C91-817B-4580-9745-288AE9755245@epfl.ch> Message-ID: <20170228162659.99976jmi8jcu6tyb@www.nexusmail.uwaterloo.ca> Quantum espresso 6.0. thanks, Quoting Giovanni Pizzi : > Hi, > Which version of Quantum Espresso are you using? > > Giovanni > > -- > Giovanni Pizzi > Theory and Simulation of Materials and MARVEL, EPFL > http://people.epfl.ch/giovanni.pizzi > http://nccr-marvel.ch/en/people/profile/giovanni-pizzi > > On 27 Feb 2017, at 16:46, > a3almuta at uwaterloo.ca wrote: > > Hello wannier90 developers and users > > First thanks for the recent update to Wannier90 and introducing the > symmetry adoptive feature. However, since I have updated my > Wannier90 (including updating the pw2wannier90.x in my QE). I have > been having an issue with the software. To try the new version I > tried to do the MoS2 wannierization again this time with the > symmetry adaptive option on. This is the input file to the > pw2wannier90: > > &inputpp > outdir='./' > prefix='MoS2', > seedname = 'MoS2' > write_unk = .true. > reduce_unk = .true. > write_amn = .true. > write_mmn = .true. > write_unkg = .false. > write_dmn = .true. > / > > While it was working before the update, now I am getting this error: > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Error in routine pw2wannier90 (1): > reading inputpp namelist > STOP 1 > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > so I decided to test the software with the examples provided. I > chose the example21 with As_sp. When I ran the pw2wannier90, I got > this error during computing DMN: > > > > ---------------- > *** Compute DMN > ---------------- > > Number of symmetry operators = 24 > 1-th symmetry operators is > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > > . > . > . > > DMN(d_matrix_wann): nir = 10 > 1 2 3 4 5 6 7 8 > 9 10 > DMN(d_matrix_wann) calculated > > > DMN(d_matrix_band): nir = 10 > 1 > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Error in routine gather_grid (1): > do not use in serial execution > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > stopping ... > STOP 1 > > > so I decided to comment the dmn calculation but I got another error > when computing A: > > --------------- > *** Compute A > --------------- > > AMN: iknum = 64 > 1 > Program received signal SIGSEGV: Segmentation fault - invalid memory > reference. > > Backtrace for this error: > #0 0x100f9aa69 > #1 0x100f99e35 > #2 0x7fff92aa6529 > #3 0x7fff95a89b06 > #4 0x10096d4f6 > #5 0x10096dd6f > #6 0x10098478d > #7 0x100cb841e > > > I tried the Cu example but I still got the same two errors. > > I am running it on macbook pro machine (v.10.6) > > May you please help me fixing this issues, mainly the MoS2 one. > > thanks, > > AbdulAziz AlMutairi > The University of Waterloo > > > > > > _______________________________________________ > Wannier mailing list > Wannier at quantum-espresso.org > http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier > > From giovanni.pizzi at epfl.ch Tue Feb 28 22:37:25 2017 From: giovanni.pizzi at epfl.ch (Giovanni Pizzi) Date: Tue, 28 Feb 2017 21:37:25 +0000 Subject: [Wannier] Issues with pw2wannier90 In-Reply-To: <20170228162659.99976jmi8jcu6tyb@www.nexusmail.uwaterloo.ca> References: <20170227104658.47195ifqb9947qia@www.nexusmail.uwaterloo.ca> <7B631C91-817B-4580-9745-288AE9755245@epfl.ch> <20170228162659.99976jmi8jcu6tyb@www.nexusmail.uwaterloo.ca> Message-ID: Does pw.x work without problems? I would check a few things: 1. That the code is not requiring too much memory 2. http://www.quantum-espresso.org/wp-content/uploads/Doc/pw_user_guide/node21.html#SECTION00060090000000000000 and in particular try to recompile with the suggestions of sec 5.0.0.9 and possibly of other sections to see if the error happens e.g. also with -O0 3. Check also if you are properly linking the libraries (lapack, bias) - e.g. if you have an issue similar to 2.7.6.1 here http://www.quantum-espresso.org/wp-content/uploads/Doc/user_guide/node14.html (I would suggest that you try at least another set of libraries, e.g. the internal ones with QE and the ones provided by Mac on the Accelerate framework). If the error is instead reproducible, doesn?t depend on memory and independent of the libraries, you can try to debug the code to see in which point the code crashes, and we can further investigate if there is a bug. Let us know the results of what you discover Thanks, Giovanni On 28 Feb 2017, at 22:26, a3almuta at uwaterloo.ca wrote: Quantum espresso 6.0. thanks, Quoting Giovanni Pizzi >: Hi, Which version of Quantum Espresso are you using? Giovanni -- Giovanni Pizzi Theory and Simulation of Materials and MARVEL, EPFL http://people.epfl.ch/giovanni.pizzi http://nccr-marvel.ch/en/people/profile/giovanni-pizzi On 27 Feb 2017, at 16:46, a3almuta at uwaterloo.ca wrote: Hello wannier90 developers and users First thanks for the recent update to Wannier90 and introducing the symmetry adoptive feature. However, since I have updated my Wannier90 (including updating the pw2wannier90.x in my QE). I have been having an issue with the software. To try the new version I tried to do the MoS2 wannierization again this time with the symmetry adaptive option on. This is the input file to the pw2wannier90: &inputpp outdir='./' prefix='MoS2', seedname = 'MoS2' write_unk = .true. reduce_unk = .true. write_amn = .true. write_mmn = .true. write_unkg = .false. write_dmn = .true. / While it was working before the update, now I am getting this error: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Error in routine pw2wannier90 (1): reading inputpp namelist STOP 1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% so I decided to test the software with the examples provided. I chose the example21 with As_sp. When I ran the pw2wannier90, I got this error during computing DMN: ---------------- *** Compute DMN ---------------- Number of symmetry operators = 24 1-th symmetry operators is 1.0000000 0.0000000 0.0000000 0.0000000 1.0000000 0.0000000 . . . DMN(d_matrix_wann): nir = 10 1 2 3 4 5 6 7 8 9 10 DMN(d_matrix_wann) calculated DMN(d_matrix_band): nir = 10 1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Error in routine gather_grid (1): do not use in serial execution %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% stopping ... STOP 1 so I decided to comment the dmn calculation but I got another error when computing A: --------------- *** Compute A --------------- AMN: iknum = 64 1 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x100f9aa69 #1 0x100f99e35 #2 0x7fff92aa6529 #3 0x7fff95a89b06 #4 0x10096d4f6 #5 0x10096dd6f #6 0x10098478d #7 0x100cb841e I tried the Cu example but I still got the same two errors. I am running it on macbook pro machine (v.10.6) May you please help me fixing this issues, mainly the MoS2 one. thanks, AbdulAziz AlMutairi The University of Waterloo _______________________________________________ Wannier mailing list Wannier at quantum-espresso.org http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier -------------- next part -------------- An HTML attachment was scrubbed... URL: From a3almuta at uwaterloo.ca Tue Feb 28 22:44:39 2017 From: a3almuta at uwaterloo.ca (a3almuta at uwaterloo.ca) Date: Tue, 28 Feb 2017 16:44:39 -0500 Subject: [Wannier] Issues with pw2wannier90 In-Reply-To: References: <20170227104658.47195ifqb9947qia@www.nexusmail.uwaterloo.ca> <7B631C91-817B-4580-9745-288AE9755245@epfl.ch> <20170228162659.99976jmi8jcu6tyb@www.nexusmail.uwaterloo.ca> Message-ID: <20170228164439.6374592ier95fnt3@www.nexusmail.uwaterloo.ca> pw.x works fine and everything before I changed to wannier90 (2.1.0) was fine. sorry for the inconvenience Quoting Giovanni Pizzi : > Does pw.x work without problems? > > I would check a few things: > 1. That the code is not requiring too much memory > 2. > http://www.quantum-espresso.org/wp-content/uploads/Doc/pw_user_guide/node21.html#SECTION00060090000000000000 and in particular try to recompile with the suggestions of sec 5.0.0.9 and possibly of other sections to see if the error happens e.g. also with > -O0 > 3. Check also if you are properly linking the libraries (lapack, > bias) - e.g. if you have an issue similar to 2.7.6.1 here > http://www.quantum-espresso.org/wp-content/uploads/Doc/user_guide/node14.html (I would suggest that you try at least another set of libraries, e.g. the internal ones with QE and the ones provided by Mac on the Accelerate > framework). > > If the error is instead reproducible, doesn?t depend on memory and > independent of the libraries, you can try to debug the code to see > in which point the code crashes, and we can further investigate if > there is a bug. > > Let us know the results of what you discover > > Thanks, > Giovanni > > > On 28 Feb 2017, at 22:26, > a3almuta at uwaterloo.ca wrote: > > Quantum espresso 6.0. > > thanks, > > Quoting Giovanni Pizzi > >: > > Hi, > Which version of Quantum Espresso are you using? > > Giovanni > > -- > Giovanni Pizzi > Theory and Simulation of Materials and MARVEL, EPFL > http://people.epfl.ch/giovanni.pizzi > http://nccr-marvel.ch/en/people/profile/giovanni-pizzi > > On 27 Feb 2017, at 16:46, > a3almuta at uwaterloo.ca wrote: > > Hello wannier90 developers and users > > First thanks for the recent update to Wannier90 and introducing the > symmetry adoptive feature. However, since I have updated my > Wannier90 (including updating the pw2wannier90.x in my QE). I have > been having an issue with the software. To try the new version I > tried to do the MoS2 wannierization again this time with the > symmetry adaptive option on. This is the input file to the > pw2wannier90: > > &inputpp > outdir='./' > prefix='MoS2', > seedname = 'MoS2' > write_unk = .true. > reduce_unk = .true. > write_amn = .true. > write_mmn = .true. > write_unkg = .false. > write_dmn = .true. > / > > While it was working before the update, now I am getting this error: > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Error in routine pw2wannier90 (1): > reading inputpp namelist > STOP 1 > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > so I decided to test the software with the examples provided. I > chose the example21 with As_sp. When I ran the pw2wannier90, I got > this error during computing DMN: > > > > ---------------- > *** Compute DMN > ---------------- > > Number of symmetry operators = 24 > 1-th symmetry operators is > 1.0000000 0.0000000 0.0000000 > 0.0000000 1.0000000 0.0000000 > > . > . > . > > DMN(d_matrix_wann): nir = 10 > 1 2 3 4 5 6 7 8 > 9 10 > DMN(d_matrix_wann) calculated > > > DMN(d_matrix_band): nir = 10 > 1 > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Error in routine gather_grid (1): > do not use in serial execution > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > stopping ... > STOP 1 > > > so I decided to comment the dmn calculation but I got another error > when computing A: > > --------------- > *** Compute A > --------------- > > AMN: iknum = 64 > 1 > Program received signal SIGSEGV: Segmentation fault - invalid memory > reference. > > Backtrace for this error: > #0 0x100f9aa69 > #1 0x100f99e35 > #2 0x7fff92aa6529 > #3 0x7fff95a89b06 > #4 0x10096d4f6 > #5 0x10096dd6f > #6 0x10098478d > #7 0x100cb841e > > > I tried the Cu example but I still got the same two errors. > > I am running it on macbook pro machine (v.10.6) > > May you please help me fixing this issues, mainly the MoS2 one. > > thanks, > > AbdulAziz AlMutairi > The University of Waterloo > > > > > > _______________________________________________ > Wannier mailing list > Wannier at quantum-espresso.org > http://mailman.qe-forge.org/cgi-bin/mailman/listinfo/wannier > > > > > > > > >