Re: [Wien] Plotfunktion von Wannier-Funktionen in w2w für SOC-Rechnungen

[Elias Assmann]

Dear Okan,

Please do not send wien2wannier usage questions to my personal e-mail.
Instead, please use the Wien2k mailing list for the benefit of other
users.  I am taking this discussion to the list and therefore answering
in English.

The first question concerns NaNs in ‘case_m.xsf’ as produced by ‘wplot2xsf’.

On 01/10/2017 08:32 PM, Köksal, Okan wrote:
> - write_inwplot case (Input-File für wplot)
> 
> - x wplot -wf m (m= Nummer der entsprechenden WF) -up -so
> 
> Bis hierhin habe ich auch keine Probleme gesehen, nur bei der
> Konvertierung zu einer Input-Datei für XCrySDen/VESTA via "wplot2xsf
> -up", sehe ich dass in der *.xsf -Datei Einträge mit "nan" und andere
> wiederum mit Zahlen belegt sind. Daher würde ich gerne fragen, was der
> Grund hierfür sein könnte? Oder müssen die Dateien "case_m.psink" bzw.
> "case_m.psiarg" eigenhändig angepasst werden? Konnte im w2w-UG keine
> Hinweise hierzu finden.

To clarify, you are saying there are no NaNs in the .psink and .psiarg
files?  Can you figure out which places in those files lead to the NaNs?
 Note that the order is not the same in .xsf; ‘wplot2xsf’ reads into the
array ‘data’ and then outputs
data.reshape((nx, ny, nz)).transpose(2,1,0).reshape(nx*ny*nz)

If the problem really is in wplot2xsf, then it cannot be directly
related to SOC, since wplot2xsf only cares about .psink and .psiarg (and
marginally a few other files that are not really different with SOC).


Question number 2 is about the correspondence of WFs in the presence of
SOC to “spin ↑” and “spin ↓” (specifically the Hamiltonian matrix
elements in case_hr.dat).

> Ich versuche derzeit ein TB-Modell mit SOC aufzustellen. Mit SOC sind
> die Matrixelemente für die entsprechenden WFs bzw. deren Imaginärteile
> ungleich 0. Da sich die Matrix mit SOC verdoppelt (im Vergleich zur
> ursprünglichen Matrix ohne SOC), stellt sich mir die Frage, wie die
> "spin up/down"-Matrixelemente im "case_hr.dat" zu lesen sind bzw. sind
> diese in einer anderen Datei abgelegt? Auch ist mir bewusst, dass durch
> das Mischen von "spin up/down" diese keine gute Quantenzahl mehr ist.

The general answer is that the WFs are free to mix “↑” and “↓”
arbitrarily and case_hr.dat contains matrix elements between those
combined-spin WFs.  Therefore such a correspondence can only ever be an
approximation.  If your material has only light elements and SOC is very
weak, you will typically find WFs that correspond to “↑” and “↓” to a
good approximation, i.e. half the WFs will have negligible projections
on ↑, and the other half on ↓.


Elias




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] shifteig in wien2wannier

[Elias Assmann]

On 01/03/2017 04:35 AM, Koyel Bandopadhyay wrote:
> When do we need to do shifteig?
> Is it done before/after w2w step?

Normally (when you have a correct Fermi energy), you do not need it at all.

If you need to use it, it is between w2w and wannier90, since it acts on
case.eig.  If you want to adapt the Fermi energy before w2w, you can do
so by editing case.fermi.


Elias





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] w2w compilation problem during siteconfig

[Elias Assmann]

On 12/22/2016 10:45 PM, Fecher, Gerhard wrote:
> Personally I like more to tell make which files I like to have compiled 
> instead of using an automatic 
> search and the makefile decides which ones I like to have compiled, 
> but maybe I am just a little bit too old fashioned.

Well, the rule I quoted just says how to build a file.o from file.f or
file.F.  The list of object files is defined like this

OBJS = $(filter-out $(R_OBJS) $(RC_OBJS), \
$(patsubst %.F, %.o, $(wildcard *.F)) \
$(patsubst %.f, %.o, $(wildcard *.f)))

I.e., converted from all Fortran source files in the directory.
Eventually, of them will be compiled because the targets depend on them.

I don't know if this is explicit enough for you.  But if you think that
the Makefile is overly complicated for building all of 3 objects (5 in
SRC_w2w/), I can agree with that.  Most of the Makefile comes from when
most procedures had their own little source file.  These days, the above
could read

OBJS = $(filter-out $(R_OBJS) $(RC_OBJS), modules.o modules_rc.ow wplot.o)

or even just

OBJS = modules.o

(OBJS is only supposed to contain those objects that are the same for
the real and complex versions.)

Other than that, a lot of the structure of the Makefile comes from the
desire to respect certain conventions of the Wien2k Makefiles, and to
have something that works for SRC_w2w/ and SRC_wplot/ with minimal
changes.  Superficial differences have accumulated, but at the core, the
differences reflect: the different names of the executables; different
dependencies among objects; and the need in SRC_wplot/ to link to some
objects from SRC_w2w/.


Elias




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] w2w compilation problem during siteconfig

[Elias Assmann]

My memory may be feeble, but the Internet remembers All.

It turns out that I had this exact problem three years ago.  I even
asked a question about it on StackOverflow [1], where a helpful user
pointed out that this is a known bug in make 3.82 [2] and suggested the
solution

.SECONDEXPANSION:

%.o: $$(wildcard %.[fF])
$(FC) $(FFLAGS) -c $< -o $@

(splitting the rule should still also work, of course).

Since this problem was fixed in later versions of make and is easy to
circumvent if you are affected, I will leave my Makefiles as they are.

It remains a puzzle though that I cannot now reproduce the problem with
make 3.82 (neither with a make 3.81 that I found elsewhere).  Maybe
RedHat backported the fix?  ‘make -v’ says

GNU Make 3.82
Built for x86_64-redhat-linux-gnu


Elias


[1] http://stackoverflow.com/questions/21193024/wildcard-in-a-pattern-rule
[2] https://savannah.gnu.org/bugs/?func=detailitem_id=31621

-- 
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] w2w compilation problem during siteconfig

[Elias Assmann]

On 12/21/2016 03:01 PM, Fecher, Gerhard wrote:
> Here it is,

Thank you.

> Don't ask me why the output is partially in Austrian ;-)

Yeah, up to the inwards-looking guillemets.  “Macht nichts” is endearing.

> make --version gives:
> GNU Make 3.82
> Built for x86_64-unknown-linux-gnu
> Copyright (C) 2010  Free Software Foundation, Inc.

Well, it is old, but it is GNU make and not that old -- I doubt that is
an issue.

> Betrachte Target-Datei »lib/util_w2w.o«.
>  Die Datei »lib/util_w2w.o« existiert nicht.
>  Suche nach einer impliziten Regel für »lib/util_w2w.o«.
>  Versuche Muster-Regel mit Ersetzung »util_w2w«.
>  Versuche implizite Voraussetzung »util_w2w.[fF]«.

There seems to be a difference here:

Considering target file 'lib/util_w2w.o'.
 File 'lib/util_w2w.o' does not exist.
 Looking for an implicit rule for 'lib/util_w2w.o'.
 Trying pattern rule with stem 'util_w2w'.
 Trying implicit prerequisite 'util_w2w.F'.

You can see that my make gives me straight '' quotes even though I have
a UTF-8 locale set.  No, that's not it …

It looks like your make does not recognize the [fF] glob.  Why this
should be, I do not understand.  I found a machine (VSC-3) that is also
running GNU make 3.82, and it does not seem to have this problem.

If you want to build wien2wannier, or just get rid of the compilation
errors, or want to help me fix this problem, you could try splitting the
rule

> $(O_DIR)/%.o: %.[fF] Makefile
> @test -d $(O_DIR) || mkdir $(O_DIR)
> $(FC) $(FFLAGS) -c $< -o$@ $(MODOPT) $(O_DIR)

into one duplicate for %.f and one %.F:

$(O_DIR)/%.o: %.f Makefile
@test -d $(O_DIR) || mkdir $(O_DIR)
$(FC) $(FFLAGS) -c $< -o$@ $(MODOPT) $(O_DIR)

$(O_DIR)/%.o: %.F Makefile
@test -d $(O_DIR) || mkdir $(O_DIR)
$(FC) $(FFLAGS) -c $< -o$@ $(MODOPT) $(O_DIR)


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] w2w compilation problem during siteconfig

[Elias Assmann]

On 12/21/2016 12:39 PM, Fecher, Gerhard wrote:
> make: *** Keine Regel vorhanden, um das Target »lib/util_w2w.o«, 
>   benötigt von »w2w«, zu erstellen.  Schluss.
> make: *** Keine Regel vorhanden, um das Target »lib/util_w2w.o«, 
>   benötigt von »w2wc«, zu erstellen.  Schluss.

