ur
consideration.
with regards,
On Sun, Jul 2, 2017 at 1:32 AM, Gavin Abo mailto:gs...@crimson.ua.edu>> wrote:
I'm not seeing anything that is noticeably problematic with
your case.indmc and case.inorb files. They seem fine.
The "error in vor
Forwarded Message
Subject:Re: [Wien] error in vorb
Date: Sun, 2 Jul 2017 20:02:22 +0200
From: Peter Blaha
To: Gavin Abo
Do "lse" (ls -als *.error)
You should get a list of all error files.
Is there a orb.error ?? (a leftover when you c
Has the use of EECE changed in WIEN2k 16.1 and not been documented?
I believe I have specified case.in0 according to the usersguide:
username@computername:~/wiendata/test$ cat test.in0
TOT XC_WC (XC_LDA,XC_PBESOL,XC_WC,XC_MBJ,XC_REVTPSS)
NR2V EECE IFFT (R2V)
32 32 322.00 1m
username@computername:~/WIEN2k$ sed -n 1p siteconfig_lapw
#!/bin/csh -fx
username@computername:~/WIEN2k$ ./siteconfig
unalias rm
set name = ./siteconfig
set bin = .
if ! ( -d . ) set bin = .
cd .
set bin = `pwd`
pwd
alias define_installdate date >$bin/WIEN2k_INSTALLDATE
alias wait echo "";echo "
Regards
Am 04.07.2017 um 17:44 schrieb Gavin Abo:
username@computername:~/WIEN2k$ sed -n 1p siteconfig_lapw
#!/bin/csh -fx
username@computername:~/WIEN2k$ ./siteconfig
unalias rm
set name = ./siteconfig
set bin = .
if ! ( -d . ) set bi
What about L2NTV_V.outputorbup, any problematic messages seen in it
similar to "Conflict in atom orb. number" [1]?
[1]
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg07531.html
On 7/6/2017 8:46 AM, shamik chakrabarti wrote:
Dear Gerhard,
I have done 0% redu
It has been awhile such that I don't remember, but I believe it was
recommended not to use runsp_lapw with "-s lapw1 -e lcore" anymore as
seen inthe post at [1] even though you still find a reference to it in
the WIEN2k 17.1 usersguide under the optic section "8.17.1 Execution" on
page 177 [2].
atoms for which SO is switch
off; atoms
Thank you in advance.
Chami
On Thursday, July 6, 2017 12:35 PM, Gavin Abo
wrote:
It has been awhile such that I don't remember, but I believe it was
recommended not to use runsp_lapw with "-s lapw1 -e lcore" anymore as
seen inthe po
rom case.inso for doing optics.
On 7/6/2017 2:14 PM, Gavin Abo wrote:
If you are editing case.inso by hand, for NX and NX1, the X needs
replaced by a number. Though, I would think that you would want to use
the nice and easy to use interactive initso script in the terminal. [1]
[1]
h
But now when "x opticc -so -orb -up " it keep crashing. I do not have
case.vectorsoup file really. How I create it.?
ERROR:
'OPTIC' - can't open unit: 10
'OPTIC' - filename: /scratch/10820461.yak.local/SCFsp-U-SO.vectorsoup
'OPTIC' - status: OLD form: UNFORMATTED
In "Table 4.
n "opticc" and
"optic -c". Do we really need to add "-c" with optic or the latest
version of Wien2k will automatically take care about "-c" switch?
Regards
Bhamu
--------
Dr. K. C. Bhamu
(UGC-Dr. D. S. Kothari Postdoc Fellow)
Department
A Hubbard U does not make much sense in a non spin polarized
calculation - and I seem to recall that this is mentioned in the UG.
Perhaps thinking of run_lapw?
username@usernamecomputer:~/Desktop$ run_lapw -h | grep orb
hup: Command not found.
-so ->run SCF including spin-orbit coupling
"x lapwso -up" creates uplapwso.def with WIEN2k 17.1. If your using
WIEN2k 14.1 as mentioned at
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16027.html
it seems that version creates lapwso.def instead.
Using "./" is not a requirement, I just suggested trying it. That is
be
Do you have this:
username@computername:~/wiendata/test$ run_lapw -orb -dm
hup: Command not found.
ERROR: option -orb does not exist !
ERROR: option -dm does not exist !
As was posted recently, a non-spin polarized calculation (run_lapw) does
not have -orb [1].
For DFT+U, you have to use eith
There may be two problems.
The first problem could be with wien2wannier. The WIEN2k 17.1 package
seems to have a version 1 write_inwf_lapw file:
username@computername:~/Desktop$ cd $WIENROOT
username@computername:~/WIEN2k$ sed -n 29p write_inwf_lapw
__version__ = "$version: v1.0.0-273-gaf9ce6
An additional comment:
You might consider upgrading from 13.1 to the latest WIEN2k version
(17.1) because of the dynamical Emax in case.in1(c) [1].
[1]
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14937.html
[2]
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.a
I looked at the Landau quantization Wikipedia entry [1]. However, it was
not clear to me whether this was needed to describe a system with moving
spin (e.g., oscillating spins).
If so, I think the answer to your question it that your not missing
anything and WIEN2k does not have an external ma
Sounds like that fixed the problem for you [1]. If not, do you have
NOCALC instead of CALC in case.intrans [2,3]?
[1] gather_energy.patch:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg13418.html
[2]
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg04755.html
There was a previous post about the orbital labels in case.win. You
should able to view the post at the following link:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12320.html
In the NEWS file [1], I see that the latest Wien2Wannier included with
WIEN2k 17.1 contains sever
Did you take into account the multiplicity:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg01379.html
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg07956.html
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg05127.html
On 7/30/2017 2:55 AM, shayml
As mentioned at
http://qe-forge.org/pipermail/pw_forum/2016-May/109991.html
Maybe this happens when VBM, CBM, and Efermi are the same, and Egap is 0.
In your case.outputtrans, are the values like that under the "OUTPUT
from BANDANA" section?
If so, I think it was mentioned at
http://cms.mpi
Currently too lazy to check, are the data values x y z div (where div is
the divisor)?
So (x y z)/div:
0.0. 0.0 0.0 0.0 => (0, 0, 0)/0 = undefined [1] <- If it is not giving a
divide by zero error [2], it sounds like the code is able to handle it
and may be setting any of these divisions to 0
sense here). Depending on the
method the 4th value is not used or is eg. a friction term for damped
newton dynamics.
On 08/04/2017 02:26 AM, Gavin Abo wrote:
Currently too lazy to check, are the data values x y z div (where div is
the divisor)?
So (x y z)/div:
0.0. 0.0 0.0 0.0 => (0, 0, 0)/
Maybe okay?
"Next to :GAP in the scf file there is a warning: if you use a proper
k-mesh. One always has to check this :GAP value and compare it vs. a
detailed bandstructure plot, identifying the position of VBM and CBM. If
the scf k-mesh is course or does not contain Gamma (shifted mesh), the
Refer to the post at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg11451.html
On 8/12/2017 7:13 AM, Walayat Khan wrote:
Dear Prof. Blaha and colleagues
I the user of WIEN2k. Now, I am doing SO coupling calculation on GeTe,
but in the first cycle I got error like
'FERMI' -
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg07551.html
On 8/15/2017 8:06 AM, prasad jayasena wrote:
Dear wien2k experts
I am trying to calculate the optical absorption spectrum of my sample.
I completed the SCF run with hubbard-U and spin orbital coupling in a
parallel calc
In [1], it says:
/In Refs. [77,82] we showed that a correct description of the band gap
and electric-field gradient (EFG) in Cu2O could only be achieved with
the hybrid functionals, while the resultsobtained with the LDA, GGA,
LDA+U, and mBJ methodswere qualitatively wrong./
In TABLE
Are you using the latest WIEN2k version? I think this gfortran error
only occurred in a older WIEN2k version:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg11575.html
On 8/30/2017 11:30 PM, mandeep hooda wrote:
Dear Wien2k users,
I am facing problems in DOS
Have you tried
cif2struct CH3NH3PbI3_cubic.cif
on a cif file for it? For example, the CH3NH3PbI3_cubic.cif at:
https://github.com/WMD-group/hybrid-perovskites/tree/master/2015_ch3nh3pbi3_phonons_PBEsol
On 9/4/2017 3:02 AM, AJAY SINGH VERMA wrote:
Dear Sir,
I have facing some problem to
If you are asking about fat band plotting [1,2], there is section
"3.11.5 Bandstructure with band character plotting / full lines" in the
WIEN2k 17.1 usersguide [3].
Spaghetti-primavera on the unsupported page [4] might also be of
interest for band character plotting.
[1]
http://www.mail-ar
There is likely a procedure(s) for what you want either in the WIEN2k
usersguide or mailing list. For example, see the post at:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg09389.html
If the QSPLIT in case.inq to 1 that Yundi sent doesn't give what you
want, I believe there i
DOS, not for the fat band structure
plotting.
Have I missed anything here?
Cheers,
Jianxin
From: Wien <mailto:wien-boun...@zeus.theochem.tuwien.ac.at>> on behalf of Gavin
Abo mailto:gs...@crimson.ua.edu>>
Reply-To: A Mailing list for WIEN2k users
mailto:wien@zeus.theochem.tuwien
The problem is that I want to know if it's possible to get a such
value of 0.05 MB for atomic magnetic moment for the AFM state of
vanadium sulphide in NiAs structure.
Correct me if I'm wrong, but I believe you are saying that you opened
the case.scf file in a text editor or did a "grep -e :
Perhaps the -ec 0.001 and -cc 0.001 are too large of values.
As I recall, to be well-converged, it is usually best to use about the
default values seen in the post [1] or WIEN2k 17.1 usersguide [2] as:
-cc 0.0001
-ec 0.0001
It sounded like about the default value for -ec was good unless
some
You might try checking the lapw2.error file. Does it show a problem with
the case.energy_1 file like in the post at:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg07963.html
If you have that same error, it might be that lapw1 failed in generating
the case.energy_1. There are
n runs well with 12 processors.
Can I ask why the linear tetrahedra method fails, and why the two k
points are missing?
Best,
Jianpeng
On Thu, Sep 7, 2017 at 9:17 PM, Gavin Abo <mailto:gs...@crimson.ua.edu>> wrote:
You might try checking the lapw2.error file. Does it show a
Does lapw0 exist in your WIEN2k directory (/home/sjana/WIEN2k_14.2)?
Maybe #PBS -V is needed [
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg15985.html
].
On 9/8/2017 1:42 AM, Subrata Jana wrote:
Dear All,
I am trying to run WIEN2k parallel. My shell script is looking like
PBS_NODEFILE:
awk '{print "1:"$1":1"}' "$PBS_NODEFILE" >>.machines
On 9/8/2017 2:20 AM, Subrata Jana wrote:
Hi Gavin Abo,
I change my job script as follows:
#
#!/bin/bash
#PBS -N wien2k
#PBS -o out.log
#PBS
I cannot recall if BerryPI works with Python 2.6. You can try it, but
maybe it doesn't work as section "8.2 BerryPI (Modern theory of
polarization)" in the WIEN2k 17.1 usersguide on page 149 has:
"It consists of a set of Python scripts (*requires* *Python 2.7* and the
NumPi library) and uses
ed to have it write the "machine names" after it. So
something like:
lapw0:gamma:2 delta:2 epsilon:4
However, you are having it write:
lapw0:granularity:1
Thus, the error about it not being able to find and connect to a
hostname called "granularity".
On 9/8/2017 2:41 AM, Subra
A brief view in XCrySDen of
Spacegroup: 221_Pm-3m
a = b = c = 6.3391
alpha = beta = gamma = 90
Pb (0, 0, 0)
I (0, 0.072, 0.5)
C (0.426, 0.426, 0.5) or (0.574, 0.574, 0.5)
N (0.627, 0.627, 0.5)
from the article titled "CH_3 NH_3 PbI_3 , A Potential Solar Cell
Candidate: Structural and Sp
In WIEN2k_14/SRC_BerryPI/BerryPI/Installation/readme.org, there should be:
* Dependencies
- WIEN2k (tested against 13.1 Release 25 June 2013) <- wien2k14
instead of 13.1 should be okay here
- WIEN2WANNIER (tested against v1.0-beta2)
- Python (tested against 2.7.4)
- NumPy (tested agains
For the (100), (101), (102), and (103), you could try a for loop in bash
[
https://stackoverflow.com/questions/24366305/how-to-write-a-bash-script-with-a-for-loop-that-creates-multiple-text-files-with
]; for example:
create_initso_inputfile.sh
--
What version of WIEN2k did this occur in?
Perhaps the error
syntax error near unexpected token `makescratch_lapw'
is due to the x_lapw script in older WIEN2k versions (such as 13.1 and
14.2) that used to use makescratch_lapw like for example coming during
the running of "x lapw1 -nmr" seen in
Some additional comments:
If you need an idea of about how computational intensive a WIEN2k
calculation might be for around 60 atoms per cell or more. The links
below and links in those posts might be helpful:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14035.html
https:/
It is of course recommended to use the latest WIEN2k version because of
the bugs found since WIEN2k 13.1 [
http://susi.theochem.tuwien.ac.at/reg_user/updates/ ].
If you want to leave the code untouched, you could try changing the
EDITOR line in your .bashrc file (note: remember to open and use
See option "[7] VARY A, B, C and Gamma (4D-case) (monoclinic lattice)"
in section "5.3.1 Lattice parameters (Volume, c/a, lattice parameters)"
on page 74 of the WIEN2k 17.1 usersguide [
http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf ].
Since there are so many degrees of fr
For the TiC example in the WIEN2k usersguide, jtype of 6 should
correspond to t2g.
What is 11 and 12 in your case? Not sure if 11 or 12 are too high of a
number and don't correspond to anything.
The "line switch" might need to be set to 2 in your case.insp and
sometimes I think the circle
I forgot, you may be right that WIEN2k can only plot one band character
at a time. To plot more than one, you might need to create your own
plot using a graphing software (like Origin, gnuplot, matlab, etc.) or
use Spaghetti-primavera. See the unsupported page for Spaghetti-primavera:
http:
I don't know everything about SO. You can read more about the
EFG-MATRIX is a NULLMATRIX error in the posts at:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg03446.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg04411.html
https://www.mail-archive.com/wien
Since I don't have a system with Rocks and qsub, I cannot be of much
help. That looks like it might be a Grid Engine error and not a WIEN2k
error, so you might get better help resolving that error on a Grid
Engine mailing list [1] or a Rocks mailing list [2].
It looks like qsub doesn't allow
In your traceback, there is:
#1 0x1090555ec in zlatd4_
/Users/hugstr/src/WIEN2k_17alpha_20170920_1100/SRC_lapwso/lap_bp.f:4427
On line 4427 of SRC_lapwso/lap_bp.f in WIEN2k 17.1, there is:
ABP(I1I)
In the same file,
Line 4212 has:
COMPLEX*16 ABP( * )
Line 4242-4243 has:
! ABP (inp
http://zeus.theochem.tuwien.ac.at/pipermail/wien/2003-October/000880.html
http://zeus.theochem.tuwien.ac.at/pipermail/wien/2003-October/000882.html
On 9/20/2017 4:44 AM, shamik chakrabarti wrote:
Dear wien2k users,
How to simulate the ground state energy of
Oxygen molec
ng the
struct file & the image (generated in vesta) of the structure
herewith this mail. I have replace z by 1.208/2 where 1.208 is the
bond length of O2 (O-O distance) molecule. Please look at the
structure & advice if the structure is correct or not.
with rega
composer_xe_2013.1.117 => This is update 1 of the 2013 composer xe [
https://software.intel.com/en-us/articles/intel-fortran-composer-xe-2013-release-notes
].
The MKL 11.0 update 2 release notes [
https://software.intel.com/en-us/articles/intel-mkl-110-release-notes ] has:
ScaLAPACK
Updated
I'm able to reproduce your new compile.msg errors below from hmsec.F in
WIEN2k 17.1 with the -Dold_scalapack switch.
This seems to be because the & (continue line feed) symbol is missing on
line 723 and 756. There also might be too many spaces in line 724.
Try placing that attached patch file
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg08516.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg08572.html
On 10/3/2017 3:14 AM, Krishnaveni. S wrote:
Dear Wien 2k users.
I am working on Heusler alloys.To plot electron density for 100 plane
is given us
It looks like you are using WIEN2k 14.2. Do you have the mixer write
patch applied:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg13760.html
There might have been other bugs too [
http://susi.theochem.tuwien.ac.at/reg_user/updates/ ]. Have you tried a
new WIEN2k version?
Dear Jaro,
I thought the spin-polarized SO optic normalization was broken in older
versions of WIEN2k and was fixed in 17.1:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16011.html
Is it still broken?
Kind Regards,
Gavin
On 10/3/2017 4:30 PM, Jaroslav Hamrle wrote:
Hall
Below in your post, you have:
-L../SRC_lib -lopenblas -llapack
Looking at the following post:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg15090.html
It looks like you need:
-L../SRC_lib -llapack_lapw -L/opt/OpenBLAS/lib -lopenblas
On 10/3/2017 3:03 AM, Rajneesh Chaurasiy
Try a different ifort compiler version or a different compiler (such as
gfortran). That error is likely to be caused by a bug in the version of
the compiler that you are using:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14923.html
https://www.mail-archive.com/wien@zeus.th
n help more, please let me know..
With my regards
Jaro
On 04/10/17 16:40, Gavin Abo wrote:
Dear Jaro,
I thought the spin-polarized SO optic normalization was broken in
older versions of WIEN2k and was fixed in 17.1:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16011.html
I don't know if it helps or not:
I could be wrong, but I believe XCrySDen has a bug for the b-centered
monoclinic:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg06205.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12479.html
However, I haven't looked in
mittivity. But I have not tested non-magnetic
cases, I did it only for bcc Fe (sp+so).
Hoping it helps.
If I can help more, please let me know..
With my regards
Jaro
On 04/10/17 16:40, Gavin Abo wrote:
Dear Jaro,
I thought the spin-polarized SO optic normalization was broken i
Ok, your suggestion sounds good to me.
The WIEN2k 17.1 usersguide [1] states on page 177 in section "8.17 OPTIC
(calculating optical properties)":
"In spin-polarized cases with spin-orbit only one call to optic, joint
and/or kram (either up or down) is necessary, since the spins are not
inde
First, WIEN2k 14.1 is expected to essentially give incorrect results for
optical property calculations (because the normalization was not
correct). Thus, the bug reports:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16011.html
https://www.mail-archive.com/wien@zeus.theochem.
You may want to contact Prof. Dronskowski's group and ask if they are
doing any development of the COHP/COOP LOBSTER program for WIEN2k. As
it says "Other codes may follow…" on their website:
http://schmeling.ac.rwth-aachen.de/cohp/
If you are good at programming, you may want to ask them wha
I suspect that the LAPW0 error comes first before the case.rho_74
error. However, I could be wrong as I'm not that familiar with the
nlvdw calculations.
It would help a little to know where those error appear. The standard
output/error file from the job?
R2V files not present, which are re
See the Intel MKL Link Line Advisor:
https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor
In the "Select dynamic or static linking" drop down box, you could
select "Static" instead of "Dynamic".
On 10/10/2017 10:20 AM, Nacir GUECHI wrote:
Dear wien2k users,
I want to install
Your .machines file seems okay.
The error indicates that LAPW1 failed. Other than that, the error
message doesn't look much more helpful.
I'm guessing that is from the standard output/error file for the job.
What about the case.dayfile, *.error files, or hidden dot files [
https://www.ma
Enter in the terminal:
echo $WIENROOT
Does it return
/cluster/home/lokanath/lib/w215
or
/cluster/home/lokanath/lib/w217
Also:
echo $PATH
Does it contain:
/cluster/home/lokanath/lib/w215:/cluster/home/lokanath/lib/w217
when it should contain only the:
/cluster/home/lokanath/lib/w217
The
I don't remember. Probably all parameters are fixed except for one of
them, then this is repeated separately for each parameter:
A, B, C fixed with changing GAMMA value, then
A, B, GAMMA fixed with changing C value, then
...
B, C, GAMMA fixed with changing A value
"x optimize" or OrthoOpt prob
See eval on page 135 in section "7.8.3 Input" of the WIEN2k 17.1
usersguide [1] where it states:
"if efmod is set to TETRA, eval .ge. 100 specifies the use of the
standard tetrahedron method instead of the modified one"
If eval is 0.101, then it is less than 100. Whereas, if eval is 101,
th
For my comments, see below.
I got the point but I still have some doubts.
My system is half metallic. For -up it is metallic while for -dn
channel it is a semiconductor.
So in case of semiconductor, the value of tetra in case.in2/c could be
same
(TETRA 0.000 (GAUSS,ROOT,TEMP,TETRA
1. Another user had to calculate plasma frequency for a half metallic [
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg07695.html
]. So it is likely that you need to do it to.
2. Yes, you must recompile the optic package after replacing joint.f
because it is a Fortran source
I could be wrong, but I think you just need to take the sqrt(2) of each
plasma frequency:
2.074/sqrt(2) 2.074/sqrt(2) 1.264/sqrt(2)
then put them in case.inkram (not case.injoint).
You should be able to use multiple plasma frequencies in case.inkram but
don't forget to add a Gamma for drude v
Is Kf the radius to the fermi surface [1]?
If so, maybe you can extract it from a fermi surface calculation [2] using:
a) XCrySDen [3]
or
b) FSGEN [4]
I have also seen the PW91 GGA equation [5]:
kF = (3*pi^2*n)^(1/3)
In a terminal, if you do:
cd $WIENROOT/SRC_lapw0
grep TKF *
In the outp
As the error message tells you, it cannot find the dstart executable
file. Either you need to compile to create the file with siteconfig,
fix the WIENROOT (and/or PATH) variables in your .bashrc, or try the
pre-compiled executables (WIEN2k_17.1_executables.tar.gz).
---
Thanks Dr. Fecher.
Sorry, this might be due to my mistake in the post:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16609.html
where the lapw1 -dn should be added:
x kgen -so
x lapw1 -up
x lapw1 -dn
x lapwso -up
A silly mistake where I forget that both the lapw1 -up and lap
lids
01187 Dresden
Von: Wien [wien-boun...@zeus.theochem.tuwien.ac.at] im Auftrag von Gavin Abo
[gs...@crimson.ua.edu]
Gesendet: Sonntag, 22. Oktober 2017 00:42
An: wien@zeus.theochem.tuwien.ac.at
Betreff: Re: [Wien] why we need to divide plasma frequency by root(2)?
I could be wrong, but I t
27/2017 10:53 AM, Gavin Abo wrote:
Thanks.
So if understand correctly, the w_pl^2(up-spin) is what is outputted
in case.outputjointup for a spin-polarized spin orbit calculation by
line 859 of joint.f in the post:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16552.html
So,
Yes, the WIEN2k limitations page [
http://susi.theochem.tuwien.ac.at/reg_user/limitations/ ] lists that the
optic package doesn't work with RLOs.
On 10/27/2017 8:45 AM, Dr. K. C. Bhamu wrote:
Hii,
I saw it but is is not helpful. Out procedure differs in many ways.
Here the person is doing -s
For the 122 I-42d struct file at:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16579.html
Did you look at it in VESTA [
http://jp-minerals.org/vesta/en/download.html ] and compare it the
zinc-blende AFIII structure at the link of your previous post:
https://www.mail-archiv
The spacegroup 11 struct in the post
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16619.html
is likely slightly wrong for what you want to do.
Take the AFM III picture from your link in the post
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16630.html
and
All,
Just curious, has anyone heard if the new BoltzTraP2 package will remain
a private code or if it is just not ready yet for public release?
The BoltzTraP website
https://www.imc.tuwien.ac.at//forschungsbereich_theoretische_chemie/forschungsgruppen/prof_dr_gkh_madsen_theoretical_materials_
o implement
parallel BoltzTrap and whether a link to graphic (ps ?) could be mads
available.
With thanks,
Kamil
On Sat, Oct 28, 2017 at 10:15 PM, Gavin Abo <mailto:gs...@crimson.ua.edu>> wrote:
All,
Just curious, has anyone heard if the new BoltzTraP2 package will
rema
In WIEN2k versions older than 17.1, I think the advanced user could
directly modify WIEN2k_OPTIONS (or OPTIONS), then run siteconfig to load
the file and just do a save to propagate the settings to the Makefiles.
I think it might be with the parallel settings that the new
auto-generation in si
Did the VASP article use the pre-compiler flag -DNGXhalf [1], which is
used for large supercells and molecules with only 1 k-point (Gamma) and
is roughly twice as fast and uses half the memory [2]? As far as I
know, WIEN2k doesn't have a similar pre-compiler flag to this.
Or did they use Gamm
Feel free to correct me if I'm wrong, but I think Si and Ge have an even
number of electrons (or paired electrons).
For Si, 4 electrons in the 3s^2 3p^2. For Ge, 4 electrons in the 4s^2
4p^2. [1]
This making them closed shell [2].
In Prof. Blaha's example for free atoms [3], spin-polarized
Yes, you can run mpi on your single PC. If I remember correctly, lapw1
(and maybe also lapw2) is usually slower than lapw0 , so you will want
to run them in parallel.
However, several PC on a GB-network might run calculations faster than
your single PC as was mentioned before [
https://www.m
Seems a bit odd. Usually, if you see that error, it first occurs
earlier during initialization (i.e., dstart in init_lapw) or during a
lapw step during the scf calculation [
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg04721.html
].
It depends a bit on how you configure an
How did you recompile?
Using sitconfig:
username@computername:~/Desktop$ cd $WIENROOT
username@computername:~/WIEN2k$ ./siteconfig
*
* W I E N *
* site configuration
e
mailing list, it is not an issue [
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14226.html
].
On 11/6/2017 12:54 AM, sandeep Kumar wrote:
Dear Dr. Gavin Abo and WIEN2k users,
Thank you very much for your suggestions. I compile siteconfigure as
you suggested and I found th
As mentioned, you can keep increasing NMATMAX until the "WARNING: RKmax
reduced due to NMATMAX" message goes away.
However, a trick I found, is to use "x lapw1 -nmat_only":
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg08134.html
Although, keep in mind that the value you set
To make that calculation feasible, it looks like you need a better
computing system like a small cluster and mpi.
If ~8 GB is your total RAM, keep in mind that the Linux operating might
use around 1 GB. Using top [
https://superuser.com/questions/282867/why-does-the-memory-usage-in-top-not-ad
This might be because of the bugs that were reported before. Are you
using the fixed band.pl and scf.pl files from the post:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16069.html
On 11/8/2017 12:42 PM, Osama Yassin wrote:
Dear Prof Blaha
I'm doing some calculations o
Regarding the "foreach" error in WIEN2k 17.1 when starting directly an
iterative diagonalization, I believe you can safely ignore it if it
occurs only in cycle 1. It looks like this is because there is not yet
a case.vector/up/dn that the vec2old_lapw script can copy to
case.vector.old/up.old/
That error message looks like it might be from Open MPI:
https://github.com/open-mpi/ompi/issues/3380
Meaning, if you intended to compile with intelmpi, it looks like you may
have something compiled incorrectly with Open MPI instead of with
intelmpi. Did you use the right blacs library in the
I did this rather quickly. So you will have to double check if it looks
correct or not.
It looks like both your lattice parameters and atomic positions are in
the R-3 hexagonal setting. So enter in SETSTRU [
http://www.cryst.ehu.es/cryst/setstru.html ]:
# Comments start with #
# Space Gro
I believe HD stands for high derivative. See where it says high
derivative LO (HDLO) in the Computer Physics Communications Vol. 220 p.
230 (2017) article:
https://doi.org/10.1016/j.cpc.2017.07.008
On 11/12/2017 8:22 AM, delamora wrote:
Dear Peter Blaha,
In the 17.1 version the HDLO and LVN
101 - 200 of 1420 matches
Mail list logo
