Re: [QE-users] not orthogonal operation in dos.x run only
Thanks for the answer, So it is possible for a system to give satisfactory results in optimization calculations, and yet show symmetry problems in further routines? Also, my job using bands.x with the optimized structure for WS2 finished without getting symmetry issues, which does not occur for dos.x and projwfc.x calculations. I will work on your tip and try to see if I can solve this problem by re-submitting relax calculations with better parameters, but it is yet strange to me why the 'not orthogonal operation' crash doesn't appear in vc-relax calc, neither in scf and nscf calculations, and we just take note of it in dos.x and projwfc.x routines. With regards, Lucas. De: users em nome de Paolo Giannozzi Enviado: sábado, 3 de outubro de 2020 13:06 Para: Quantum ESPRESSO users Forum Assunto: Re: [QE-users] not orthogonal operation in dos.x run only Obscure symmetry problems almost invariably come from the usage of "free" Bravais lattice (ibrav=0) and almost-symmetric-but-not-enough lattice vectors, or by almost-symmetric-but-not-enough atomic positions Paolo On Sat, Oct 3, 2020 at 6:36 PM Lucas Dória mailto:lucasdoriacarva...@hotmail.com>> wrote: Dear all, I ran into this problem while doing a dos.x calculation (nscf and scf calculations finished succesfully): 'from checkallsym : error # 2 not orthogonal operation' The structure is a WS2 bilayer. (WS2 is a layered material, we optimized bulk structure and then added vaccum in z-direction to get bilayer structure.) When i looked up for possible reasons and solutions, I found this problem only occuring in vc-relax calculations. Our group did in fact optimized the hexagonal structure, but vc-relax calculations finished succesfully. I add that we already studied electronic properties of another very similar hexagonal structure, of the same point group, namely MoS2, and we didn't get symmetry issues. (using v5.4 at the time) So, I don't know why this problem of 'not orthogonal operation' is happening to WS2, and just in dos.x calculation, if it's a crash due to symmetry breaking. We think that the only major differences between WS2 and MoS2 are that W is heavier than Mo, and the PP used. But we are using an optimized ecutwfc. Thanks in advance. QE-version used: 6.5. Lucas. ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu<http://www.max-centre.eu>) users mailing list users@lists.quantum-espresso.org<mailto:users@lists.quantum-espresso.org> https://lists.quantum-espresso.org/mailman/listinfo/users -- Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche, Univ. Udine, via delle Scienze 208, 33100 Udine, Italy Phone +39-0432-558216, fax +39-0432-558222 ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] not orthogonal operation in dos.x run only
Dear all, I ran into this problem while doing a dos.x calculation (nscf and scf calculations finished succesfully): 'from checkallsym : error # 2 not orthogonal operation' The structure is a WS2 bilayer. (WS2 is a layered material, we optimized bulk structure and then added vaccum in z-direction to get bilayer structure.) When i looked up for possible reasons and solutions, I found this problem only occuring in vc-relax calculations. Our group did in fact optimized the hexagonal structure, but vc-relax calculations finished succesfully. I add that we already studied electronic properties of another very similar hexagonal structure, of the same point group, namely MoS2, and we didn't get symmetry issues. (using v5.4 at the time) So, I don't know why this problem of 'not orthogonal operation' is happening to WS2, and just in dos.x calculation, if it's a crash due to symmetry breaking. We think that the only major differences between WS2 and MoS2 are that W is heavier than Mo, and the PP used. But we are using an optimized ecutwfc. Thanks in advance. QE-version used: 6.5. Lucas. ___ Quantum ESPRESSO is supported by MaX (www.max-centre.eu) users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] Gamma_only case not implemented CRASH
Paolo, thanks for replying.
v.5.4.0.
Regards.
Lucas.
De: users em nome de Paolo Giannozzi
Enviado: quarta-feira, 10 de outubro de 2018 09:30
Para: Quantum Espresso users Forum
Assunto: Re: [QE-users] Gamma_only case not implemented CRASH
QE version?
On Wed, Oct 10, 2018 at 2:01 PM Lucas Dória
mailto:lucasdoriacarva...@hotmail.com>> wrote:
Thanks for your reply, Lorenzo.
The first round of calculations is an scf calculation where I use an automatic
grid of k-points:
&SYSTEM
celldm(1) = 6.04253156,
degauss = 1.0e-02,
ecutrho = 148.,
ecutwfc = 37.,
ibrav = 0,
nat = 7,
nspin = 2,
ntyp = 3,
occupations = 'smearing',
smearing = 'gaussian',
/
&ELECTRONS
conv_thr = 1.0e-10,
electron_maxstep = 200,
mixing_beta = 0.7000,
diagonalization = 'cg',
startingpot = 'atomic',
startingwfc = 'atomic+random',
/
K_POINTS {automatic}
7 7 1 0 0 0
The second one is a band calculation with the k-path calculated with XCrysDen
(Gg M K Gg):
&SYSTEM
celldm(1) = 6.04253156,
degauss = 1.0e-02,
ecutrho = 148.,
ecutwfc = 37.,
ibrav = 0,
nat = 7,
nspin = 2,
ntyp = 3,
occupations = 'smearing',
smearing = 'gaussian',
/
&ELECTRONS
diagonalization = 'cg',
conv_thr = 1.0e-08,
electron_maxstep = 200,
mixing_beta = 4.0e-01,
startingpot = 'atomic',
startingwfc = 'atomic+random',
/
KPOINTS {tpiba_b}
0.00 0.00 0.00 1 1 1
0.50 0.00 0.00 6 1 1
0.33 0.33 0.00 6 6 1
0.00 0.00 0.00 1 1 1
The third and last one is just an input for bands.x:
&BANDS
filband = 'bands.dat',
lsym= .false.,
prefix = 'bands_F',
outdir = '/tmp/scratch/ldoria/saida',
/
Best regards.
Lucas.
De: users
mailto:users-boun...@lists.quantum-espresso.org>>
em nome de Lorenzo Paulatto mailto:paul...@gmail.com>>
Enviado: quarta-feira, 10 de outubro de 2018 04:39
Para: users@lists.quantum-espresso.org<mailto:users@lists.quantum-espresso.org>
Assunto: Re: [QE-users] Gamma_only case not implemented CRASH
Dear Lucas,
please provide you input example (to the list, not to me) because:
1. running bands.x after a calculation at the gamma point only does not
make sense
-or-
2. if you did SCF with gamma only, NSCF with more k-points (which is
questionable but legit) and bands.x afterwards, then this error should
not occur, may be a bug
kind regards
--
Lorenzo Paulatto - Paris
___
users mailing list
users@lists.quantum-espresso.org<mailto:users@lists.quantum-espresso.org>
https://lists.quantum-espresso.org/mailman/listinfo/users
users Info Page -
lists.quantum-espresso.org<https://lists.quantum-espresso.org/mailman/listinfo/users>
lists.quantum-espresso.org<http://lists.quantum-espresso.org>
This is the mailing list for discussions about the Quantum ESPRESSO
distribution. Only registered users can post. To see the collection of prior
postings to the list, visit the users Archives.. Using users
___
users mailing list
users@lists.quantum-espresso.org<mailto:users@lists.quantum-espresso.org>
https://lists.quantum-espresso.org/mailman/listinfo/users
--
Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users
Re: [QE-users] Gamma_only case not implemented CRASH
Thanks for your reply, Lorenzo.
The first round of calculations is an scf calculation where I use an automatic
grid of k-points:
&SYSTEM
celldm(1) = 6.04253156,
degauss = 1.0e-02,
ecutrho = 148.,
ecutwfc = 37.,
ibrav = 0,
nat = 7,
nspin = 2,
ntyp = 3,
occupations = 'smearing',
smearing = 'gaussian',
/
&ELECTRONS
conv_thr = 1.0e-10,
electron_maxstep = 200,
mixing_beta = 0.7000,
diagonalization = 'cg',
startingpot = 'atomic',
startingwfc = 'atomic+random',
/
K_POINTS {automatic}
7 7 1 0 0 0
The second one is a band calculation with the k-path calculated with XCrysDen
(Gg M K Gg):
&SYSTEM
celldm(1) = 6.04253156,
degauss = 1.0e-02,
ecutrho = 148.,
ecutwfc = 37.,
ibrav = 0,
nat = 7,
nspin = 2,
ntyp = 3,
occupations = 'smearing',
smearing = 'gaussian',
/
&ELECTRONS
diagonalization = 'cg',
conv_thr = 1.0e-08,
electron_maxstep = 200,
mixing_beta = 4.0e-01,
startingpot = 'atomic',
startingwfc = 'atomic+random',
/
KPOINTS {tpiba_b}
0.00 0.00 0.00 1 1 1
0.50 0.00 0.00 6 1 1
0.33 0.33 0.00 6 6 1
0.00 0.00 0.00 1 1 1
The third and last one is just an input for bands.x:
&BANDS
filband = 'bands.dat',
lsym= .false.,
prefix = 'bands_F',
outdir = '/tmp/scratch/ldoria/saida',
/
Best regards.
Lucas.
De: users em nome de Lorenzo
Paulatto
Enviado: quarta-feira, 10 de outubro de 2018 04:39
Para: users@lists.quantum-espresso.org
Assunto: Re: [QE-users] Gamma_only case not implemented CRASH
Dear Lucas,
please provide you input example (to the list, not to me) because:
1. running bands.x after a calculation at the gamma point only does not
make sense
-or-
2. if you did SCF with gamma only, NSCF with more k-points (which is
questionable but legit) and bands.x afterwards, then this error should
not occur, may be a bug
kind regards
--
Lorenzo Paulatto - Paris
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users
users Info Page -
lists.quantum-espresso.org
lists.quantum-espresso.org
This is the mailing list for discussions about the Quantum ESPRESSO
distribution. Only registered users can post. To see the collection of prior
postings to the list, visit the users Archives.. Using users
___
users mailing list
users@lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/users
[QE-users] Gamma_only case not implemented CRASH
Hi. I've got this crash during a band structure calculation for MoS2 and I didn't find any solution for it. In the crash file it says "from bandstask # gamma_only case not implemented". The crash was during the third round of calculations (bands.x). I would appreciate any help on the subject. Regards. Lucas. ___ users mailing list users@lists.quantum-espresso.org https://lists.quantum-espresso.org/mailman/listinfo/users