Strange.  It should be made according to the rule

$(O_DIR)/%.o: %.[fF] Makefile
@test -d $(O_DIR) || mkdir $(O_DIR)
$(FC) $(FFLAGS) -c $< -o$@ $(MODOPT) $(O_DIR)

which seems fairly standard.  Can you please post the output of

make --version

and

make --debug=a lib/util_w2w.o

run from SRC_w2w/.

Thanks,

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] WIEN2k_16

[Elias Assmann]

On 12/20/2016 11:45 PM, Martin Kroeker wrote:
>> [1m init_lapw finished ok (B;[m
>> -
>> this seems strange, but does not give a problem
> 
> …

By the way, Martin, both of your replies in this thread do not show up
as such in my mail client, there is no line like ‘delamora wrote:’ above
the quote, there is not even a ‘Re:’ in the subject.  This makes it
difficult to place the message into the proper context.  (Although, too
be fair, the archive somehow manages to place your messages properly
<http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg15137.html>.)

Just saying.


    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] WIEN2k_16

[Elias Assmann]

On 12/21/2016 09:34 AM, Peter Blaha wrote:
> The strange symbols should not matter, but if you don't like them,
> either fix your Linux, or modify init_lapw setting   bold and normal
> 
> set bold=
> set normal=

FWIW, you can detect whether STDIN is a terminal using `tty':

$ tty # returns 0
/dev/pts/6
$ tty 

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] wien2wannier with SOC in WIEN2k 16.1

[Elias Assmann]

On 12/15/2016 10:13 PM, Kefeng Wang wrote:
> Thanks a lot for your help and explanation. With the new script
> write_inwf_lapw, everything works fine now.

Great.

> ->For this one, the exact error message is  “recommended file
> ‘GaAs.spaghetti_ene’ not found (will continue)”. But it does not affect
> the calculation since spaghetti file is only for reference. I believe
> the command did not recognize the “spaghettiup_ene” and
> “spaghettidn_ene” file.

If I am not mistaken (certainly people on this list can correct me if I
am), with SOC you should have called spaghetti as ‘x spaghetti -so’,
which would have produced GaAs.spaghetti_ene.  In the presence of SOC, a
priori it does not make sense to talk of separate “↑” and “↓” states.

Elias




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] wien2wannier with SOC in WIEN2k 16.1

[Elias Assmann]

Dear Kefeng Wang,

On 12/15/2016 06:01 PM, Kefeng Wang wrote:
> 2.   Then I run “init_w2w –up”, after k mesh (10 10 10) and find 
> band, “write_inwf” shows “error: unrecognized arguments: -up” and 
> init_w2w exit.  I also found the help file did not include [-up/dn] 
> option for write_inwf command. So I manually run write_inwf and then 
> copy case.inwf to case.inwfup and case.inwfdn.  Is this right?

Oops, this isn't right!  For some reason, the latest version of that
script did not make it into the 16.1 distribution.  You can get the
correct version from <https://git.io/write_inwf-2.0>.

Otherwise, here are step-by-step instructions for wien2wannier with SOC:
<https://github.com/wien2wannier/wien2wannier/wiki/wien2wannier-with-SOC>.

> 1.   Then I run *prepare_w2wdir WANN, but this command cannot 
> recognize Case.spaghettiup_ene and Case.Spaghettidn_ene file,
> instead it shows “cannot find spaghetti_ene file”. I copy them
> manually. Is something wrong?

I don't know.  Help me help you by showing the precise error message.

> 3.   After that, x lapw1 –up; x lapw1 –dn; x lapwso –up; x w2w 
> –so –up; xw2w –so –dn; and finally x wannier90 –so. Everything goes 
> smooth, I got reasonable band structure except that there is only one
> Case_band.dat file. I tried run “x wannier90 –so  -up”, but it shows
> “wannier90: -so should be used without –up/-dn”. Shall we expect two
> band data file for two spin channels or somehow I am stupid?

This seems right.  Why do you expect separate bands for up and down?
With SOC, that is not a good quantum number anymore.

> Also, I found a recipe for SOC case without spin polarization, but it
> seems outdated. What should I do with this new version for the SOC 
> case without spin polarization?

Which one?  Why do you think it is outdated?


Elias

-- 
Elias Assmann

Wien2Wannier: maximally localized Wannier functions
  from linearized augmented plane waves

 http://wien2wannier.github.io/
  https://github.com/wien2wannier/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] unit of |w(r)|^2 in case.xsf and case.psink

[Elias Assmann]

Dear Wenhu Xu,

On 12/12/2016 08:10 PM, Xu Wenhu wrote:
> Then I want to check the normalization of the wannier function, so I
> integrate the grid and assume the unit of |w(r)|^2 to be 1/A^3, as
> the unit parameter set in my case.inwplot file. But the number turns
> to be ~450, too much larger than the expected 1.

The most important factor is likely the number of k-points.  You are
probably using wien2wannier 1.0 (as included in Wien2k 14.2), where an
erroneous factor of sqrt(#k-points) was included in the WFs (see
wien2wannier issue #2 at https://git.io/wf-norm).  To fix this issue,
best upgrade to the brand-new Wien2k 16.1
.

Then, depending on what you did, you might see a remaining factor of
Å/Bohr.  To get that right, keep in mind:

 * the unit of distance you selected in case.inwplot (in the template,
   Å is selected, contrary to Wien2k convention);

 * the proper “dV” factor (in the header of case_i.psink, the lengths
   of the plot axes are always given in Bohr, regardless of the units
   option -- I should probably change that).

> Please see below the case.inwplot I used. The length of grid axes is
> twice of the lattice vectors, and the number of mesh points is
> 100x100x100.

Normally, you do not need to worry about WF normalization.  If for
some reason you do, then you need to be very careful about the
integration.  In my experience from one project [1], you may need to
go to surprisingly large plot regions (2×2×2 may or may not suffice,
depending on your unit cell and the shape of your WFs).

But to do a convergence study in the r-mesh, you also have to make
sure your r-meshes are commensurate.  That is to say, if the r-points
are slightly shifted from one mesh to another, you will pick up
contributions from different regions of the (sharply peaked) WFs and
converge to a different integral.

In summary: If possible, it is best to treat the r-integral over the
WFs as an arbitrary constant.


Elias


[1] T. Ribic, E. Assmann, A. Tóth, and K. Held, Phys. Rev. B 90,
165105 (2014)



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] wien2wannier in WIEN2k_16

[Elias Assmann]

Dear wien2wannier users,

Please take note of the following *backward-incompatible changes* in
your favorite LAPW → MLWF interface:

 * The format of `case.inwplot' changed. Several outdated options have
   been removed, as has `write_inwplot'.  The new script
   `checkinwplot' converts old-style input files.  `x wplot' calls
   this script automatically, but to use a converted file, you must
   re-run `wplot':

  $ x wplot  # prints notification about converted file
  $ x wplot  # use converted file

 * In spin-polarized cases, `x w2w -up|-dn' now expects separate input
   files case.inwfup and case.inwfdn.  To re-run `w2w' in an existing
   directory, copy `case.inwf':

  $ cp -vi $(basename $PWD).inwf $(basename $PWD).inwfup \
&& mv -vi $(basename $PWD).inwf $(basename $PWD).inwfdn


This release incorporates a number of fixes and enhancements that have
accumulated since Wien2k 14.2.  For more details, see
https://git.io/w2w-NEWS-2.0 or the file $WIENROOT/SRC_w2w/NEWS.

Many of those changes were the direct result of users' feedback.  In
particular, I would like to thank Marc Höppner, Hong Jiang, Okan
Köksal, Gernot Kraberger, Laurence Marks, Oleg Rubel, Liang Si, Yundi
Quan, Ulrich Wedig, Jiaxu Yan, Jianxin Zhu, and Manuel Zingl for their
valuable comments on past versions.


    Elias Assmann

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

Re: [Wien] Error running wannier90.x for GaAs spin-orbit coupling wien2wannier

[Elias Assmann]

On 12/04/2016 03:01 PM, Dara Goldar wrote:
> With the following command, I get some information on the version of
> c-shell I am running:
> 
> dpkg -l csh
> 
> 
> ||/ Name Version  Description
> +++---
> ii  csh  20110502-2ubuntu Shell with C-like syntax

Run ‘csh --version’.  Mine says ‘tcsh 6.19.00’; it should be ‘tcsh’,
otherwise I would recommend installing tcsh instead of csh.

> I am not familiar with c shell, but will try to test whether -s works on
> my version or not.

It is easy to test interactively, e.g.

$ echo 1 > test
$ csh
% if (-s test) echo yes
yes


> Is your suggestion that I make the following change in x_lapw which you
> suggested and then recompile x_lapw?
> 
> /I later changed ‘! -s $file’ to ‘! ( -e $file.amnup && ! -z $file.amnup
> )’ because older csh versions do not have the ‘-s’ test.  (Maybe it is a
> ‘tcsh’ vs. ‘csh’ issue.)/

You could do that, but if this is indeed the problem, I would upgrade to
tcsh if possible.

Note the typo above: I meant replace

  -s FILE

with the equivalent

  ( -e FILE && ! -z FILE )


Elias




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] Error running wannier90.x for GaAs spin-orbit coupling wien2wannier

[Elias Assmann]

Dear Dara Golda,

On 12/04/2016 12:29 PM, Dara Goldar wrote:
> I am trying to run wien2wannier on a spin-orbit GaAs - case, but
> experiencing problems when running *x wannier90 - so*.
> 
> …

>>>> (x) w2waddsp: neither mmn nor amn files present -- nothing to do -> exit

> I have however confirmed that the files case.amnup and case.amndn etc
> are present in the folder. Furthermore, no files in the WANN-files
> contain any information on errors!

In Wien2k 14.2, the ‘w2waddsp’ section of x_lapw reads

case w2waddsp:
true >$def
…
if (! -s $file.amnup && ! -s $file.mmnup) then
  error "w2waddsp: neither mmn nor amn files present -- nothing to do"
endif
…

I later changed ‘! -s $file’ to ‘! ( -e $file.amnup && ! -z $file.amnup
)’ because older csh versions do not have the ‘-s’ test.  (Maybe it is a
‘tcsh’ vs. ‘csh’ issue.)

Does your csh support ‘-s’ (you can test that interactively)?  What does
‘csh --version’ say?

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

Re: [Wien] How to include the localized d orbitals in the atomic spheres?

[Elias Assmann]

On 11/30/2016 05:07 PM, Abderrahmane Reggad wrote:

How to consider electrons (for example d electrons ) as localized or
itinerant or half half or it's considered within the calculation?


Sorry, but I do not understand the question.

If this is still about DFT+U and the MT spheres, the key thing to 
understand is what Martin wrote: The spheres are a mathematical 
construct introduced in order to define the basis set.  They have no 
inherent physical meaning.


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] How to include the localized d orbitals in the atomic spheres?

