[Wien] Segfault in lapw1_mpi (SL_INIT)
Hello, When I execute lapw1_mpi, it dies on me immediately: $ ./lapw1_mpi w2k_dispatch_signal(): received: Segmentation fault Child id 0 SIGSEGV, contact developers -- MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD with errorcode 6. NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes. You may or may not see output from other processes, depending on exactly when Open MPI kills them. -- It turns out that the offending line is the first call to SL_INIT in INIT_PARALLEL (SRC_lapw1/modules.F), SUBROUTINE INIT_PARALLEL IMPLICIT NONE #ifdef Parallel include 'mpif.h' INTEGER :: IERR,i,j call MPI_INIT(IERR) call MPI_COMM_SIZE( MPI_COMM_WORLD, NPE, IERR) call MPI_COMM_RANK( MPI_COMM_WORLD, MYID, IERR) CALL BARRIER -CALL SL_INIT(ICTXTALL, 1, NPE) which is called eventually via GTFNAM at the top of the main program LAPW1. I used ifort version 11.1 (specifically, I tried two revisions: 046 and 072) and the corresponding MKL libraries (including ScaLAPACK). The MPI version is openmpi-1.3.2-icc, in case that matters. Neither lapw0_mpi nor lapw2_mpi have this problem (then again, they do not seem to use SL_INIT). Any pointers how I should proceed? Thanks, Elias
[Wien] Joining mommat2_* files
Dear List,
I would like to join optic's mommat2_* files from a parallel run into
a single mommat2 file as from a single-processor run. To this end, can
somebody tell me how the parallel files are related to the single
file? I cannot seem to figure it out.
Here is an example (just one data point):
Nb1 Nb2 Re x Im x Re y
Im y
mommat2_1: 2.1000e+01 2.2000e+01 4.4492e-17 1.5245e-11
1.5082e-11 -1.0270e-13
mommat2_2: 2.1000e+01 2.2000e+01 1.7002e-15 1.5248e-11
1.1791e-07 1.4978e-11
mommat2_3: 2.1000e+01 2.2000e+01 1.9808e-04 8.9362e-09
9.5944e-09 1.8848e-14
mommat2_4: 2.1000e+01 2.2000e+01 -1.5247e-11 1.1789e-07
1.5321e-15 1.0723e-13
mommat2 : 2.1000e+01 2.2000e+01 2.1545e-17 1.5245e-11
2.6584e-16 1.4979e-11
In opticpara, I notice that there are some lines for concatenating the
mommat2_'s, but they are commented out:
# concatenating the case.symmat files and case.mommat files
...
set i = 1
while ($i = $maxproc)
if ( $i == 1 ) then
#testinput $case.symmat_$i$updn scratchwarning
cat ${scratch}$case.symmat_$i$updn
${scratch}$case.symmat$updn
#cat ${scratch}$case.mommat2_$i$updn
${scratch}$case.mommat2$updn
cat ${scratch}$case.mat_diag_$i$updn
${scratch}$case.mat_diag$updn
cat ${scratch}$case.mme_$i$updn${scratch}$case.mme$updn
else
tail -n +2 ${scratch}$case.symmat_$i$updn
${scratch}$case.symmat$updn
#tail -n +2 ${scratch}$case.mommat2_$i$updn
${scratch}$case.mommat2$updn
tail -n +2 ${scratch}$case.mat_diag_$i$updn
${scratch}$case.mat_diag$updn
tail -n +2 ${scratch}$case.mme_$i$updn ${scratch}$case.mme$updn
endif
...
end
Thank you,
Elias Assmann
[Wien] :WARN P(J,JATOM) almost zero
Hi, I got a lot of warnings :WARN : P(J,JATOM) almost zero. Shifted Energy by -0.05 down to 0.3230 in a calculation. Can somebody tell me what it means? (And perhaps even if I need to worry about it?) The warning is given for some, but not all, of the Sr atoms in my structure. Elias Assmann PS: I will of course give details about the calculation on demand, but right now I do not know what is relevant.
[Wien] :WARN P(J,JATOM) almost zero
On 12/18/2012 07:06 PM, Peter Blaha wrote: Most likely not a problem. All it has done was to shift the E-parameter for some Sr atoms and l-values a bit, such that the radial wf. is non-zero at RMT. Good to know, thanks. I had never encountered the warning before. Am 18.12.2012 13:40, schrieb Elias Assmann: Hi, I got a lot of warnings :WARN : P(J,JATOM) almost zero. Shifted Energy by -0.05 down to 0.3230 in a calculation. Can somebody tell me what it means? (And perhaps even if I need to worry about it?) The warning is given for some, but not all, of the Sr atoms in my structure. Elias Assmann PS: I will of course give details about the calculation on demand, but right now I do not know what is relevant. ___ Wien mailing list Wien at zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
Re: [Wien] reg: wannier function
On 04/30/2013 04:14 PM, Swetarekha Ram wrote: I could understand, that I have to adjust the case.wplotin file. I have ran the SrVO3 compounds, And I have got the result. Now what I am trying for is the prototype structure, ABY3 type So this is also a perovskite? Here is the my case_centres.xyz X 7.70968951 0.69339674 9.73310398 Y 0. 2.59855000 2.59855000 Y 2.59855000 0. 2.59855000 Y 2.59855000 2.59855000 0. A 0. 0. 0. B 2.59855000 2.59855000 2.59855000 WF centre and spread1 ( -2.111410, 0.693397, -0.087996 ) 121.89828660 Sum of centres and spreads ( -2.111410, 0.693397, -0.087996 ) 121.89828660 This is from the case.wout file, yes? I think something is wrong with your Wannier projection. The spread is huge and the center is nowhere near the B atom. I have asked for the wannier function only for one orbital (in the case for B atom p orbital) I think you need to think about whether this makes sense, both from a physics point of view, and whether it is something one can reasonably expect Wannier90 to do. If you really want only one p-orbital, likely you have to at least include more bands and use disentanglement. Or did you already do that? HTH, Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] ‘mixer’ crashes when forces too large
I had a problem with a calculation that ran peacefully for a while, but then crashed in ‘mixer’ with the error forrtl: severe (59): list-directed I/O syntax error, unit -5, file Internal List-Directed Read Image PCRoutineLine Source mixer 0050704D Unknown Unknown Unknown mixer 00505B55 Unknown Unknown Unknown mixer 004AD449 Unknown Unknown Unknown mixer 00460288 Unknown Unknown Unknown mixer 0045FA98 Unknown Unknown Unknown mixer 004837C1 Unknown Unknown Unknown mixer 0048109B Unknown Unknown Unknown mixer 004286BE scfana_ 365 scfana.f mixer 0040C2DC MAIN__364 mixer.F mixer 0040411C Unknown Unknown Unknown libc.so.6 2AB1180EC994 Unknown Unknown Unknown mixer 00404029 Unknown Unknown Unknown Upon investigation, I found that the cause of the crash was a line :FSU033: 33.ATOM 120503.840520617-118793.163618910 -4395.235042983 19749.475095455 in the ‘scf’ file, which it had tried to read as [scfana.f:365] READ(MARGN(18:120),*)FHELP(1:4) !READ(MARGN,740) (FHELP(j),j=1,4) (where ‘margn’ contains the whole line). I do not attach a patch because I am not sure how this should be fixed, e.g. * change scfana.f to formatted input, * change whatever writes this line to list-directed output, or even * emit an error when the forces are so large (?) In this case I will simply change the line in the ‘scf’ and see how the calculation goes on from there. Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] ‘mixer’ crashes when forces too large
Dear Laurence and Peter, Thank you for the suggestion of changing to TOT. It appears to work (I say appears because after 2 iterations I hit the dreaded QTL-B error, but still: progress!). Elias On 05/25/2013 08:37 AM, Peter Blaha wrote: I've never seen this before. Anyway, I suggest that you resubmit with runsp -I ... This will switch in case.in2 from FOR to TOT and thus does not calculate :FSU (until the partial forces are converged and you get the converged total forces). ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Problem in SO calculation
On 05/28/2013 05:32 PM, Peter Blaha wrote: The default value 0.30 has to be changed. Use the –in1ef switch in runsp_lapw This is NOT TRUE ! When you use the latest WIEN2k version, I do NOT recommend -in1ef anymore. Any 0.30 will be automatically adjusted to EF-0.2 Ry. I think that the FAQ (qtlb, scf) still reflects the old situation: changing linearization energies manually, and -in1new, if not -in1ef (s -in1new still recommended?). It might be helpful to change that. Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] wien2wannier error
Dear Wasim, On 06/12/2013 12:09 PM, wasim raja Mondal wrote: I have written wien2wannier mail. But I didnot get any reply. So It is surely not my place to dispense personal advice, but ... Maybe you should be a little more patient? You wrote me two e-mails *yesterday* to wien2wann...@ifp.tuwien.ac.at (yes, it is just me behind that address, just a lowly grad student). I am writting wien2k mailing list. I am using wien2wannier for BaTiO3. I want to construct 9 wannier function for 3 O p orbital. I am getting the following error: Wannier90: Execution started on 12Jun2013 at 20:46:02 Exiting... No subdir.eig file found. Needed for interpolation Asking good questions is a skill. [1] Since you no longer talk about the problem you mentioned in the personal e-mails, I am going to assume you solved that one on your own. Now, all I can tell you about the error you are seeing is that the “.eig” file should be created by “w2w”, so obviously something went wrong at that step or before. Below I am giving the win file. Unfortunately that does not help me help you. Elias [1] http://www.catb.org/esr/faqs/smart-questions.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] wien2wannier error
Dear Oleg, On 06/12/2013 04:11 PM, Oleg Rubel wrote: I am certainly not an expert in w2w, but I noticed some NaN in the kpoint_path. This is usually not a good sign. Is it normal? Good catch, but that cannot explain the error as reported. These NaNs are in fact due to a bug in write_win (sorry!). It will be fixed in the next wien2wannier version, until then it is probably best to put in the right coordinates by hand. In any case, the actual Wannier projection should be independent of these NaNs. I expect them to show up only in the band structure (“_band.dat”), but I am not sure exactly how. Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] x kgen -fbz
On 06/13/2013 02:47 PM, Oleg Rubel wrote: I would suggest to explore 'x kgen -fbz' According to the UG: -fbz - runs kgen and generates a full mesh in the BZ Thank you for the suggestion. I have in fact thought had same idea, and this may well be in the next wien2wannier release. (In case it is not obvious, I am the guy who took over the maintenance of wien2wannier after Philipp left.) Before I make that change though, I want to make sure it works in all cases. I seem to recall that x kgen -fbz is sometimes different from what we are doing now (i.e. x kgen -so with case.ksym containing the identity as the only symmetry operation). But to be honest, I cannot even remember what the difference could be. Maybe someone else can comment on that. For the time being, I attach a Perl script that I use to ease the pain of ksym creation. If you use emacs, you can apply it with the following sequence: M- M-| C-x-C-c (or, you can just edit init_w2w to call the script). Elias w2w_hackstruct.pl Description: Perl program ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] wien2wannier error
On 06/12/2013 09:35 PM, wasim raja Mondal wrote: (1) There was NaN . This was my mistake. I have not given the k-path. I donot think it is related to any bug. I have given k-mesh. Now Nan is not coming. Okay. There is a bug like that in write_win (where under some circumstances reading of case.klist_band will fail, and NaNs may appear in case.win). But maybe in your case the cause was something else. (2) when some body is doing init_w2w, *.win file is automatically created. In the *.win file it is selecting hr_plot=true. which should be commented out initially. Why should it be commented out? (3)In UG, in the init_w2w section (quick start), it is written after write_win, run wannier90.x. with this you one cannot create *.nnkp file which is the aim of the this preliminary run. One should run wannier90.x --pp (subdir). then it will create the *.nnkp file. wannier90.x -pp $case will normally be run by init_w2w. If case.nnkp is not there, it means something went wrong in init_w2w. (4) In the Ug, it is written w2w caes. It should be subdir. Because we are doing prepare_w2w caes subdir. The case terminology, as well as the idea that (almost) all files are called $case.$suffix stems from Wien2k, but in Wien2k you do not give the case explicitly as an argument -- it is inferred from the working directory. On the other hand, in Wannier90 you have to give a case argument, but I do not think it needs to match the CWD. On the third hand, in wien2wannier, Philipp decided to follow Wannier90's lead in that you give a case argument to most of the programs he wrote. But, since we also need to call Wien2k programs, effectively case also has to match the CWD. History aside, it is up to you whether you want to run wien2wannier in your Wien2k case directory, or in a subdirectory (or a subsubdirectory, or in /tmp, or on a machine on the other side of the Earth). While I would strongly advise using prepare_w2wdir, it is not mandatory. So do not get hung up on this usage of the word case -- you can simply substitute $(basename $PWD) [at least if you use bash]. Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] wien2wannier error
On 06/13/2013 07:31 AM, wasim raja Mondal wrote: (1) For the generating of *.nkp file, after running Write_win, one has to run wannier90.x - -pp subdir which will creat the *.nnkp file if you have used prepare_w2w case subdir. This is not mentioned in the user guide. only wannier90.x will not work. This is a small thingh. But it creates lot of tension in the first time user mind like me. What user guide are you reading? The one I downloaded from http://www.wien2k.at/reg_user/unsupported/wien2wannier/wien2wannier_userguide.pdf says (p. 3, under Initialization (init_w2w)): wannier90.x(preliminary run): wannier90 requires the input data to be given on a special k-mesh which includes information with respect to nearest-neighbor k-points. A preliminary call of wannier90 with the option -pp stores this mesh to the file case.nnkp. (2) Before running init_w2w, one hast to do subdir.sym file. In the file one has to set number of symmetry operation is 1 and first operation has to to be identity. This is discussed by phillip in the wien2k forum and in the UG also. I think this symmetry is strongly related with k-points generation. I may be wrong. I assume you mean the case.ksym file. This is generated (rather, you are asked to generate it) in init_w2w. (3) I am felling that we are generating k-points in the init_w2w, which is showing the number of k-points for LAPW computation. There is previous generated k-points also which is called k-points for band structure calculation. The number k-points for LAPW should be less than the number of k-point for band structure k-point. In this point I may be completely wrong. I want some experts comment on that. The Wannier projection is done on a full-BZ unshifted k-mesh as generated in init_w2w. This k-mesh can be rather sparse (8x8x8 already gives well-converged results for SrVO3, for example), but since no symmetries are considered, you still tend to end up with a lot of k-points to run lapw1 on compared to your standard Wien2k run. write_win also reads the case.klist_band file, tries to sift out the special points (it takes those that have labels) and writes those to case.win (section kpoint_path). Wannier90 will then (if bands_plot is True) make a band structure for a BZ path generated from those points. The discretization of that path is controlled by the variable bands_num_points. (4)If third point is right, than one has to increase the number of k-point in the band structure . In this point I am struggling at the moment. For example I have run SrVO3 example in wien2k. In the scf I have used 8000 k-points. In the band structure calculation I have generated k-points in the simple cubic not with xcrysden. In the init_w2w run, it is showing 10 k-points for band structure calculation. Now the point is that how can I increase the k-point for band structure calculation? Note the last thing I said above -- the number of k-points in case_band.dat is independent of all the klist files; it is instead controlled by bands_num_points in case.win. HTH, Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Choice of Coulomb Energy
On 06/17/2013 03:53 PM, Laurence Marks wrote: N.B., personally I consider LDA+U to be relatively obsolete and would always use the on-site -eece as a more general method. You calibrate this via a reference, in my opinion. I do not have any experience with ‘-eece’ myself, so I am curious: isn't it true that you have to select a HF fraction ‘alpha’ in this case? Where do you get that from? Seems to me you are exchanging one adjustable parameter for another one. Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] The Wien2wannier
On 06/21/2013 10:59 PM, mourad boujnah wrote: - wannier90.x: wannier90.x computes kmesh... wannier90.x -pp cr (14:40:58) wannier90.x: Commande introuvable. So do you have Wannier90 installed and in your $PATH? ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Reg: wannier function
On 07/10/2013 05:54 AM, Swetarekha Ram wrote: But my first few line of the case.outputkgen looks like DEPENDENCE OF DIVISION OF TRANSLATION VECTORS IARB= 0 0 0 SYMMETRY MATRIX NR. 1 SYMMETRY MATRIX NR. 2 SYMMETRY MATRIX NR. 3 SYMMETRY MATRIX NR. 4 100 000 00 0 000 010 000 00 0 000 001 000 00 0 000 This means that you have only one symmetry (the identity). Did I miss something, such that it is effecting my band structure plots ? Because the SrVO3.outputkgen looks ortho= T R1 = 7.261300 0.00 0.00 R2 = 0.00 7.261300 0.00 R3 = 0.00 0.00 7.261300 DEPENDENCE OF DIVISION OF TRANSLATION VECTORS IARB= 0 0 0 NUMBER OF POINT GROUP OPERATIONS =2 SYMMETRY MATRIX NR. 1 SYMMETRY MATRIX NR. 2 SYMMETRY MATRIX NR. 3 SYMMETRY MATRIX NR. 4 100 -100 00 0 000 010 0 -10 00 0 000 001 00 -1 00 0 000 SYMMETRY MATRIX NR. 1 SYMMETRY MATRIX NR. 2 SYMMETRY MATRIX NR. 3 SYMMETRY MATRIX NR. 4 100 -100 00 0 000 010 0 -10 00 0 000 001 00 -1 00 0 000 This also looks strange, because SVO should have 48 symmetries, not 2; also, normally only one “SYMMETRY MATRIX” line would be printed if there are no more than 4 symmetries. Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Wien2Wannier with spin-orbit coupling
Dear Kyohn, I finally got a chance to look into your problem, and I can reproduce the behavior you describe. Without SO everything worked fine. With SO, the projection clearly went awry: The spreads were too large (~16 Ų vs ~4 Ų in the non-SO case), the centers were off, and the Wannier bandstructure was bad also. Is that what you saw? I then tried the example on a different machine, because I had a different Wien2k version there -- I thought maybe something about SO had changed and broken the w2w procedure. There, I really did get good results, but it turns out that the key difference was the compiler and LAPACK library used for wannier90. The problem happened when I used ‘ifort’ together with the ATLAS library. I tried various combinations of ifort/gfortran and MKL/ATLAS/netlib, but only ifort+ATLAS seems to have this problem. Can you please try if a similar strategy works in your case? Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] ssh with password authentication
On 08/25/2013 01:03 PM, Yundi Quan wrote: Can WIEN2k use multiple nodes which do not share memory with each other and requires password to communicate? If you are talking about a situation where you are unable to use passwordless login like Peter suggested, there is a way to do it. It is not trivial (i.e. `echo PASSWORD | ssh ...´ does not work) because `ssh´ tries to prevent this kind of thing because it is insecure; you have to trick `ssh´ into thinking its input comes from a terminal. One such solution is provided by `sshpass´: http://sourceforge.net/projects/sshpass/. Use this script with care, if you have to. If you can, use the proper ssh-keygen / ssh-copy-id method. Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Reg: wannier
Dear Swetarekha Ram, On 09/01/2013 06:17 PM, Swetarekha Ram wrote: I am running wannier function programme. I have followed the UG and could able to reproduce the example. Now I was running for other compound, with the perovskite structure. When I put the command write_win case, I got the error as below. I have checked the memory of my system also, I have nearly 200 GB space. This step need more than this space for the calculation . Or what could be the reason ? glibc detected *** write_win: malloc(): memory corruption: 0x00ec00b0 *** From this error message, I can only tell you that something went wrong in `write_win´ (although the real problem may be at an earlier step); and it is not an out of memory error (incidentally, are you sure that 200 GB is not your disk space rather than RAM [=memory]). Please tell us what you did to arrive at this error, and/or produce a more meaningful error message (compile with `-g´, debug print statements, ...). Elias Assmann ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Reg: wannier
On 09/03/2013 02:28 PM, Swetarekha Ram wrote: Then I used x kgen -so and took the 8*8*8 mesh and got total 512 points in the irriducible Brillouin zone. Then I ran x lapw1 find_bands case -2 1 write_w2win case and then write_win In this point I got the error massage as before Did you execute these commands manually (rather than through init_w2w)? write_win expects to find a file case.outputkgen_orig (from which it reads symmetry operations). init_w2w will create this as a copy case.outputkgen. Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] to change an atom in the unit cell
On 09/18/2013 11:44 AM, AJAY SINGH VERMA wrote: atom, (below is the .struct file), for creating the 2 vacancies i replaced MULT= 2 by MULT= 1 and removed the 7th line (ATOM -1:X= 0. Y=0.5000 Z=0.2500) That should work, but the ‘struct’ is a fixed-format file, so you have to be really careful not to mess it up (try “overwrite” mode in your favorite editor). HTH, Elias cugas2 B LATTICE,NONEQUIV.ATOMS: 3122_I-42d MODE OF CALC=RELA unit=ang 10.027836 10.027836 19.840242 90.00 90.00 90.00 ATOM -1: X=0. Y=0. Z=0. MULT= 2 ISPLIT= 8 ATOM -1:X= 0. Y=0.5000 Z=0.2500 Cu NPT= 781 R0=0.5000 RMT=2.2000 Z: 29.0 LOCAL ROT MATRIX:1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 ATOM 2: X=0. Y=0. Z=0.5000 MULT= 2 ISPLIT= 8 ATOM 2:X= 0. Y=0.5000 Z=0.7500 Ga NPT= 781 R0=0.5000 RMT=2. Z: 31.0 LOCAL ROT MATRIX:0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 ATOM 3: X=0.25540025 Y=0.2500 Z=0.1250 MULT= 4 ISPLIT= 8 ATOM 3:X= 0.2500 Y=0.74459975 Z=0.8750 ATOM 3:X= 0.74459975 Y=0.7500 Z=0.1250 ATOM 3:X= 0.7500 Y=0.25540025 Z=0.8750 S NPT= 781 R0=0.0001 RMT=1.8000 Z: 16.0 LOCAL ROT MATRIX:0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0 NUMBER OF SYMMETRY OPERATIONS ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] to change an atom in the unit cell
On 09/18/2013 02:14 PM, AJAY SINGH VERMA wrote: thank u for the reply, sir i had asked 1 more question to replace one of the Cu atom to Ga As u can see that in .struct file we have only one Cu atom left and if i change this, whole of the unit cell will contain no Cu atom. Ok, I misread what your problem was, sorry. In this case you need to (1) create a supercell (e.g. in ‘octave’ with the ‘structeditor’ suit of functions, or using the ‘supercell’ program, both of which come with Wien) (2) split the equivalent positions in a suitable way (i.e., reduce MULT); you can do this with an editor like you did, or with ‘structeditor’ or maybe also with StructGen under ‘w2web’ (3) remove Cu's as desired (4) replace Cu-Ga as desired (if you do this in an editor, you have to make sure that you change the name, Z, and R0 consistently) (5) run ‘nn’, ‘symmetry’, and ‘sgroup’ to get the “real” multiplicities. More information about all of these steps should be available in the list archives, as well as the documentation. Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] symmetso warns operation was not found in struct
Dear List, For a rhombohedral structure, I did `initso´ after converging a non-SO calculation. `symmetso´ complains (in the last section of `outsymmetso´): WARNING !! nsym found by symmetry differs from iord read in struct 12 4 Why does it say that? This would seem normal to be, since it is `symmetso´s job to reduce the symmetry. After that: Symmetry operation 2 0.50.866030.0 0.86603 -0.50.0 -0.00.0 -1.0 0.00.00.0 -1. -0. -0.0. 0.0. -1.0. 0. -1.0.0. WARNING ! this symmetry operation was not found in struct!! This kind of thing is repeated a couple of times. What does this mean? The last three lines of numbers specify a symmetry operation which *is* in fact in the struct file; what are the four lines before that? I am not very familiar with SO, nor with rhombohedral symmetry calculations, so I am unsure if it is safe to continue. The new `struct´ file created looks fine. It has 4 symmetry operations. The `ksym´ is empty, is that normal? Wow, that was a lot of questions. Thank you for you patience. Elias PS: I am using Wien2k13. ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] optic sum rules
On 10/01/2013 11:24 AM, ali ghafari wrote: Actually, I have repeated the calculations again. I see the spectra are almost same for 2000 and 3000 kpoints but still there is a significant change in the spectra for 9 kpoints. As Xavier indicated in his PS, it almost certainly means that something is going wrong, though I cannot tell you what it is. If you see no difference in epsilon between 2k and 3k k-points, I would say that means the mesh is converged for optics. Even if you want to be very careful in your convergence test, keep in mind that all other optical quantities are calculated directly from epsilon. The only other thing you could check is convergence in the energy range you calculate Im(eps) in, because the Kramers-Kronig needs it (in principle) from 0 to infinity. how can I explain it? furthermore, when you said 2000, 3000 kpoints, your means is in the BZ or IBZ? In the full Brillouin zone. Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Error in *.vectorup and *.vectordn type files unformatted in SCF and Volume Optimization
On 10/09/2013 06:03 PM, Gavin Abo wrote: I think the / in front of /CoFeMnSn.vectordn suggests that SCRATCH might have been set to the root directory were user permission problems can occur instead of the current directory ./ [http://zeus.theochem.tuwien.ac.at/pipermail/wien/2012-May/017013.html]. IIRC, that happens when SCRATCH is empty (or unset). If you want to “not use SCRATCH”, it is necessary to ‘set SCRATCH=.’. On 10/9/2013 8:56 AM, Vivek Jain wrote: Dear all, I am running wien2k version on Ubuntu 12.04 system. i am Calculating SCF for CoFeMnSn heusler alloys using PBE-GGA 96 approximation, Rmt*Kmax = 7.0 after 3 cycle completely successful run then following error occurs in dnlapw1.error file Error in LAPW1 'INILPW' - can't open unit: 10 'INILPW' -filename: /CoFeMnSn.vectordn 'INILPW' - status: unknown form: unformatted 'LAPW1' - INILPW aborted unsuccessfully. This type (*.vectordn) of file present in folder but i am not able to open *.vectordn. this error also occur when we copy the struct file in other session and different folder and SCF calculation run. sometimes SCF successfully run and when we do Volume optimization then same problem occurs. -- Vivek Kumar Jain Department of Physics MohanLal Sukhadia University, Udaipur ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] Why does ‘save_lapw’ save ‘vsp’ but not ‘vns’?
Hi List, The ‘save_lapw’ script saves the spherical part of the potential (‘case.vsp’), but not the aspherical part (‘case.vns’). The user guide mentions [‘restore_lapw’, 5.2.2] that after restoring, you should run a ‘x lapw0’ to recreate the potential before running ‘x lapw1’. I wonder, what is the reasoning behind this choice? Why not save ‘vns’? Given that ‘x lapw0’ will recreate it anyway, why save ‘vsp’ at all? I could not find any discussions about this in the archive, but I thought an explanation might be interesting to more people than just me. Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] ‘lapw2 -so’ hangs
Dear Peter, On 11/07/2013 09:50 AM, Peter Blaha wrote: energysoup and energysodn should be the same. They are, up to a small difference in the header. (case.energyup/dn could be larger because in lapw1 you may have a larger E-window (more eigenvalues) than in case.inso What puzzled me was that in the case that works normally, `energysodum´ and `energysodn´ are the same size; while in the broken case, `energysodum´ is the same size again, but `energysodn´ is much smaller. Have you looked into case.outputso and case.inso ? $ cat Bi100.inso WFFIL 4 0 0 llmax,ipr,kpot -10 1.5Emin, Emax 1 0 0 h,k,l (direction of magnetization) 0 number of atoms with RLO 0 0 number of atoms without SO, atomnumbers The only difference to the `inso´ for the non-broken case is the magnetization direction. The calculation ran fine for a long time before this problem appeared, and I did not change the input file. As for `outputso´, like I said, it goes through all 12008 k-vectors. But in `energysodn´, only 2431 k-points are listed. What else should I look for in `outputso´? Do you get sufficient eigenvalues ?? Maybe E-max in case.inso is wrong?? How many is sufficient? What I can say is that the calculation ran fine for a long time before this problem appeared, and I did not change the input files. Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] ‘lapw2 -so’ hangs
Dear Peter,
I have tried to narrow things down a bit. The subroutine
‘fermi_tetra’ gets stuck in the loop labeled ‘14’. Here is a
code snippet:
498 4 K=K+1
499if(iloop0.ne.0) KPP(ILOOP0)=K
500 !para begin
501 ! testing
502 ! write(*,*)'reading k=',K,itap,ispin,iloop,iloop0
503 !para end
504IF(K.GT.2*NKPT) GOTO 900
505READ(ITAP,5001,END=999) SS,T,ZZ,KNAME,N,NEHELP(K,ispin),WEI
506nmat=MAX(n,nmat)
507
508 !para begin
509NE(K+k1)=NEHELP(K,ispin)
510 !para end
511if(nehelp(k,ispin).gt.nume) GOTO 920
512if(nemax.lt.nehelp(k,ispin)) nemax=nehelp(k,ispin)
513IF(N.GT.MAXWAV) MAXWAV=N
514IF(N.LT.MINWAV) MINWAV=N
515 14 READ(ITAP,*) NUM,E1
516Eb(num,K,ispin)=E1
517if(itap.eq.30.and.(e1.gt.ebmax(num))) ebmax(num)=e1
518if(itap.eq.30.and.e1.lt.ebmin(num)) ebmin(num)=e1
519 ! READ(ITAP) (A(I),I=1,N)
520IF(NUM.EQ.NEHELP(K,ispin)) GOTO 4
521GOTO 14
I put a debug statement
write(0,*) 'Hello ', k,ispin, nehelp(k,ispin), nume
before l. 511. The last few lines of output look either like this:
Hello 2434 2 54 60
Hello 2435 2 54 60
Hello 2436 2 56 60
Hello 2437 2 0 60
Hello 2438 2 0 60
Hello 2439 2 1198992928 60
FERMI - Error
where an error is raised on l. 511, or like this:
Hello 2434 2 54 60
Hello 2435 2 54 60
Hello 2436 2 56 60
Hello 2437 2 0 60
Hello 2438 2 0 60
Hello 2439 2 -820289632 60
where the program goes into the infinite loop instead.
What happens is that the NEHELP array is too small, so the READ on
l. 505 fails and NEHELP(K,ispin) ends up containing uninitialized
data. So I guess the problem stems from the ‘energysodn’ which is too
small, and I need to go look at what is going wrong in lapwso.
But I thought I should share this anyway. In particular, I do not
understand what is going on with the SIGSEGVs the program gets. They
would be caused by NEHELP being too small, but why doesn't the program
die? The Wien2k signal handling is not invoked (since this is not
parallel); I do see a call
rt_sigaction(SIGSEGV, {0x4d2480, [],
SA_RESTORER|SA_RESTART|SA_NODEFER|SA_SIGINFO, 0x2b472c1f5ca0}, NULL, 8) = 0
in the trace, but ifort seems to do this even for the simplest test
program, and that does not prevent it from dying on a SIGSEGV.
Secondly, I thought the READ on l. 515 would raise an error on EOF;
instead it seems to “busy wait” (it never returns but keeps the CPU
usage at 100%).
What is more, I found that the problem interacts in a subtle way with
ifort's (V. 11.1) ‘-ipo’ and ‘-g’ switches. Originally, I had ‘-ipo’
set, resulting in the infinite loop. For debugging, I took that out
and added ‘-g’ instead, which resulted in the behavior described
above.
Turning ‘-ipo’ back on, the debug output looks like this:
Hello 2434 2 54 60
Hello 2435 2 54 60
Hello 2436 2 56 60
Hello 2437 2 56 60
and the infinite loop always happens.
When I use neither switch, the result is what I would normally expect:
the program dies from the segfault.
Summarizing, this is what I see:
-g -ipo : silent fail
-ipo : silent fail
-g : “FERMI - Error” / silent fail
: “normal“ segfault
Sorry for the overlong e-mail.
Elias
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] ‘lapw2 -so’ hangs
Hi, Regarding my original problem, it has disappeared upon another “lapw0; lapw1; lapwso” cycle, only this time I first did a ‘clean’. I guess something must have been left in an inconsistent state from previous calculations in that directory, and ‘clean’ removed the offending file. Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Large magnetic moment in LaCoO3 compound in Low Spin state
On 11/13/2013 11:29 AM, saurabh singh wrote: :MMI002: MAGNETIC MOMENT IN SPHERE 2=1.0879. It is well known that this compound shows zero moment in ground state for Low Spin. Why this is showing non zero moment. One thing to keep in mind is that you can often stabilize different magnetic configurations (which you set in ‘lstart’, whose default is ‘up’, not ‘nm’!). These should be compared by total energy. For spin polarize calculations we apply some field in a particular direction to split the up and down spin to get the net moment. Is there any setting in wien2k_13.1 to set the field manually. You can apply a magnetic field (in some approximation) using ‘orb’ (q.v. in the UG). You can force a particular total spin magnetic moment using ‘runfsm’, and ‘runsp_c’ fakes a spin-polarized calculation constraining both spins to be the same. A non-sp ‘run’ would, of course, also force zero moment. HTH, Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Print plane wave coefficients flom LAPW1 with -p option
On 01/08/2014 01:20 AM, Oleg Rubel wrote: I wonder if anybody can reproduce this error? I can. I used only MPI-parallelism: $ cat .machines 1: localhost localhost $ x lapw1 -up -p w2k_dispatch_signal(): received: Segmentation fault $ cat uplapw1.error ** Error in Parallel LAPW1 ** LAPW1 STOPPED at Wed Jan 8 10:26:39 CET 2014 ** check ERROR FILES! Error in LAPW1 'Unknow' - Process termination signal received Wien2k v13.1; Intel Fortran v11.0.074; MKL v10.1.0.015; MVAPICH2 $ cat $WIENROOT/VERSION WIEN2k_13.1 (Release 17/6/2013) `cat $WIENROOT/COMPILER` -V Intel(R) Fortran Intel(R) 64 Compiler Professional for applications running on Intel(R) 64, Version 11.1Build 20090630 Package ID: l_cprof_p_11.1.046 with Open MPI 1.4.4 HTH, Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Print plane wave coefficients flom LAPW1 with -p option
Dear Oleg, I attach a little program for converting the ‘vector’ file to plain text, maybe this can help. This was just a quick hack (derived from ‘join_vectorfiles’), but it worked for me. As for reading ‘vector’ in Python, are you using f2py for that? I guess you could take (the read-in part of) ‘join_vectorfiles’ and wrap that with f2py … Elias !!! wien2wannier/util/vec2ascii.f90 !!! !!!Translates WIEN2k vector files to plain text. Based on !!!join_vectorfiles. !!! !!!Usage: vec2ascii [-up/-dn] [-c] case numberofparallelfiles !!! !!! Copyright 2013 Elias Assmann PROGRAM vec2ascii use util, only: line_count use structmod, only: struct, struct_read use const, only: BUFSZ implicit none character(50) seedname integer nkpoints,nfiles integer iarg,argcount !command line input argument counter integer jatom,i,j,k,jl,jj,jk integer lmax,lomax,nloat integer unitklist,unitkgen,unitstruct,unitvector, unitenergy, unittargetvector,unittargetenergy character(70) argdummy,startmessage logical :: usecomplex INTEGERNE, NV DOUBLE PRECISION SX, SY, SZ, WEIGHT CHARACTER(3) IPGR,filenr CHARACTER(10) KNAME DOUBLE PRECISION, allocatable :: EIGVAL(:) DOUBLE PRECISION, allocatable :: E(:,:),ELO(:,:,:) INTEGER, pointer :: KZZ(:,:) DOUBLE PRECISION, allocatable :: Z(:,:) DOUBLE COMPLEX, allocatable :: ZC(:,:) type(struct) stru character(bufsz) :: vectorfileend, targetvectorfileend character(bufsz) :: energyfileend, targetenergyfileend character(bufsz) :: suf DOUBLE PRECISION eorb_ind !default fileending: non spin-polarized targetvectorfileend = .vector_ascii vectorfileend = .vector energyfileend = .energy targetenergyfileend = .energy_ascii startmessage = ++ join vector files of standard input ++ unitkgen = 1 unitvector = 2 unitenergy = 3 unittargetvector = 4 unittargetenergy = 5 unitklist = 11 !parameters LMAX = 13 LOMAX = 3 nloat = 3 !command line argument read-in iarg=command_argument_count() argcount = 1 usecomplex = .false. if ((iarg.ge.1)) then do j=1,iarg call get_command_argument(j,argdummy) if (argdummy(1:1).eq.'-') then if ((argdummy(2:3).eq.'up').or.(argdummy(2:3).eq.'dn')) then !for spin-polarized calc. the fileendings have additional up/dn vectorfileend = .vector//argdummy(2:3) energyfileend = .energy//argdummy(2:3) startmessage = ++ join vector files of spin-polarized input files://argdummy(2:3)// ++ elseif ((argdummy(2:5).eq.'soup').or.(argdummy(2:5).eq.'sodn')) then vectorfileend = .vectorso//argdummy(4:5) energyfileend = .energyso//argdummy(4:5) usecomplex = .true. startmessage = ++ ascii'ize vector files of spin-polarized spin-orbit input files://argdummy(4:5)// ++ elseif (argdummy(2:2).eq.'c') then usecomplex = .true. elseif (argdummy(2:2).eq.'h') then write(*,*) 'joins multiple WIEN2K vector files to one for further processing' write(*,*) 'Usage: vec2ascii [-up/-dn/-soup/-sodn/-c] case numberofparallelfiles' stop else write(*,*) 'Unknown option' write(*,*) 'Usage: vec2ascii [-up/-dn/-soup/-sodn/-c] case numberofparallelfiles' stop endif else if (argcount.eq.1) then read(argdummy,*)seedname argcount = argcount + 1 else read(argdummy,*)nfiles endif endif enddo else write(*,*) 'Usage: vec2ascii [-up/-dn/-soup/-sodn/-c] case numberofparallelfiles' stop endif write(*,*)case is:, seedname write(*,*)startmessage open(unit=unitklist,file=trim(seedname)//'.klist',status='old') open(unit=unitstruct,file=trim(seedname)//'.struct',status='old') call struct_read(unitstruct, stru) nkpoints = line_count(unitklist) -2 !take care write(*,*)#kpoints,nkpoints close(unitstruct) close(unitklist) allocate( E(LMAX,stru%nat) ) allocate( ELO(0:LOMAX,nloat,stru%nat) ) open(unit=unittargetvector,file=trim(seedname)//trim(targetvectorfileend), status='unknown',form='formatted') open(unit=unittargetenergy,file=trim(seedname)//trim(targetenergyfileend), status='unknown',form='formatted') do j=1,nfiles if (nfiles == 1) then suf = else write(filenr,(I3))j suf = _//trim(adjustl(filenr)) end if open(unit=unitvector, file=trim(seedname)//trim(vectorfileend)//suf, status='old',form='unformatted') open(unit=unitenergy, file=trim(seedname)//trim(energyfileend)//suf, status='old',form='formatted') do jatom= 1,stru%nat read(unitvector) (E(jl,jatom),jl=1,LMAX) read(unitvector) ((ELO(jl,k,jatom),jl=0,LOMAX),k=1,nloat
Re: [Wien] Print plane wave coefficients flom LAPW1 with -p option
On 01/08/2014 06:49 PM, Oleg Rubel wrote:
I tried to compile the FORTRAN code you attached. It has the include statement
use util, only: line_count
use structmod, only: struct, struct_read
use const, only: BUFSZ
I was able to find 'util.f' in the w2w package, but not 'structmod'
and 'const'. Would you please send me those too.
Sorry, I forgot about that. I attach ‘util.F’ (which contains all those
modules) and a header file it needs. The ‘util.f’ from the current
wien2wannier distribution will not work with this ‘vec2ascii.f90’.
When compiling remember that for the ‘.F’ file you have tell that
compiler that it is free-form, so
$ ifort -warn all -free util.F vec2ascii.f90 -o vec2ascii
or
$ gfortran -ffree-form -Wall util.F vec2ascii.f90 -o vec2ascii
(of course you need to use the same as for lapw1 …)
Elias
!!! wien2wannier/util/util.f90
!!!
!!!Collection of routines for the programs in util/ and woptic/
!!!
!!! Copyright 2010-2012 Philipp Wissgott
!!! Copyright 2013 Elias Assmann
!--- Constants mathematical and configurational ---
module const
use iso_fortran_env, only: int32
implicit none
public
integer, parameter :: BUFSZ = 256
!! Default kinds
integer, parameter :: DP = selected_real_kind(15,300) ! inherited from W90
integer, parameter :: IP = int32
!! Kinds for WIEN-compatibility
real*4, private :: four_real
real*8, private :: eight_real
complex*16, private :: sixteen_complex
integer, parameter :: R4 = kind(four_real)
integer, parameter :: R8 = kind(eight_real)
integer, parameter :: C16= kind(sixteen_complex)
real(DP), parameter :: PI = 3.1415926535897932d0
real(DP), parameter :: ORTHO_TEST = 1.d-12
real(DP), parameter :: SQ3= sqrt(3d0)
end module const
!--- Assorted miscellanea ---
MODULE util
use const, only: DP, BUFSZ
implicit none
private
public :: string, inverse3x3, ptime, uppercase, lowercase, line_count
interface string
module procedure int2str, real2str
end interface string
contains
character(len=10) function int2str(n)
integer, intent(in) :: n
write(int2str,(I5)) n
end function int2str
character(len=15) function real2str(r)
real(DP), intent(in) :: r
write(real2str,(E16.9)) r
end function real2str
subroutine inverse3x3(a, ainv)
!inverse of th 3x3 matrix A
implicit none
real(DP), intent(in) :: a(3,3)
real(DP), intent(out) :: ainv(3,3)
real(DP) :: det
det = a(1,1)*a(2,2)*a(3,3) + a(1,2)*a(2,3)*a(3,1)
+a(1,3)*a(2,1)*a(3,2) - a(3,1)*a(2,2)*a(1,3)
-a(1,1)*a(3,2)*a(2,3) - a(2,1)*a(1,2)*a(3,3)
ainv(1,1) = ( a(2,2)*a(3,3) - a(2,3)*a(3,2) ) / det
ainv(2,1) = (- a(2,1)*a(3,3) + a(2,3)*a(3,1) ) / det
ainv(3,1) = ( a(2,1)*a(3,2) - a(2,2)*a(3,1) ) / det
ainv(1,2) = (- a(1,2)*a(3,3) + a(1,3)*a(3,2) ) / det
ainv(2,2) = ( a(1,1)*a(3,3) - a(1,3)*a(3,1) ) / det
ainv(3,2) = (- a(1,1)*a(3,2) + a(1,2)*a(3,1) ) / det
ainv(1,3) = ( a(1,2)*a(2,3) - a(1,3)*a(2,2) ) / det
ainv(2,3) = (- a(1,1)*a(2,3) + a(1,3)*a(2,1) ) / det
ainv(3,3) = ( a(1,1)*a(2,2) - a(1,2)*a(2,1) ) / det
end subroutine inverse3x3
subroutine ptime(descr, unit)
character(len=*), intent(in), optional :: descr
integer, intent(in), optional :: unit
character(len=*), parameter :: fmt = ('Times for ', A, T33, '(sec):',
F8.3, ' wall;', F9.3)!, ' cpu =', F8.3, ' user +', F8.3, ' sys')
real(DP), save :: cputime1, cputime2
integer,save :: walltime1, walltime2, count_rate
integer,save :: default_lun
integer :: lun
if (.not. present(descr)) then
call cpu_time(cputime1)
call system_clock(walltime1, count_rate)
if (present(unit)) default_lun=unit
return
end if
if (present(unit)) then
lun=unit
else
lun=default_lun
end if
call cpu_time(cputime2)
call system_clock(walltime2)
write(lun, fmt) descr, real(walltime2-walltime1)/count_rate,
(cputime2-cputime1)
walltime1 = walltime2
cputime1 = cputime2
end subroutine ptime
pure function uppercase(str)
character(*), intent(in) :: str
character(len(str)) :: uppercase
integer :: ic, i
character(26), parameter :: CAP = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'
character(26), parameter :: low = 'abcdefghijklmnopqrstuvwxyz'
uppercase = str
do i = 1, len_trim(str)
ic = index(low, str(i:i))
if (ic 0) uppercase(i:i) = CAP(ic:ic)
end do
end function uppercase
pure function lowercase(str)
character(*), intent(in) :: str
character(len(str)) :: lowercase
integer :: ic, i
character(26), parameter :: CAP = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'
character(26), parameter :: low = 'abcdefghijklmnopqrstuvwxyz'
lowercase = str
do i = 1, len_trim(str)
ic = index
[Wien] wien2wannier release 1.0-beta
Dear Wien2k users, A new version of wien2wannier (1.0-beta), the interface from Wien2k to Wannier90, is available at http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/ The new version is tagged as a “beta” release until it has been more thoroughly tested. Nonetheless, it is fully functional and you are encouraged to use this version. Bug reports to wien2wann...@ifp.tuwien.ac.at will be appreciated. New features include: * more flexible and powerful specification of initial projections (e.g., arbitrary rotations are supported) * fix handling of k-points for various lattice types * wien2wannier may now be used under the terms of the GNU GPL Please see the file ‘NEWS’ in the distribution for more information. -- Elias Assmann (TU Wien) Wien2Wannier: maximally localized Wannier functions from linearized augmented plane waves http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/ ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] error in mixer upon changed k-points
Hi, I encountered the following error after generating a new klist: At line 968 of file mixer.F (unit = 22, file = 'svo.scf') Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE The klist changed in the course of ‘initso’. After I removed ‘*.clm*_old’, it seems to run fine. This is WIEN2k_13.1 compiled with gfortran. Elias -- Elias Assmann Institute of Solid State Physics Vienna University of Technology http://www.ifp.tuwien.ac.at/cms/ ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] wien2wannier release 1.0-beta2
Dear wien2wannier users, A minor update of the package is available at http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/ It fixes a couple of bugs that have turned up in the 1.0-beta release. -- Elias Assmann (TU Wien) Wien2Wannier: maximally localized Wannier functions from linearized augmented plane waves http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/ ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] leaking core charge and ‘.lcore’
Hi, I am working on a structure containing Osmium. In init, I got a warning that Os 5s core charge (about 1%) leaked out of the sphere (RMT=2.08 set by setrmt). I increased the Os RMT to 2.5 manually, decreasing the RMT of its O neighbor to 1.3. Then there were no warnings in lstart, but the calculation crashed after a couple of iterations with QTL-B / “semicore band-ranges too large” errors. (The errors were about Os.) So I tried instead to run the calculation with the original RMTs and the ‘.lcore’ file created by init. This way, the SCF converged without any errors or warnings; ‘lcore’ and ‘dstart -lcore’ were executed at every step. The band structure looks reasonable as well. What does this lcore stuff imply for my calculation? Should I consider the results suspect? Thanks, Elias -- Elias Assmann Institute of Solid State Physics Vienna University of Technology http://www.ifp.tuwien.ac.at/cms/ ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] leaking core charge and ‘.lcore’
Dear Peter, On 04/04/2014 09:30 AM, Peter Blaha wrote: I don't know the energy of Os 5s. If it is just a little below -6. Ry, just lower E-core, if it is at lower energies, .lcore should be fine. From ‘outputst’ (Os): 4D -19.549263-19.549263 3.00 3.001. T 5S -6.687517 -6.687517 1.00 1.000.9941 T 5P* -4.363745 -4.363745 1.00 1.000.9824 F For comparison, there is also a Barium atom (RMT=2.5) in the cell which has: 4P -12.947176-12.947176 2.00 2.001. T 4D* -6.697509 -6.697509 2.00 2.000.9998 T 4D -6.505422 -6.505422 3.00 3.000.9998 T 5S -2.471967 -2.471967 1.00 1.000.9295 F So if I do this by changing the separation energy, at least the Ba-4D state would go into valence as well. Would that be a problem? The solution with .lcore should be perfectly ok in your case. .lcore directs the code to use the spherical core-density (also beyond RMT) and do a superposition of these densities using dstart (see the dayfile). .lcore would NOT be ok if Os-O distances become so small, that the Os-5s band gets a significant band-width due to the interaction with O. Okay, good to know. Many thanks, Elias -- Elias Assmann Institute of Solid State Physics Vienna University of Technology http://www.ifp.tuwien.ac.at/cms/ ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] [wien2wannier] wplot error
Dear Kefeng, On 05/09/2014 10:27 PM, Kefeng Wang wrote: I tried to follow the SrVO3 example in wien2wannier 1.0 beta2 and Wannier90 1.2. Everything went well until the command ‘x wplot –wf –m” failed. The error message is “forrtl: severe (59): list-directed I/O syntax error, unit -5, file Internal List-Directed Read”. Before that, I compared the bandstructures and it is good. Could anybody help me out? We are going to need more info. That error message only says some read failed. On which file, for starters? Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] [wien2wannier] wplot error
On 05/09/2014 10:27 PM, Kefeng Wang wrote: Dear All, I tried to follow the SrVO3 example in wien2wannier 1.0 beta2 and Wannier90 1.2. Everything went well until the command ‘x wplot –wf –m” failed. The error message is “forrtl: severe (59): list-directed I/O syntax error, unit -5, file Internal List-Directed Read”. Before that, I compared the bandstructures and it is good. Could anybody help me out? Sorry, I see I was a bit too fast there -- it is an “internal read”, i.e. it is trying to read from a string. My guess is that it is the ‘-m’ in your command line. The option is ‘-wf M’ where M is a number; ‘-m’ is not a valid option. Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] wien2wannier 1.0-β3
Dear Wien2k Users, A new version of wien2wannier (1.0-β3) is available for download at http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/. It includes an important fix to ‘convham’, which produced wrong results in the last version. If you use this program, you should definitely upgrade. -- Elias Assmann (TU Wien) Wien2Wannier: maximally localized Wannier functions from linearized augmented plane waves http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/ ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] wien2wannier version 1.0-β4
Dear wien2wannier Users! A new version of the package is available at http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/. This is a minor update that fixes a few bugs, including one in ‘wplot2xsf’ that caused it to crash. -- Elias Assmann (TU Wien) Wien2Wannier: maximally localized Wannier functions from linearized augmented plane waves http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/ ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] specific DOS plots
On 07/17/2014 04:20 AM, delamora wrote: plot BiRuO-U-afm.dos1evup using 1:2 title Total w l lt 1 lw 2, \ BiRuO-U-afm.dos1evup using 1:5 title Ru w l lt 3 lw 2, \ BiRuO-U-afm.dos1evup using 1:6 title Ru w l lt 4 lw 2, \ BiRuO-U-afm.dos2evup using 1:($2+$3+$4) title O1 w l lt 8 lw 2, \ BiRuO-U-afm.dos1evup using 1:($3+$4) title Bi w l lt 2 lw 2 This is the most straightforward way, but note that the newest ‘tetra’ can also sum columns for you. See the end of ‘SRC_templates/case.int’ for how to do that. Of course you could also sum them with some script, e.g. perl -lne '@x = split; $sum=0; $sum+=$_ for @x[1,2,3]; print join(qq(\t), $x[0], $sum)' or … -- Elias Assmann Institute of Solid State Physics Vienna University of Technology http://www.ifp.tuwien.ac.at/cms/ ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] How to subtract a particular orbital character from a valence electronic density?
On 07/21/2014 03:40 PM, Martin Gmitra wrote: I would like to plot valence density (lapw5) in a narrow energy window around Fermi level (calculated by lapw2 -all flag) to which I would like to subtract specific atomic orbital character. Say that the density can be expressed as a combination (due to hybridization) of atomic orbitals rho(r)=A(r) s + B(r) p + C(r) d + ..., where the coefficients A(r), B(r), C(r), ... reflect hybridization. My case would be to subtract, say d-orbitals as rho(r) - C(r) d. This differs from modifying case.inst (lstart -sigma flag) and subtracting case.sigma. It looks like to dig in QTL files or can you provide another solution or hint how to start? If the bands in question are fully occupied, you could use Wannier functions. Transform “all” bands to s,p,d-like WFs in one Wannier projection (using wien2wannier http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/ and Wannier90 http://www.wannier.org/), then either compute the density |w(r)|² of the d-like WFs using ‘wplot’ and subtract from the total density computed by lapw5; or add the densities of the other WFs from ‘wplot’. Some points to keep in mind if you decide to try this: * The wave functions output by wplot are currently not normalized to unity. If you mix densities from lapw5 and wplot, you need to control this carefully. * The WFs are not atomic orbitals, i.e. you will not get exactly what you describe (depending on what you want to do, I suppose this might be an advantage or a disadvantage). Qualitatively, the more bands you include in your projection, the more they will approach the atomic orbitals. See http://arxiv.org/abs/1405.3804 or http://arxiv.org/abs/1405.7232 for discussions of this with respect to specific materials. This means you should think carefully about what kind of projection is appropriate. * While anything you do with QTLs or similar will be limited to the MT spheres, the WFs are not affected by RMTs. Of course, for very localized states this will make little difference. Elias -- Elias Assmann Institute of Solid State Physics Vienna University of Technology http://www.ifp.tuwien.ac.at/cms/ ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Problem about the optic calculation
On 08/13/2014 08:05 AM, 田丰 wrote: 1. normal SCF run. 2. change the 'tetra' in file .in2 to 101. 3. run step by step of Optic in w2web. However when I click 'x joint -up(dn)' error message is reported as following: opmat allocated with kkk,nemax1,ncol 560 12 2 ( 0 MB) forrtl: severe (24): end-of-file during read, unit 4, file /home/lapw/fccNi.weightup You need to run ‘x lapw2 -fermi’ to get the ‘weight’ files. -- Elias Assmann Institute of Solid State Physics Vienna University of Technology http://www.ifp.tuwien.ac.at/cms/ ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] wien2wannier with wien2k.14.1
On 09/24/2014 03:32 AM, Zhu, Jianxin wrote: Sorry for disturbing you this afternoon. It is for me to apologize for inflicting this problem on you (and on other wien2wannier users, I fear) through my choice to use UTF-8 characters in some wien2wannier messages. I chose to use those characters because they were nice for formatting the names of orbitals for the initial projections in `write_inwf' (like Peter's example `z²'), and because I thought that support for them should be pretty much universal on any modern system. Of course I was aware that there might be a few people it would fail for, but not that it would fail so badly. (You showed that not only are the Unicode characters displayed wrongly, but ASCII character between them are deleted: `-emin X -emax Y' [substituting apostrophes for the offending Unicode quote marks] becomes â!) I will shortly provide an ASCIIized version of wien2wannier, and avoid non-ASCII characters in future versions. (Of course, the Right Thing would be to make the programs aware of the locale settings and adjust the messages accordingly, as many tools do these days ...) After a few more times of struggling, I pinned down the root cause to be with the setting of xterm under x11. With the correction, the problem disappears. Of course, we still need to setenv LANG en_US.UTF-8 on the linux cluster if the UTF-8 is not set as default, if we remotely log onto it. On my machine, experimentation shows that it is a question of the locale settings in effect when the terminal is started. I.e., $ unset LANG $ xterm gives me a terminal that displays the characters wrongly, but just changing it in the current shell [old terminal] $ xterm [new xterm]$ unset LANG does not change the behavior. Also, xterm showed the problem while my standard terminal application does not. Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] DMFT
Hi Pablo, On 10/13/2014 03:55 AM, delamora wrote: I want to include the DMFT into the calculations and apparently wannier90 does this type of calculations, but I cannot see how to do them. The wannier90 user-guide does not even mention DMFT. Is there a guide for these type of calculations? Wannier90 does not do DMFT; to use the MLWFs from Wannier90 as a basis for DMFT is one of the many applications you might use MLWFs for. In the interest of completeness, I will just mention two DMFT implementations that are often used with Wien2k: TRIQS, and its Wien2k interface Wien2TRIQS http://ipht.cea.fr/triqs/1.1/applications/dft_tools/index.html; and w2dynamics, http://www.physik.uni-wuerzburg.de/en/institute_einrichtungen/department_of_theoretical_physics_and_astrophysics/theoretische_physik_i/tp_i/mitarbeiter/prof_dr_giorgio_sangiovanni/ Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] wien2wannier and gfortran for complex cases
Dear wien2wannier users, Unfortunately, there is a problem with wien2wannier (specifically, the ‘w2wc’ program) for complex cases which appears when it is compiled with gfortran. The symptoms are similar to the problem discussed in this thread http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg09109.html: ‘x w2w’ finishes normally, but Wannier90 fails to converge with the generated ‘amn’ and ‘mmn’ files. This problem appears at least with Wien2k_14.2 compiled with gfortran 4.4 and 4.8 with ATLAS and OpenBLAS libraries. Executables compiled with ifort and MKL have worked fine in my tests. Currently I do not know what causes this problem and would appreciate any feedback. I apologize for the inconvenience to gfortran users and will post back here if there are any new developments. -- Elias Assmann (TU Wien) Wien2Wannier: maximally localized Wannier functions from linearized augmented plane waves http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/ ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] wien2wannier for non-spinpolarized SOC cases
Dear wien2wannier users, There is a minor problem in the ‘wannier90’ script for cases with spin-orbit coupling but without spin polarization. It looks for ‘eigup’ and ‘eigdn’ files which do not exist. The easiest solution is simply to copy the ‘eig’ file: $ x w2w -so -up x w2w -so -dn $ cp CASE.eig CASE.eigup $ cp CASE.eig CASE.eigdn $ x wannier90 -so -- Elias Assmann (TU Wien) Wien2Wannier: maximally localized Wannier functions from linearized augmented plane waves http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/ ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Some questions about the vec2ascii program
Hi Majid, I am cross-posting this to the mailing list. On 10/25/2014 12:34 PM, Majid Yazdani wrote: I have two questions about the vec2ascii program. Could you help me to solve them? First off, I do not really consider ‘vec2ascii’ fully supported. I wrote that code for a specific problem and thought it might be helpful for other people as well. I have not tested it since then. I use the wien2k14.1 code to calculate the electronic and optical properties of a compound by 12 core Intel processor.I need to change the case.vectores for some calculations. So I use the vec2ascii which is implemented in the wien2k14.1 to do this. If you want to “change the .vector files” (to continue with lapw2 using the new ones?) are you sure vec2ascii is the best way to proceed? If you need to write them in binary, maybe you can skip the plain-text step. After running this program a case.vector_ascii is produced. That's already good news, I suppose! ;-) The size of the case. vector_ascii is: [papi@cm6 case]$ du -sh case.vector_ascii 23G case.vector_ascii While the size of the case.vectore is: [papi@cm6 case]$ du -sh case.vector* 619Mcase.vector_1 … 620Mcase.vector_12 Why is the size of the case. vector_ascii very larger than that of the case.vectors? Because the regular vector files are in binary rather than plain text. Thus they need much less space and less time to read and write. I suppose that is the reason why they are stored in binary in the first place. (You can try zipping the plain-text file, that should get it back to roughly the binary-file size.) Is there any program to reproduce the case.vectors from the modified case.vector_ascii file so that they are suitable for the Wien2k code? Not that I know of. Of course, you can try “reversing” the input code … -- Elias Assmann Institute of Solid State Physics Vienna University of Technology http://www.ifp.tuwien.ac.at/cms/ ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Some questions about the vec2ascii program
On 10/25/2014 09:42 PM, Majid Yazdani wrote: If one would like to shift up the unoccupied eigenvalues by a constant for a specific test, one would change the case.vector_* files. If seems that for this purpose, it is better to do it by case.energy_* files. But, case.energy will not be read by optic programs, e.eg http://e.eg/., joint, which will be not the case for case.vector_* files. Therefore, for performing some tests, sometimes it is necessary to change the case.vector_* files. The problem is that these files are written in binary format and not plain text. I do not know where ‘joint’ gets its eigenenergies from, but ‘kram’ can take an “energy shift” (a.k.a. “scissors operator”) option. Maybe that can help. But, why the size of the case.vector_* files after converting to the plain text (by vectoascii.f) is extremely larger than the case.evergy_* files. Maybe the contain something different information. Certainly. ‘energy’ contains only the eigenvalues (one number per state), ‘vector’ the eigenvectors (many coefficients per state). Here, I am a little bit confused. If the above numbers represent the eigenvalues, why the magnitudes of them are close to zero, but the magnitudes of the numbers given in the case.energy_* are between -7 Ry to 2 Ry (around the energy window in case.in1c)? If you need to know precisely which information is in the ‘vector’ file in what order, I think your best bet is to read the code that writes or reads them. I cannot tell you that without looking it up myself. If you think that there is another better way to shift up the unoccupied energies so that the changed made in energies can be read by the optic programs, please let us know. Maybe here Peter can make more clear the problem. Sounds like the scissors operator should do it. Not that I know of. Of course, you can try “reversing” the input code … I believe you are the best to reverse reads and writes in a suitable manner in the vec2ascii.f so that the procedure is revered, as we really do not know the format of the original vector files. This task more or less just means replacing every READ() with a WRITE(). What is the original format of the case.vectores which are produced by the wien2k code? Are they produced as plain text files (or other format different from the binary) and then stored as binary files or they are produced as binary files at the first by the wien2k code? They are written in binary. In the ‘def’ files, some files are listed as ‘formatted’, this means plain-text and they are written using FORMAT strings; others are ‘unformatted’, this means binary and no FORMATs in READ()/WRITE(). If this is the way you want to do it, I would just read the vector record by record and write it back out (in binary) to a new file immediately, applying whatever changes you need. If you wanted to get fancy, you could probably use STREAM access to replace only the changed records in the original file in-place. Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] (no subject)
On 10/28/2014 10:24 AM, Kevin Jorissen wrote: 1. Upgrade WIEN2k ; your version is much too old. We have version 14.1 now. 14.2 actually ;-P ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] wien2wannier and gfortran for complex cases
Dear wien2wannier users,
The problem with w2wc and gfortran reported previously appeared because
the makefile did not keep the real and complex module files separate.
I include a detailed explanation below, but the easy fix is to compile
the complex version before the real one, i.e.
===
cd $WIENROOT/SRC_w2w
make clean
make complex
make real
cp -v w2w{,c} ..
cd ../SRC_wplot
make clean
make complex
make real
cp -v wplot{,c} ..
===
If this fix does not work for you, please report.
‘wplot’ should also be affected because it uses the same real/complex
system. The problem was (probably) introduced with the first 1.0-beta
version.
Detailed explanation: The source files that do not differentiate between
real and complex are compiled with
gfortran -Ilib -c $OBJ.f -olib/$OBJ.o -J lib
the “complex” ones with
gfortran -Ilib -c $OBJ.F -olibc/$OBJ.o -J libc -D_COMPLEX_
but the “real” ones are compiled with
gfortran -c $OBJ.F -olibr/latgen.o -J lib
instead of -Jlibr.
This means that the ‘.mod’ files for the “real” modules end up in lib/
instead of libr/. If they are already there, they are then used in
compiling the complex executable, which is inconsistent. Unfortunately,
the compiler does not catch this problem. As for ifort, it is the same
in principle (just replace -J by -module), but it seems that ifort does
not mind the inconsistent ‘.mod’s, or maybe it uses the correct ones by
chance or design.
I tested all of this with gcc 4.8.2.
Elias
PS: Should this be considered a bug in gfortran? I am wondering if I
should submit a bug report.
--
Elias Assmann (TU Wien)
Wien2Wannier: maximally localized Wannier functions
from linearized augmented plane waves
http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] wien2wannier interface
On 03/12/2015 03:14 PM, wasim raja Mondal wrote:
Going through the script, I found it is related with case.
Sorry, but I do not understand that. Which script, precisely? What is
“case”, the Wien2k “case name”, or character case (big/little)?
Thanks,
Elias
PS: For the reference, I tried this with a directory named “W_test”
using the current wien2wannier version; everything seems to work fine.
If it works for you as well, we can put this issue to rest. The
following is straight from my terminal:
elias@hupuntu ~/W/SrVO3 prepare_w2wdir W_test
elias@hupuntu ~/W/SrVO3 cd W_test
elias@hupuntu ~/W/S/W_test init_w2w -b -bands 21 23 -proj V:dt2g
next is kgen
kgen -fbz ( 100 0 ) (13:51:57)
1 symmetry operations without inversion
NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
length of reciprocal lattice vectors: 0.865 0.865 0.865 4.642
4.642 4.642
Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)
64 k-points generated, ndiv= 4 4 4
KGEN ENDS
0.003u 0.000s 0:00.00 0.0% 0+0k 0+104io 0pf+0w
/home/elias/wien2k/write_inwf -f W_test -bands 21 23 V:dt2g (13:51:57)
write_win (13:51:58)
wannier90 -pp (13:51:58)
0.035u 0.024s 0:00.10 50.0% 0+0k 18728+72io 53pf+0w
elias@hupuntu ~/W/S/W_test x lapw1; x w2w; x wannier90
LAPW1 END
9.752u 0.179s 0:09.96 99.5% 0+0k 8192+21296io 30pf+0w
W2W END
3.507u 0.012s 0:03.52 99.7% 0+0k 0+416io 0pf+0w
0.065u 0.018s 0:00.09 77.7% 0+0k 4752+488io 24pf+0w
elias@hupuntu ~/W/S/W_test write_inwplot W_test
From wannier90 output W_test.wout(in Angstrom):
WF centre and spread1 ( -1.921251, -1.921251, -1.921251 )
1.65655335
WF centre and spread2 ( -1.921251, -1.921251, -1.921251 )
1.65655337
WF centre and spread3 ( -1.921251, -1.921251, -1.921251 )
1.65655337
Sum of centres and spreads ( -5.763753, -5.763753, -5.763753 )
4.96966010
Enter origin of spatial mesh in fractions of the conv. unit vectors [n1
n2 n3 ndiv]
-1 -1 -1 1
Enter endpoint on x-axis [n1 n2 n3 ndiv]
0 -1 -1 1
Enter endpoint on y-axis [n1 n2 n3 ndiv]
-1 0 -1 1
Enter endpoint on z-axis [n1 n2 n3 ndiv]
-1 -1 0 1
Enter number of mesh points, [nx ny nz]
10 10 10
elias@hupuntu ~/W/S/W_test x wplot -wf 1; x wplot -wf 2; x wplot -wf 3
written on 16Mar2015 at 13:52:22
0.810u 0.011s 0:00.82 100.0%0+0k 0+128io 0pf+0w
written on 16Mar2015 at 13:52:22
0.802u 0.019s 0:00.82 98.7% 0+0k 0+128io 0pf+0w
written on 16Mar2015 at 13:52:22
1.000u 0.019s 0:01.02 99.0% 0+0k 0+128io 0pf+0w
elias@hupuntu ~/W/S/W_test wplot2xsf -v
+ wplot2xsf converting 3 Wannier functions +
Will print |w(r)|^2*sgn(Re w(r)).
Reading atoms info from `W_test.struct':
atom 1 ``Sr'', Z: 38.0
atom 2 ``V'', Z: 23.0
atom 3 ``O'', Z: 8.0
Read offsets: [ 3.84250188 3.84250188 3.84250188]
[ 3.84250188 3.84250188 3.84250188]
[ 3.84250188 3.84250188 3.84250188]
from `W_test_centres.xyz' - `W_test.wout'.
Converting WF #3: (W_test_3.psink, W_test_3.psiarg) - W_test_3.xsf
reading `W_test_3.psink'
reading `W_test_3.psiarg'
Converting WF #2: (W_test_2.psink, W_test_2.psiarg) - W_test_2.xsf
reading `W_test_2.psink'
reading `W_test_2.psiarg'
Converting WF #1: (W_test_1.psink, W_test_1.psiarg) - W_test_1.xsf
reading `W_test_1.psink'
reading `W_test_1.psiarg'
elias@hupuntu ~/W/S/W_test ls -l W_test*.{psink,psiarg,xsf}
-rw-rw-r-- 1 elias elias 16100 Mar 16 13:54 W_test_1.psiarg
-rw-rw-r-- 1 elias elias 16307 Mar 16 13:54 W_test_1.psink
-rw-rw-r-- 1 elias elias 16792 Mar 16 13:54 W_test_1.xsf
-rw-rw-r-- 1 elias elias 16100 Mar 16 13:54 W_test_2.psiarg
-rw-rw-r-- 1 elias elias 16307 Mar 16 13:54 W_test_2.psink
-rw-rw-r-- 1 elias elias 16792 Mar 16 13:54 W_test_2.xsf
-rw-rw-r-- 1 elias elias 16100 Mar 16 13:54 W_test_3.psiarg
-rw-rw-r-- 1 elias elias 16307 Mar 16 13:54 W_test_3.psink
-rw-rw-r-- 1 elias elias 16792 Mar 16 13:54 W_test_3.xsf
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] wien2wannier interface
On 03/17/2015 09:58 AM, Kyohn Ahn wrote: Maybe I can share my experiences. I'm a user of v0.96. Thank you for the report. The problem is most likely related to ‘xsfAll.sh’ looking for a string “_N” in the filename, where N is a number. I believe this is already fixed in the new version, where ‘wplot2xsf_lapw’ by default simply looks for all ‘*.psink‘ files, and does not care about the filenames except for the extensions. Elias The problem occurs when _ exists in the filename. More specifically, the trouble appears when I tried to get Wannier plots. I think that the key is in either [prepare_plots.sh] or [xsfAll.sh]. (I could not find any problem with other operations, such as write_w2win, write_win, w2w, ..., etc.) My filename was, for example, [SrVO3_super.~~~]. Then the outputs (~xsf files, etc,) were strange. I deleted _ in the name of input files, i.e., [SrVO3_super.~~~] → [SrVO3super.~~~]. Then the problem disappeared. Have a nice day.! - Kyohn ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] wien2wannier interface
Hi Wasim, Of course it is possible to produce plots (in psink+psiarg but also xsf format) using pre-1.0 wien2wannier (the last version was 0.97). If the problem is really the conversion to xsf, you should also be able to use the wplot2xsf script from the new wien2wannier version to do this conversion, regardless of where your psink/psiarg files came from. (That script is one of the things that changed a lot) However, I would recommend upgrading to Wien2k 14.2. This is of course the standard advice, but I think it applies especially to wien2wannier since so much has changed from 0.x to 1.0, and it is probably more trouble than it would ever be worth to “backport” wien2wannier 1.0 to Wien2k 13. Elias On 03/09/2015 02:27 PM, wasim raja Mondal wrote: Dear Ellias, I was using wien2k version 13 and wien2wannier version 0.96. With this version of wienwannier interface I am not able to plot wannier function. I am using SrVO3 example. I able to create case m.psiarg and case.psink but not creat XSF file to visualize in xcrsden. So my question is following 1. Is this bugs with version 0.96 of wien2wannier interface? 2. I have to install new veriosn (1.0)? If yes, then I have to install wienk_14? With wien2k_14 , wien2k_wannier interface will be automatically install? Wannier90 also? or I have to install separately install wannier90? 3. Is it possible to install this interface with wanneir13? Regards wasim ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] wien2wannier interface
On 03/10/2015 10:09 AM, wasim raja Mondal wrote: *xsfAll.sh subdir_final* If you are using wien2wannier 1.0 now, note that xsfAll.sh is no longer part of that. The new version of wplot2xsf can convert all your plots in one step. ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] wien2wannier interface
On 03/11/2015 07:24 AM, wasim raja Mondal wrote: wplot2xsf.py subdir_final 2 o.out I think wplot2xsf.py is still the pre-1.0 incarnation of wplot2xsf_lapw (as it is known in the new Wien2k distribution). Two suggestions if you want to use the new version now: * Remove the old wien2wannier from your $PATH. * Read the documentation. Yes, even if you are an experienced pre-1.0 user; a lot of things have changed. You may get away with only looking at the file CHEATSHEET. Is this o.out file is in xsf format which I have to see in xcrysden? That does look like an xsf file (just look at another xsf and compare — there is also a good description of the format on the XCrySDen homepage http://lmgtfy.com/?q=xsf+formatl=1). Elias CC: Wien2k list for the archives. ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] wien2wannier interface
Glad you could solve the problem. Could you clarify what happened? If a bug like this exists in the current version of wplot2xsf, I would like to fix it. Elias On 03/11/2015 09:33 AM, wasim raja Mondal wrote: Hi Kyhon, Just now I have solved the issue this way. Thanks a lot. Regards wasim On Wed, Mar 11, 2015 at 2:01 PM, Kyohn Ahn kyohn1...@gmail.com mailto:kyohn1...@gmail.com wrote: Hi, Mondal. Could you try to delete _ in the name of your files? for example.., [abc_qwe.vector] → [abcqwe.vector] I had a similar experience to you (for old version of w2wan). Have a nice day.! - Kyohn ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] wien2wannier interface
On 03/09/2015 04:52 PM, wasim raja Mondal wrote: Hi Ellias, Thanks. In 1.0 version when I am using write_inwf , it tells to give next proj. (3 to go; Ctrl-D if done)? V 2 didn't catch that: SITE and ORB must be given This is a question that the ‘-h’ switch of write_inwf (or the wien2wanner user's guide) should really answer. Please look at that again, and if it does not become clear, get back to me and tell me what you intend “V 2” to mean. Elias what I have to give for SrVO3? Regards wasim On Mon, Mar 9, 2015 at 8:06 PM, Elias Assmann elias.assm...@gmail.com mailto:elias.assm...@gmail.com wrote: Hi Wasim, Of course it is possible to produce plots (in psink+psiarg but also xsf format) using pre-1.0 wien2wannier (the last version was 0.97). If the problem is really the conversion to xsf, you should also be able to use the wplot2xsf script from the new wien2wannier version to do this conversion, regardless of where your psink/psiarg files came from. (That script is one of the things that changed a lot) However, I would recommend upgrading to Wien2k 14.2. This is of course the standard advice, but I think it applies especially to wien2wannier since so much has changed from 0.x to 1.0, and it is probably more trouble than it would ever be worth to “backport” wien2wannier 1.0 to Wien2k 13. Elias On 03/09/2015 02:27 PM, wasim raja Mondal wrote: Dear Ellias, I was using wien2k version 13 and wien2wannier version 0.96. With this version of wienwannier interface I am not able to plot wannier function. I am using SrVO3 example. I able to create case m.psiarg and case.psink but not creat XSF file to visualize in xcrsden. So my question is following 1. Is this bugs with version 0.96 of wien2wannier interface? 2. I have to install new veriosn (1.0)? If yes, then I have to install wienk_14? With wien2k_14 , wien2k_wannier interface will be automatically install? Wannier90 also? or I have to install separately install wannier90? 3. Is it possible to install this interface with wanneir13? Regards wasim _ Wien mailing list w...@zeus.theochem.tuwien.ac.__at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.__ac.at/mailman/listinfo/wien http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/__wien@zeus.theochem.tuwien.ac.__at/index.html http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html _ Wien mailing list w...@zeus.theochem.tuwien.ac.__at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.__ac.at/mailman/listinfo/wien http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/__wien@zeus.theochem.tuwien.ac.__at/index.html http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] wien2wannier interface
On 03/09/2015 06:54 PM, wasim raja Mondal wrote: Hi, In wein2k_14 version, wannier90 also compiled with wien2k? At the stage of wanner90.x -pp I am getting this error /home/wien2k_14_installation/wannier90: line 156: wannier90.x: command not found 0.0u 0.0s 0:00.00 0.0% 0+0k 0+0io 0pf+0w I have to separately download and install wannier90 and add the path in bashrc? On Mon, Mar 9, 2015 at 9:22 PM, wasim raja Mondal wasimr.mon...@gmail.com mailto:wasimr.mon...@gmail.com wrote: Hi Ellias, Thanks. In 1.0 version when I am using write_inwf , it tells to give next proj. (3 to go; Ctrl-D if done)? V 2 didn't catch that: SITE and ORB must be given what I have to give for SrVO3? Regards wasim On Mon, Mar 9, 2015 at 8:06 PM, Elias Assmann elias.assm...@gmail.com mailto:elias.assm...@gmail.com wrote: Hi Wasim, Of course it is possible to produce plots (in psink+psiarg but also xsf format) using pre-1.0 wien2wannier (the last version was 0.97). If the problem is really the conversion to xsf, you should also be able to use the wplot2xsf script from the new wien2wannier version to do this conversion, regardless of where your psink/psiarg files came from. (That script is one of the things that changed a lot) However, I would recommend upgrading to Wien2k 14.2. This is of course the standard advice, but I think it applies especially to wien2wannier since so much has changed from 0.x to 1.0, and it is probably more trouble than it would ever be worth to “backport” wien2wannier 1.0 to Wien2k 13. Elias On 03/09/2015 02:27 PM, wasim raja Mondal wrote: Dear Ellias, I was using wien2k version 13 and wien2wannier version 0.96. With this version of wienwannier interface I am not able to plot wannier function. I am using SrVO3 example. I able to create case m.psiarg and case.psink but not creat XSF file to visualize in xcrsden. So my question is following 1. Is this bugs with version 0.96 of wien2wannier interface? 2. I have to install new veriosn (1.0)? If yes, then I have to install wienk_14? With wien2k_14 , wien2k_wannier interface will be automatically install? Wannier90 also? or I have to install separately install wannier90? 3. Is it possible to install this interface with wanneir13? Regards wasim _ Wien mailing list w...@zeus.theochem.tuwien.ac.__at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.__ac.at/mailman/listinfo/wien http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/__wien@zeus.theochem.tuwien.ac.__at/index.html http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html _ Wien mailing list w...@zeus.theochem.tuwien.ac.__at mailto:Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.__ac.at/mailman/listinfo/wien http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/__wien@zeus.theochem.tuwien.ac.__at/index.html http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html Yes. ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] initial projections with spin-orbit coupling for wien2wannier?
On 05/07/2015 04:25 PM, Xu Wenhu wrote: --- !!! Dummy `projections' block for guiding centers !!! ! guiding_centres = .true. begin projections 1:s 1:s ... end projections --- Does it do any good or harm if I change the orbital labels 's' to, say, 'dxy', 'dxz', 'dyz', to be consistent with those in 'case.inwf'? No. They are not actually used. I notice the comment line so I guess perhaps this part is only for the 'guiding' purpose and the orbital information is not used anyway? Precisely. Elias ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] (no subject)
Hi, I am a bit late to this thread, but I wanted to point to this earlier post where I had the same problem: http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg10349.html I /think/ I found that the error happened with gfortran but not ifort (which might help explain how the bug slipped through). This thread http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg07949.html also discusses evidently the same issue. But about -fno-whole-file, note that on my machine (gfortran 4.8), the docs say “The '-fno-whole-file' option is deprecated and may lead to wrong code”; in gfortran 4.9 the option was effectively removed https://gcc.gnu.org/wiki/GFortran/News#gfortran_4.9. Anyhow I do not see how -fno-whole-file relates to the end-of-file issue. Finally there is this gcc bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477 which seems to me to imply that gfortran is simply adhering to a stricter interpretation of the standard than ifort (as it often does). But note that I have not checked if the issue in mixer.F is really the same as in the bug report. HTH, Elias On 04/16/2015 07:42 AM, Jiayi Wu wrote: Dear wien2k users: I am a new Wien2k user . I am running version 13.1 on debian7.7.0 compiling with gfortran. The purpose of my calculations is to get the DOS of Fe2CrAl including the spin-orbit coupling.I am following the user guide for this calculation. runsp_lapw save_lapw case_nrel initso_lapw runsp_lapw -so There are the case.inso WFFIL 4 1 0 llmax,ipr,kpot -10. 10.0 emin,emax (output energy window) 1. 1. 1. direction of magnetization (lattice vectors) 2 number of atoms for which RLO is added 1 -4.97 0.0005 atom number,e-lo,de (case.in1), repeat NX times 3 -4.97 0.0005 atom number,e-lo,de (case.in1), repeat NX times 2 2,4number of atoms for which SO is switch off; atoms But, it happens after I was running runsp_lapw -so . Checking the STDOUT I have the following: hup: Command not found. STOP LAPW0 END STOP LAPW1 END STOP LAPW1 END STOP LAPWSO END STOP LAPW2 END STOP LAPW2 END STOP CORE END STOP CORE END At line 968 of file mixer.F (unit = 22, file = 'FeCrAlSi.scf') Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE stop error Have tried many methods, but those did not work. I do not know where was wrong and how should I do. Please help me, thanks! Jiayi ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] initial projections with spin-orbit coupling for wien2wannier?
Dear Wenhu Xu, SOC is one of those areas that are less well explored with wien2wannier, so please take everything I say with a grain of salt. On 05/06/2015 07:34 PM, Xu Wenhu wrote: 1. Is it possible to mix spin-up and -dn components in the 'case.inwf' file to have the Jeff=1/2 orbitals as the trial function? I notice there are only LM components in 'case.inwf' and no options for the spin sector. The A_mn and M_mn matrix elements are summed over spins before they are passed to Wannier90. In this sense, yes, spin-up and -dn are mixed, though you cannot give a specific linear combination for your initial projections. Should I also execute BOTH 'init_w2w -up' and 'init_w2w -dn' for a non-spin polarized calculation? No. init_w2w should only be called once for a given directory, and the only thing that the -up/-dn options are used for in that script is findbands (i.e., figuring out which band numbers lie within a given energy interval). With SO, in any case, init_w2w should be run in “-so mode” (although the explicit -so switch should not be necessary, i.e. just run ‘init_w2w’); it will then look at case.outputso for the states (and normally find twice as many states as you would have for one spin). 2. If not possible to mix spin-sectors in 'case.inwf', do I need to repeat each LM projector when using 'init_w2w' so there will be two for each of them in 'case.inwf' and 'case.win'? Yes. Since you have “twice as many states” you should also give twice as many initial projections. Normally, they will just be repeated. -- Elias Assmann Wien2Wannier: maximally localized Wannier functions from linearized augmented plane waves http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/ ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] Kinetic Energy for a subset of bands
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, As explained in the UG, one can get the total Kohn-Sham kinetic energy T_S using the KCX switch of lapw0. Is it also possible to get the KS kinetic energy corresponding to a subset of bands (or an energy range)? (To be precise, the kinetic energy of orbital i f_i| -hbar^2/2m nabla^2 |f_i summed over a specified range of i rather than all occupied bands.) It seems this might be possible by imposing a different Fermi energy, and taking the difference in :EKIN between two calculations. Is this feasible? If yes, how to do it technically? Elias -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJVhDwBAAoJEE/4gtQZfOqPbfwP/jcB8Rmy9FCqdZkUlSRk+Eh7 L7iFwEDc34HEL+LANa7TAt3C3mXx8f6Xv3q6yToYgcRKaDawRMG/aSnmGlt6XCfP e1zXVGfU8wdF53fzG50eS8Kiffjm7qHsDQdoDOvHfPOVo6dHgHG2CaFZkKLJwJhR we3tE5uxVUXjTCVi+UrwEiT2663PzHnWD9tAl1s6NokBOGKWGyO8iKuZUTv5xIxs MR9Lrlhq2EVOqpjYd7zvRWBjX1uYexT4Q+LKsnUVtGLXNO8m7NH5ZQjA1Y+pQ+6E hKlRpi4OlmPUHDm+fEWgRJbBIeb0UUEg0ZdZ7rL1+uetCflw3Uydk4nec9JROFSe kYFqY51e+Kzcfbh09ARKTwb7X3Nvh2dmr57r7V1qenhTHeFCKKHyqS6N07//tZH5 MQJG4NcBvolWux/uRMq0Wqzm/zWeIz67g9/WRoQbiB3yXWVSSvMPVPqRNRUdojxl BG+Cf6++qgjs/JSp946we9K9JpksWaVom+BBifyOV02Pc2365J68GsxTxbwSWEVW 4/XVwF9kiv8Jt5k4+pdDZCTBFDNIUYqhaOrXgVQ1nuWUR+1w17ngdIK7mblCKf0c TUMpy/kIlaEC2eMybh2PI15iATIbscUm1h3MZJhehi+atgFA5W88XdLfJpmDixJs vFEXUnvLhx0VT3Pj/bhD =GrbJ -END PGP SIGNATURE- 0x197CEA8F.asc Description: application/pgp-keys ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] x w2w error in WIEN2k.14
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/27/2015 10:31 AM, Yue-Wen Fang wrote: > BTW, the band structure (subdir.spaghetti_ene) was written. This is from Wien2k's ‘spaghetti’ rather than Wannier90. > $ ~/fang/v1/subdir 17:46:20 >x wannier90 wannier90 error: examine > the output/error file for details 0.009u 0.007s 0:00.05 0.0% > 0+0k 0+0io 3pf+0w > > *At the end of the file "subdir.wout", it said that * This seems okay, but you say nothing about the /error/ file. Is there a ‘subdir.werr’, and what does it contain? > *Then, "vi subdir.nnkp" was used to check the contents of nnkp > file. This file contained many k-points. But the official guide > said that position and spread of the WF’s should be written in > subdir.wout, in my case, this part of data was missing. Have you > ever encountered this problem?* ‘nnkp’ is an auxiliary file generated by ‘wannier90.x -pp’, see Wannier 90 UG. Elias -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJWL0W4AAoJEE/4gtQZfOqP37gP/jfmEYBQI6TdXjWxc/WUPfk7 X+A/dX4DKL69H9KNwISU0kBHxIYN2lC3tqojNvj8mcBFZvbWD1cnsw28Ms6W8K36 epfwsmGABGjSUyq90uD0Whz/fIS7WgEvr/OS5flDI3wWyFO4bVK3umdUW/KJ/18X fQA7DgQ98B5QRhgHSKjiGr1xJIMq7QB3/VVpZXyZLERTCUfzSkw1O+WxUX8eEg68 0Jrp5XLsCuNElioSoHq/FP36HXtTE0PfWQQC9VjhEaDqO5Ehbfa3ooIK/eBmKJZr Yqi4fWqSlCvKNQSbTbhL/eRotF6mHALMbkVua8/dVnrYLLCse0AiIFe4fC22O1vf uLu233EvHFTLaV6wCm7wx1fFAHaXBhFPWZ6tfsvNyttbIR66R2pgDxBbSGJTQAoI uwn2APPh58Prge8j3N3Fcej4SKcK4EcCrZIpSE8p9YC6d26f8QQyXK6E+Z6VSzlx 0+WcN/f1ED+XxGQI0cClsa8GDH73bWeAOZj4oG2m92KmmV1CsRK8RIu0p8v+AMt0 zMu4+GliJxJDdDRiy5wpG4tWe0976MSi+YQZzDi0o2RvNrGp8oObAq1z2/3rdG0C TfBgryLT4uXEfKvXll+wt+dl/Izg/cFExEU89CzsW3sxniK2yeBK8mEkhcMgw1L0 LWpZDD62qx8Dz6oWOjKQ =q+Dl -END PGP SIGNATURE- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] x w2w error in WIEN2k.14
On 10/27/2015 02:04 PM, Yue-Wen Fang wrote: > For the hoping > integral, I reviewed the content of case_hr.dat, it contains much data, > how could I find hopping between different orbitals? The file ‘case_hr.dat’ contains seven columns: the displacement R, the WF indices i and j, and the complex hopping amplitude H_ij(R): Rx Ry Rz i j Re Im I usually just use ‘grep’ to filter out specific hoppings, e.g. $ grep case_hr.dat -e '^ +0 +0 +0' for the local terms, or $ grep case_hr.dat -Ee '^ +[-0-9]+ +[-0-9]+ +[-0-9]+ +([0-9]+) +\1 ' for the diagonal (i=j) terms. -- Elias Assmann Institute of Theoretical and Computational Physics TU Graz ⟨https://itp.tugraz.at/⟩ signature.asc Description: OpenPGP digital signature ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] x w2w in wien2wannier
Dear Fang, I am taking this back on list because it might be of interest to others. On 10/27/2015 12:46 PM, Yue-Wen Fang wrote: > *Another question:* > I inspected the fitted band using 512 kpoints , the shape of it was same > to the bands generated by wien2k-lapw, nevertheless the values between > them had discrepancy, it looked that the fitted one's Fermi level was > shifted and scaled by certain factor, what may cause this error? I > looked up the manual, but didn't get answer by myself. The band > structure created by the command "p ’case.spaghetti ene’ u ($4/0.53):5, > ’case band.dat’ w l" was attached. The image you attached ⟨http://i.imgur.com/dLbUo6V.jpg⟩ looks as if the Wien2k bands are okay, but the Wannier bands are “compressed” by some factor on the energy scale, rather than shifted as by a wrong Fermi level. (It is hard to tell by eye if that is the whole difference, but at least they are much too narrow.) I do not know how that would happen. Did you apply any post-processing? Choose different units in Wannier90? Do your projections pass the other usual tests (spreads, H(R))? Otherwise, they might just be wrong. -- Elias Assmann Institute of Theoretical and Computational Physics TU Graz ⟨https://itp.tugraz.at/⟩ ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] x w2w error in WIEN2k.14
Dear Fang,
Glad you could solve your problem. For the record:
On 10/27/2015 12:46 PM, Yue-Wen Fang wrote:
> *After catting the file "subdir.werr", I found that "Error: Found
> keyword mp_grid more than once in input file**".
This is a known bug in ‘write_win’ as contained in Wien2k 14.2 (i.e.
known to me, apparently it has not turned up on the list before). If
you run ‘write_win’ repeatedly in a given directory, it will add an
‘mp_grid’ line each time. The bug will be fixed in the next
wien2wannier version; if you do not want to wait, you can use the
attached version of write_win_backend.f (just save to SRC_trig/; make
write_win_backend; cp write_win_backend ..). I *think* it should work
as a drop-in replacement without breaking anything.
--
Elias Assmann
Institute of Theoretical and Computational Physics
TU Graz ⟨https://itp.tugraz.at/⟩
!!! wien2wannier/SRC_trig/write_win_backend.f
!!!
!!!Prepares input case.win for Wannier90
!!!
!!! Copyright 2009-2012 Philipp Wissgott
!!! 2013-2015 Elias Assmann
!!!
!!! $Id: write_win_backend.f 424 2015-07-14 11:17:35Z assmann $
program write_win
use structmod, only: struct_t, struct_read
use inwfmod, only: inwf_t, inwf_read
use const, only: BUFSZ, DPk
use util, only: lowercase, newunit
use clio, only: fetcharg, argstr
use kpoints, only: get_kmesh_band, get_kmesh_klist
implicit none
!!!--- Configurable parameters ---
!! Initial size and size increment of keys, vals.
integer, parameter :: NKEY_FIRST=50, NKEY_INC=50
character(len=*), parameter :: &
fmt_kpoint_path = "(2(A3,3(1X,F9.5),2X))", &
fmt_brlat= '(3(1X,F11.6))', &
fmt_centers = '(I4, ":s")',&
fmt_atoms= '(I4, 3(1X,F13.8))', &
fmt_mp_grid = '("mp_grid : ", 3(I0, 1X))', &
fmt_mp_grid_bare = '( 3(I0, 1X))', &
fmt_kmesh= "(3F19.15)"
!!!--- Variables ---
integer :: num_bands, mp_grid(3)
integer :: c, i, j, k, nfill, iarg
real(DPk), allocatable :: kpath(:,:), kmesh(:,:)
character, allocatable :: knames(:)
integer, allocatable :: centers(:)
type(argstr) :: inwffile, structfile, klistfile, bandfile
character(len=BUFSZ) :: line, key, filler, comment
character(len=BUFSZ), allocatable :: keys(:), vals(:)
logical, allocatable :: keys_done(:)
integer :: nkeys
logical :: atoms_done=.false., uc_done=.false., proj_done=.false.
logical :: kmesh_done=.false., kpath_done=.false.
logical :: bandsplot_done=.false., guiding_done=.false., mpgrid_done=.false.
logical :: write_kpath, bands_plot, guiding_centres
type(struct_t) :: stru
type(inwf_t) :: inwf
!!!--- Code---
call fetcharg(1, inwffile, "failed to get `inwf' argument")
call fetcharg(2, structfile, "failed to get `struct' argument")
call fetcharg(3, klistfile, "failed to get `klist' argument")
call fetcharg(4, bandfile, "failed to get `klist_band' argument")
!!! Read âinwfâ file for num_bands, Nproj
call inwf_read(inwffile, inwf)
num_bands = inwf%bmax - inwf%bmin + 1
!!! Read parameters from command line
call allocate_keyval(NKEY_FIRST)
!! num_wann, num_bands, and mp_grid must match with âinwfâ and
!! âklistâ
keys(1)= 'num_bands'
write(vals(1), '(I0)') num_bands
! rationale for setting num_wann: num_wann=0 is not very useful, and
! this matches the behavior of w2w
keys(2)= 'num_wann'
write(vals(2), '(I0)') merge(inwf%Nproj, num_bands, inwf%Nproj>0)
! the following will be filled later
keys(3) = 'mp_grid'
vals(3) = ''
nkeys = 3
optarg: do iarg = 5, command_argument_count(), 2
nkeys = nkeys+1
if (nkeys > size(keys)) call realloc_keyval(NKEY_INC)
call fetcharg(iarg, keys(nkeys))
i = findkey(keys(nkeys))
if (i==nkeys) then
i = nkeys
else
nkeys = nkeys-1
end if
call fetcharg(iarg+1, vals(i))
end do optarg
!!! Find centers of projections for âguiding centresâ; disable
!!! âguiding centresâ if a projection is not uniquely centered, or if
!!! we have no projections
allocate(centers(inwf%Nproj))
guiding_centres = inwf%Nproj>0
do i = 1, inwf%Nproj
ylm: do j = 1, inwf%projections(i)%NY
c = inwf%projections(i)%iat(j)
if (j==1) then
centers(i) = c
elseif (c /= centers(i)) then
guiding_centres = .false.
end if
end do ylm
end do
! user input always overrides
i = findkey('guiding_centres')
if (i /= 0) read(vals(i), *) guiding_centres
!!! Read âstructâ
call struct_read(structfile%s, stru
Re: [Wien] x w2w in wien2wannier
On 10/27/2015 04:29 PM, Yue-Wen Fang wrote: > I found a lecture note written by you where an example of GaAs was > presented. Those are actually Oleg Rubel's notes from a Wien2k workshop. > Final State > WF centre and spread1 ( 0.00, 0.00, 0.00 ) > 1.92014359 > WF centre and spread2 ( 0.00, 0.00, 0.00 ) > 5.87323243 > WF centre and spread3 ( 0.00, 0.00, 0.00 ) > 5.87323243 > WF centre and spread4 ( 0.00, 0.00, 0.00 ) > 5.87323205 > * WF centre and spread5 ( -1.413301, 1.413301, -1.413301 ) > 1.62562519* > * WF centre and spread6 ( -1.413299, 1.413300, -1.413300 ) > 3.82132703* > * WF centre and spread7 ( -1.413300, 1.413299, -1.413300 ) > 3.82132703* > * WF centre and spread8 ( -1.413300, 1.413300, -1.413299 ) > 3.82132668* > > In your lecture notes, it shows that WF’s 1-4 are all positioned at the > origin (atom 1), WF’s 5-8 are centred at the 2nd atom. For me, WF's 5-8 > are out of the primitive cell of GaAs model. Is it reasonable? What > physic is indicated by the change of WF centre? This is probably okay due to periodic repetition of the unit cell. Wannier90 can be a bit unpredictable in that regard. -- Elias Assmann Institute of Theoretical and Computational Physics TU Graz ⟨https://itp.tugraz.at/⟩ signature.asc Description: OpenPGP digital signature ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] x w2w error in WIEN2k.14
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/29/2015 05:46 AM, Yue-Wen Fang wrote: > My question is how to find the band index in the interested energy > windows in a faster way*?* Did you try `findbands´ (which is also called by `init_w2w´)? That would be the ``standard´´ way in wien2wannier. > I also wander what rules WIEN2k code depends on to print the > information of band indices in specific energy windows in case.scf* > files? I do not know about that. Elias -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJWMbymAAoJEE/4gtQZfOqP3vgQAMIq6kQ9D8dLP7x9BDHXM6HU vIZ93ATKD5kwKfjTnwE42YRTTqDWvyldJykLu7jl0ftE82cgRzim1e7Cgdy89E/B +wKGDXXrE6Mo3SpSiD6ws91VhGvgiZMf+dk1peXKX5mKRDFImytDjOLD9QOeh3mY zW8ROGjIVcRTU3DjlJtaYe8RRqBxzH7mW1BiKXWP3DJqrGk/CDwIw+AT40YMAEbh b7L1TzoxHMXyZMs0AXbg5ytivAEIadgeGOsKSFaB1LO6NXrekPzmEWwfuQtuVk+C KG8j3qur3TfuUFnHgaA7tE9G2t3KMZPePRtEsQOPXIgxyN85a9ccqQ52moC3sBZs j5n+98P5Zi2eH45pE/ouRKqbE9frMXPkfRt+QQc5ngpvc+W+x/F23KeZuydTkv01 rJ41SWE5dSwA+NdkNYxNH/mvPVJxZKVuL/93zH4EA/i9BJ818U4sY9GHBkQMiSg1 epqAiYacUKeUmGntsu+VxI8363Ob6Ev2V9Pem2JSXudcBDAVr365a6TOc3oo/WiK 7AFbyF5Lbt5fL7dWOeEb4CMWz44FIYZzx7D/7KhlMF+Sk+Si5fjw5sCP90TbChXZ GUMlUggdQ48za0GeU+aNk6S1dx1UcHqf2ZPG0rvFNJRa3/BupHjRK6/09A0YuG2a pqICj155KAN9DqI/tW5W =g+OY -END PGP SIGNATURE- 0x197CEA8F.asc Description: application/pgp-keys ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] x w2w error in WIEN2k.14
On 10/29/2015 10:25 AM, Yue-Wen Fang wrote: > I am encountering another question in the case of 4-atom CoO. To say in > detail, if I input too many projections (eg. 7 projections) in the step > of "init_w2w", the program would crash and say that "write_inwf: too > many projections, 7 > 6". How can I add more bands to projections? “Too many projections” means nproj > nbands; this is not possible. To have nproj < nbands (disentanglement), simply select more bands in the first step of ‘write_inwf’. -- Elias Assmann Institute of Theoretical and Computational Physics TU Graz ⟨https://itp.tugraz.at/⟩ signature.asc Description: OpenPGP digital signature ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] passing env variables to lapw1 and 2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/10/2015 03:49 PM, Luis Ogando wrote:
> What about to include them in the job submission script ?
The trouble with this is when processes on other nodes are started
with ssh. Then, the environment is not passed on (and the OP says the
option to do so is disabled on his cluster).
FWIW, I always put my settings in ~/.bashrc, but the suggestion with
‘parallel_options’ is certainly cleaner. Of course, if you need to
set a variable on a per-job basis for many jobs, it is still troublesome.
If you unset ‘mpi_remote’ during configuration, passing variables
through MPI should work for lapw{1,2} (as long as you are using MPI,
of course). But even so, some commands (the ones that do not have an
MPI version, I guess) are still run through ssh.
Elias
> 2015-11-10 12:32 GMT-02:00 Laurence Marks
> >:
>
> A partial solution is to include them in
> $WIENROOT/parallel_options, as all the parallel routines source
> this file. You may be able to tweak this for what you want, but
> since I don't know exactly what you want to set I am not sure.
>
> N.B., if you are using openmpi then you have to enable transfer
> for variables in the mpi call command, and perhaps for other
> flavors as well.
>
> On Tue, Nov 10, 2015 at 8:25 AM, Pavel Ondracka
> > wrote:
>
> Dear Wien2k mailing list,
>
> I'm having some troubles passing environmental variables (eg.
> OMP_NUM_THREADS or similar) to lapw1 and lapw2. This works in
> serial mode where the lapw* programs are called directly, however
> in parallel mode they are run through remote shell and all
> environmental info is lost. I can declare them in my .bashrc and
> then it works (since the .bashrc is reloaded when remote shell is
> spawned) however i would like to specify them per task. One
> solution I had in mind was to go through AcceptEnv in sshd however
> this is considered insecure according to cluster admins an is
> disabled. Another option is to modify the wien scripts to include
> the required variables when calling the remote shell, however at
> the moment I'm wondering if there is more universal and elegant
> solution? Any ideas?
>
> Best regards Pavel Ondračka
> ___ Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
>
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the
> MAILING-LIST at:
> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
>
>
>
>
>
> -- Professor Laurence Marks Department of Materials Science and
> Engineering Northwestern University www.numis.northwestern.edu
> Corrosion in 4D:
> MURI4D.numis.northwestern.edu
> Co-Editor, Acta Cryst A
> "Research is to see what everybody else has seen, and to think
> what nobody else has thought" Albert Szent-Gyorgi
>
> ___ Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
>
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the
> MAILING-LIST at:
> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
>
>
>
>
>
> ___ Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the
> MAILING-LIST at:
> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBAgAGBQJWQivyAAoJEE/4gtQZfOqP8wcP/RQD5S+Nmceioc/9a5rxzAJG
woNNt7JWq7FZUnuIZFAu3TWKzcrMn7b4JEGjG48hjN4dGIM5RbNWPkXE/wGrNwep
s5dz1vnoqwPAsNdo1u/vk+AiyMTlbk7jqq9QUH3NTSphyp01GA5fazUPHqZWj7fY
HOHgb6juFJs8B5DreyQkW49QYXIfR1/GvtmOKAHR6DLLRjaU5H20LrSrOuqw5c25
XfD97n1hM0Md06W/lRSf98/22SnBtJwdZOmWudRPUZuStPO+dILCn95EZ/k0cUfa
PT0CIo1jpfo7hcxgW4HgRsmkxenxu7S29kDEIGr+CrQhAQ1wJChnuyWCgVtWOSu/
80sYbYDi7LEtHWoYWTC4CN6PsVbFxQQxT5kKvQXpBvt7P32waRI5dfzLzftX0DHU
jQZ/gkwpwmEddrbK4MuqDQRELltyEjIc/MG3mUQxYvYfmhNifMeohfMyov73sisj
DD4uJYGexaTweE/i8XZsHru6k4Z9wfBtTn4tdN6cGOUOcWhO44EKDPiHd9R4QoEP
1vcqAWgEpzOBY99zRu1OMwMmI469r7k5xCiZE5Hr1+0232rCm0PXuqCKJ0yWrc12
l1dHKQaW/S0Hxp18gIh90U158ggms/9FTjS5XsWmmogkzEvhY/9JWI9AuqYbQQIi
WFwPahxA2e63w1lL6g8h
=+JbL
-END PGP SIGNATURE-
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] segfault in mixer
On 11/11/2015 03:40 PM, Laurence Marks wrote: > There is some code inside mixer.F which reduces the number of PW's to > only those which are non-zero. With your clmval this is zero, so the > array kzz in setn probably has a size of (3,0) which is zero. A zero > size array will lead to a SIGSEGV, I suspect that ifort has decided that > line 27 is where it is going to prefetch the first values of kzz (i.e. > kzz(1,2) at line 30). > > Something went wrong earlier either (or both) in lapw1 & lapw2. I think you are right, and I think I localized the problem. EMIN in case.in2 was set too large (0.53 to be precise). Thus in case.output2 the band energies were reasonable, but the occupations were all zero. I have to wait for my batch job to start, but this looks promising. The EMIN was probably a leftover from a charge distribution calculation. Thanks for the help! Elias -- Elias Assmann Institute of Theoretical and Computational Physics TU Graz ⟨https://itp.tugraz.at/⟩ signature.asc Description: OpenPGP digital signature ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] segfault in mixer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/11/2015 04:04 PM, Zhu, Jianxin wrote: > I am curios. How come the value emin becomes so big? It is > automatically set, no. I think I set it when I was calculating a charge density (to get only the “valence” density). When I picked the calculation up again, I forgot to change it back. Elias > The EMIN was probably a leftover from a charge distribution > calculation. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJWQ1s6AAoJEE/4gtQZfOqPKXUQAKF8yBlnXybrBcqOFkO5swxU YoVvRaSHXFjvqoKVvdRAQyX6XyCQq+croO0TeMllMms2jGQ75Orwt1hPj0mY5fgS pJ/8TnXDqWM7kI9fCbb/ImlXnVNazzLN4NfHKXXAK9Zh5SF/bg2JY1sWb1I3NQVD ifvTCr8wkSkPx4w4OgHAB11SbXYQUvx3l4U2KQ42DNVRUvNpI1+SQeLOg8iTmeuJ OGeH2XDHerfEtRL4inY67hK7y/MK8QXvo9mGRtFoxOg9CvLXkPt4kBY+E7yDRcLW tYF2n2BjhHd12vtaSwy+ZEppACbEspUMrkoM5lKRcu2V/fUtYYfXNrnpuqAd4Byj RGnfDSSZK+BqfvineuhZx1VxV7lCw9A4WFClV0u5UNkmqFHDpEA2uM45WAPyi9Fo KIamOaVKDtrOmKU/FhnbRZHQ3JbOWUVphP4QdHyxBkC/a+n95lb5iqKHP21YUtbp v4q4O5ZUQW4DBNJLeuzGwNMbnyWYap1E1oFnrdG5Mqvqtmk6J+nin1BXA00qmmty qtaXpuOrpk111OAKNYoWwfApatomD90f/gZ9tC901AdmUbbpjpjiVZYGkpQxdIPD jz4WoRhYd95y0/r/s/Xy0Vi7yaAFxonAeEgN98Ybea181PXshVAWgU2O8BEpG35u 0xTwhiZEaRzAEnXV2xKd =ZsIi -END PGP SIGNATURE- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Slurm
On 11/11/2015 03:07 PM, Laurence Marks wrote: > And, at least in an interactive job, none of these work... > > Sigh. The man page of srun is also inconsistent with the actual srun > used Not sure if it will be better for your purposes, but what I use is scontrol show hostnames $SLURM_NODELIST -- Elias Assmann Institute of Theoretical and Computational Physics TU Graz ⟨https://itp.tugraz.at/⟩ signature.asc Description: OpenPGP digital signature ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] segfault in mixer
On 11/11/2015 02:53 PM, Peter Blaha wrote:
> Anything in case.outputm ?
No warnings or errors. Apart from the size information I quoted, the
only “suspicious” thing is the first line
filename of case.inc: case.incup
where case.incup is empty. But I checked other calculations and
case.incup seems to be empty always.
> setn has not much to do with the actual clmsum/val file input, except
> when the number of PW is zero (check out clmval and clmsum and
> clmsum_old files, if the K-lists are ok.), as this fft array gets
> allocated with nkknew1
The clmval files are zero (the whole files), but there are definitely
plane waves:
$ grep -e PW *.clmvalup -A10
594657 NUMBER OF PW
000 0.E+00 0.E+00
00 -1 0.E+00 0.E+00
001 0.E+00 0.E+00
00 -2 0.E+00 0.E+00
002 0.E+00 0.E+00
00 -3 0.E+00 0.E+00
003 0.E+00 0.E+00
00 -4 0.E+00 0.E+00
004 0.E+00 0.E+00
00 -5 0.E+00 0.E+00
$ grep -e PW *.clmsum -A10
594657 NUMBER OF PW Change
Residue
000 5.630359813726E-02 0.E+00
00 -1-1.150778984163E-02 8.051431134897E-03
001-1.150778984163E-02-8.051431134897E-03
00 -2-9.470078634937E-04 1.160395119838E-02
002-9.470078634937E-04-1.160395119838E-02
00 -3 3.822712367509E-03 5.400713534390E-03
003 3.822712367509E-03-5.400713534390E-03
00 -4 2.813831811510E-03 4.780854323303E-04
004 2.813831811510E-03-4.780854323303E-04
00 -5-1.336690365246E-03 4.849945762786E-04
> Otherwise more with the struct file.
>
> Is this still ok ? Can you run x nnwith this struct file ?
‘x nn’ is fine, in fact, the whole SCF cycle is fine up to mixer.
I checked all files in the directory for NaN's, there are none.
Elias
--
Elias Assmann
Institute of Theoretical and Computational Physics
TU Graz ⟨https://itp.tugraz.at/⟩
signature.asc
Description: OpenPGP digital signature
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] segfault in mixer
Hi List, In a fairly large calculation (200 atoms) I am running I get a segfault in mixer: $ x mixer forrtl: severe (174): SIGSEGV, segmentation fault occurred Image RoutineLineSource mixer Unknown Unknown Unknown mixer Unknown Unknown Unknown mixer Unknown Unknown Unknown mixer Unknown Unknown Unknown mixer Unknown Unknown Unknown libpthread.so.0 Unknown Unknown Unknown mixer setn_ 27 setn.f mixer MAIN__ 1232 mixer.F mixer Unknown Unknown Unknown libc.so.6 Unknown Unknown Unknown mixer Unknown Unknown Unknown Line 27 in setn.f is just FFT(1)=U0 the ‘FFT’ array corresponds to ‘cfft’ in mixer.F, and indeed $ tail STO6LVO2_ovac.outputm … Allocating CLM-arrays 678 MB Allocating nwav-arrays 57 MB Allocating cfft-array0 MB Any idea where this might come from? I strongly suspect some error in the input because another, similar, calculation is running without this problem; but I have no idea what I might have changed to cause the error. Here is my case.inm: MSR1 0.0 YES (BROYD/PRATT, extra charge (+1 for additional e), norm) 0.20mixing FACTOR for BROYD/PRATT scheme 1.00 1.00 PW and CLM-scaling factors 8 idum, HISTORY The error keeps happening even after I removed case.broyd*. Elias -- Elias Assmann Institute of Theoretical and Computational Physics TU Graz ⟨https://itp.tugraz.at/⟩ signature.asc Description: OpenPGP digital signature ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] lapw0_mpi compilation problem
On 11/16/2015 05:07 PM, Osama Yassin wrote: > /usr/lib64/libfftw3_mpi.so: undefined reference to `ompi_mpi_op_lor' It looks like your libfftw was compiled with Open MPI, … > current:RP_LIBS:-lmkl_scalapack_lp64 -lmkl_blacs_lp64 > -lmkl_blacs_intelmpi_lp64 $(R_LIBS) … but you are trying to compile Wien2k with Intel MPI. I think they should both be the same, i.e., you should compile / get a version of FFTW for Intel MPI or use Open MPI also for Wien2k. HTH, Elias -- Elias Assmann Institute of Theoretical and Computational Physics TU Graz ⟨https://itp.tugraz.at/⟩ signature.asc Description: OpenPGP digital signature ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] prima.py v0.3.0 — Colorful band structures with Wien2k
Dear Wien2k users, This is to announce version 0.3.0 of `prima.py´ (http://eassmann.github.io/prima.py/), a tool to create color-coded band structure plots from Wien2k output built on top of Maurits Haverkort's SpaghettiPrimavera.f90. New features include: * options to combine spins in one plot: `--mix-spins´ (add characters to draw a single set of lines) and `--join-spins´ (separate lines for each spin in one plot) * support for specifying options in a file (`--config-file´) * make atoms and orbitals case insensitive * support for named colors and HTML-style hex notation For some example plots see (https://github.com/eassmann/prima.py/wiki/Examples). With this release, `prima.py´ has moved to GitHub. You can clone the repository or contribute at (https://github.com/eassmann/prima.py). Direct link to download v0.3.0: (https://github.com/eassmann/prima.py/tarball/v0.3.0) Happy plotting! -- Elias Assmann Institute of Theoretical and Computational Physics TU Graz <https://itp.tugraz.at/> ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] x w2w error in WIEN2k.14
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/30/2015 03:40 AM, Yue-Wen Fang wrote: > Step 1. write_inwplot > > Step 2. x wplot -wf 1 -up > > Step 3. x wplot -wf 1 -dn > > According to the User guide, these three commands should create > case*.psink and case*.psiarg " files, but I found there was no > data within these files. Could you show me how to export WF for > spin-polarized cases? Do you mean the files existed but were empty? Then there must have been some error, and you need to include error messages. Elias -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJWMzGzAAoJEE/4gtQZfOqPenAP/iQbqOv1E1bVA5EZqVQyz6zn IzQKts6LmiBefA8BgUqN0PrIxPptC0WdrFy+YSUu/Jua0Q9aFSKwJj0ZfFvhUpNz YT7Wjf3TcLShhQhhpAAZOZLMaLpLaTJQ0MY126r4OCOI+LABiGKL7gN76X7fuYi0 i5Dk8EKFUfylv9kNjnmRHWaLR3jM+Lv715A0lVIgGAPFTtiKaNkPRH870ni+ihse fQ67j2UFFY5c5IZ/uo0l8fTZ/ce6vHtPJGxh9Mwpw++0d3Jfi9/XmE9zTZwNgrEk sL7YbnSES3LNbNLLxTwjhmElMPo08XeopuXQE3K+DCcG9UBDutBSz+I/R2xKMD/u lo86KwpUHzXbygKaYFGKjVEuBpEsoDD0VYFddz6l8Wk+npi0zJ714EZslmN/n1MH uEiR4s9nLXSBlg2RyQHiehTAUZULVP3qxRdJjR4/XCKolzJ13I8pUqKLTQXaSD20 GNGweLtIZ+uTfASbSnV6mZKBootm56zhavmjg3XfHheQ9nLxes4/1kw1WLqS0+rc V6ewnHW9ogGkqRGwXgNj8ACJAjbIZIT748Y5CBogkpI62JS+1GDv8SjZ5Av4564m 1t+2Ta4EWRt2TgBMubMHhgxplZfqhg5owABO6i3zI1tO1unDbhsngc1sLza+HeVA tjKnOPe/sCWiCrDyDrKV =E5uQ -END PGP SIGNATURE- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] RMTs changing on their own?
Hi List, My MSR1a (‘-min’) calculation was running along happily until I reduced the RMTs (using ‘clminter’). After that it continued to run for several iterations, but now has crashed (“SELECT” error in lapw1). I noticed that the RMTs in the current struct file are back to their original values, before the reduction. Is it possible that this change happened automatically? I happened to check on the calculation in the last iteration before it crashed, and saw that the ‘case.struct’ had the original, larger, RMTs while ‘case.struct_old’ still had the reduced ones. Now, after the crash, both files have the original radii. This is corroborated (I think) by the :RKM tag in ‘case.scf’, which changes in the last iteration, apparently back to the value it had before the RMT reduction: ... :RKM : MATRIX SIZE 8870LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: :RKM : MATRIX SIZE 8870LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: ... :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: :RKM : MATRIX SIZE 10382LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: :RKM : MATRIX SIZE 8870LOs: 616 RKM= 6.50 WEIGHT= 2.00 PGR: By the way, I had a separate calculation running in a subdirectory of this one, in case there could be any interference from that. Also, this is still the same calculation I asked about earlier, and I still get the *WARNING*s from ‘mixer’ without a more explicit message. Elias -- Elias Assmann Institute of Theoretical and Computational Physics TU Graz ⟨https://itp.tugraz.at/⟩ signature.asc Description: OpenPGP digital signature ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] x w2w error in WIEN2k.14
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/30/2015 12:04 PM, Yue-Wen Fang wrote: > + x wplot -wf 2 -up -p written on 30Oct2015 at 01:34:44 > NON-ORTHOGONAL AXES Well, that tells you what happened: ‘wplot’ thinks the axes you specified are not orthogonal, but you asked it to check the ORTHOgonality of the axes. Please double-check your ‘inwplot’ file. Elias -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJWM1XvAAoJEE/4gtQZfOqPrEwP+wQwu3LnKSWhtUxwluxcmyXy 2dF7N+GLJ5Q8jVqIWLX+Ni2CFq0l2KkIlSJPCMe0cV2fie+5JxL7IrKFMz1SeEXs 7BXKRJgB/vqNC4TbJbre6bLXMCpAjz5uC9Klv9jElU7hVt1tefpehCoAN7vXQ2ER oVcsNqtKjuTcaVsQ5g8X9pGuwj+17J4w8AlKR4xJpNJS57ziEpY1ldDhwl4z+pwV iU3XNob2pv6+tjm1NmU7E4dZqNQBs85NnM7EacXXHsiFIXEfIVHea5eGgFIMGDUd YRSNBPQeqZmjY2Hat46LDFd3xvzlp4l+enW5BH1UyOkDBuz9M9mSLyInwX+9QTK+ kf0Qbyf/DUr65KXKC3NIm3bCC+uyHjUn6ygVlGtTY5k8Yly8TNGW4RD5wyEIoIgz rnrs7QUE5it2rySaAtHekXVCq0V5JALw5f36cHAiGFzX5CkSm9cu08+Y4KQylAiQ JXa0C8nVikBS/nZ29BFARoSJriNLhsgXqyT+7HV4WZggGNRPOJ1gEVMZxiojdR29 UFIpLRfxoqw3d6DNDP8DgU5+86vyM2tFpSWaiugykUsV1EtIQrtMgN9uoRRDq2O1 qp6ewPEbFgY5P07QWxz7R3n89/qv1Abk/iKr38wm2ctwO1uVsQU1HocxdmlC0YyY Evj6hnaul8ou9J3rb9jZ =8DtZ -END PGP SIGNATURE- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
[Wien] runsp -it: lapw1 called thrice?
Hi List, I started a calculation with ‘runsp … -it -noHinv -min’, and noticed that lapw1 was being called three times per cycle: once with ‘-up -it’, then ‘-up’, ‘-dn’ without ‘it’ (after the first two, when :MIX switched from PRATT to MSE1a). Is that normal? Note that the calculation seemed to be running normally; there was a *WARNING** from scfm, but I could not find any details about that. Elias From the scf: :ENE : *WARNING** TOTAL ENERGY IN Ry = -222788.07263654 :ENE : *WARNING** TOTAL ENERGY IN Ry = -222788.08807566 :ENE : *WARNING** TOTAL ENERGY IN Ry = -222788.07629953 :ENE : *WARNING** TOTAL ENERGY IN Ry = -222788.10757386 :DIS : ( 0.0516339 for atom5 spin 1) 0.0115736 :DIS : ( 0.2895640 for atom1 spin 1) 0.0590266 :DIS : ( 0.1109556 for atom1 spin 1) 0.0266441 :DIS : ( 0.4511020 for atom2 spin 2) 0.0847330 Here is the :log file (first column is the runtime, I removed the date for brevity): > (runsp) options: -p -ec .0001 -cc .0001 -fc 0.5 -i 1000 -it -noHinv -orb -min 00:00:28 > (x) lapw0 -p 00:00:00 > (x) orb -up -p 00:00:00 > (x) orb -dn -p 00:02:01 > (x) lapw1 -it -up -p -orb -noHinv -c 00:01:59 > (x) lapw1 -it -dn -p -orb -noHinv -c 00:00:44 > (x) lapw2 -up -p -c -orb 00:00:45 > (x) sumpara -up -d 00:00:38 > (x) lapw2 -dn -p -c -orb 00:00:44 > (x) sumpara -dn -d 00:00:41 > (x) lapwdm -up -p -c 00:00:00 > (x) sumpara -up -d 00:00:42 > (x) lapwdm -dn -p -c 00:00:01 > (x) sumpara -dn -d 00:00:01 > (x) lcore -up 00:00:02 > (x) lcore -dn 00:00:11 > (x) mixer -orb 00:00:28 > (x) lapw0 -p 00:00:00 > (x) orb -up -p 00:00:25 > (x) orb -dn -p 00:01:06 > (x) lapw1 -it -up -p -orb -noHinv -c 00:01:07 > (x) lapw1 -it -dn -p -orb -noHinv -c 00:00:44 > (x) lapw2 -up -p -c -orb 00:00:45 > (x) sumpara -up -d 00:00:45 > (x) lapw2 -dn -p -c -orb 00:00:45 > (x) sumpara -dn -d 00:00:43 > (x) lapwdm -up -p -c 00:00:00 > (x) sumpara -up -d 00:00:41 > (x) lapwdm -dn -p -c 00:00:00 > (x) sumpara -dn -d 00:00:01 > (x) lcore -up 00:00:03 > (x) lcore -dn 00:00:12 > (x) mixer -orb 00:00:28 > (x) lapw0 -p 00:00:00 > (x) orb -up -p 00:00:28 > (x) orb -dn -p 00:01:08 > (x) lapw1 -it -up -p -orb -noHinv -c 00:01:59 > (x) lapw1 -up -p -orb -c 00:02:01 > (x) lapw1 -dn -p -orb -c 00:00:39 > (x) lapw2 -up -p -c -orb 00:00:44 > (x) sumpara -up -d 00:00:39 > (x) lapw2 -dn -p -c -orb 00:00:44 > (x) sumpara -dn -d 00:00:40 > (x) lapwdm -up -p -c 00:00:01 > (x) sumpara -up -d 00:00:40 > (x) lapwdm -dn -p -c 00:00:01 > (x) sumpara -dn -d 00:00:01 > (x) lcore -up 00:00:02 > (x) lcore -dn 00:00:14 > (x) mixer -orb 00:00:27 > (x) lapw0 -p 00:00:00 > (x) orb -up -p 00:00:23 > (x) orb -dn -p 00:01:07 > (x) lapw1 -it -up -p -orb -noHinv -c 00:02:01 > (x) lapw1 -up -p -orb -c 00:02:01 > (x) lapw1 -dn -p -orb -c 00:00:35 > (x) lapw2 -up -p -c -orb 00:00:45 > (x) sumpara -up -d 00:00:33 > (x) lapw2 -dn -p -c -orb 00:00:45 > (x) sumpara -dn -d 00:00:40 > (x) lapwdm -up -p -c 00:00:01 > (x) sumpara -up -d 00:00:40 > (x) lapwdm -dn -p -c 00:00:01 > (x) sumpara -dn -d 00:00:01 > (x) lcore -up 00:00:02 > (x) lcore -dn > (x) mixer -orb -- Elias Assmann Institute of Theoretical and Computational Physics TU Graz ⟨https://itp.tugraz.at/⟩ ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] runsp -it: lapw1 called thrice?
On 10/30/2015 01:03 PM, Laurence Marks wrote:
> This is normal. You will see that the second call has no "-it". The
> shell script detects if there is a problem with the iterative mode and
> switches to non-iterative diagonalization.
Thank you for the clarification. I had never noticed the behavior
before. I guess this also explains why I sometimes see ‘-it -up; -up;
-dn’, and sometimes ‘-it -up; -it -dn; -dn’.
Elias
--
Elias Assmann
Institute of Theoretical and Computational Physics
TU Graz ⟨https://itp.tugraz.at/⟩
signature.asc
Description: OpenPGP digital signature
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] RMTs changing on their own?
On 11/03/2015 02:47 PM, Laurence Marks wrote: > a) :FCHECK (bottom of case.scf) was large. This is the sum of all > the forces, and should be small. Particularly for cells without > inversion one can get bad, highly asymmetric densities in which case > MSR1a can have problems. True, I had not notice this before. :FCHECK was already quite large (hundreds for x and y, even >1000 for z) before ‘clminter’ and “jumped” to even larger values afterwards. > b) The greed is small. Too small a value can be as bad as too large. > I have struggled with this for years and failed to find a strong > ansatz for this, although I believe the next release of the mixer > will be better. AFAIK, the greed in MSR1(a) is set internally by the mixer (the corresponding value in case.inm being ignored), so there is nothing I can do directly to influence this, is there? > I am not sure what the calculation is, perhaps an oxide surface > where you have made a guess at the initial structure and want to > minimize to something more reasonable. Quite a good guess, it is an oxide heterostructure including a slab of vacuum, but the initial structure is derived (cut out) from a converged one from an older calculation, so I would have expected only relatively minor adjustments. As such, the large forces also come as something of a surprise. > I strongly suggest trying to use cells with inversion, they behave > much, much better. In this case, inversion symmetry could only be achieved by adding an additional “film” on the back side of the “substrate”. > I also strongly suggest that you look at the Bond Valence Sums (BVS) > and tweak the initial positions until they are reasonable. (x nn ; > grep Bond *tnn). If, for instance, you have highly underbonded O > (e.g. 0.8) it can take forever and the calculations can be unstable > -- convergence is faster the more physical are the atomic positions. I guess the expectation is that the BVS should be close to the “formal valence” of the ion, right? In this case, it seems okay: The first BVS value is between 1.4 and 2.2 for O, deviations for other species are rather smaller). > Good luck. Thanks, and thank you for your tips. Elias -- Elias Assmann Institute of Theoretical and Computational Physics TU Graz ⟨https://itp.tugraz.at/⟩ signature.asc Description: OpenPGP digital signature ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] berryPI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear Nilofar, Oleg, and Peter,
I cannot say for sure whether w2w will work with HF because I have
never tried it, and do not know too much about how an HF calculation
works in Wien2k. If, as Peter says
On 10/15/2015 09:30 PM, Peter Blaha wrote:
> I can confirm that case.vectorhf has the same structure than
> case.vertor.
it should probably work out. Nilofar, maybe you can give it a try and
report back here -- I would be interested to know, and if problems do
turn up, I will try to help.
> For testing one could simply copy case.vectorhf case.vector and
> try it out.
For w2w, I believe the ‘-hf’ switch should be enough.
> I don't know if there are any other input files requires for w2w or
> BerryPI (case.energy ? there is also a hf file), ...
Looking at the w2w.def file
5,'$file.inwf','old','formatted', 0
6,'$file.outputwf$updn', 'unknown','formatted', 0
7,'$file.amn$w90updn', 'unknown','formatted', 0
8,'$file.mmn$w90updn', 'unknown','formatted', 0
9,'${scratch}$file.vector$sc$hf$soupdn', 'unknown','unformatted',9000
10,'$file.nnkp','old','formatted', 0
12,'$file.eig$updn','unknown','formatted', 0
18,'$file.vsp$updn','old','formatted', 0
20,'$file.struct', 'old','formatted', 0
50,'$file.energy$soupdn', 'old','formatted', 0
51,'$file.fermi$updn' 'old','formatted', 0
only ‘vector’ and ‘vsp’ is needed in the “normal” case. What is there
in the ‘hf’ file?
> Am 15.10.2015 um 20:08 schrieb Oleg Rubel:
>> From BerryPI perspective, you can probably do the onsite hybrid
>> functional the same way as the orbital potential (LDA+U). The
>> flow of "runsp_lapw -eece" looks similar to "runsp_lapw -orb".
“Onsite hybrid”/EECE is quite a different beast than “full hybrid”,
and I believe it should pose no problems to w2w/BerryPI. Just run
lapw1 with the appropriate switches (‘-orb’?).
Elias
- --
Elias Assmann
Institute of Theoretical and Computational Physics
TU Graz <https://itp.tugraz.at/>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJWIJSLAAoJEE/4gtQZfOqPYX4P/i1n8L/Je0PWmG8wp+oONgz+
+8jzMctUPX471hy8b9LMplfwstQrt3ggr7zcV4fCAOWs3fnu0YiQ1pTWtivB5pfZ
rG6IkynKvo3nFrDMpSDQE4pDUqDvBFG4onwOaVgmlihRmCgQzvZEKzo0xCtwlOPx
0JFD4bkMByMuyH6uetaa4tiGkdNdW+Nf9yZ5WJcqmCdLVk1Ixcp3USGgRiCo53/q
LnEcetczXr7j8QYq1uLrmxl6uQ1uBuTD5WQFAi7lmUP/yI00Y22XOCfwSzmMhbh5
+4y5M0R3XlwxbuaAHlrqrGZ157ThQdL5FbEMHfEX7ZEDP9w2KqjhkjwzQyjugTHz
ky/Qm0+KLesy+CTxiJF/uC1ht6TFnYFLq97w8hGXs87ehVaZ15Pz+0VRwFRYOcLP
bLcaCmp1lJhdyPDAUt4vatez3t267TIkAvl6Rr9kbK5S+PQBp5W9Q5h9+QuH8Ayh
ISDgnvrp6U1WVrEnLTDrwENEYIpNjXbEjXWqTWDJ+w42gYySgx09buRJW7IMQPSq
TxkoyiyMnSm+lnLoiS4NfeLM4RTF97ngKbU4YHQLNSwZuyY0iWH9FZUzFKoJh30h
TPpDbjoFgIWUmfalPdKEx2fusr0Pb/2KbqDfWCBc2qdJ21WxpA3yTCY3pB9M04lV
rKYbLIVkdABO4qauBisH
=MYc+
-END PGP SIGNATURE-
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] berryPI
On 10/19/2015 10:47 AM, Peter Blaha wrote: > I'm not fully familiar with the w2wannier flow, but I can see from the > def file, that the $file.vector file already has a $hf option. Yes, I put that in “for completeness”, but it is so far completely untested. > However, then it should probably be also in the $file.energy$hf line Thanks for the pointer. Right now we have ‘$file.energy$soupdn’; what would be the “most correct” way? ‘$file.energy$sc$hf$soupdn’? > and I also see a required $file.fermi file (I don't know when it is > created), but that should also relate to a hf calculation. That is the Fermi energy, which ‘prepare_w2wdir’ takes from ‘$file.scf’ or, failing that, ‘$file.scf2$updn’. Elias -- Elias Assmann Institute of Theoretical and Computational Physics TU Graz ⟨https://itp.tugraz.at/⟩ ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] CHARGE DENSITY --> TOTAL CHARGE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/08/2015 07:34 PM, prasenjit roy wrote: > I want to obtain the total number of electron in the unit cell, by > summing over the total charge density within that unitcell and then > match that number to the "atomic numbers times the respective > multiplicity". Since WIen2K is full electron code, I expect these > two be equal. I have never tried that, but I would expect the number to depend quite sensitively on your mesh of r-points. At least, this is what I saw when I looked at normalization of Wannier functions on an r-grid. Since you want also the core electrons, you could actually expect even larger spikes. > The system I worked on is : Mn6Fe6Si2P4 (total electron 394 in > unitcell). When I summed up all the densities over the mesh (I > chose 74*74*80 points), I obtained ~257050. However, this I would say sounds more like some missing factor … Units? dV? Elias -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJWG3HAAAoJEE/4gtQZfOqPmxoP/2pSiQe7vm2b5q9eyjN9X5VN pQvq+RUE8F5pjgSK8W86YlRCFK34TIw3b8g7OvRW6noaeUGLqszWpFArfF0ToRE7 +kS9+YcVLzoogCSoan5demVARHdP5oyKcv08NOpQBwndPYgvCAlPm+nN+Wg9T/m+ b6znR2WzoXdLaMxK3uQW94fK+D/T2k4fDRSrd0rU5BU7FztzJ/qnbiywtZqnJbZ5 mXUJCQuC+E5Uw1XGEvWR8XIisW5n/ZY1d27PHRStSG3utFbZxfdhxYpHHSAWX0di SIO/DSfp1UGte3sfcjmtc41QFNBod1El6frLxNehmEhY4jMgsJRWST4qEblLdfk4 fSz0cSRplff4WAQkiNUnFK2wiHtB/ZceiXDM1dxZmo76ItkyBMu0oDUpwpw75r3f s+otHS2XPsMnd9knD0D7SXf5Ko3qNNR/Sj0hWBfpdPwHmDpg8k0clu23vGc6srWK ISJrtABNcSDBuJp9IhURLc7VpbUCfKJ0WFXSLLorTXM5eb2oNJT+MPm4EDxK9zyQ gaMcnV3nxoYYsNjgVwG4Du8XZO90T+Zc8AAdP7t1VW88QAMy85g9q1CH21AS3nnk HSna4W7R3vTd2XP2cTQ2UYIKBzyBQYj/9HbNV7F0e5FlzMfirgPj3j2HVvTJLVYm murT9xCL6Q8O0PH6SZHw =Gwas -END PGP SIGNATURE- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] berryPI code
On 09/08/2015 11:57 PM, nilofar hadaeghi wrote:
> I tried to implement this run this command :x w2w -up -so
> but I again faced the following error:
>
> forrtl: severe (174): SIGSEGV, segmentation fault occurred
> Image PCRoutineLine
> Source
> w2wc 0042E242 almgen_ 120 almgen.F
> w2wc 00423E21 l2mmn_ 72 l2mmn.f
> w2wc 004223C6 MAIN__226 main.f
> w2wc 004038CC Unknown Unknown Unknown
> libc.so.6 003B06621735 Unknown Unknown Unknown
> w2wc 004037A9 Unknown Unknown Unknown
That is quite an unspecific error, but at least you have line numbers.
Which exact version of the code are you using? Can you post the output of
grep Id: SRC_w2w/{almgen.F,l2mmn.f,main.f}
--
Elias Assmann
Wien2Wannier: maximally localized Wannier functions
from linearized augmented plane waves
<http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/>
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Serial installation of WIENNCM package: we need guru!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/11/2015 11:53 AM, Lyudmila Dobysheva wrote: > # Routines which can be compiled unmodified OBJS1 = module.o > errclr.o ... # Routines which may require preprocessing before > compiling PREOBJS = module.o OBJS = $(PREOBJS) $(OBJS1) A little experimentation: > head module.f90 try.f90 ==> module.f90 <== module module integer :: i end module module ==> try.f90 <== program test use module print*, i end program test > gfortran -c module.f90 try.f90 gfortran try.o module.o [success] > gfortran try.o module.o module.o [error] module.o:(.bss+0x0): multiple definition of `__module_MOD_i' module.o:(.bss+0x0): first defined here collect2: error: ld returned 1 exit status I do not know if that alone can replace a guru, but the double inclusion thing seems clear enough to me. Elias PS: Before you wonder, ifort does the same thing. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJV8qncAAoJEE/4gtQZfOqP2+AP/0RWPi2Nw6Zzks8NN/IUOtXM N6lixJDEsjYwaEeCzZHr9GFMIt6mLM6V4wmCJJT/f/aMBdU/2On8lwMuvnlcM5tR odRC5fdKvsw1dgE/VTEthVzKNWOxBMZnPlUJBLUSVJas8r5JXCsxJjU149Vz+Ztl Ao1eF4csx749/K+rSAbJ6dKF5mzKaqPCJGhW+fPFhMFN4WJJtRIWuzFEFU0wrYB2 Z3qg4o+49VE6Ym2TV3JxjiNXt62kZvO8ndRMf4GKabppVOILo1XuLIlg8uZejMNQ 8BSq7lCucdZoOblZ/7UcFGYdQhMTGV+3SH5WgoJ5qgVCL09ju6CndWxa/GoTIlZR UI0fzffVrAEbU9AiTX+cJqK8EufP6kXyWlcKxaXXIfGP6OH8oJdflQEkIrFIN0D6 pCMLGxksLsyVc5qY4EQdzRf4zJsZcSvPu+zAl1RHQWH5BuaA/kDFG67kdAQj1g6o tQAqZCSlKRY7dg3yPg+uplQJKUTI7HXS8gQtMJqlD40LyxNpbMOqIYyJXGCCNPQm aXfVzekXpjUzxDiDTxP+cL/UK+pYsft/pe4py9rAm9I9tKD2N9kC5JudEUDFWM+5 bnrMNjJrWY7C6GQgpzrKwyjcipnf5tWu173ElK430d7Lm5JNaYFGYLBEzI7CNz59 mvS53CJhvGC7E0rbPb1M =TMtm -END PGP SIGNATURE- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Serial installation of WIENNCM package: we need guru!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/11/2015 12:48 PM, Laurence Marks wrote: > I remember that gfortran & ifort are different on this. Ifort does > not care if XYZ.o is present twice in the list of files to link, > gfortran does. The Makefile needs editing -- I am a Makefile > anti-guru. Not for me: > ifort module.o module.o try.o module.o: In function `module._': module.f90:(.text+0x0): multiple definition of `module._' module.o:module.f90:(.text+0x0): first defined here > ifort -v ifort version 15.0.1 Elias -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJV8rZMAAoJEE/4gtQZfOqPUQEP/R7050fXFX7c/M+x7NbmONsr nkk0abfvG3VSn6vAntmgC1y3mO2GQ0/WvlKfd6RQsdb4PWcOp3OgloGmeQHDdB3i 2xYg0djRBEvFejiLLxIEy/8gtXuwjlbXxLlcr4Mq00BLiQ6BkeBhKBeqrwQFYYIU SzSANd3qW62ZmqzQDYxEdzdK/xmpIo7CcawDdBzJNx+daagaGSaOeDa1IK5ifop3 3XWxnrNwNzcw2laJuytI5dbbMrXD2sFSh/QOozYoTVDGcY1laq7nT94pnjOlQTkf 9feYQD0KxqNt/N9MKwhXIMkeEBAoDDwp2ncifNmuLHmCI81B4kTmTz/wKoBTpGhp mlKT4/8UqNMMeme3d64kpldNeVDG3Z3lgMnMbbcuoFwjzrFE3IsCIbHfECa31ODY GVCnfu36Qn4l6MhodAzTdrKZ5Jk1azFnCmP106xvs6FJvHrtVVcX6MmD9OV7mLBD DqLXywAbjKP0u3I6VDXGQvXu2hGlCMYYQD8LZafC8tP1ixy6Q2hkmHOuSu3BoGFr x6eA9OiLlz4nYmKqvj55ndlIRETCMu6lieHrvUEEwiD/AqB5HGcwxcZLQrrKdtq9 040c1i5M3kQlGWmqJIpZQ/8o0H64f4piaXCUJKmDasxr+3YrQdVbSKRqzI4YncHT yOMOnjicTYJNkoGtXmgv =incu -END PGP SIGNATURE- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] time difference among nodes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/28/2015 01:58 PM, Luis Ogando wrote: > The problem is solved ! The solution was one suggested by Lyudmila > Dobysheva : reboot the nodes. We will never know the origin of the > problem, but, honestly, I do not care ! Good to hear that! So, how did you get the admins to reboot them? > "There are more things in heaven and earth, Horatio, Than are > dreamt of in your philosophy." That is an apt quote for people working on clusters ;-). Elias -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJWCjTGAAoJEE/4gtQZfOqPhFAQAKZmda0t9FGgfAsk9UjymogK oN1WxHdenQVOSaOblpAFEn4c0ihTog7zePEXdTqNl03OcBUcdKtOPVqSVLBKlmlF f0VOBUeXjmOZKd6SAIuwNojflW0k9ysrJ2sLCo/dOGepT4L2Q8Um5DHpgh+mjehM XtGbn6uDUQlcjoLKgHG9GxBzr9qRDqc4chYnMAvwNGkm7qntt7Q1jol9yGZikB8e CONyaqYghNBr4x7BtGOaITJQ7yWw++l7t56oMSCNOXzee8Noy53cKPCVOvzh8lUF PlMRNFB9pTgdxs59dy5yF31R4LTJjMG7zm+gHjmWDMi7BnQZQGEWDc6MIzLIwTPj kN5dZm4R/cbVjYEzIlmsr9h67H/+9Otr36AvwfvvwycL/wy0RkC7jxqY0eC8i3fK v/FdmFbt6b2wxzalmjvg+sEILe18Uz0fCmhcCDRdZ2fgmOWC68WeH4I7d2/kCJTr Az2K8ZvZ5LxBCSH9MLoh/heZVSI3rowHu3aUNqfcbZ1pJLmT68RU9ZmPgfQnA4bK 4uny7MaDcyYN/IvMRWf8lUiuY3OsRHGZAmcIfagkqvV2ukWPRFQ2AmsaZpMxbYyg FsdKDJfYocUdp14KMT3wEhiGmUTE5BwtxAXq4NTq1sdJGESZIzhbEXYHbgnD7mbF QDT7WZ/DqG+KpcVTRmnz =JtdF -END PGP SIGNATURE- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] berryPI code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/09/2015 06:22 PM, nilofar hadaeghi wrote: > I really thank You. I will try to find these lines in the source > code of w2w but any further help would be desirable. BerryPI > Version 1.2 Python version: 2.7.3 Numpy version: 1.6.2 At least on the first level, this is a problem in w2w, so I do not think the BerryPI version is relevant, much less Python of numpy. Assuming you are using the latest Wien2k version (WIEN2k_14.2 (Release 15/10/2014)) and the wien2wannier version distributed with it, the ‘Id:’ lines I asked for (which give the precise version of the file) would be > grep Id: almgen.F main.f l2mmn.f almgen.F:!!! $Id: almgen.F 167 2014-02-03 09:43:33Z assmann $ main.f:!!! $Id: main.f 199 2014-04-11 16:18:29Z assmann $ l2mmn.f:!!! $Id: l2mmn.f 167 2014-02-03 09:43:33Z assmann $ Please tell me if that is correct. I looked at the differences between those versions and my most recent ones, but I did not find any differences that seem relevant to your error, which would mean that the error should still occur in the development version. Bottom line: if you are not using the Wien2k 14.2, please upgrade and try again. If you are, please send me the struct file and init parameters for which the error happens, so I can try to reproduce it. Elias -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJV8GKRAAoJEE/4gtQZfOqPjCYQAIBzi/MhBsCl0XjcTwH/TzR9 1ZdtEHapQue85JCwfaI5+gJYf5F3hPGSH4j8uTvIa5nABmmD3Fmq1UPIUpxbfAt3 PwKYZx2HAaaOy8GE2Kd6sbSUk/EfjzwDRgVnAvcclawAz8S70mc/jPKRIL+Zzyxs 0zWAjaCIXO/rJzzk+PUL2oKyDNUw301pMB6XurkcYtwjKNjKk6GXKhc2L1BUfwcW jQZugT8QtTITU8/Ol8kJT/Tari0OfxKV0wLzz+w2DaoV7rvNNZHywyhYUOqoM0sf s6PP621CA7wyC/b0c+yFJiJ2Q8hEZ6n+jXFG1/jEMAv7jkbGZipP2FEwYzOpCoUR 3T2ONxbqeJx/MlcTCPZeapGtFt82td0oxCzgllIliYUnaSeOoYHXhSfkGEoIPB2k iVTPRt/RYds4Dn1mo5Br/IgznrdM4/2J7ZLBqGvWpU9Gg7P7Us3nSwv+91hti3Dn 9gNOqs1KbUPttRFu0i1iApY5pMFUcCH6e25/D3+fj6Pk386Bc3so69iXXbUZ8N9p Fq+u1beVhM6+JhYgWmK/sBnaxSiqZbEcxVnROeRqOJTieGVlmjTCp0XkHNM3focp Ltjsh6kQAexl48BuJ9lUodqAAjtKkNGmVqrXFnwmwhTDslzmPxkbhA7/zmeTJNDm bnzF8D667POkRjeG5Rof =vH91 -END PGP SIGNATURE- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] berryPI code
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks everybody for chiming in :-).
On 09/09/2015 06:36 PM, Víctor Luaña Cabal wrote:
> grep -B 5 -A 5 Id: SRC_w2w/{almgen.F,l2mmn.f,main.f}
That is very useful in many cases (or just ‘-C 5’, FWIW), but in this
case, the one line is really all that is needed -- it identifies the
last svn revision the file was changed in. Essentially it would make
sure that Nilofar was using the version of 14.2, plus save me the
trouble of looking up that information myself.
> Notice that Elias command corresponds to a bash shell, probably.
And many others. Personally, I use (and highly recommend!) fish
⟨http://fishshell.com/⟩, it works there as well.
Elias
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBAgAGBQJV8GYoAAoJEE/4gtQZfOqPExsP/0phlFjTsSuFTazD7KgO5Yjd
UaeCK4DjuQ+NWzzD6srRvDFt9sVhrgmeazkyccjM3y4zkZpImCHHU2KbgsFtb2UU
ZbVsmOC1m/o+0/lRhyIqIi8R0Rw4crUJnDsfLcLqLExsYE4vi2amaN+xGkcqLEdd
9/TitsQAv4Kff8I8D4aTUks2OIP6+c/FwoGgaE36m0XeOeoDPyhlPo6nzRXRdOp/
Lfhdw7TSN/aTYsTK8cPbB6V45Sr9as8qh7etjT+GS6+eVP0ulY+G/65LoToYVKhz
BFu8Jek4q6KPcV/CsoV2xSDdpNCAR539PRD8iDRqtG2muKoGDmVqNBx6KnmuwUji
KMbah5B1GukgAZS0/ZCKs0yCW/dPKN806BCtbVg/FJwROg96LY7JDssCY5ay7haw
/D92VI6jzEolTZifcM4Dn57ttIiZWNqHqmmY6hF5syoFhCliEilNxH4bLhy79RkJ
z2pn414TfXILNaFqVV9GSsqJmYqWJ762rCueAfxgWuYs++SM3dLcSzVoDcFEIono
6zOs5xyJLwwtDT6l0doBv5XneSbNhLcQiNCDkRYk3/ZuTkOGVufwlIVfeN6ft1Vj
kNK9XKoNezhdfVUs7fPqVX0NTcmZvGVgM1J2MEH8kHb8K0gDjbKet17/rI0D2M1t
+gWQlJ7jIyf61s+Vesgf
=k0HR
-END PGP SIGNATURE-
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] time difference among nodes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luis, First of all, I wonder: To what extent is this problem reproducible? E.g., does your job always run on the same 4 nodes? Is it always the same node(s) that are slow? Does the problem also show up in other calculations (maybe just changing the number of k-points, or restarting the same case from scratch). Is it only lapw1 that is slow? Second, how did you make those ‘top’s? As for ‘lapw0’ and ‘lapw1’, I am guessing that this is just because the snapshots were taken at different times (notice that the CPU times of lapw0 on the two nodes are quite different, too). About the CPU usage on ‘n2’, I find this very suspicious. If it is as Peter said that the jobs are in the initialization and therefore not computing much, that may be fine; but I have to disagree with his assessment, because the memory usage of lapw1 on the two nodes is basically the same (if anything, the image sizes on ‘n2’ are slightly larger). Note also that it is *not* the case that other processes are using the CPU; the total usage is at 7.5 %. It would be good to clarify that by getting a ‘top’ such that we know that lapw1 had been running for a while. To this end, top has an ‘-n’ option which says how many frames to output, e.g. ‘top -bn 10’. I am also curious about the load averages. ‘n2’ has larger “mid-term” and “long-term” load averages than the others, and its “short-term” average is just as large. I am not sure what that means. On 09/23/2015 02:21 PM, Luis Ogando wrote: > I can not access the nodes. SSH among them is forbidden ! We have > to ask the administrators for anything !! It is the hell !! Of > course, only the PBS jobs can "travel" among the nodes. I do not know about PBS Pro, but Torque and SGE have an option (I think ‘-I’ in either case) to submit an interactive job where you get a login on a node. Of course that is only a realistic option when the queuing time is not too long. Otherwise, any information that a more sophisticated tool can give you will also be available from the command line (just more painful to extract!) via ‘top’, ‘ps’, ‘/proc’, etc. You can also put these things in a jobs script (which you apparently already did with ‘top’). Good luck, Elias -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJWA7M8AAoJEE/4gtQZfOqPu5AQAJERPcJ8VBgVJdiVmDPSmfC0 9lJ+NUXWbNKxP9oXVChniwB/p0TUn588xVtVGIiXuviIW6jWM/reh7aU4NkXfxz/ J3zQq+yZ/gqMnK3JseNpq5hosU6f8keG4dGvq/qz3a+fDefe3Q1KoaTotG3oOyzY foq3RJjIoY0M7Yl2VJXhhDU6fLWNuu2Uixd9DpbWDmUzhY2o7y8zUZrCdEN0CMN7 OcaUWAkPzFwAdGY/ZVzmc4AvBICXAndBRd29KIMF5JJAxKqwXzbCbROZC14spCl5 Yt8A3deCiUrCGKTuT8w4or8shtkfGxFXXWAEKxY9kKpsHRGmbcOmIVljXk3x6JpV VOo5y3xHOEmaGOGGRZSDRGK0AWpkiep71us9zOYmnTd0GVuulOOAfi6m4FyTS0vc 3FPws2FUaOZWHm+K0AEMJyyxY5Sz6NwN6sTmiPfelvUdKLDHpDDVyig1a0X+x39+ jfgOx/J927rCYvyWA1/n5h6Mqj7ByUYA3zM9nrrTt3mw5YM/fgCyqlFp8M9cWWRF cW54Aes9cnV2GdhnbLy7cuOwXK5J7FV6uyQFPipaAkuGEG7ynvUWQdvnftX9j1hL O8S6WOzZDUYduB3mXJ5XT2iV2jjRd3zEk1niQcRfyFuQUYneY9zuGjpxkknmxEln 5KaBqwFCLo4XnRrvlDkg =PO9e -END PGP SIGNATURE- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Optic
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/15/2015 08:36 PM, Lawal Mohammed wrote: > I understand that in gga/lda the Kohn-Sham eigenstates are regarded > as excited only when the scissors operator is non zero, is this > correct? If yes then how valid is optical calculation when the > scissors operator is set to zero? If no then what bring about the > optical excitations that allow determination of some optical > properties? The “scissors operator” is simply a rigid shift of the unoccupied bands in energy (where rigid means that the states themselves are not changed). This is done to “correct” band gaps which come out wrong (usually too small) in DFT. An optical excitation takes an electron from an occupied to an unoccupied state. This means that the scissors operator will change the energies where these excitations are possible, e.g. to adjust the optical gap in your calculation to the experimental value. HTH, Elias -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJV++3ZAAoJEE/4gtQZfOqPKvEP/Rn5QZqwVZcNdtlAsl9OiWVl 49pkLhtV98TuuXnItDvI/1kzcuQrggK2vvCgfXpu2zD7RE2eP6sUBfMTSsB7/Rlh duCESsliMt/LBFU+vwxBhEEF4zJu0MQrQ5Tb6Pnl1LUb+2YvaoVCL1e3nNfPP1iU 5so5Db3MVnGpNiiTRtiSvTCnUj6z0tALao6pvegzob5w/HOaIqMeY7pcPZBymnaY uobcaXnscCPd75omhLXwsRIvynRfXgTblcxU3ld5242EEZRzg0wtkUJoSYKQsQVJ t4DUUbO+tsn3wgsZOaJPZ8X79lvUOcgb/7MO/DbP+tXVhAzxjx3sD+Tnx0wqRU+V p/HPpN7Eu3YzekCqtc6kTE9szX9CKjYWFhpMItqnRfKQTcNbDtkJLexm/XbUu/W7 WpgHoQVWmgYmLGwMLP3rZvH+oGHCqFHfHxxcMou9Bq8Oj44ul35alP3qZcvaJ7gp nceY+cXbsnuacaiTc4WqF/qc92EwYuKJoRkF8kcHj2YnrFoJTiHuFS8dtsH4Juwn 4Vq/NUPNVliL1XFKnCeBYqaQk6Gi8g6kgFRKDS/mU3RuTDNzvO/KEECG5Of1VB3j rg82hbszX4ZW07d4V05Yg1UNJeRypJ8ZLYmMLeiK+HrJ4HONHnq4WopLmWqht1I0 Yv2ikdHGRyXn7rwghXqQ =BART -END PGP SIGNATURE- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] time difference among nodes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sounds like a nasty problem … In terms of strategy, I think the first thing should be to find out if the node is really to blame. If so, you have to convince the admins and/or find a way to avoid it. If not, you can turn to figuring out whatever else (presumably in your Wien2k setup) is causing the trouble. On 09/24/2015 07:37 PM, Luis Ogando wrote: > First of all, I wonder: To what extent is this problem > reproducible? E.g., does your job always run on the same 4 nodes? > > Yes. > > Is it always the same node(s) that are slow? > > Yes It seems unusual that your job should always be assigned the same nodes, but okay. If you get your job to run on a different set it could help establish if the node is really to blame. In some queuing systems, you can request specific nodes. Or you could submit two copies of your job. > The strangest part: at the beginning of this month, the same > calculation was running properly. I had a crash for convergence > problems and when I reduced the "mixing factor" in case.inm (it is > now 0.04 in pre-convergence scf cycle) the problems started. > Obviously, I do not believe that the mixing factor is the problem. > > No. All the executables are running slowly in the problematic > node. I would try to widen the tests then -- restart the calculation from scratch, try a different case, try other programs … > Users can do nothing. The administrator sent me the "top's" and I > have asked him for simultaneous ones. Like I said, even if you have no direct access you can put it in a job script. Something along these lines (in bash): run & pid=$(jobs -p %1) while [[ "$(jobs)" ]]; do for n in $NODES; do ssh $n top -bn1 >>$n.top # plus whatever else you want to check done done wait Elias -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJWBP9EAAoJEE/4gtQZfOqPHfkQALvFqdz2yL5CGbVH7c7klkoo UT3vR6W+3Ev6in9Ed/z/KOc09m8j2hFrZ0p32jW9EF78jfiObFKaaNVkbHJLpw8l 6ru8AEVBxdNIeCJp53aakILSboRx/GzRnTHdZMyjj8EGfEng+0+fPG2+xm+OWipU Nsreceb/n+gwJvZTKTn719xushxAM9JSUmSMPrN3WESH4nEgm3wFeR/FuPFyoqfZ S3RNb0CYd8tB3bs0MP4lYFbHWVeiQVy0j2uOwoiqjfqkSlC1vvJoxnBXO900ybvX AaIRRXGcmd8XiTaQfD/VPvZX0R3Un1swee4EI0LcMNxiYFGkvuN0p7lMd5MC5Zny 7h+IeXIMH9QNtlWF4HDr7stMAYSeKxKLhTWlddJgIOXrXGPF9BHHJsY/X3LwUIYF E8UzP061j1LNVwDMUIOYYBX4UCIQJfMpnW3PvbTJIIq56NE3Z6ppxV4ZMAkK2JBo HRmdtQX8pSCXJaggu7QbAIzdhH4Eat+YoEgBAo6uj1M4tYjZ1GivNlwBO2ItQFTu Y5JCrWILBKloCEym4TDezcwCR0R2/4cUKkXQlgQUh+iLVrKCG2QkAYnJwSxzdIDe q19gOQEU5MrUCHtH1vaUTYE+Oq4Z0UNWhKiGRapBgJNFYnRonqzKywqOciWt2SmU JV7fZo5W2vviyEW/e9TF =eXD9 -END PGP SIGNATURE- ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] :FCHECK in Wien2k 13.1 vs. 14
Dear Prof. Marks, Dear Peter, Thank you both for your comments. It took a little while for me to digest them. Let me try and answer some of your points. On 11/30/2015 04:40 PM, Laurence Marks wrote: > In your case this "disturbed" 14.2 and it is adjusting the greed > down to try and stabilize. In 13.1 this push is missing, so it starts > with a small greed and finds what it thinks might be a solution. Fair enough. I guess I can see the “push” in the first to :MIX lines 14.2 :MIX : PRATT REG: 1.00E-06 GREED: 0.200 :MIX : PRATT REG: 1.00E-06 GREED: 0.200 Reduce 0.25 0.20 13.1 :MIX : PRATT REG: 1.00E-06 GREED: 0.025 :MIX : MSR1a REG: 1.00E-06 GREED: 0.030 Newton 1.00 0.03 But is this really a sufficient explanation for the difference in the forces? To reiterate, :FCHECK stays in the hundreds with 14.2 throughout hundreds of iterations and shows no sign of getting better. In 13.1, it may still be “large” in the segment I posted, but (a) the difference (an order of magnitude!) to 14.2 seems significant to me, and (b) it does get better in 13.1. I let the calculation continue for some iterations, and it seems to be converging (in :DIS, :ENE, :FCHECK): :FCHECK: -0.032439112-1.13594371416.929383355 :FCHECK: -0.028389245-1.09488071115.228531069 :FCHECK: -0.019806079-1.04724149515.222784275 :FCHECK:0.066957613-0.532750625 6.877936902 :FCHECK:0.198624197 0.113074627 4.947166063 :FCHECK:0.290335137 0.709393143 5.480758387 :FCHECK:0.230186592 0.748489732 8.063734492 Of course, this decrease happens only after the mixer switches off MSR1a, so maybe it is really a consequence of that. On 11/30/2015 05:59 PM, Peter Blaha wrote: > However, you should now check if the final forces with 13.1 are > really small (so that it was "justified" that the mixer switched from > MSR1a to MSR1 and stopped optimizing the positions (you probably need > a few more normal scf iterations to get a lower :DIS and better > converged forces to get a convincing answer) - otherwise 13.1 stopped > to early and was "stagnating"; It seems to be going that way, but I will certainly do more iterations and report back then. Thanks again, Elias -- Elias Assmann Institute of Theoretical and Computational Physics TU Graz ⟨https://itp.tugraz.at/⟩ signature.asc Description: OpenPGP digital signature ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
Re: [Wien] Another Question
Dear Zhaoming Fu, For the benefit of other wien2wannier users, I am taking this to the Wien2k mailing list. I hope you do not mind. On 12/13/2015 10:43 AM, 付召明 wrote: > For a degenerate energy level, take t2g (including three orbitals: > dxy,dyz and dxz) as an example, Can we get three Wannier functions > corresponding to dxy,dyz and dxz localized orbitals by wannier90 program? > > I feel it can not give them. According to the defination of wannier > functions and the initializing steps of Wannier90 calculations, it seems > that one energy band can only give one wannier function though this band > include three > > degenerate states at each K point. I list the detail problems in the > attachment. On general grounds, where you say you have “one energy band that includes three degenerate states at each k-point”, I would see three bands that happen to be degenerate in this region of k-space. However you want to call it, what matters is the number of Bloch and Wannier states. The “normal” Wannier transformation gives you an equal number of Wannier and Bloch states. With disentanglement, you can also have fewer Wannier than Bloch states. Now, some comments on your concrete example, as far as I can tell what is going on from the DOS. It seems that the states are approximately but not entirely degenerate. By “disentanglement window”, I assume you mean what Wannier90 calls the frozen window. It seems that above -1 eV or so, you target bands are not in fact entangled, so you could actually increase your frozen window to [-1, 1] eV. This may or may not help with the problem of “wrong” dxz and dyz states. Some other tips (which apply to many situations): 1. Seeing that your Wannier centers are “wrong”, make sure that your initial projections in case.inwf are correct. 2. In case.wout, check that first Disentanglement and then Wannierization are both converged. 3. Also check the Wannier-interpolated band structure in case_bands.dat. 4. Look at the band structure from Wien2k, not just the DOS. Personally, I find a color-coded band structure most helpful (you can use e.g. https://github.com/eassmann/prima.py for that). Often, this brings to light relevant details which are otherwise overlooked. Elias -- Elias Assmann Wien2Wannier: maximally localized Wannier functions from linearized augmented plane waves http://wien2wannier.github.io/ https://github.com/wien2wannier/wien2wannier/ signature.asc Description: OpenPGP digital signature ___ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
