Hello Madhav,
The thickness of the slab will vary depending on the interplanar
distance for that surface. Usually you can do this more accurately by
using an expression based on the bulk lattice constants. For instance:
bulk = loadstruct(...)
surface = makesurface(bulk,1,bulk.a(3)/2,20.0)
wh
Exactly like this.
And then: "look" at your structure (xcrysden or VESTA or ..), "count"
the number of generated layers, check if all atoms are there, .
On 06/27/2013 09:18 AM, Michael Sluydts wrote:
Hello Madhav,
The thickness of the slab will vary depending on the interplanar
distance
Are you sure that the that and phi meshes are ok ??
> 20 0.0 1.5707963267949
> 20 0.7853980 2.35619
In particular phi looks very special (can be ok for a certain
site-symmetry), but is dangerous, if you do not understand the meaning.
Without symmetry, theta should run from 0-pi and phi from 0
Dear Michael & Prof. Blaha,
The information you provided are really helpful. My doubt are clear now.
Thanks
Madhav
On Thu, Jun 27, 2013 at 4:30 PM, Peter Blaha
wrote:
> Exactly like this.
>
> And then: "look" at your structure (xcrysden or VESTA or ..), "count" the
> number of generated laye
Dear prof. Blaha,
Thank you for your reply. Now it is essay for me to understand the input
file.
I have used the value of theta as 0-pi and phi as 0-2pi. I also used the
different values of ntheta and nphi as 40 and 60 (in two separate run ).
The calculated charge transfer is as follows:
for Gd
Dear Dr. Blaha,
Thanks for your consideration and reply,
Yes, I'm calculating the band structure of some topological half-heuslers that
as far as I know for them RKmax=9 (at least) is needed.
Do you think is there any other way for removing the error instead of reducing
RKmax?
regards
--Saba
__
Probably ok. At least they look consistent.
On 06/27/2013 11:21 AM, alpa dashora wrote:
Dear prof. Blaha,
Thank you for your reply. Now it is essay for me to understand the input
file.
I have used the value of theta as 0-pi and phi as 0-2pi. I also used the
different values of ntheta and nphi
If you are claiming you can run with RKmax 8, but not with 9, there are
only 2 ways:
used only RKmax=8
set the sphere sizes better.
But without details nobody can help.
PS: Who says that for the bandstructure of topological half-heuslers
RKmax=9 is needed ???
Rkmax is a function of the typ
I notice that the new wien2k 13.1 spends a lot of time (=up to 1 minute)
in kgen. This appears to be due to a large fort.10 file that is written
by create_filehf.f in SRC_kgen (it is 40 Mb for a simple test case).
This fort.10 file is not present when wien2k 12.1 is used.
Is this the desired
This should happen only if you specifyx kgen -hf
However, checking the source I found that "createhf" is not set to
.false. as a default and since we changed an "if" statement from .eq. to
.eqv., it might be that it leads to this behavior on some computers (not
on mine with latest ifor
One week ago, a two-question survey was posted on this mailing list.
Here comes the result and a discussion/interpretation of the data.
The goal of the survey was to collect quantitative information on the
following hypothesis:
"In the transition from code development to code usage, inevitable
Indeed, this works fine.
Thanks,
Stefaan
On 27/06/2013 15:00, Peter Blaha wrote:
This should happen only if you specifyx kgen -hf
However, checking the source I found that "createhf" is not set to
.false. as a default and since we changed an "if" statement from .eq. to
.eqv., it mi
They don't matter with ifort, but could with some other compilers (maybe):
SRC_lapw1/lopw.f(128)
# in first line should be !
SRC_nmr
c3fft.frc
Line 207 is #endif without any #if and the file is of the wrong type
(not .F or .frc90)
make_charge.frc
Line 159 has too many ")" at the end
make_fopvec_gr
The determination of Emax in case.in1 seems to have been changed from a
fixed value at 2.5 Ry to a dynamic value determined as E_fermi plus a
default 1.5 Ry:
K-VECTORS FROM UNIT:4 -10.0 1.518 emin / de (emax=Ef+de) /
nband
This 1.5 Ry might be too small, as it makes reappear i
Hmm. I can verify the problem.
The question is: it nonmagnetic bcc Fe an exception ? Does this happen for any
"more-atomic" unit cells, which one would use in usual research work ??
At least in my tests the new setting is a good compromise and in particular with
the dynamic range it is much more
I've updatedhttp://www.wien2k.at/reg_user/faq/rkmax.html
Maybe it helps if I put a link in w2web in the initialization section next to
the
RKmax input/editing ? (But which experienced user is using w2web for
intialization ?)
Am 27.06.2013 16:49, schrieb Stefaan Cottenier:
One week ago,
Done. Updates on the web.
Am 27.06.2013 17:28, schrieb Laurence Marks:
They don't matter with ifort, but could with some other compilers (maybe):
SRC_lapw1/lopw.f(128)
# in first line should be !
SRC_nmr
c3fft.frc
Line 207 is #endif without any #if and the file is of the wrong type
(not .F or .
I'm working on a cluster with many nodes. Each node has its own /scratch
folder which cannot be accessed by other nodes. My own data folder is
accessible to all nodes. When the WIEN2k scratch folder is set to './',
everything works fine except that all the data write/read are done in my
own data fo
I'm working on a cluster with many nodes. Each node has its own /scratch
folder which cannot be accessed by other nodes. My own data folder is
accessible to all nodes. When the WIEN2k scratch folder is set to './',
everything works fine except that all the data write/read are done in my
own data
I forgot to add that after lapw2, all the output files should be written to
a shared folder (not to scratch folder of each node) so that sumpara -p
could access all the output files. In the version that I'm using (11.0), it
seems that lapw1 is not executed locally.
Yundi
On Thu, Jun 27, 2013 at
If you are talking about a mixed (MPI & k-parallel) job, there are
suggestions in FAQs: http://www.wien2k.at/reg_user/faq/pbs.html
I use SGE scheduler and the following parallel_options file:
setenv USE_REMOTE 0
setenv MPI_REMOTE 0
setenv WIEN_GRANULARITY 1
setenv WIEN_MPIRUN "mpiexec -machinef
Hi, Oleg,
Thanks for you advice.
Yundi
On Thu, Jun 27, 2013 at 8:08 PM, Yundi Quan wrote:
>
>
> -- Forwarded message --
> From: Oleg Rubel
> Date: Thu, Jun 27, 2013 at 7:46 PM
> Subject: Re: [Wien] scratch folder in k-point parallel calculation
> To: wien@zeus.theochem.tuwien
22 matches
Mail list logo