[Elias Assmann]

On 11/28/2016 06:04 PM, Abderrahmane Reggad wrote:
> Sorry for my question 

No worries!  Asking and answering questions is the purpose of this
forum, after all.

> Wen we use the maximum values for the Rmt such a way the spheres become
> touched. Does that guarantee that the 3d electrons are all inside atomic
> spheres?

To answer the implied question as well: Yes, this means that the U /
EECE potentials are applied only to “a part of” the states you specify
(or, as Martin wrote: “between the atomic spheres the potentials … are
set to zero”).  You can view this as a deficiency of the method, but it
is standard practice and normally quite good enough.

Think about how the target states are defined: as the d states (for
example) of some atom, i.e., as the projection of the Kohn-Sham states
onto the d manifold around that atom.  But to even define this
projection, you need to specify a sphere around the atom.  In an APW
code, the muffin-tin sphere is the natural choice.

To go beyond this approach and make sure that you cover the “whole” d
states, you would need to provide an alternative definition of those
states.  One possibility would be Wannier functions, but it would not
(normally) make sense to do a Wannier projection during each DFT
iteration “only” for DFT+U.

    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

Re: [Wien] runsp_c_lapw issue [unmatched] not solved even after looking on mailing list

[Elias Assmann]

On 11/24/2016 08:57 PM, Dr. K. C. Bhamu wrote:
> 1. Initialised without any problem.
> 2. runsp_lapw -orb -ec 0.0001 -cc 0.0005 -i 2 -fc 2  works fine
> but if I run
> 3. runsp_c_lapw -orb -ec 0.0001 -cc 0.0005 -i 2 -fc 2 gave me two
> problems:

>  hup: Command not found.
>  LAPW0 END
>  ORB   END
>  ORB   END
>  LAPW1 END
>  LAPW2 END
> LAPWDM END
>  CORE  END
>  CORE  END
>  MIXER END
> Unmatched ".
>  MIXER END
> Unmatched ".
> in cycle 2 
> 

Ah, the csh!  You have got to love a good error message.

First question: Does the calculation stop there?  I am under the
impression that sometimes this “Unmatched "” is sometimes “harmless”.
If so, is there any other error message?  “Unmatched "” is not even
the last output.

Second question: are those asterisks (*) part of the output or did you
add them?

> kcbhamu@Lenovo-B570:~/wien_work/test_case/AAO_LU_50$ csh -v
> $WIENROOT/run_lapw -NI -i 1

Third question: You wrote ‘runsp_c’ gave you problems but ‘runsp’
works fine, yet now you are testing ‘run’.  What gives?

> the out put of this command is this (I do not understand what is mean by
> this output) and I see and error message at the bottom:

Sometimes, reading the fine manual really helps: ‘man csh’ says
(search for ‘-v’)

  -v Sets the ‘verbose’ shell variable, so that command input is
 echoed after history substitution.

and further down (searching for ‘verbose’ now)

  verbose If set, causes the words of each command to be printed,
  after history substitution (if any).  Set by the -v command
  line option.

So, first thing I notice in the output that you posted is that
“Unmatched "” does not appear!  Instead, at the end, you have

> lapw1full:
> total_exec lapw1 $it0 $para $nohns $readHinv0 $cmplx $scratchstring
> LAPW1 - Error
> printf "\n>   stop error\n" >> $dayfile
> printf "\n>   stop error\n"
> 
> *>   stop error*
> *exit 9*

which is probably a totally unrelated error.  (I suspect it is related
to the question which script you are running …)

One more comment:

> hup
> hup: Command not found.

I do not know where that comes from since ‘hup’ is supposed to be a
csh builtin.  (Or is it tcsh only?  You can see which version you are
running with ‘csh --version’.)  Anyway, it should not be a problem.


Elias



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] regarding permission of Wien2k commands

[Elias Assmann]

Dear Bhamu,

I fail to understand the problem.

On 11/17/2016 08:33 AM, Dr. K. C. Bhamu wrote:
> While playing with unix commands on my machine, I lost permission of all
> Wien2k commands. Because of this I am not able to run any Wien2k commands.
> 
> I am getting the following permissions for all commands:
> 
> -rwxrwxr-x" .

That combination of statements does not make sense.  If you see the
permissions you state, you have permission to “execute” that file (and
so does every other user since the “a+x” bit is set).

> How to get rid off this problem?

If the problem is that you cannot run the commands, the reason is
somewhere else.  Post the error you are seeing.

If the problem is that you set executable permissions on every file and
want to reverse that, that is harder since you have to figure out which
files “should” have that permission.


Elias





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] What does it mean the commment " Unmatched " during SCF cycle

[Elias Assmann]

On 11/02/2016 01:07 PM, Abderrahmane Reggad wrote:
> During the Volume optimization and after adding another point "-9 per
> cent " to get a good curve , I got this comment "Unmatched "even the
> calculation still running without error:
> 
> The following show part of the SCF cycle with the comment "Unmatched "
> 
> in cycle 5ETEST: .064458035000   CTEST: .0057531
> Unmatched ".
…
> in cycle 4ETEST: .03565563   CTEST: .0207127
> Unmatched ".
>  MIXER END

It is an error (warning?) from csh, which was looking for a "quoted
string" but did not find the second quote mark.  (Note that the error
message is actually «Unmatched ".» to be precise.)

$ tcsh
> echo "foo
Unmatched ".

> What does it mean that ? Is there any problem ?

I cannot say.  Maybe someone else has seen this message in this context
and can tell you something particular.  Failing that, try to locate the
offending line in your scripts (an editor with syntax hiliting might help).


Elias




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] wien2wannier with SOC

[Elias Assmann]

Dear Jianxin,

Normally, wien2wannier usage questions should go to the Wien2k mailing
list for the possible benefit of other users.  I am copying to the list now.

On 09/16/2016 09:38 PM, Zhu, Jianxin wrote:
> x lapw1 –p
> x lapwso –p
> cp fccYb-W.fermi fccYb-W.fermiup
> cp fccYb-W.fermi fccYb-W.fermidn
> cp fccYb-W.vsp fccYb-W.vspup
> cp fccYb-W.vsp fccYb-W.vspdn
> x w2w –so –up –p
> x w2w –so –dn –p
> x wannier90 -so

This sounds like the “old” prescription -- copying vsp files should no
longer be necessary.  See also this page

(I just edited that to make it hopefully a little easier to understand).

> (I am using the
> wien2wannier coming with wien2k 14.2. I notice that you also post the
> program on the Github but I hope there is no severe change.)

