Why do you want to use LDA+U for LiCoO2? It’s trivalent nonmagnetic Co, GGA is
physically more justified then DFT+U.
Sent from a mobile device - please excuse typos.
> On Sep 27, 2023, at 03:11, Murat Aycibin wrote:
>
>
> Hi
> I am trying to perform LiCoO2 calculation using hubbard method
en.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
--
Igor Mazin, Prof. of Advanced Studies
Quantum Science and Engineering Center
Department of Physics and Astr
ien@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.th
should run without problems.
>
> Best regards
> Peter
>
> Am 06.09.2023 um 17:51 schrieb Igor I Mazin:
>> I am trying to run fixed spin moment calculations for a
>> noncentrosymmetric lattice that requires complex versions of both lapw1
>> and lapw2. My WIEN versi
I am trying to run fixed spin moment calculations for a
noncentrosymmetric lattice that requires complex versions of both lapw1
and lapw2. My WIEN version is WIEN2k_23.1/
On the first iteration, it correctly runs lapw1 -c -up, but then it
bombs with the diagnostic
cp: cannot stat ‘RUN.in2up’: N
I have used before the OPTICS code in WIEN2k to calculate magnetooptics,
i.e., nondiagonal elements of optical conductivity generated in some
magnetic structures by spin-orbit. Before, I used only orthorhombic
symmetry or higher, and the results were in perfect agreement with the
symmetry analy
My WIEN2k installation works fine - except for lapw2 -qtl.
This module bombs with the following diagnostics:
x lapw2 -qtl -up
forrtl: severe (64): input conversion error, unit -5, file Internal
List-Directed Read
Image PCRoutineLineSource
lapw2
my installations bombs with messages such as
--
make: Circular modules.o <- modules.o dependency dropped.
make: Circular fft_modules.o <- modules.o dependency dropped.
make: Circular fft_modules.o <- fft_modules.o dependency dropped.
ifort -c -O -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -t
saw in WIEN, and I've seen
a lot...
--
Igor Mazin, Prof. of Advanced Studies
Quantum Science and Engineering Center
Department of Physics and Astronomy
George Mason University
phone 1-703-503-8152 (h)
http://mason.gmu.edu/~imazin2
___
Wien mailing lis
I have been able to locate the source of the error. The weight files
generated by lapw2 are supposed to have the actual value of EF in the
first line. With the TETRA or GAUSS choices, they do. With the TEMP
choice, they are displaced by exactly 30*T. Correspondingly, JOINT uses
a wrong Fermi en
I found a curious inconsistency in optical calculations. If I use TETRA
in case.in2 for the lapw2 -fermi step, or TEMP with a very small
broadening (1 mRy or less), or Gauss, I get more or less consistent
results for jdos (and, of course, for epsilon2). However, if I start
increasing the broade
t
in mixer.
I could imagine adding an option "4" in case.inorb, which is identical
to case 3, but does not write this term.
Would that make sense to you ??
Peter
--
******
Igor Mazin, NRL, code 6390, 4555 Overlook Ave SW, Washing
I've been testing the orbital potential module in the 3rd mode (external
field).
The case.inorb file is as follows:
3 1 1
PRATT 0.2
1 1 2 (for Mo, or 1 3 0 1 2 for Cu)
1000
0.000E+00 0.000E+00 1.00
I am varying the field and plotting th
Earlier this year it was discussed on this list that relativistic
qtl-decomposition does not work as designed:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg15958.html.
In particular, with more than one relativistic atom only the first one
was decomposed properly.
I've proba
Hi,
I am running a pretty standard calculation for the BaFe2As2
superconductor; have done zillions of those before. For testing
purposes, I wanted to plot bands for the double-cell AF structure
(.struct attached), but for the nonmagnetic case and, again, I do think
I did the same before with
d his notes, too, I think.
Best
Igor
On 5/16/2017 9:10 AM, Peter Blaha wrote:
It was quite some time ago when I implemented the scaled Vxc.
I looked again into the paper by Mazin and I'm not completely sure about
his nomenclature about E_xc^P. If I assume that this term is just our
(E_x(
Good time of the day,
I am having a strange problem with the nn module. I have a struct file,
listed below, which was actually generated by WIEN2k some time ago.
Previously determined symmetry group was #22. I verified that it is
correct by reading the struct file into VESTA and exporting it t
you be more specific: Which program "bombs" ? How ?
Peter
Am 13.03.2014 17:56, schrieb mazin:
Hi,
I am working with a C2/m structure, the struct file follows.
It appears that with some sets of a,b,c,gamma WIEN works fine and
produces meaningful results. With some other set it fails t
, Peter Blaha wrote:
With my sources both struct files work without problems (both during
init_lapw as well as for 2 scf cycles).
Are you using version 13 ? (although my version might be updated).
Can you be more specific: Which program "bombs" ? How ?
Peter
Am 13.03.2014 17:56, schrieb
Hi Xavier,
Thanks for your effort, but my problem is unrelated with the one you
refer to.
I have two IDENTICAL struct files, differing only in numerical values
for the lattice parameters (slightly), incidentally, both were generated
by cif2struct, and one of them works and the other doesn't.
Hi,
I am working with a C2/m structure, the struct file follows.
It appears that with some sets of a,b,c,gamma WIEN works fine and
produces meaningful results. With some other set it fails to find the
right symmetry and bombs. An example of the setting that works:
27.031372 26.390653 8.947710
gence in either case, and can verify manually that both
>>>> calculations are fully converged. The problem is therefore unrelated
>>>> to a possible bug in the mixing scheme.
>>>>
>>>
>>
>
--
**
Igor Mazin, NRL, code 6390, 4555 Overlook Ave SW, Washington, DC 20375
Phone: (202) 767-6990; Fax: (202) 404-7546; e-mail mazin at nrl.navy.mil
Home Page http://cst-www.nrl.navy.mil/users/mazin
**
They are identical within 10^-8
On 8/3/2010 11:45 AM, Laurence Marks wrote:
>> I do not see how. I start with the charge densities that in the old version
>> were fully converged, the output was identical to the input.
>>
>
> Is the density matrix converged -- look in case.dmatup_old&
> case.dmatu
I agree. Unfortunately, the opposite is not necessarily true - LDA+U may
converge well, and still be unphysical.
On 8/3/2010 11:36 AM, Laurence Marks wrote:
> One important addendum. If LDA+U is unphysical, it may not converge
> and nothing you do will make it! I ran into something like this some
problem
>> with convergence in either case, and can verify manually that both
>> calculations are fully converged. The problem is therefore unrelated
>> to a possible bug in the mixing scheme.
>>
>
--
******
I
ause they
> are metallic.
> I simply used it to find out why the LDA+U does not work for Ce systems.
>
>
> Laurence,
>
> I just copied the two files you pointed from 10.1 into 9.2 SRC_mixer
> folder, and will report again what I can obtain.
>
>
> Best regards,
>
>
talking
about U on Fe, except that LDA+U is completely unphysical for these
materials.
Igor
--
**
Igor Mazin, NRL, code 6390, 4555 Overlook Ave SW, Washington, DC 20375
Phone: (202) 767-6990; Fax: (202) 404-7546; e-mail mazin at
This may have been already discussed here, but here is the question:
I have a calculation (CeTe3, if that matters) that was 2 years ago
converged with LDA+U (FLL, U=0.32 Ry, J-0) and spin-orbit.
Now if I try to run WIEN2k_09 on these files, it finds the calculation
completely unconverged and eve
mments?
Thanks
Igor
--
**
Igor Mazin, NRL, code 6390, 4555 Overlook Ave SW, Washington, DC 20375
Phone: (202) 767-6990; Fax: (202) 404-7546; e-mail mazin at nrl.navy.mil
Home Page http://cst-www.nrl.navy.mil/users/mazin
**
keywords: Force calculations, R0, Forces and total energy
Thank you Peter,
This solved the problem.
This is one parameter I never ever have paid any attention to, and,
sorry to say, the Users Guide all but ignores it as well.
The w2web by itself does not reset this parameter either, it copies
SO is of course physically important, but irrelevant for my question:
the forces should be consistent with the total energy withing given
approximation.
There is a problem with describing SOMETHING here, and it may very well
be the 6s electron. Yet it strikes me as unlikely for two reasons:
(1)
Laurence Marks wrote:
> Which version of Wien2k? Centro-symmetric or not? How big is the
> discontinuity at the RMT, and how large are the distances between the
> atoms (if too small there can be problems)? What are the RMT's (maybe
> attach the struct file, as well as in1/in2.
(1) The result
I am calculating a Bi-containing compound, BiOCuS. It has a rather
simple tetragonal structure with two free parameters, Bi (z) and S (z).
When I vary Bi(z) keeping everything else fixed I obtain a well defined
total energy minimum at one z, and a well defined Bu force zero at
another z. Both s
33 matches
Mail list logo
