I think that gives the numerical z values of the contour lines, where
the units of those values should depend on the case.in5 input (see
section 8.11.3 Input in the Wien2k 13.1 usersguide
[http://www.wien2k.at/reg_user/textbooks/usersguide.pdf]).
As the userguide says, if the input is a
Maybe Appendix A. STM Image Simulations: Theory Implementation in
the dissertation by one of Prof. Marks students at the following link is
of interest to you:
http://www.numis.northwestern.edu/thesis/ThesisAndresHD.pdf
However, I don't know if the lapw2STM code is available to the public.
FYI, there is also the Determining Structure from Symmetry slides in
the The International Tables for Crystallography lecture notes at:
https://chemistry.osu.edu/~woodward/chem_754_files/Page405.htm
___
Wien mailing list
That could happen if the format of the cif file is not compatible with
cif2struct or the cif file is bad (has incomplete information)
[http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg10456.html].
You could try to make a compatible cif file with VESTA as mentioned in
the
It is looking for the Wien2k executable file called 'nn' in the
directory '/home/mohamed/Desktop/wien/', but cannot find it, which is
why you are getting the error 'Command not found'.
The WIENROOT environmental variable in .bashrc might not be pointing to
the directory of the Wien2k
Did you read the information at the links:
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg10833.html
http://www.wien2k.at/reg_user/unsupported/(Elastic constants under
Physics)
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg10641.html
On 7/9/2014 3:55
cd /PATH-TO-FFTW3/lib/
grep -e fftw_alloc_complex *
Binary file libfftw3.a matches
This indicates that 'fftw_alloc_complex'' is part of the libfftw3.a
library (i.e., -lfftw3).
I think two possible causes might be that the wrong fftw3 library is
referenced or fftw3 library was not compiled in
Can you tell us what kind of systems this happens on and what the errors
are? The information might be helpful to others.
I had xcrysden-1.5.53-linux_x86_64-semishared.tar.gz installed on a
ubuntu 64 bit 14.04 LTS system. I just downloaded
xcrysden-1.5.60-linux_x86_64-semishared.tar.gz from
Correction: xcConfigure.sh should be in the scripts folder not the bin
folder.
On 7/16/2014 4:04 PM, Gavin Abo wrote:
Can you tell us what kind of systems this happens on and what the
errors are? The information might be helpful to others.
I had xcrysden-1.5.53-linux_x86_64
I am not clear what is the role of this MULT. Equivalent atoms mean
here ?. I would be glad if you can ellaborate this term more.
Yes, that is what it means, and that is what it says in the Wien2k 13.1
usersguide on page 41 (pdf page 58)
Is File-Close available? If so, a structure might already be open in
xcrysden, which disables the Open Wien2k option in the File menu and
clicking Close can make Open Wien2k-Fermi Surface highlightable again.
If that does not fix the problem, xcrysden has its own mailing list
It seems to me that pbs_tmrsh is only available on systems that have PBS
Professional.
There is information about it in the PBS Professional support
documentation (Reference Guide and User Guide) on Altair's PBS Works
website:
As far as I know, not with the current versions (13.1 or later) of Wien2k.
Maybe with the next release
[http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg10640.html]?
Unfortunately, the next version is apparently taking longer than
originally estimated
hup: Command not found is not a problem:
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg06444.html
Invalid null command might be due to a problem with csh, maybe it is
using an exotic version:
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg00132.html
On
Maybe the BoltzTraP interpolation scheme (src/fite4.F90) has failed
because your k-mesh is too course. You could try increasing the number
of k-points to create a fine k-mesh (x kgen) followed by regenerating
case.energy[up/dn] (x lapw1 [-up/-dn])
The reason for the error ls: pas de correspondance (French) or ls: No
match (English) is probably because the command
ls eos_*.struct | cut -c 1-9
in eos.job cannot find the eos_*.struct files. I believe the
eos_*.struct files should be created by elast_setup (when it internally
executes
As a reminder, lattice constants in the case.struct file are always in
bohr. The unit=ang' is only used by w2web, which is a flag that tells
the program if the value should be converted or not for display in
StructGen.
As it says, the problem is that it cannot open the TiC.vector file in
the directory '/work/02212/miz016/WIEN2K/data/scratch/'. The problem
might with how you defined SCRATCH, probably you should set it to use
the current case directory
'LAPW1 crashed' is commonly from a preceding error like
rsh: command not found
[http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg01194.html]
or
can't open unit
[http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg01445.html]
or
lapw1c: command not found
What Wien2k version is this occurring with? I 'assume' you are using
13.1. Hopefully, you are not using 12.1, because mBJ sometimes did not
work in that older version due to a bug [
http://www.wien2k.at/reg_user/updates/ ].
What Intel Fortran compiler version are you using? I suspect that
Looks to me that your atomic positions are in the hexagonal setting,
when they need to be in the rhombohedral setting
[http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg05554.html]
and your hexagonal lattice constants seem fine.
On 8/24/2014 11:01 AM, Minghao Zhang wrote:
Hi
Please some one send me the commands for calculating the
anti-ferromagnetic calculation.
i did these steps
did initialization
did changes
case.inst
The commands are given in section 4.5.4 Antiferromagnetic (AFM)
calculations of the Wien2k 13.1 usersguide [
See:
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg10561.html
On 8/30/2014 9:14 PM, Bing Zhou wrote:
Dear all,
The run_lapw failed with the following error message as:
LAPW2: semicore band-ranges too large
(standard_in) 1: syntax error
(standard_in) 1: syntax error
You did Dr. Pieper's exercise [
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg11090.html
]?
For example:
muB = ~5.7884*10^-5 eV/T [ http://en.wikipedia.org/wiki/Bohr_magneton ]
muB*Bext = (5.7884*10^-5 eV/T)*(10 T) = 5.7884*10^-4 eV
Likely the point is, say you plot DOS
If you compiled with ifort using -traceback, there is usually a forrtl
error message like the one at:
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg10716.html
or an error message in the dstart.error file like the one at:
I'm not sure, but I'm thinking that error might be caused by trying to
do a spin-orbit optic calculation with RLOs. Do you have any RLOs in
case.inso, because the optic package does not work with relativistic
local orbitals (RLOs) [ http://www.wien2k.at/reg_user/limitations/ ].
On 9/25/2014
%40zeus.theochem.tuwien.ac.at/msg05752.html
].
On 9/29/2014 5:23 AM, NARSIMHA RAO wrote:
Dear Prof.Peter Blaha, /Gavin Abo / and all
As you all know from my previous mails, I am trying to calculate
optical properties of HgI2 and a lead based compound. Based on your
suggestions I did calculations
I have two questions about the new version.
1.How to avoid EFG-MATRIX is a NULLMATRIX?
For cubic cell it is said running runsp -s -so lapw1 before normal
scf can avoid the problem. But for v14 it seems does not work. What is
the problem? Is the message EFG-MATRIX is a NULLMATRIX important
FYI
-
Problem: Compiling txspec with -C (check bounds) in WIEN2k 14.1 results
in an ifort forrtl runtime error
Effects: Can prevent complete debugging of txspec with check bounds
Fix: txspec.patch (attached)
Previous discussion and alternate fixes:
In the BoltzTrap code file, see Table 1.2 in UserGuide.pdf. For
example, you should see that the Seebeck coefficient (S) will be in
column 5 of case.trace. You can create a graphic of the data in your
favorite graph program like Origin, Excel, etc.
An example was also given before using
In order for you to answer that, you have to know what the magnetic
material is (Fe, NiO, NiFe, ...) and what 'initial' spin configuration
it has (ferromagnetic, antiferromagnetic, ...). The -ask is usually
chosen, since it allows for the specification of any linear
configuration (note:
You should run 'x nn' without any errors first.
On 10/24/2014 9:33 AM, Mohammed Abujafar wrote:
Dear WIEN2k users,
I have compiled the latest version of WIEN2k-14 on a Mac Os X 10.6.8.
No errors in the compilation.I got an error while running the
interface when I try to view outputnn.I got
Most likely, you need to do the x lapw1 [-up | -dn] steps shown in
w2web before running x lapw2 -qtl [-up | -dn] -so [
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg09896.html
].
On 10/26/2014 5:18 PM, Mohammed Abujafar wrote:
Dear WIEN2k Users,
I have calculated the band
Dear Prof. Blaha,
When you have a chance, can you have a look at the sentence regarding
rhomb_in5 on page 155 of the Wien2k 14.2 usersguide:
/You can find this programusing Run Programs - Other Goodies from
*w2web*.//
/
I believe it is remnant of WIEN in a box like hex2rhomb was [
Not a problem
[https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg07283.html].
However, if you use the latest Wien2k version (14.2), it looks like it
has been fixed so that the message is not printed.
On 10/29/2014 12:36 AM, mouhamed mahdi wrote:
Dear prof. Blaha
Dear wien2k
I don't see a save_lapw step between runsp_lapw -p and initso_lapw
[
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg05130.html
]. Without save_lapw, maybe there is some mixing of non-SO and SO files
that lead to the error, because when I started with just your struct
file
I think that error typically happens when users try to enter exactly the
command in the usersguide:
cp $WIENROOT/SRC_templates/case.inm_vresp case.inm_vresp
However, 'case' is only a general placeholder, and you need to replace
'case' with the actual name of your calculation [
case.inst not consistent with Z can happen if one or more of your Z
values in your struct file are not correct. In StructGen, the element
name of an atom should match with the atomic number (Z) like in the
periodic table. An easy way to correct this is to delete all the values
in the Z boxes
Probably nobody can help, unless you provide your case.struct file.
More than likely, the errors are caused by a problem with your case.struct.
On 11/11/2014 1:16 AM, Mona Rahimian wrote:
hi friend
I do your suggestions, but I have same errors.
in your openion , what should I do?*:( sad
--
Did you upgrade your WIEN2k to the latest version (currently, 14.2) and
run the calculation again from scratch? If you are using an old version
(like 11 in your email below), there were bugs in the older versions
that might cause that error. So you might not have that error with the
latest
I haven't calculated the effective mass with WIEN2k, but my current
understanding is as follows.
One method used to calculate the effective mass is the parabolic
approximation method.
You can probably find this method described in semiconductor physics or
solid state physics textbooks. I
Summary of possible causes and solutions:
a) Something went wrong previously (wrong input, diverging scf) -- no
reasonable eigenvalues
-
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg07669.html
b) NUME is too small. Increase NUME and recompile. Also, check about
I guess you mean the AFM NiO struct files at:
[1]
https://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg09765.html
[2]
https://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg09763.html
Of course, it should be better to use the struct file at [1] with space
group
In StructGen, if you select space group R with
a=5.572783 b=5.572783 c=27.300952 (in bohr)
alpha=90 beta=90 gamma=120
Ni1 (0,0,0) Ni2 (0.5,0.5,0.5) O (0.25,0.25,0.25) O (0.75,0.75,0.75)
you should get a WARNING: Mult not equal. PLEASE CHECK outpunn-file
when you run x nn in w2web.
Are there any WARNING messages when you run 'x nn' on the supercell?
On 12/1/2014 3:58 PM, Sayah Jamal wrote:
Dear Peter Blaha
https://www.mail-archive.com/search?l=wien%40zeus.theochem.tuwien.ac.atq=from:%22Peter+Blaha%22
I mad SUPERCELL Li0,5TiO2 and When I
try to run the x dstart
For space group 227_Fd-3m, you need to enter the structure parameters in
the Origin 2 setting, but it looks like you might have entered them in
the Origin 1 setting [
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg08164.html
].
On 12/9/2014 7:14 PM, bayarr temuujin wrote:
lorb = 2 in case.inorb and l = 2 in case.indm [1-3]
[1] http://zeus.theochem.tuwien.ac.at/pipermail/wien/2009-March/012306.html
[2] http://zeus.theochem.tuwien.ac.at/pipermail/wien/2004-July/003071.html
[3] For additional information on case.inorb and case.indm, see section
7.3.3 Input and
/I calculated x lapw 2 -fermi -so and this step was without any error/
= Seems to be a non-parallel calculation (no -p).
So your optic step likely needs to be non-parallel (x optic -so). If
that is not the cause of the error, then it might be due to a wrong
case.inop or case.vectorso file [
See the description for NO ENERGY LIMITS FOUND IN SELECT in section
12 Trouble shooting of the WIEN2k usersguide [
http://www.wien2k.at/reg_user/textbooks/usersguide.pdf ]. As it says,
the SELECT error has probably happened because your input is not ok
(like the input files case.struct and
In the WIEN2k directory SRC_lapw0, there should be a file called
lapw0.F. You have to open the file in a text editor. Then, you need to
find line 1831, which should have on that line:
READ(11,'(1X,,I10)') NKKSP
You need to replace (1X,,I10) with (9X,I10) in that
Did you set XCRYSDEN_TOPDIR and included it in the PATH in .bashrc [
https://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg11246.html
]?
To help set the variables automatically, you can run the xcConfigure.sh
of XCrySDen (in the scripts folder for version 1.5.60). However, it
It does sound like a problem with the setting of the environment. You
should consult your operating system documentation on how to set the
environment so that it can find the libblas.so.3gf on your system.
Usually, that involves setting an environmental variable in .bashrc or
setting a
The w2web and change.cgi files look fine. The solution to that error
before was to install fresh WIEN2k again (in particular, SRC_w2web),
because something in SRC_w2web was broken [
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg10981.html
].
Also, it is recommended to get
Hard to know what is causing the problem with the given information.
Probably, there is still not enough information provided.
Maybe there is a more detailed error message in the lapwso.error file or
you might have to run directly x lapwso -up -p in a terminal (if you
are allowed to, or
As far as I know, it is not possible to calculate a single Ni atom
having no crystal structure (no lattice parameters/spacegroup) with
WIEN2k, because WIEN2k is a 'periodic' structure code. I think you must
have a lattice parameter to describe the distance between atoms (the
periodicity of the
The default energy convergence criteria value for runsp_lapw should be
the same as for run_lapw, which is 0.0001 Ry as given on page 60 in the
WIEN2k 14.2 usersguide [
http://www.wien2k.at/reg_user/textbooks/usersguide.pdf ]. However, if
you are concerned about what it is, you can specify what
First, the latest WIEN2k version (14.2) removed some bugs in 14.1 [
http://www.wien2k.at/reg_user/updates/ ]; so it is quite recommended to
not use 14.1.
Second, the error you are getting might be because the fftw3-mpi.f03 in
SRC_lapw0 is probably still for version 3.3.2 of fftw3. There are
, February 12, 2015 11:13 PM, Gavin Abo
gs...@crimson.ua.edu wrote:
You are correct, there are no longer free non-commercial licenses for
Intel's ifort, because too many people were not adhering to the
non-commercial licensing terms [
https://software.intel.com/en-us/forums/topic/330003
You are correct, there are no longer free non-commercial licenses for
Intel's ifort, because too many people were not adhering to the
non-commercial licensing terms [
https://software.intel.com/en-us/forums/topic/330003 ]. If you have not
used the latest ifort version before, you should be
1) Download BoltzTraP.tar.bz2 from
http://www.icams.de/content/?page_id=356
2) Change to and extract it in your home directory in a terminal with
the two commands:
cd ~
tar xvf BoltzTraP.tar.bz2
3) Edit the Makefile in a text editor like gedit; in the terminal, for
example, with the two
Probably, you cannot get the 'same' result (just something close to it).
Madsen and Novak got F_eff = 0.438 Ry [
http://www.wien2k.at/reg_user/textbooks/Constraint_U.pdf ]. However,
keep in mind that they wrote this document in 2007, so the calculation
was likely with a WIEN2k version 7 or 8
A comment:
I'm not familiar with your increase RKmax until the energy start to
increase again.
From what I have seen or read, you want to increase RKmax until the
parameter you are interested in has converged. That parameter might
be total energy, EEL spectrum intensity, or another
Search the archive:
http://www.mail-archive.com/search?q=%22FERMI+-+Error%22l=wien@zeus.theochem.tuwien.ac.at
On 3/8/2015 1:53 AM, Qasim Mahmood wrote:
Dear Wien2k Users,
I am working on alloys under pressure study during run SCF following
error occur. what should I do?
FORTRAN STOP FERMI -
This might be due to the blocksize bug. The blocksize bug can be fixed
by using the current 2014 version of WIEN2k, which is 14.2.
On 3/24/2015 7:39 AM, farouk boutaiba wrote:
Dear members
After compilation of wien2k 2010, i tried to run SCF cycle with
binary GaAs compound. But it doesn't
Have you tried adding -I/opt/intel/composer_xe_2013.0.079/mkl/include
after $(FOPT) in the Linker Flags?
Also, see the post at the link:
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg10594.html
On 3/25/2015 7:43 AM, farouk boutaiba wrote:
I have used wien2k 2014, but
In the same terminal that you use to run siteconfig, what do you get as
output when you enter:
head -n 1 /opt/intel/composer_xe_2013.0.079/mkl/include/mkl_vml.fi
On 3/25/2015 12:01 PM, farouk boutaiba wrote:
I have change -L to -Ias you told me
-I/opt/intel/composer_xe_2013.0.079/mkl/include
Sorry, in siteconfig, add to the end of your Compiler options:
-I/opt/intel/composer_xe_2013.0.079/mkl/include
-
I found in at least one module that mkl_vml.fi is needed earlier in the
compile stage:
I think the parameters for the 141_I41/amd spacegroup in WIEN2k need to
be in the origin 2 setting, but it looks like you have entered them in
the origin 1 setting. You can use Bilbao Crystallographic Server's
SETSTRU [ http://www.cryst.ehu.es/cryst/setstru.html ] or program like
VESTA [
I think you need to be concerned about the first error:
mv: cannot stat `aCGT.vector': No such file or directory
The other errors probably just follow because of it.
What WIEN2k version are you using? I remember seeing almost the same
sequence of errors before because of how the SCRATCH
In addition:
Did you setup and run the calculation from scratch for each WIEN2k
version in its own directory? It is usually not a good idea to mix
initialization and run of a calculation in a single directory with
different WIEN2k versions. In WIEN2k 12/13, I believe the exchange and
In a terminal, run:
path-to-BoltzTraP/src/x_trans -h BoltzTraP
Change path-to-BoltzTraP to where BoltzTraP is located on your system.
For example, path-to-BoltzTraP on my system is ~/boltztrap-1.2.5:
~/boltztrap-1.2.5/src/x_trans -h BoltzTraP
In the output, you should see that you need the
Good, that means that the file mkl_vml.fi exists and can be opened.
However, I don't know why you still have the error that it cannot open
the file, when it can be opened.
The only things I can currently think of that could cause that are:
a) When you added the -I line in siteconfig to the
Look at the compile.msg file in SRC_lapw0 with a text editor. It will
probably contain additional error information on why your gcc failed to
compile the C source code into the object files (cputim.o and W2kutils.o).
Also, I suggest that you download and install the current WIEN2k
version.
Links to the other details:
Fermi Energy
http://www.wien2k.at/reg_user/faq/neg_fermi_energy.html
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg12066.html
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg12126.html
Ecut
I am doing mBJ calculation for a ternary semiconductor. There are
four options for different parametrization of mBJ:
0: Original.
1: New parametrization (Koller.
2: New parametrization for semiconductors
3: Unmodified BJ potential (Backe.)
1) Go to: http://www.cryst.ehu.es/cryst/get_wp.html
2) Put 167 in the box and click ITA Settings
3) Click the R-3c :r link
4) In the table, you should see 12c (0,0,z) for the hexagonal setting
and 12c (z,z,z) for the rhombohedral setting. Your In atomic position
appears to be in the
On page 131 in the User's Guide for Intel mkl 11.1 for Linux [
https://software.intel.com/en-us/mkl_11.1_ug_lin_pdf ], it has:
libmkl_blacs_intelmpi_lp64.so = LP64 version of BLACS routines for
Intel MPI and MPICH2
So -lmkl_blacs_intelmpi_lp64 might also work with MPICH2.
From the compile
Remove -orb from the 'x lapw1' steps:
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg10757.html
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg09117.html
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg02807.html
On 4/28/2015 11:44 AM,
Ok, now it is clear that there is no additional error messages.
Unfortunately, I cannot tell specifically what went wrong from those
error messages.
You might try replacing mpirun with mpirun_rsh. As you can see at
See below for my comments.
Thanks for all the information and suggestions.
I have tried to change -lmkl_blacs_intelmpi_lp64 to -lmkl_blacs_lp64
and recompile. However, I got the following error message in the
screen output
LAPW0 END
[cli_14]: [cli_15]: [cli_6]: aborting job:
Fatal error
Yes, the x_lapw script automatically detects whether to use -c or not.
So for any subroutine that you call with 'x' in front of it like 'x
lapw2' [
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg07747.html
].
On 5/10/2015 8:19 PM, Yundi Quan wrote:
Hi,
For crystal
First, I suggest that you upgrade to WIEN2k 14.2, because some updates
have been made to SRC_tetra [ http://www.wien2k.at/reg_user/updates/ ,
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg11178.html
(patch to only WIEN2k 14.1?)].
Second, this might be due to a bug in
For a non-spin polarized spin-orbit calculation (run_lapw -so), lapw2
should read one file case.vectorso. So you do not need case.vectorsodn.
For a spin polarized spin-orbit calculation (runsp_lapw -so), lapw2
should read two files case.vectorsoup and case.vectorsodn. So you do
need
Your scf calculation is probably non-complex, so you have to remove the
'-c'.
On 5/10/2015 10:24 AM, saurabh samant wrote:
Dear WIEN2k users,
I am doing a spin-polarized mBJ calculation with SO as given in UG.
After the calculation converged successfully, I was trying to plot the
FYI, there is a separate BSE code for WIEN2k called BSE@WIEN2k.
It seems to require a cluster with hundreds of cores and a large amount
of memory as described on slide 23 in the document at:
http://www.wien2k.at/reg_user/textbooks/WIEN2k_lecture-notes_2013/DFT_advanced.pdf
It cannot be
!!
Am 15.05.2015 um 09:01 schrieb Santu Baidya:
Dear Prof. Blaha,Gavin Abo andXavier Rocquefelte*,*
** Thank you for your suggestions. As you see from my previous mail I
first did GGA+U+SO calculation for XMCD of Co L23 edge.
It did not work and I moved to GGA+U cal.
I first did scf calculation
First, install the latest WIEN2k version (14.2) unless you want to
experience the frustration of the WIEN2k 13.1 bugs listed at
http://www.wien2k.at/reg_user/updates/
Second, regarding the errors like f951: error: unrecognized command line
option -ip, if you do a google search, it looks like
In the runsp_lapw script of WIEN2k 14.2, there is:
lcore:
...
total_execlcore -up #line 738
...
total_execlcore -dn #line 742
Since total_exec calls teststop when lcore -up finishes, I think it
never continues with lcore -dn. Any ideas on how to best fix it so
that x lcore -dn does
In w2web of WIEN2k 14.2,to view case.outputjointup and
case.outputjointdn for a spin polarized optic calculation, try:
a) Replacing all occurences of $CASE.outputjoint with
$CASE.outputjoint$spin in $WIENROOT/SRC_w2web/htdocs/exec/optic.pl.
or
b) Apply optic.patch.
1. To get optic.patch,
In SRC_w2web/bin/w2web on line 656, I suggest that you use a text editor
to change Failed to open file to Failed to open file $full.
By adding $full, it might output in the error message what file it
cannot open.
After saving the change to the w2web file, you will need to kill all
running
The problem might have been caused by using a special character in the
base directory where WIEN2k was installed, for example:
/home/username/$WIEN2k
After a) reinstalling WIEN2k in a directory without the special
character ($), like /home/username/WIEN2k, and b) fixing the WIEN2k
.bashrc
FYI, it looks like Intel is offering free software development tools
again for certain qualified uses. More information can be found at:
https://software.intel.com/en-us/qualify-for-free-software
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
If you search the mailing list archive, you should find that the error
is commonly caused by rounding problems in the atomic positions:
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg07944.html
http://www.mail-archive.com/wien%40zeus.theochem.tuwien.ac.at/msg06624.html
If you
For option 7 with 15 structures and 1% change during x optimize on the
initial struct file that you provided, the TlSbSe2_mon__11.0.struct does
not pass x nn as the struct file has a multiplicity problem (Mult not
equal):
username@computername:~/wiendata/TlSbSe2$ mkdir TlSbSe2_mon__11.0
I think your struct file will be okay if you select for the lattice in
StructGen spacegroup 12_B2/m instead of CXZ, and of course, use setrmt
again after changing to 12_B2/m.
Sure, you should be able to specify 'all' the atomic positions in the
general CXZ lattice to get the same structure.
Did you create the file wien2k.32bits.in0? The file is usually created
by executing init_lapw.
On 5/19/2015 5:51 AM, muhammed thaha hashim wrote:
Dear All,
I am running Wien2k 32bits on Linux (Arch) operating system.
I am a grad student. My goal is to evaluate the performance of Wein2k
on
As Pavel mentioned, open the SRC_lapw1/compile.msg file in a text editor
and check for error messages (e.g., enter in a terminal: gedit
$WIENROOT/SRC_lapw1/compile.msg).
On 5/20/2015 9:52 AM, rachida lamouri wrote:
Dear all,
I'm sorry, i made a careless mistake; lapw1c doesn't exist.
what
For experimental EELS data, I think there are software programs out
there for that:
EELSTools [ http://www.dmscripting.com/eelstools.html ]
EELSModel [ http://www.eelsmodel.ua.ac.be/ ]
However, I don't know if you can import WIEN2k EELS data into them, and
I'm not aware of any software for
Sorry, there is a mistake in my previous post. The -Wl,--end-group
should go after libmkl_core.a. The corrected settings are given below:
current:R_LIBS:$(MKLROOT)/lib/intel64/libmkl_lapack95_lp64.a
-Wl,--start-group $(MKLROOT)/lib/intel64/libmkl_intel_lp64.a
wanted to do some calculations
on Cluster (Rocks 6.1) with intel compilers. Can you please look into my
compile message?
On Mon, May 18, 2015 at 11:17 PM, Gavin Abo gs...@crimson.ua.edu wrote:
First, install the latest WIEN2k version (14.2) unless you want to
experience the frustration
301 - 400 of 1289 matches
Mail list logo