In fact, that is the first thing I have to recommend: please get the
latest “master“ version from GitHub and try again.  There have been
important changes especially with regards to SOC.

If you have the same problems (“wiggly” Wannier bands) with the master
version and the procedure from the Wiki, please report back.


Elias






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] error in x wplot

[Elias Assmann]

On 08/01/2016 12:34 PM, Ravi Kashikar wrote:
> Hi Elias
> 
> Now I Have tried with w90chk2chk.x utility, its creating case.chk.fmt.
> error is repeating. After x Wannier90 execution. I used  *w90chk2chk.x*,
> then *write_inwplot* and *x wplot -wf 1*. which is printing the error, as

w90chk2chk.x is for converting the .chk to plain text so you can read it
and check for problems (or transfer it to another machine without binary
compatibility).  It is not useful to call it before ‘wplot’.

> -
> forrtl: severe (24): end-of-file during read, unit 32, file
> /home/cmtcl/WIEN2k_cal/ga/gas/gas.chk
> Image  PCRoutineLine   
> Source
> wplotc 0042BEB3  Unknown   Unknown  Unknown
> wplotc 00457A74  Unknown   Unknown  Unknown
> wplotc 00415C32  main2_180  main.F
> wplotc 004034BE  MAIN__ 61  wplot.f
> wplotc 00402FEE  Unknown   Unknown  Unknown
> libc.so.6  2B529756CF45  Unknown   Unknown  Unknown
> wplotc 00402EE9  Unknown   Unknown  Unknown
> 0.0u 0.0s 0:00.00 0.0% 0+0k 0+8io 0pf+0w
> error: command   /home/cmtcl/WIEN2k_14/wplotc wplot.def 1   failed
> 

I notice that this error comes from a different line than before.  Is it
possible that w90chk2chk replaced the binary .chk with the plain-text
one, i.e. that wplot is trying to read a text file as binary?

Otherwise I cannot say any more than I already have.

> Something seems to be wrong with Wannier90's checkpoint file ‘case.chk’.
>  It could also be an inconsistency between input files.  Try re-running
> Wannier90; if the problem persists and you want to dig deeper, new
> versions of Wannier90 come with a utility called ‘w90chk2chk.x’ which
> you can use to convert the .chk to plain text.


Elias





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] Problem with x w2w -so -up (wien2wannier)

[Elias Assmann]

On 07/21/2016 09:51 AM, Wen Fong Goh wrote:
> Hi Elias, I have tried out the current development version and it
> reports no error, except it asked for case.inwfup and dn, which I assume
> can be copied from case.inwf. So do you think the current wien2k package
> should be updated with this wien2wannier version?

One more thing: I would advise that you check the results of this
calculation carefully, just to keep an eye on the possibility that the
problem was “fixed” only such the calculation does not crash, but that
some subtler problem remains.

Since it is difficult to check the .amn and .mmn files by eye especially
in the presence of SOC, realistically that means checking the Wannier90
results (even more carefully than you do it anyway …).  If you notice
something strange, please keep us posted.


Elias




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] Fwd: Re: Problem with x w2w -so -up (wien2wannier)

[Elias Assmann]

I forgot to CC the mailing list on the reply below:

On 07/21/2016 09:51 AM, Wen Fong Goh wrote:
> Hi Elias, I have tried out the current development version and it
> reports no error

Good news!

> except it asked for case.inwfup and dn, which I assume
> can be copied from case.inwf.

Yes, if you do not need them to be different.  It has been requested to
allow for separate up/dn input files with SOC; personally, I have no
idea how widespread this need is.

In fact I am not quite sure about the best way to handle this issue in
the user interface.   Currently, you call ‘init_w2w’ with either -up or
-dn and it generates one input file for you.  It could do other things
as well, e.g. ask whether you want a separate input file for the other
spin, or just silently copy it.  I am open for suggestions here and
would welcome the opinions especially of people who use both
“spin-agnostic” projections and such where separate input files are needed.

It is worth keeping in mind that this is a matter of convenience.  For
example, it was always possible to use separate .inwf{up,dn} files by
editing .def files by hand.

> So do you think the current wien2k package
> should be updated with this wien2wannier version?

There have been a number of bugs fixed and things improved (or so I
hope) since 14.2.  These will be included in the next Wien2k version,
but you can always upgrade wien2wannier separately.  On GitHub, I try to
keep the ‘master’ branch in a presentable state while other branches are
reserved for more experimental things.


Elias







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] error in x wplot

[Elias Assmann]

Dear Ravi,

I am copying the Wien2k mailing list for the potential benefit of other
users.

On 07/20/2016 12:52 PM, Ravi Kashikar wrote:
> forrtl: severe (67): input statement requires too much data, unit 32,
> file /home/cmtcl/WIEN2k_cal/NiO/NiO4/nio/nio.chk
> 
> Image  PCRoutineLine   
> Source
> wplot  0042BD53  Unknown   Unknown  Unknown
> wplot  004599B6  Unknown   Unknown  Unknown
> wplot  00457573  Unknown   Unknown  Unknown
> wplot  004161BE  main2_189  main.F
> wplot  004034BE  MAIN__ 61  wplot.f
> wplot  00402FEE  Unknown   Unknown  Unknown
> libc.so.6  2B215C8F3F45  Unknown   Unknown  Unknown
> wplot  00402EE9  Unknown   Unknown  Unknown
> 0.0u 0.0s 0:00.00 0.0% 0+0k 0+8io 0pf+0w

Something seems to be wrong with Wannier90's checkpoint file ‘case.chk’.
 It could also be an inconsistency between input files.  Try re-running
Wannier90; if the problem persists and you want to dig deeper, new
versions of Wannier90 come with a utility called ‘w90chk2chk.x’ which
you can use to convert the .chk to plain text.


Elias




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] Error in wien2wannier for spin orbit coupling case

[Elias Assmann]

On 07/05/2016 07:18 PM, Niraj Aryal wrote:
> However, there is something serious thing I am encountering. When I do
> wannier90 calculation after finding case.mmn, case.amn and case.eig (up
> and down spins are added using w2waddsp), it gives me negative spread
> for Omega I e.g:
> 
>  Spreads (Ang^2)   Omega I  = -2549.235637370
>    Omega D  =  1558.555122007
>Omega OD =  3178.612948567
> Final Spread (Ang^2)   Omega Total  =  2187.932433204
> 
> But we know that the spread has to be positive because it is expectation
> value of (r- )^2 . I found similar post here:
> http://mailman.qe-forge.org/pipermail/wannier/2008-September/000199.html

Hm, I do not recall ever seeing negative values for the Ω components.
For completeness, note that the expectation value corresponds to the
*total* Ω; but nonetheless Ω_I must be nonnegative also on its own.
Also, your Ω_D and Ω_OD look very large.  (Typically, they should be
small compared to Ω_I.)

> Since Omega I is only calculated from the case.mmn file, I suspect that
> there is some problem in doing so.

As Jonathan noted in the e-mail you linked, this is the case for an
isolated group of bands (no disentanglement).  (This is not to say that
the error is not on the wien2wannier side, which it almost surely is.)

When you mention `w2waddsp`, does that mean you ran that program
manually?  You should not need to do that, it is called by `x wannier90
-so`.  Did you follow the procedure outlined in the wiki
<https://github.com/wien2wannier/wien2wannier/wiki/wien2wannier-with-SOC>?

If the problem persists, I can try it myself, but please give me any
parameters I need, i.e. anything that differs from

init -b -sp
runsp
initso
runsp -so

and the bands and initial projections you used.


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

Re: [Wien] Please help with wannier90 error?

[Elias Assmann]

Dear Yukio Watanabe,

I am taking this to the Wien2k mailing list for the benefit of other users.

On 07/03/2016 08:27 AM, Yukio Watanabe wrote:
> After the standard scf, I could go to "write_inwplot" without error 
> messages. In the next step, I encountered the following error: 
> 
> [we@localhost GaAs-W]$ x wplot -wf 1
>  written on 24Jun2016 at 14:29:29 
> forrtl: fatal error (24): reached the end of the file during reading unit 32, 
> file  /home/we/W/out/exerciseX/GaAs-MLWF/GaAs-W/GaAs-W.chk
> Image  PCRoutineLineSource
>  
> wplotc 0048CC83  Unknown   Unknown  Unknown
> wplotc 004B8844  Unknown   Unknown  Unknown
> wplotc 0042AF3C  main2_.R  180  main.F
> wplotc 004035AE  MAIN__ 61  wplot.f
> wplotc 004030DE  Unknown   Unknown  Unknown
> libc.so.6  2AD36C429B15  Unknown   Unknown  Unknown
> wplotc 00402FE9  Unknown   Unknown  Unknown
> 0.002u 0.006s 0:00.00 0.0%0+0k 0+16io 0pf+0w
> error: command   /home/we/W/w14/wplotc wplot.def 1   failed

