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
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
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
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, not for the fat band structure
plotting.
Have I missed anything here?
Cheers,
Jianxin
From: Wien <wien-boun...@zeus.theochem.tuwien.ac.at
<mailto:wien-boun...@zeus.theochem.tuwien.ac.at>> on behalf of Gavin
Abo <gs...@crimson.ua.edu <mailto:gs...@crimson.ua.edu>>
Repl
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
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]
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
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
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
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
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
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
Maybe try changing hr_plot to write_hr in
$WIENROOT/SRC_templates/case.win of WIEN2k 17.1 [1,2].
[1]
https://translate.google.com/translate?js=n=auto=destination_language=http://www.slab.phys.nagoya-u.ac.jp/ai/pukiwiki/index.php?wien2wannier
[2]
Students, Classroom Educators (Professors), and Open-Source Contributors
might be able to get a free license for some Intel tools:
https://software.intel.com/en-us/parallel-studio-xe/choose-download
For WIEN2k, I believe commercial researchers have to buy a commercial
license. Professors
Are you using the fixed band.pl and scf.pl files in the mailing list
archive:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16743.html
On 11/30/2017 3:59 PM, Sergio Castillo Robles wrote:
Hi dear Wien users,
I would appreciate any help you could give me to solve this
After running "x tetra", did you run "dosplot2_lapw -i" (see section
5.10.5 dosplot2_lapw [1]) or "Cgrace_dos_lapw" (see section 5.10.6
Cgrace_lapw, Cgrace_conf_lapw and Cgrace_dos_lapw [1]) in a terminal
while in the case directory?
On the other hand, there is no mention of SUM-DOS option
Instead of plotting E [eV] vs k^2 [(2*pi/angstrom)^2], have you tried
plotting E [J] vs k [pi/m]?
Take for example the plot at:
http://www.nextnano.com/nextnano3/images/tutorial/2Deffective_mass_vs_8x8kp/kz_dispersion_small.jpg
[ from http://www.nextnano.com/nextnano3/tutorial/2Dtutorial4.htm
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
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
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
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
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
0 0.0590(6) 1. 0
0.5
and they have two symilar structures
*De:* Wien <wien-boun...@zeus.theochem.tuwien.ac.at> en nombre de
Gavin Abo <gs...@crimson.ua.edu>
*Enviado:* domingo, 12
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 [
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
How did you recompile?
Using sitconfig:
username@computername:~/Desktop$ cd $WIENROOT
username@computername:~/WIEN2k$ ./siteconfig
*
* W I E N *
* site configuration
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 [
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
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
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 a
Not an expert on the subject, but below are my comments.
For /I/*DOS(/E/_F), whether you use
/I/ in eV and DOS(/E/_F) in 1/eV [1,2]
or
/I/ in (eV*spin*f.u.)/states and DOS(/E/_F)in states/(eV*spin*f.u.) [3]
or
another unit variant such aswith energy in Ry [4]. It does not look
like it
In your .bashrc, you can see:
export SCRATCH=/home/mmk/WIEN2k/lapw
If you want to store the scratch files in the case directory itself,
change it to [
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg09245.html
,
SIGSEGV errors can have many possible causes [
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg14476.html
].
In your case, I see W_14.2 below. So perhaps it is due to a bug in an
the older WIEN2k 14.2 or wien2wannier version that you are using. You
might try the newer
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
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
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).
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
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
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
l 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 <gs...@crimson.ua.edu
<mailto:gs...@crimson.ua.edu>> wrote:
All,
Just curious, has anyone heard if the new BoltzTraP2 package will
I'm fairly certain that the asterisk's symbol (*) corresponds to the /s/
= -1 column for the orbital quantum number (/j/) in Table 6.6 on page
107 in the WIEN2k 17.1 usersguide [
http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf ].
For example, p* is the 1/2. Without the
I think you found a bug in init_lapw. The fix seems like it should be
simple though. On line 498 in the init_lapw script in the sed command,
it looks like $fermit just needs changed to $fermits.
I made a patch file called init_lapw.patch [
In the BaTiO3 tutorial, lambda1.struct and lambda0.struct both have
spacegroup 99_P4mm and 8 symmetry operations [
https://github.com/spichardo/BerryPI/wiki/Tutorial-1:-Spontaneous-Polarization-in-BaTiO3
].
I see a sentence in the tutorial:
/The symmetry operations are identical (!) to the
2/3/4 ] [ -f FILEHEAD ] [ -scf '*xxx*.scf' ] [-a/b/g]
-a/b/g allows to specify alpha,beta or gamma in 4D fit.
On 5/8/2018 7:34 AM, Víctor Luaña Cabal wrote:
On Tue, May 08, 2018 at 06:22:25AM -0600, Gavin Abo wrote:
Currently, I believe parabolfit_lapw is the best way available at this
tim
Just to repeat some things that have been said before:
Probably something wrong with the struct file [
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg07816.html
].
Did the original struct file make it through init_lapw okay [
First, the WIEN2k updates page says the 17.1 contains some bug fixes to
repair some severe issues found in previous versions like 16.1 [
http://susi.theochem.tuwien.ac.at/reg_user/updates/ ]. So you may want
to consider using 17.1 and also apply the fixes to it found in the
mailing list
Regarding the LOPW error, you might try increasing the RKmax value (in
case.in1[c]) [
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg13902.html
, http://susi.theochem.tuwien.ac.at/reg_user/faq/rkmax.html ].
On 5/11/2018 9:49 PM, Arvind Kumar wrote:
Dear Prof. Blaha and
Yes, I believe that is correct that Constraint_U.pdf is performing the
same calculation as Anisimov's paper.
As illustrated nicely on slide 11 in
http://www.fhi-berlin.mpg.de/~xinguo/talks/jiang_cdft-coffeetalk.pdf ,
just as you say, an electron is added for spin-up and an electron is
That calculation I did quite some time ago. So, I cannot remember my
reasoning behind it. Since I didn't see an explanation for it in
Constraint_U.pdf and didn't know how Madsen and Pavel got the weights, I
likely just assumed the ε3d_dn would be the same as the ε3d_up.
I could be wrong,
file.
Isn't there another smarter way to do that fitting?
Thanks, Victor
2018-05-06 16:50 GMT+03:00 Gavin Abo <gs...@crimson.ua.edu
<mailto:gs...@crimson.ua.edu>>:
I haven't really used parabolfit_lapw, but I believe you can use
it for that.
However, you may want to use
I haven't really used parabolfit_lapw, but I believe you can use it for
that.
However, you may want to use the improved WIEN2k 17.1 parabolfit_lapw
script:
[1]
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16799.html
[2]
Just installed WIEN2k 17.1 on Ubuntu 18.04 LTS using Intel Fortran
Composer XE 2013 (ifort version 14.0.1).
It didn't seem too bad. I had to make a few adjustments when following
Intel's instructions at:
https://software.intel.com/en-us/articles/using-intel-compilers-for-linux-with-ubuntu
I believe that is usually controlled with the OMP_NUM_THREADS
environment variable:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg05475.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg03997.html
However, I have never really tried using the multiple
In WIEN2k 17.1, is tol=1.e-3 in SRC_symmetso/symmetso.f on line 110 okay
or does the same change need to be made too? Thanks in advance.
On 5/15/2018 11:43 AM, Peter Blaha wrote:
Of course the error occurs always, also when running x symmetry.
In init_lapw in batch mode, the error is
- Is there a difference between *.inm and *.inM files for MSR1a
position optimization?
The case.inm (section "7.12.3 Input" on page 142) and case.inM (section
"8.15.3 Input" on page 173) seem to have their own sections in the
WIEN2k 17.1 usersguide [
As I recall, NEWT may need to be specified in case.inM for min_lapw
(mini) to do that [
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16213.html
].
Though, when constraining of atomic positions makes sense [
Try a setrmt reduction of 5%. I didn't run the entire calculation, but
it seems to start off well with that:
username@computername:~/Desktop$ cd ~/wiendata
username@computername:~/wiendata$ mkdir NiO
username@computername:~/wiendata$ cd NiO
username@computername:~/wiendata/NiO$ makestruct_lapw
Someone else may know differently, but as far as I know, WIEN2k has no
function for calculating MR (magnetoresistance).
I don't know the details of what your are trying to do exactly, but it
may be that WIEN2k's magnetic field doesn't do what you think it does.
Refer to the previous posts:
The fort.xx format should be described in the post at:
http://zeus.theochem.tuwien.ac.at/pipermail/wien/2012-December/018026.html
There is fort2dx [
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg08441.html
] if you need to convert it to dx format. The fort2dx should be in
That looks like just the dayfile. What does the terminal or w2web
standard output/error look like? What do the error files contain (cat
*.error)?
The dayfile does show that you are using a bad WIEN2k version (i.e.,
14.2) for spin-orbit calculations.
That is because to avoid problems with
If the folder NdGaO3 is where you did "run_lapw", maybe you accidentally
skipped the "cd NdGaO3w2w" step when following the wien2wannier cheat
sheet [
https://github.com/wien2wannier/wien2wannier/blob/master/doc/CHEATSHEET
] after creating the NdGaO3w2w.fermi file in the NdGaO3w2w folder using
At
https://github.com/aoterodelaroza/critic2/blob/master/doc/user-guide.txt,
there is:
* meta-GGA: xc(rho,grad,lapl,tau,idx)
where rho is the electron density expression, grad is its gradient, lapl
is its Laplacian and tau is the kinetic energy density
In the WIEN2k 17.1 usersguide, there
The libimf.a & libimf.so will not be were you installed WIEN2k. Those
two files should be were the Intel Fortran compiler was installed,
because they should come with the ifort program.
If ifort was already installed by the manager(s) of your cluster (i.e.,
administrators, help desk team, or
I'm not too familiar with NMR calculations. I suspect that a non-zero
nmr_q0.vector should be written by the "x_nmr -mode lapw1". Does
nmr_q0.vector have a zero or non-zero file size (file size should be
given in the output for example of the terminal command: ls -l
In the paper titled "Density-functional theory investigation of oxygen
adsorption at Pd(11N)(N=3,5,7) vicinal surfaces" [
https://arxiv.org/abs/cond-mat/0606033v1 ]:
l_max^wf = 12
l_max^pot = 6
E_wf^max = 20 Ry
E_pot^max = 196 Ry
R_MT_Pd = 2.1 bohr
R_MT_O = 1.1 bohr
To me, it looks like the
The "ssh cn308 ldd $WIENROOT/lapw0_mpi" is finding files for your ifort
installation like
/THFS/opt/intel/composer_xe_2013_sp1.3.174/mkl/lib/intel64/libmkl_scalapack_lp64.so
just fine. So your environmental variables seem to be setup and working
fine on both nodes. It looks like the
For LVNS, see section "5.1.3 Job control for initialization (init_lapw)"
on page 63 in the WIEN2k 17.1 usersguide [
http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf ].
There it looks like you just need to add the '-lvns L' switch to your
init_lapw command.
For example, if
As pointed in my mail I kept all the variable paths to bashrc file as
well as in the jobscript file.
You didn't mention you were using a job script. I assumed you weren't.
That may be important. Some queue systems require a flag in the job
script to export the environmental variables
Prof. Blaha,
For WIEN2k_18, please check SRC_joint/joint.f to see if the following
problem in WIEN2k 17.1 has been fixed.
When running "x joint -up" for an XCMD calculation, the following error
appears:
forrtl: severe (64): input conversion error, unit 4, file
The XMCD calculations seem to be seriously broken in WIEN2k 17.1. I
suspect that any structure will run into an XMCD error similar to:
username@computername:~/wiendata/testXMCD$ x optic -so -up
emin,emax,nbvalmax -5.00 3.00
XMCD selected for atom
Refer to the previous post:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg08969.html
On 5/31/2018 11:51 AM, Luc Fruchter wrote:
Hi,
While running a case, I have noticed that the lapw1/2.error file is
not empty, and contains 'Error in lapw1/2'.
However, this does NOT stop
I believe the __libm_sse2_sincos symbol is defined in the files called
libimf.a or libimf.so. If the Intel Fortran compiler is installed in
the default location, then both of those files are usually in the
/opt/intel/lib/intel64 directory on a 64 bit system. Do those two files
exist on your
Yes, the problem seems to come from more atoms/cell.
I haven't had a chance to look further into it. However, the top part
of Fe3O4.vspup looks like this:
TOTAL SPHERICAL POTENTIAL IN MT SPHERES 4.ITERATION
NORM: V*R
ATOMNUMBER = 1
NUMBER OF LM 1
VLM(R) FOR L
Let me add something to that:
If I remember correctly, if there is a problem with either the inorb or
indm(c) files, I believe there is typically a forrtl error produced in
the standard error/output. The forrtl error is usually helpful for
narrow down what particular problem the input file
If it helps, there are the following related posts:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg06138.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg03184.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg01143.html
In your case.insp, try changing the font switch to 0, 1, 2, or 3:
- top of file: case.insp ---
### Figure configuration
5.0 3.0 # paper offset of plot
10.0 15.0 # xsize,ysize [cm]
1.0 4 # major ticks, minor ticks
1.0 1 # character height, font switch
The WIEN2k
I could be wrong, but as far as I know, there is currently no output
file or program in WIEN2k to recover the vacuum thickness created by "x
supercell" or the structeditor.
So, to get the vacuum thickness, you would have to look at the lattice
parameters and atomic positions in case.struct,
If you are using w2web in WIEN2k 17.1, we have seen this before [
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16843.html
]. The fixed band.pl and scf.pl files (or band.patch and scf.patch
files) need to be used [
Just a thought, maybe it doesn't help, but have you checked the :log
file for which programs are involved in your calculation. Then, used
that to check if there are differences in the code for those programs
that could affect your calculation using the updates list on WIEN2k website:
I believe NLO is Bernd Olejnik's personal code package (an extension
package for WIEN2k). You would have to contact Bernd to get it. The
email address to request it is on the first slide in:
http://susi.theochem.tuwien.ac.at/events/ws2003/downloads/ws2003_olejnik.pdf
However, I don't know
Using:
64 bit Ubuntu 16.04.4 LTS
WIEN2k 17.1 (with the siteconfig, libxc, and gfortran patches [
https://github.com/gsabo/WIEN2k-Patches/tree/master/17.1 ])
username@computername:~$ gfortran --version
GNU Fortran (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
In SRC_lapw1/inilpw.f, I added a
it is z=0?
Thank you once again
Best regards
*/Lawal
/*
On Wednesday, May 2, 2018, 8:49:58 AM GMT+8, Gavin Abo
<gs...@crimson.ua.edu> wrote:
Boxbe <https://www.boxbe.com/overview> This message is eligible for
Automatic Cleanup! (gs...@crimson.ua.edu) Add cleanup
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,
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
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
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 think
: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, w_pl^2(dn
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
The message indicates a problem occurred in lapw0. Beyond that, there
is not enough information to help.
As the message says, you have to check the ERROR FILES (cat *.error) for
any additional error information.
You should also check the standard output in the terminal, or if you are
using
FYI, write_inwf_lapw in WIEN2k 17.1 should be from version 1 of
wien2wannier. If you want write_inwf_lapw from the version 2 of
wien2wannier. You may download and install it [
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16099.html
].
On 12/31/2017 9:10 AM, Oleg Rubel
This seems to be because the names :FFTW_LIB and :FFTW_LIBNAME are too
similar on lines 157 and 158 in siteconfig_lapw.
So when you "grep :FFTW_LIB WIEN2k_OPTIONS", it gives lib and fftw3 from
both of them:
username@computername:~/WIEN2k$ grep :FFTW_LIB WIEN2k_OPTIONS | cut -d :
-f 3-
lib
As the error messages say, -fsloppy-char and -freal-loops are not
recognized as flags by gfortran. So try removing them in the siteconfig
compiler settings.
At https://www.myroms.org/forum/viewtopic.php?f=31=1047=next , it
says:
The -ffree-line-length-huge option is g95-specific. The
Don't know if it helps or not, but you could check if this sounds right
or not:
Let
iz: a fractional position of z
where z ∝ iz
then
In SRC_lapw0/eramps.f, the backramp0 function on line 129 in WIEN2k 17.1:
z0 = z <- Assuming z = iz even though it might just be that z ∝ iz
z0 = 1 - z0, if
I tested siteconfig_lapw on a live USB stick [
http://www.democritos.it/pipermail/xcrysden/2017-December/001902.html ].
Does pwd return the location of where WIEN2k was installed?
ubuntu@ubuntu:~$ cd $WIENROOT
ubuntu@ubuntu:~/WIEN2k$ pwd
/home/ubuntu/WIEN2k
Does the WIEN2k_INSTALLDATE file
If you're still using some version of composer 2017 as was mentioned
previously [1], the "input statement requires too much data" error might
be due the Intel compiler version that you are using. You might try
googling or searching the Intel forum as that seems to be a known issue
with some of
fix for get_nloat.f [
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg16589.html
]?
On 1/12/2018 11:12 PM, Osama Yassin wrote:
Dear Gavin Abo
- I have installed Intel Compiler 2108 update 1. Then Wien2k 17.1 was
complied successfully (serial and parallel).
- Normal SCF cyc
In SRC_lapw0/inputpars.F, it looks like SWITCH3 corresponds with putting
either KXC or screened exchange-correlation energy and no
exchange-correlation potential (e.g., EX_SPBE VX_SPBE VX_NONE VC_NONE)
in case.in0_grr.
The message "Charged cell and SWITCH3 not possible", and "Charged cells
What Intel Fortran version did you use to compile WIEN2k (e.g., terminal
command: ifort -v)? What serial compiler settings did you use to build
dstart in single mode (e.g., terminal command: cat
$WIENROOT/WIEN2k_OPTIONS)?
There is a higher chance that the error is caused by a broken version
701 - 800 of 1289 matches
Mail list logo
