Are you answering y to the question "Should x=0.6669 ..."?
On 04.05.2024 12:12, Pranjal Nandi wrote:
Dear Fabien,
Thank you.
But I am getting the following error when I am using x xyz2struct
x xyz2struct
Hexagonal lattice detected. The possible rounding errors are removed.
Should
Hi,
You can use the program xyz2struct:
mv Contcar_BaTiO3_relaxed.vasp case.xyz
x xyz2struct
mv xyz2struct.struct case.struct
Then you have to execute init_lapw in step-by-step mode (i.e., with -m
flag for recent WIEN2k versions). At the end you should get the same
struct file as the one that
The file vectorhfdn_old is probably corrupted. Delete it and restart the
calculation.
On 08.02.2024 05:19, shamik chakrabarti wrote:
Dear Wien2k users,
I have started to run -hf for a 16 atom cell. The
simulation was running smoothly while at some time, power failure
occurred
With bash this should be
run_lapw ... >STDOUT 2>&1 &
On 13.09.2023 19:47, Peter Blaha wrote:
I'm using a tcsh. There you would detach a job from the terminal
using:
run_lapw ... >& STDOUT &
The job will continue, even if the terminal closes. All output and
errors are directed into a file
As Peter mentioned, U is applied only inside the atomic spheres. In
general, the details of the implementation of DFT+U depends on the basis
set, which can lead to disagreements between codes that are more
important than for plain LDA or GGA (see
https://doi.org/10.1063/1.4945608).
You wrote
clean_lapw should not be executed if the option -newklist is used for
the second calculation. Otherwise, yes.
In any case, save_lapw should be executed.
-newklist is recommended to reduce the number of iterations.
On 08.08.2023 18:22, shamik chakrabarti wrote:
Dear Wien2k users,
Information can be found in
https://doi.org/10.1103/PhysRevMaterials.3.063602
https://doi.org/10.1103/PhysRevMaterials.2.034005
https://doi.org/10.1002/adts.202200055
and in many others.
On 04.08.2023 12:33, shamik chakrabarti wrote:
Dear Wien2k users,
I have used
In general, both SCAN and HSE06 are not supposed to describe properly
van der Waals interactions. You can probably find a certain number of
DFT papers on chalcogenides providing more detailed answers.
On 29.07.2023 10:31, shamik chakrabarti wrote:
Dear Wien2k users,
We know
Hi,
In principle, mBJ can not be applied to systems with vacuum or an
interface (see section "Modified Becke-Johnson potential (mBJ) for band
gaps" in the user's guide). An alternative is to use lmBJ as you did,
but convergence was not possible. Another possibility is to use mBJ, but
by
It seems that this calculation was never going to converge. Try to run
lmBJ-SOC just after GGA-PBE-SOC (and save_lapw) in the same directory.
Is lmBJ without SOC also showing such problems?
On 24.07.2023 10:04, Burhan Ahmed wrote:
The results from the last 20 iterations (for lmbj calculation)
Could you show how the total energy and distance charge evolve during
the iterations of the lmBJ-SOC calculation (grep for :ENE and DIS in
case.scf)?
Before using lmBJ-SOC, did you succeed to converge a calculation on your
system using another method, like GGA-PBE or lmBJ without SOC? If yes,
Hi,
As mentioned by Peter Blaha, this is not possible to do a calculation
with a hybrid functional using XC_HYB_LDA_*, XC_HYB_GGA_* or
XC_HYB_MGGA_* from Libxc. Actually, without entering into detail, this
is not possible to use Libxc at all for a hybrid calculation (the
results would be
You have to delete case.inm_vresp and case.vresp*. These files are not
used for the functional that you have chosen and may perturb lapw0.
On 27.06.2023 07:08, shamik chakrabarti wrote:
Dear Prof. Blaha,
I have used XC as XC_GGA_X_B86_R EC_LDA VC_LDA in case.in0. When I am
running from w2web
And since you used the -redklist option, the files case.klist_fbz,
case.klist_ibz, case.kgen_ibz and case.outputkgenhf should also be
present. Is it the case?
As Peter mentioned, check if case.inhf is ok. In particular, the number
of bands "nbands" needs to be set large enough (see Sec. 7.7.2
Not enough information is provided. In particular, were the various
files case.klist* and case.kgen* properly generated with the command
"run_kgenhf_lapw -redklist"?
On 21.06.2023 13:47, Brik Hamida wrote:
Dear
I have done hf-SFC calculation for BULK semiconductor and it is well
done.
Then
In case.scf you have to consider the global band gap, ":GAP (global)".
With you struct file this gap is 3.17 eV (still fare from 0.96 eV). The
two other values of the band gap (6.93 eV and 10.37 eV) in case.scf are
for spin-up and spin-down channels.
On 07.06.2023 11:08, shamik chakrabarti
Executing clean_lapw is still preferable to avoid a case.scf file that
contains the info about this 1st wrong iteration.
On 02.06.2023 18:18, Peter Blaha wrote:
Try it out.
Am 02.06.2023 um 14:21 schrieb shamik chakrabarti:
Dear Wien2k users,
Initially I have
Do not forget to upgrade to WIEN2k_23.2, in particular for systems with
atoms having a cubic point group.
On 14.03.2023 18:07, delamora wrote:
Thanks Prof. Marks,
I ran the simple Na BCC and I got
Cholesky INFO = 87
Then Lu Hex
Cholesky INFO = 136
also Cu FCC
Yes, alpha is quite often considered as a tunable parameter. A certain
number of papers on that topic have been published, e.g.,
https://aip.scitation.org/doi/10.1063/1.4722993
More papers can be found with google (https://www.google.com) with
keywords like "hybrid functionals" and "fraction
It is on my to-do list to reimplement ELF in VASP in a more proper way.
In any case, it seems that ELF was buggy in a certain number of codes
(WIEN2k, VASP, Quantum Espresso).
On 04.11.2022 22:06, Kateryna Foyevtsova wrote:
Hello,
since I see that VASP results are being discussed here, I'd
Hello,
Before the bug fix, create_elf_lapw and create_rho.f were producing a
wrong ELF function in the non-spin-polarized case. However, with the bug
fix sent previously this is now in the spin-polarized case that ELF is
wrong. We will fix the problem for both cases and probably send the
I don't think that it is worth using the FSM method. The calculation
started with non-zero moments (FM state) which at the end disappeared,
which is already an indication (at least with PBE). In addition,
magnetism in solids is usually expected when there are transition-metal
atoms, which is
Dear Pascal,
Depending on the system it may be possible to stabilize more than one
magnetic state. In such cases, the magnetic state obtained at the end of
the calculation typically depends on the initial magnetic state when
starting the calculation. What was the initial magnetic state in
Both in spin-polarized and non-spin-polarized calculations, nband is the
number of orbitals per spin.
On 29.10.2022 19:24, Peter Blaha wrote:
It is number of orbitals per spin.
Am 29.10.2022 um 19:07 schrieb pboulet:
Dear all,
I have a question regarding the number of orbitals to set in the
About magnetism with mBJ:
https://journals.aps.org/prb/abstract/10.1103/PhysRevB.83.195134
https://journals.aps.org/prb/abstract/10.1103/PhysRevB.87.045103
https://journals.aps.org/prb/abstract/10.1103/PhysRevB.102.024407
On 21.09.2022 19:16, shamik chakrabarti wrote:
Dear Wien2k users,
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg06561.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg03239.html
On 06.09.2022 18:06, Xudong Huai wrote:
Dear WIEN2k users,
I am running a PBE+SP+SOC calculation on MnSi.
The OS is Rocky Linux 8.6. WIEN2k
This type is not yet available in WIEN2k. The forces would be easier to
implement, but with probably numerical difficulties because of the high
derivatives of rho.
On 29.06.2022 22:30, Laurence Marks wrote:
Not even SCANL?
On Wed, Jun 29, 2022 at 3:20 PM wrote:
https://doi.org/10.1103/PhysRevB.105.195138
No forces at the moment and probably not easy to have them.
On 29.06.2022 22:14, Laurence Marks wrote:
I am ever hopeful! While the energy is useful, really want to have it
be self-consistent with forces.
--
Professor Laurence Marks
Department of
Please have a look at Sec. III and Table II in
https://publik.tuwien.ac.at/files/publik_289949.pdf
On 25.06.2022 08:45, reyhaneh ebrahimi wrote:
Dear WIEN2k users;
Would you please let me know why for an antiferromagnetic system, as
stated in
In https://publik.tuwien.ac.at/files/publik_289949.pdf
we used the AIM method to calculate the magnetic moment and on page 9 we
wrote:
"The contribution from the interstitial region is one order of magnitude
smaller and has opposite sign (negative), which is due to reverse
polarization of the
Yes, this should be the most simple procedure to follow: first optimize
the geometry with PBE and then use HSE06 with TEMP.
Besides, with PBE you can check what is the influence of using TETRA or
TEMP on the final property that you want to calculate.
On 21.06.2022 14:39, shamik chakrabarti
For a metal the total energies obtained with TETRA and TEMP will be
different.
If there is no way to achieve convergence with TETRA, then all
calculations should be done with TEMP.
On 21.06.2022 14:11, shamik chakrabarti wrote:
Dear Wien2k users,
We know the total
Not only the last 72th iteration, but all 72 iterations. I want to see
how :ENE and :DIS behave.
On 15.06.2022 11:09, shamik chakrabarti wrote:
ENE and :DIS of the 72 iterations
Analysis of parameter:
:ENE :DIS
in GN_Li_TEMP_TETRA.scf (showing last 1 / 1 lines)
--- ENE ---
:ENE :
Can you show :ENE and :DIS of the 72 iterations.
On 15.06.2022 10:55, shamik chakrabarti wrote:
Dear Prof. Blaha & Tran,
Following your advice I have done the
followings;
(1) Use HSE06 with alpha=0.25, TEMP in case.in2c & got converged
solution.
(2) After convergence
In general, the total energies that are compared need to be obtained
with the same setting. So, all the total energies have to be obtained
with either TETRA or TEMP.
You can try to restart with TETRA the calculation that you converged
with TEMP (clean_lapw should not be executed after the
If the calculation really did not seem to converge (:ENE was oscillating
or :DIS was staying at some high value for ever) then yes it may be
better to delete the case.vector files with clean_lapw and regenerate
case.clmsum in some way (with dstart or with some functional, PBE or
PBE+U).
I
36 matches
Mail list logo