That sounds like Wannier90's “checkpoint” file ‘case.chk’ is incomplete
or missing.  Did ‘w2w’ and ‘wannier90’ run properly before ‘wplot’?


Elias




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] Error in wien2wannier for spin orbit coupling case

[Elias Assmann]

Dear Niraj,

On 07/02/2016 02:57 AM, Niraj Aryal wrote:
> Thank you Elias. The newer version of w2w ran without giving any
> errors for test case. I will do more tests and let you know.

Good to hear, and thank you for reporting the compilation error.

> For this, I used the executables from the old SRC_trig directory and
> they work fine with the new w2w executable.

This should pose no problems, except that there have been some
bugfixes in write_win_backend.

> write_win_backend.f(292): error #6460: This is not a field name that
> is defined in the encompassing structure.

L. 292 is the empty line after

do i=1,inwf%Nproj
   print fmt_centers, centers(i)
end do

I can only assume that the error refers to inwf%Nproj.  This is a bit
odd because this and other fields of the same structure are used
throughout that file.  Are there any other errors?  What compiler and
version are you using?

Also, can you make sure that write_inwf_backend.f is compiled against
the new util_w2w.F?  For instance, compile it in the wien2wannier
source directory rather than the Wien2k one (“cd
wien2wannier/SRC_trig; make write_win_backend”).


    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] Error in wien2wannier for spin orbit coupling case

[Elias Assmann]

Dear Niraj,

On 06/30/2016 08:04 PM, Niraj Aryal wrote:
> Dear Elias
> Thank you for your reply.
> This is full error message I get when I run x w2w -up -so -p
> 
> forrtl: severe (39): error during read, unit 9, file
> /home/aryal/work_wein2k/lapw/Zr2Te2P/wannier/./wannier.vectorsoup_1
> Image  PCRoutineLine   
> Source
> w2wc   0043CB33  Unknown   Unknown  Unknown
> w2wc   00465A44  Unknown   Unknown  Unknown
> w2wc   00429D82  read_vec_  52 
> read_vec.f
> w2wc   004238FD  MAIN__159  main.f
> w2wc   00403B9E  Unknown   Unknown  Unknown
> libc.so.6  0037F501ED5D  Unknown   Unknown  Unknown
> w2wc   00403AA9  Unknown   Unknown  Unknown
> 0.042u 0.037s 0:00.09 77.7%0+0k 24+32io 0pf+0w

This looks a lot like the error reported recently by Wen Fong Goh on the
mailing list and here
 (as well as by
others), although this observation:

> However, the program runs smoothly in serial version!

does not fit.

So also in your case, I would advise you to try the latest development
version.  If you send me your struct file and relevant parameters, I can
also try it out, if the calculation is not too large.

> Also as I said here: 
> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14497.html ,
>  I get no error at all when I consider bands starting from band index 1!

Oops, I missed that message.  (In the interest of “netiquette”, if you
find more information related to a previous e-mail, it is usually better
to reply to that e-mail rather than starting a new thread.)


Elias




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] Error in wien2wannier for spin orbit coupling case

[Elias Assmann]

On 07/01/2016 07:33 AM, wasim raja Mondal wrote:
>   Have you change symmetry operation 1 before running init_w2w?

Why would you do that?




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] Problem with x w2w -so -up (wien2wannier)

[Elias Assmann]

Dear Wen Fong Goh,

Sorry for the delayed reply, and thank you for the report both here
and on GitHub.  Since this problem has become a recurring issue, I will
continue the discussion here, where more users are likely to see it.

On 06/01/2016 01:43 AM, Wen Fong Goh wrote:
> Hi, I know this issue has been floating around in the mailing list, but
> I still couldn't find the solution. When I execute x w2w -up so, I got
> the following error:
> 
> forrtl: severe (174): SIGSEGV, segmentation fault occurred
> Image  PCRoutineLine   
> Source
> w2wc   004EED15  Unknown   Unknown  Unknown
> w2wc   004ECAD7  Unknown   Unknown  Unknown
> w2wc   004946C4  Unknown   Unknown  Unknown
> w2wc   004944D6  Unknown   Unknown  Unknown
> w2wc   0043FED6  Unknown   Unknown  Unknown
> w2wc   00443AF0  Unknown   Unknown  Unknown
> libpthread.so.02EE31850  Unknown   Unknown  Unknown
> w2wc   0046709D  Unknown   Unknown  Unknown
> w2wc   0042B8B3  read_vec_  52 
> read_vec.f

On 06/01/2016 11:57 PM, Wen Fong Goh wrote:
> I don't think that's the case, all of the other work fine with spin
> orbit coupling. What bothers me is that, for the same material, it works
> well with cubic structure, but when I change to tetragonal, it fails.

I am not sure if I reproduced your error.  I do get an error in the
situation you describe, but also in the cubic case.  The messages are
different from what you see as well, but that might be compiler-related.

In the tetragonal case, I see

   *** Error in `w2wc': free(): invalid next size (normal):
0x0235ed90 ***
   forrtl: severe (67): input statement requires too much data, unit 9,
file W-14.2.vectorsoup
   Image  PCRoutineLine
Source

   Stack trace terminated abnormally.

In the cubic case instead it is

*** Error in `w2wc': free(): invalid next size (normal):
0x0257c490 ***
*** Error in `w2wc': free(): invalid next size (normal):
0x025805f0 ***
Abort

Anyway, those errors happen with the version of wien2wannier included
in Wien2k 14.2, which I assume you are using.  With the current
development version, I get no error.

Could you try the development version and report back if the error is
fixed?  If so, could you also check if the results make sense?  I only
tested if w2wc runs without error.

To do this, go to https://github.com/wien2wannier/wien2wannier and
clone or download the repository (there is a green button for that).
When you have that, go to the wien2wannier directory

$ cd wien2wannier-master

and make and unpack a “dist” tarball

$ make wien-dist
$ tar -xvf wien2wannier-*-wiendist.tar.gz

Now I suggest you copy your original Wien2k directory (below, `wien2k')
and replace it with a copy.  This should ensure that the new
executables will be in your path.

$ cp -r wien2k wien2k-new-w2w
$ mv wien2k wien2k-old
$ ln -s wien2k-new-w2w wien2k
$ cd wien2k-new-w2w

There, overwrite the wien2wannier files and recompile

$ tar -xvf
../wien2wannier-master/wien2wannier-*-wiendist/wien2wannier-*-expand-in-wienroot.tar
$ ../wien2wannier-master/compile_wien2wannier.sh

To make sure that you are running the new versions, you can do

$ ls -ld $(dirname $(which w2w))


Elias


PS: Strangely, I have been unable to find your original post in the
archive http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/,
though the answers to it are there.



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] Error in wien2wannier for spin orbit coupling case

[Elias Assmann]

Dear Niraj Aryal,

Sorry for the delayed reply.  I will give my two Euro cents on your
report below.  If you have solved the problem in the meantime, please
tell us what it was.

On 06/15/2016 06:37 AM, Niraj Aryal wrote:
> The crystal I am working is Zr2Te2P which has rhombohedral lattice
> structure and has inversion symmetry. First I performed spin polarized
> with spin orbit coupling DFT calculation and as per the direction in the
> manual of w2w, I performed following steps:
> 
>  ->prepare_w2wdir dft_dir wannier_dir
> 
> ->cd wannier_dir ; then init_w2w
> 
> -> x lapw1 -up -p ; x lapw1 -dn -p
> 
> -> x lapwso -up -p
> 
>  -> x w2w -up -so -p

This appears to be correct.

> /forrtl: severe (39): error during read, unit 9, file wannier.vectorsoup_1/

This is not a lot of information to go by.  Are there no other messages?

Does the same thing happen in a non-parallelized calculation?  (If
necessary use fewer k-points, smaller RKmax etc.)


Elias




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] wien2wannier

[Elias Assmann]

Dear Subhasis,

Sorry for the delayed reply.

On 06/20/2016 11:51 AM, Subhasis Samanta wrote:
> I want to plot the wannier f orbitals for Yb doped inverse
> spinel ferrite. I have performed the spin polarized calculation. Can you
> please give some suggestions how to choose the origin of in this system?
> The case.woutup file is written below.
> 
>  Final State
>   WF centre and spread1  (  1.043108,  1.049474,  1.086064 )
>   WF centre and spread2  ( -0.999792, -1.018269, -1.070017 )
>   WF centre and spread3  (  0.995676,  1.038278,  1.047774 )
>   WF centre and spread4  ( -0.72, -0.32,  4.170776 )
>   WF centre and spread5  ( -1.038806,  3.101160,  3.106850 )
>   WF centre and spread6  ( -2.085413, -0.43,  2.085452 )
>   WF centre and spread7  (  0.000261,  0.14,  4.170773 )

