YES! So, I downloaded and compiled 19.2 three days ago, including, for the
first time openblas. However, deep in my .cshrc file, it seems that I'm still
pointing to an older version of WIEN2k. It seems that W2k has stopped putting
$WIENROOT, etc. at the bottom of .cshrc. Now, when I run
What WIEN2k version are you using?
That looks similar to problems we had with older WIEN2k versions [1],
which have been resolved with the latest version (WIEN2k 19.2), when
compiled with gfortran.
[1]
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18106.html
On 5/25/2020
Gavin:
This is what I'm getting:
Names of point group: -43m -43m Td
Number and name of space group: 216 (F -4 3 m)
-> check in GaN_3dc.outputsgroup for proper symmetry, compare
with your struct file and later with GaN_3dc.outputs
sgroup has also produced a new struct file based on your
Are you getting during the "x symmetry" step of init_lapw that it "does
not contain inversion"?
-> continue with symmetry (old case.struct) or use/edit
GaN_3db.struct_sgroup ? (c/e)
c
next is symmetry
> symmetry (14:50:47) SPACE GROUP DOES NOT CONTAIN INVERSION
0.0u 0.0s 0:00.03
Gavin:
Thanks for your response.
Fopr some reason, when I run this I don't get a message that there is no
inversion. Here is the snippet.
-> continue with kgen or edit the GaN_3dc.inst file and rerun lstart (c/e)
c
-> in GaN_3dc.in1_st select RKmax ( usually 5.0 - 9.0 ), LVNS and LOs
Dear Sir,
Thank you so much for your solution. It converges smoothly.
with kind regards,
On Mon, 25 May 2020 at 19:08, Peter Blaha
wrote:
> No.
>
> The proper solution is to look into case.scf1 and case.scf2
>
> In case.scf2 you can see that the intended EF is:
>
> :FER : F E R
Changes discussed below (proper weighted mixing of up/dn spin channels
when SO coupling is enabled) are now implemented in a new version of
fold2Bloch: https://github.com/rubel75/fold2Bloch-Wien2k
Note: new '-so' execution option and changes in compilation.
gfortran is not tested. Reports are
No.
The proper solution is to look into case.scf1 and case.scf2
In case.scf2 you can see that the intended EF is:
:FER : F E R M I - ENERGY(TETRAH.M.)= -0.2835569073
Edit case.in1 and put instead of 0.3 --> -0.2 for EF (1st line)
Then do another run_lapw and it converges quickly.
Am
Unfortunately the initial density and parameters are sometimes not very
good and leads to ghost bands in the 1st iteration. If you reduce the RMTs
to 2.0 (setrmt case -a O:2.0,Na:2.0 ; cp case*setrmt case.struct) and then
run there will be a warning in the 1st iteration, but for me it ran OK.
FYI, it looks like case.in1(c) and case.in2(c) is automatically created
(in WIEN2k 19.2) around the "inputfiles prepared" when "c" is answered
for the following question:
username@computername:~/wiendata/GaN_3db$ init_lapw
...
-> continue with kgen or edit the GaN_3db.inst file and rerun
Dear Wien2k users,
I have tried to simulate total energy of
Na2O after optimizing its volume. I have obtained Ghost band error at the
first cycle as;
'l2main' - QTL-B.GT.15., Ghostbands, check scf files
In SCF2 file the following line indicates the error;
:WARN :
When you use init_lapw in sequential mode, it asks many questions at
each step. In one of the steps you were asked to copy the generated
input files and you probably did not say yes at that point.
In any case, I recommend to run
x nn(or setrmt case); x sgroup; x symmetry
to check the
Prof Blaha:
Thanks very much for such a quick response.l I was using the command line.
Specifically, Iused init_lapw starting with the .struct file I'm attaching. I
didn't modify any of the files that resulted from the various sub processes. I
woild be glad to send anything else you might find
13 matches
Mail list logo