Without knowing the lattice parameter, I cannot tell what these numbers
mean in fractional coordinates.  But anyway, notice that the centers
have both positive coordinates (which would be in the home unit cell)
and negative coordinates.

To choose one window to plot them all, make sure that all the centers
are contained in the window, plus some room around them to cover all the
relevant features of the WFs.  Of course, you are also free to use
different windows for the different functions.  This may be a good idea
if you have a large unit cell.

If you go on to transform your .psi{nk,arg} files to .xsf files, the
results may also depend on whether you have used the Wannier90 options
‘write_xyz’ and ‘translate_home_cell’.

Hope this helps,

Elias




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] Wien2kwannier with SOC (Spin-polarised case)

[Elias Assmann]

On 05/26/2016 02:14 AM, Guanxiong Qu wrote:
> I successfully projected the orbit following your suggestion. 
> However, I was a little confused that I didn’t turn on the “Spinnor” 
> option in the Case.win file.

All the ‘spinors’ option does is set the number of electrons per state
to 1 rather than 2 (W90 UG 2.4.8).  I am not sure where exactly that
setting becomes relevant; in some of the postprocessing tools, I am
sure.  For the Wannier projection itself, the occupation is
irrelevant.

> Why didn`t I need to turn on the Spinor option in Wien2kwannier?

Let me emphasize that ‘spinors’ is an option of Wannier90 (in the
‘.win’ file, as you said) and has no effect on wien2wannier itself.

> As was said in wannier tutorial, the wannier function should be 
> spinors, when projecting spin-orbit coupled orbits.  Further,
> without case.spn file (companied with spinors projection), I can not
> plot the band structure in spin colors.

We do not have ‘.spn’ files in Wien2k (yet), so spinor projections,
spin-projected band structure, an so on are out of reach for now.
However, I think it would not be too hard to construct it.  For the
record, this is a separate issue from the ‘spinors’ option.


Elias



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] Wien2kwannier with SOC (Spin-polarised case)

[Elias Assmann]

On 05/16/2016 01:13 PM, Guanxiong Qu wrote:
> I wonder if anybody could tell the correct work flow for SOC case on 
> wannier calculation through Wien2kwannier interface.

Here is the general work flow in 14.2 with so and sp; without sp, run
only one ‘x lapw1’ and leave out the ‘-up’ options everywhere.  In your
case (Fe sp), it should apply as written.

$ prepare_w2wdir W
$ init_w2w -up
...
> findbands -so -up -all -1 1 (13:30:56)

‘findbands’ should report “2*N” bands in the interval, i.e. twice as
many as you would expect in the non-so case.

> write_inwf -f W (13:31:01)
...
> minimal and maximal band indices [Nmin Nmax]?

Name the 2N bands found above.

> next proj. (6 to go; Ctrl-D if done)? 1:dt2g

In the simplest case, you will have two identical blocks of N
projections each.

added 3 projections: 2:dxy,dxz,dyz
> next proj. (3 to go; Ctrl-D if done)? 1:dt2g
added 3 projections: 2:dxy,dxz,dyz

--> 6 bands, 6 initial projections
...
$ x lapw1 -up; and x lapw1 -dn; and x lapwso -up
$ x w2w -so -up; and x w2w -so -dn
$ x wannier90 -so

This is assuming that the initial projections for the ‘up’ and ‘dn’
parts are identical.  In 14.2, there is only one ‘case.inwf’ file by
default, so if you need ‘up’ and ‘dn’ to be different, you have to edit
‘{up,dn}w2w.def’.  The next version will have separate
‘case.inwf{up,dn}’ by default.

HTH,

Elias

PS: I added as much to the wien2wannier wiki (our first page!):
https://github.com/wien2wannier/wien2wannier/wiki/wien2wannier-with-SOC

PPS: The above is written to work in the shell that I use
.  If yours is different, you may need to adapt
the ‘; and’ parts.



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] Weird wannier functions coming out from wien2wannier

[Elias Assmann]

On 04/06/2016 06:14 PM, Pablo Villar Arribi wrote:
>> 3. Did you check if the real-space representation of the WF is real
>> (i.e., case.psink should be 0 or ±π up to numerical precision)?  Because
>> the xsf format does not accomodate complex numbers, wplot2xsf by default
>> writes |w(r)|² sgn Re w(r).  This could lead to “strange” isosurfaces if
>> there is a phase.
> 
> When I open the *psink files I see something like this (this is only the
> head of the file)

Sorry, I see I made a mistake there — it is case.psiarg that gives you
the phase, case.psink is the magnitude.

> "rephase case" but it does not work, I get an error of the type

Unfortunately, ‘rephase’ is broken.  There is a “dephasing” option in
case.inwplot (inherited from lapw7), which has also been deactivated,
but may be reactivated next release.  For a quick fix, you could modify
wplot2xsf_lapw, l. 384 ff.

if args.do_phase:
verbalize("   reading `"+psiarg.name+"'")
data *= np.sign(np.cos(np.fromfile(psiarg, sep=' ')))
psiarg.close()

if args.do_sqrt:
data = np.sqrt(data)

You can easily add a global phase,

data *= np.sign(np.cos(np.fromfile(psiarg, sep=' ') + PHI))

should work.  Or try the -abs option to ignore the phase.

> I've been using the 14.1 version, not 14.2. Should I change to 14.2 or
> is it OK with 14.1?

In general, yes, I would recommend that users of wien2wannier use
version 14.2.  However, I think the differences in wplot are minor.
Rather, I would recommend that you try with the current version from
GitHub (or wait for the next Wien2k release which, rumor has it, should
not be long).


Elias




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] Question regarding wien2wannier for wannier.spn file

[Elias Assmann]

On 03/17/2016 02:54 PM, Santu Baidya wrote:
> There is module kpath to plot the energy bands coloured by the 
> expectation value of the spin along [001]:
> 
> " Error: Problem opening input file wannier.spn Error on node 0:
> examine the output/error files for details"
> 
> Can anyone please help me to overcome this problem. Does
> wien2wannier support spin as a function of k vector information to
> write?

Short answer: no.

In general, the new postw90 offers quite a lot of functionality that,
unfortunately, wien2wannier/Wien2k does not support.

As for case.spn specifically, the Wannier90 user's guide tells me:

  write_spn – Set to .true. to write out the matrix elements of S
between Bloch states (non-collinear spin calculation only).

I am not sure I understand why that would be useful only for a
non-collinear calculation.  I do not think that Wien2k provides this
data directly, but it seems like it should be doable (with SOC, of
course).


Elias

-- 
Elias Assmann

Wien2Wannier: maximally localized Wannier functions
  from linearized augmented plane waves

<http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/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

Re: [Wien] Regarding DFT+U Results

[Elias Assmann]

On 02/24/2016 02:58 PM, Paresh Chandra Rout wrote:
> I have done it correctly or not. Any help would be highly
> appreciated . Here I am attaching the following files case.inorb,
> case.indm,case.outputorbup,case.outputorbdn.

You explicitly put a U of 0 on atoms 6 and 7.  Is that intentional?

Other than that, it will take more of an expert than me to find
something in these files …


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] optic program crashed

[Elias Assmann]

On 02/18/2016 04:31 PM, Dr. K. C. Bhamu wrote:
> [1] 1371
> ssh: connect to host nid01855 port 204: Connection refused^M

This is the relevant message, I think.

Two guesses what could be happening:

 1. You have not set up the passwordless ssh login that k-parallel
Wien2k requires (try the command ‘ssh-copy-id’).

 2. You are on a cluster that permits ssh only to nodes that are
allocated to your job but you are trying to connect to other nodes (e.g.
due to a stale ‘.machines’).

Actually, my guess is no. 2 since no. 1 should show a password prompt
instead.  Do any k-parallel jobs work?


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] Weird wannier functions coming out from wien2wannier

[Elias Assmann]

Pablo,

On 02/15/2016 05:17 PM, Pablo Villar Arribi wrote:
> Any ideas on why this different behaviour between Wien2k and Quantum
> Espresso? Could it be due to the intrinsic diferences between an
> all-electron code and a pseudopotential code in terms of their Bloch
> states, which are used as a starting point for Wannier90?

I think it is much more likely to be a problem in wplot [unfortunately
for me :-)].  In particular, it sounds like you have a good projections,
but something is going wrong in the plotting itself.

Here are some suggestions:

1. By way of general advice, I suggest to start with a coarse r-mesh
(e.g. 10×10×10 points) and a larger plot region than you think you need,
to figure out the correct plotting window.  You said you checked this,
but it can really be tricky, what with different settings both in
Wannier90 (translate_home_cell) and wplot2xsf (-noshift).  Once you have
that, you can scale up the precision.

2. All parts of the calculation (mainly, case.chk and case.vector) have
to match.  If, for some reason, you ran another lapw1 after wannier90,
wplot will not work.  Therefore, it sometimes helps simply to repeat the
whole procedure (lapw1 && w2w && wannier90 && wplot), just to be sure
that there is no inconsistency.

3. Did you check if the real-space representation of the WF is real
(i.e., case.psink should be 0 or ±π up to numerical precision)?  Because
the xsf format does not accomodate complex numbers, wplot2xsf by default
writes |w(r)|² sgn Re w(r).  This could lead to “strange” isosurfaces if
there is a phase.

4. If the above does not help and you just want your plots, it could be
an option to simply use the ones from Quantum Espresso.  In my view,
real-space WFs are a qualitative rather than a quantitative tool (unless
you are very careful …), therefore it could be okay to use the QE
real-space WFs as a visualization for your Wien2k WFs, as long as H(R)
and the band structure are “the same”.  Obviously, this depends on what
you want to do with them.

5. On the other hand, if you want to get it right with Wien2k (and
possibly help me find a bug), the next thing I would try is a different
version of wplot (I am assuming that you tried the one included in
Wien2k 14.2).  This is one part of the package that I changed quite a
lot recently and invariably, bugs creep in.  You could either try the
newest version from GitHub (caveat: the format of case.inwplot changed)
where some of those bugs are fixed; or the  “old” one (0.97, available
at
http://www.ifp.tuwien.ac.at/forschung/arbeitsgruppen/cms/software-download/wien2wannier/),
which has a different set of bugs.

6. Relatedly, what crystal structure do you have?  Wien2Wannier has had
some problems with more “difficult” lattice types in the past.


Good luck,

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

Re: [Wien] plot wave function

[Elias Assmann]

On 01/15/2016 03:20 AM, Yundi Quan wrote:
> I used lapw7 to generate case.psink which contains the wave
> function on a grid. Is there a program available to plot the data?
> I know that the wien2wannier has wplot2xsf routine which converts
> the case.psink and case.psiarg files into case.xsf compatible with
> xcrysden.

Have you tried using wplot2xsf?  I haven't, but as far as I know, the
formats output by lapw7 and wplot are the same, or at least very
similar, so there should be a good chance you can use wplot2xsf.

One important thing to keep in mind is that wplot2xsf discards the
phase except for the sign.

Otherwise, lapw7 should print the number of points per direction and
the order (x changes fastest, z slowest, I believe).  Knowing this,
you could re-order them so that your visualization program of choice
understands.  Another alternative would be to use a manual grid
(case.grid file) where the order is up to you.

HTH,

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

Re: [Wien] case.qtlup/dn files were empty

[Elias Assmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/21/2015 06:51 PM, venkatesh chandragiri wrote:
> I have done parallel SCF calculations in a cluster (the
> case.vector_* files are created in a separate scratch folder) and
> later I was copied the entire folder into a local computer due to
> memory issues at cluster. After some days, I was copied the entire
> folder into cluster (the same case.vector_* files are also copied
> into scratch folder into the cluster ). Although, the x lapw2
> -up/-dn -qtl -c -p runs smoothly without error (writing shell
> script for generating .machines file), the case.qtlup/dn files does
> not contain any data (0 bytes). Kindly, let me know the possible
> error in the present DOS calculation.

I do not know what would cause that, but note that `x lapw2 -qtl' is
not itself parallelized; `-p' means only “read parallel vector files”.
 This means you do not need `.machines'.  On the other hand, it reads
`.processes' to see how many vector files there should be, so if you
deleted that, that might have caused the error.

> I also tired to run the "x lapw2 -up/-dn -qtl -c -p " by keeping
> all the case.vector_* files into same parent folder. This gives
> also give error without running x lapw2. But, this error is
> connected to location of case.vector_* files which is not seen the
> earlier run.

You probably need to `set SCRATCH=./' in this case.  Include the error
messages next time.


Elias

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJWeRahAAoJEE/4gtQZfOqPKH8P/0xjS1Oh3N1VZO6AQ6Kia0a/
KiSSulv3B2+8wGpsVJHI30xl1RhSF2llZCaEBXHLGX/rHadNxyVILMVcWvfr/ba0
Sl0L3Aa1FzrLVVZJOIO62tQWPQc6MwLmE8fios4uZUb/tOxYdpzH/omzLpyDt8A3
HIMPhOm8fsIWB3o+9x/d6S48G//zs7JujLCmwwiH3BB4qcYJd3yV5Q8tNo4FVGdP
wL/FvdGobLCVPU6QYI/dq4q3Uho6SGrJC0f+cgZkw+8G0AVhf2ISRzFlgbMaqJqQ
iYphe7hReaxiH3UIKO1LDYIZSif1X7N18Im5V+BUrErg8GRmGwFy7a/MiwWT51Ok
McFOOXl7RiyVJQglty9TuLNnIKa4lXdnMxHaGRIMSO8ppEVnlca47Sitlxy45JxJ
qeGEEa9bwaK9sqRjjO22Pwn7Lqew8Ds4f/s60mBbYb0vdbvHPM+W60ybQOJRQ3o4
QUCZ58HuuNfSbgPACx2WRLE69wgGSCkU+Ll0KiEhGbkQhjS61NyyAK1kjVPv9Ywy
qecv/Y7xURfibwMWpYymDajLTAgI21vsmZyZg3vfAxqKn1xg0yZW5l3uh9XHi9lI
DS7F4o8m+x/XOtfqyYQBA6yNvmQHItZxZUOJ5qvQWGDbpT+ZdCJ4yh2VUkmV8Y0D
XPStXYHeEj9tNeSWtddt
=Aqg5
-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] Spaghetti_ene

[Elias Assmann]

On 12/18/2015 08:27 AM, Adam Bakheet wrote:
> I am running a bandstructure calculations on doped Cax(PO4)y compound.
> After x spaghetti I got a distorted bandstructure plot. I checked the
> case.spaghetti_ene, and the last two columns of some bands appeared
> merged together.
> Please how can fix this problem? Your help is appreciated.

That sounds like the energy numbers got “too large” for the Fortran
format they are printed with (or rather, so large that they only just
fit into the format).  On my installation, a line from
case.spaghetti_ene looks like this:

   0.41296   0.41296   0.41296   0.0 -48.30905

So apparently you have three-digit negative energies (or even four-digit
positive ones!).  If this is correct, some suggestions:

1. Do you really want those large energies?  Otherwise, just change the
energy range.

2. Change the format in the spaghetti source to include a space between
the fields.

3. Parse the file in a way so as to account for the fixed format, e.g.
using a standard Unix tool (see ‘man cut’):

   cut --output-delimiter=\  -c 1-40,41- case.spaghetti_ene

4. Dirty hack: Run spaghetti in Rydberg mode instead of eV.


    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

[Elias Assmann]

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

Re: [Wien] :FCHECK in Wien2k 13.1 vs. 14

[Elias Assmann]

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

[Wien] woptic: optical conductivity from Wien2k+many-body calculations

[Elias Assmann]

Dear Wien2k users!

I am happy to announce the release of *woptic* <http://woptic.github.io>,
a package to calculate the optical conductivity, dc conductivity, and
thermopower in the Wien2k ecosystem.

Woptic builds upon the optic and wien2wannier modules of Wien2k,
combined with Wannier90 and (optionally) an external many-body
calculation, to work with the dipole matrix elements from optic in a
basis of maximally-localized Wannier functions.

Interesting features include:

 * woptic can incorporate a local self-energy Σ(ω) from a many-body
   calculation such as dynamical mean-field theory (DMFT)

 * it employs an adaptive k-integration scheme to sample the Brillouin
   zone efficiently

 * it uses the full dipole matrix elements, rotated to the Wannier
   basis

 * transitions beyond the Wannier orbitals can be included in an
   “outer window”.


For more information, and to download the code, visit
<http://woptic.github.io>.

Since the code is still new, feedback is especially welcome, either
through the GitHub page <https://github.com/woptic/woptic>, or by
e-mail.

For the theory behind woptic and a description of the algorithm see
the preprint

  woptic: optical conductivity with Wannier functions
  and adaptive k-mesh refinement

  E. Assmann, P. Wissgott, J. Kuneš, A. Toschi, P. Blaha, K. Held
  <http://arxiv.org/abs/1507.04881>


Note: Long-time users of wien2wannier may know woptic as a part of
early releases of that package.  Since then, it has been much expanded
and updated to work with the current version of wien2wannier.


    Elias Assmann
for the woptic authors

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

[Wien] :FCHECK in Wien2k 13.1 vs. 14

[Elias Assmann]

r atom5 spin 1)  0.0008169
 :DIS  :  ( 0.0009736 for atom8 spin 2)  0.0006944
 :DIS  :  ( 0.001 for atom5 spin 1)  0.0007013
 :DIS  :  ( 0.0009991 for atom7 spin 1)  0.0003925

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
 :MIX  :   MSE1a  REG: 1.88E-06  GREED: 0.120  Newton 1.00  0.01
 :MIX  :   MSE1a  REG: 2.17E-06  GREED: 0.083  Newton 1.00  0.01
 :MIX  :   MSE1a  REG: 3.19E-06  GREED: 0.050  Newton 1.00  0.01
 :MIX  :   MSE1a  REG: 4.08E-06  GREED: 0.034  Newton 1.00  0.03
 :MIX  :   MSE1a  REG: 5.17E-06  GREED: 0.022  Newton 1.00  0.00
 :MIX  :   MSE1a  REG: 5.20E-06  GREED: 0.021  Newton 1.00  0.06
 :MIX  :   MSE1a  REG: 7.51E-06  GREED: 0.018  Newton 1.00  0.14
 :MIX  :   MSE1a  REG: 4.52E-06  GREED: 0.017  Newton 1.00  0.10

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
 :MIX  :   MSE1a  REG: 1.59E-06  GREED: 0.030  Newton 1.00  0.18
 :MIX  :   MSE1a  REG: 2.61E-06  GREED: 0.042  Newton 1.00  0.29
 :MIX  :   MSE1a  REG: 3.72E-06  GREED: 0.057  Newton 1.00  0.54
 :MIX  :   MSE1a  REG: 3.58E-06  GREED: 0.093  Newton 1.00  0.46
 :MIX  :   PRATT  REG: 1.00E-06  GREED: 0.025
 :MIX  :   MSR1   REG: 1.00E-06  GREED: 0.050  Newton 1.00  0.05
 :MIX  :   MSE1   REG: 1.60E-06  GREED: 0.050  Newton 1.00  0.22
 :MIX  :   MSE1   REG: 2.41E-06  GREED: 0.055  Newton 1.00  0.40

On 11/03/2015 02:47 PM, Laurence Marks wrote:
> I am not sure exactly what the problem(s) were, but from you case.scf it
> was "right" that there were Warnings
> 
> 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.
> 
> 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.



-- 
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] gather_energy

[Elias Assmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/25/2015 02:11 PM, emami seyyed amir abbas wrote:
> Dear users
> 
> I am trying to construct the case.energy as an input file for
> BlotZtraP. My normal calculations were performed in parallel. Now I
> want to use gather_energy.pl to generate case.energy. Now, how can
> i run this program. What is the command for doing this?

I do not remember the usage of Boltztrap, but if you run ‘x joinvec’,
that should give you a combined .energy file.

HTH,

Elias


-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBAgAGBQJWVenWAAoJEE/4gtQZfOqPdicQAKIJ5lm/THr1HRAwiuY8sO2u
/QGR5cRP1GM+Zlvy3nAooASY/C78F5wex0sjMvy1qikw6rBfQrf9B0XJxpY+wd1j
NmGGrFExiIt7Qumf3zI0XSPmwzYOa14C/h9YQrhw8Qv+T+hed5OR8CQcaYIzfcRO
3SlTFwnM/p3dcJ84d/xmSAVAOuw07BWgQwarLmoQXTgMFfMpHO7JZ+qP4CoXsLOU
88ZQLkVQ6AdGsQFVrrGeSDZ+nO0zGrEyE51kFW/z7tFRB4Nip2OY2aReWRRigWPd
0BV/0TiG98v+DzmaUZ8a38O9dRV0ciekhJ4S/GHwxPZEw4WHfhYABOnERABpzTue
i4nFuOYPIh6I6u5/eVWj9ffEio11fZJbvT7BcOKOV8Gq6EZaGx2xAntdvNTOxJG6
HdT5sYzSPTm32a4uqW4RyiaCs8JEomBJH58SqUnXm2kEbwM1V2fK/3kpQpEk+jrk
en2J9uHrq7wB7K84RTJyGDE6SZh9YpExPik8YmEbxDHswhHJ++LqHk64SkiH/VvN
kjR3lg22ev6bGM4XEXdpr873NL6PgLXtpzfSGRejiBlG4b7caEYjCW0woKyNV2Kb
1zDsNXiaAnrtTvDIB4FOL+BuxjbVThUO6To7yCiHQS7EaJgEXNBiwcNNU7UfirA0
gukYpFPJ33V3QgLzPgNR
=dbjS
-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] “Empty” states are populated during SCF

[Elias Assmann]

Hi List,

I have a big calculation running with MSR1a (one of those oxide surfaces
I asked about earlier).  After a while, it stopped due to touching
spheres, so I used clminter with `setrmt -r 3' and restarted.  After 130
more iterations, the calculation stops with a QTL-B error

   QTL-B VALUE .EQ.9.42627   in Band of energy   -0.21251   ATOM=
129   L=  3
:WARN : QTL-B value eq.  29.45 in Band of energy  -0.35946  ATOM=  134
L=  3

Now, atom 134 is a La and its f-states should be *empty*.  And so they
were for most of the calculation, but ~30 iterations after clminter,
they start to be full (they pretty much jump from 0 to 7/spin, here is a
plot: <http://i.imgur.com/DZavhiq.png>; the scale goes to 7).

This actually runs (with some oscillations) for ~100 iterations, then
the QTL-B error happens.

What could be the cause of this?

The R-MT for La is 2.28, before the clminter it was 2.35.  ‘scf1’ section:

  ATOMIC SPHERE DEPENDENT PARAMETERS FOR ATOM  La lo
:e__0134: OVERALL ENERGY PARAMETER IS0.2434
  OVERALL BASIS SET ON ATOM IS LAPW
:E0_0134: E( 0)=   -2.9884   E(BOTTOM)=   -3.787   E(TOP)=   -2.190  4
5   177
 APW+lo
:E0_0134: E( 0)=0.6434
 LOCAL ORBITAL
:E1_0134: E( 1)=   -1.5836   E(BOTTOM)=   -2.710   E(TOP)=   -0.457  3
4   218
 APW+lo
:E1_0134: E( 1)=0.6434
 LOCAL ORBITAL
:E2_0134: E( 2)=0.2434   E(BOTTOM)=   -0.980   E(TOP)= -200.000  2
-1   175
 APW+lo


Thanks,

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

[Elias Assmann]

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

[Elias Assmann]

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] segfault in mixer

[Elias Assmann]

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

[Elias Assmann]

-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

[Elias Assmann]

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

[Elias Assmann]

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

[Elias Assmann]

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] passing env variables to lapw1 and 2

[Elias Assmann]

-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] RMTs changing on their own?

[Elias Assmann]

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

[Wien] RMTs changing on their own?

[Elias Assmann]

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

[Elias Assmann]

-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

Re: [Wien] x w2w error in WIEN2k.14

[Elias Assmann]

-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?

[Elias Assmann]

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?

[Elias Assmann]

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] x w2w error in WIEN2k.14

[Elias Assmann]

-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

[Elias Assmann]

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] x w2w error in WIEN2k.14

[Elias Assmann]

-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

[Elias Assmann]

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

[Elias Assmann]

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

[Elias Assmann]

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

[Elias Assmann]

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] berryPI

[Elias Assmann]

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] berryPI

[Elias Assmann]

-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] CHARGE DENSITY --> TOTAL CHARGE

[Elias Assmann]

-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] time difference among nodes

[Elias Assmann]

-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] time difference among nodes

[Elias Assmann]

-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] time difference among nodes

[Elias Assmann]

-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

[Elias Assmann]

-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] Serial installation of WIENNCM package: we need guru!

[Elias Assmann]

-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!

[Elias Assmann]

-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] berryPI code

[Elias Assmann]

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] berryPI code

[Elias Assmann]

-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

[Elias Assmann]

-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

[Wien] Kinetic Energy for a subset of bands

[Elias Assmann]

-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] initial projections with spin-orbit coupling for wien2wannier?

[Elias Assmann]

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] initial projections with spin-orbit coupling for wien2wannier?

[Elias Assmann]

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

Re: [Wien] (no subject)

[Elias Assmann]

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] wien2wannier interface

[Elias Assmann]

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

[Elias Assmann]

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

[Elias Assmann]

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

[Elias Assmann]

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

[Elias Assmann]

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

[Elias Assmann]

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

[Elias Assmann]

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] wien2wannier interface

[Elias Assmann]

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 and gfortran for complex cases

[Elias Assmann]

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] (no subject)

[Elias Assmann]

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] Some questions about the vec2ascii program

[Elias Assmann]

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] Some questions about the vec2ascii program

[Elias Assmann]

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

[Wien] wien2wannier and gfortran for complex cases

[Elias Assmann]

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

[Elias Assmann]

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] DMFT

[Elias Assmann]

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