Re: [Wien] XCrySDen

[delamora]

Dear Tone,
You said;
"This annoying issue will be fixed in the next release"
I feel that this issue is not with XCrySDen but with "linux fedora 6.4.7"
Tanks again

Pablo

Thank you,
I updated my linux fedora;

with
linux fedora 6.2.15
there is no problem

but
with
linux fedora 6.4.7
the letters are quite small
-
Linux fedora 6.2.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 16:51:53 
UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

 > Linux fedora 6.4.7-100.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 27
> 19:56:37 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux


De: Wien  en nombre de Tone Kokalj 

Enviado: jueves, 17 de agosto de 2023 04:10 a. m.
Para: wien@zeus.theochem.tuwien.ac.at 
Asunto: Re: [Wien] XCrySDen

Dear Pablo,

You only upgraded the OS, or you got a new computer with a high screen
resolution, such as Quad HD (2,560×1,440) or Ultra HD (3,840×2,160).
For such high resolutions, xcrysden appearance is indeed awkward (too
small). This annoying issue will be fixed in the next release.

Best regards,
Tone
--
Jožef Stefan Institute, Ljubljana, Slovenia

On Wed, 2023-08-09 at 18:36 +, delamora wrote:
> I am having problems with XCrySDen; the figures and the letters are
> very small.
> I have the Fedora Linux;
> ---
> Linux fedora 6.4.7-100.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 27
> 19:56:37 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
> ---
> In earlier versions I did not have this problem
>
> Saludos
>
> Pablo
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.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
___
Wien mailing list
Wien@zeus.theochem.tuwien.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
___
Wien mailing list
Wien@zeus.theochem.tuwien.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

[Wien] XCrySDen

[delamora]

Thank you,
I updated my linux fedora;

with
linux fedora 6.2.15
there is no problem

but
with
linux fedora 6.4.7
the letters are quite small
-
Linux fedora 6.2.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 16:51:53 
UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

 > Linux fedora 6.4.7-100.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 27
> 19:56:37 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux


De: Wien  en nombre de Tone Kokalj 

Enviado: jueves, 17 de agosto de 2023 04:10 a. m.
Para: wien@zeus.theochem.tuwien.ac.at 
Asunto: Re: [Wien] XCrySDen

Dear Pablo,

You only upgraded the OS, or you got a new computer with a high screen
resolution, such as Quad HD (2,560×1,440) or Ultra HD (3,840×2,160).
For such high resolutions, xcrysden appearance is indeed awkward (too
small). This annoying issue will be fixed in the next release.

Best regards,
Tone
--
Jožef Stefan Institute, Ljubljana, Slovenia

On Wed, 2023-08-09 at 18:36 +, delamora wrote:
> I am having problems with XCrySDen; the figures and the letters are
> very small.
> I have the Fedora Linux;
> ---
> Linux fedora 6.4.7-100.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 27
> 19:56:37 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
> ---
> In earlier versions I did not have this problem
>
> Saludos
>
> Pablo
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.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
___
Wien mailing list
Wien@zeus.theochem.tuwien.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
___
Wien mailing list
Wien@zeus.theochem.tuwien.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

Re: [Wien] Optimized lattice constants using pbe+U

[Park, Ken]

Thank you for the reference and the suggestion to test for k-mesh and gmax. I 
will check for the convergence on those parameters.
Ken

From: Wien  on behalf of 
fabien.t...@vasp.at 
Date: Monday, August 28, 2023 at 3:01 AM
To: A Mailing list for WIEN2k users 
Subject: Re: [Wien] Optimized lattice constants using pbe+U
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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.1063%2F1.4945608=05%7C01%7CKenneth_Park%40baylor.edu%7C9c56ac9a53554583d76b08dba79cfdd0%7C22d2fb35256a459bbcf4dc23d42dc0a4%7C0%7C0%7C638288064986024084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=YdiCdZbFIO4Ty0PvpPvIo%2BSaNNmOjsKwxl3i0fugsu8%3D=0).

You wrote that you used the default k-mesh and gmax. You should also
test these parameters.


On 25.08.2023 18:48, Peter Blaha wrote:
> Hard to say without repeating the calculations, but:
>
> a) I see nothing wrong in your calculation setups/procedure
> b) I've seen previously VERY wrong PBE+U results using VASP in other
> cases. VASP potentials have been optimized for PBE (and probably for
> HSE), and those results are usually ok, but I don't know about PBE+U.
> c) At the time when the rutile/anatase stability problem came up, I
> let a student try if PBE+U could fix it. It did not do it. But this is
> long time ago.
>
> Maybe repeat one U value with a significantly larger RMT for Ti. Note
> that the Hubbard-U is applied only within the spheres in WIEN2k and
> since the Ti-3d states are not too localized, there might be an
> effect.
>
> Am 24.08.2023 um 17:55 schrieb Park, Ken:
>> Dear Wien2k experts,
>>
>> I have been studying the effect of the Hubbard U on various phases of
>> TiO2 using wien2k 23.2. I have observed that some calculated
>> properties are different from those reported in literature (mostly
>> with pseudopotential) and would like to get your suggestions to see if
>> I have made a mistake.
>>
>> For rutile TiO2 using pbe, my optimized lattice constants are a=4.648
>> Å and c=2.966Å, which are close to the published result of 4.650 and
>> 2.968 [1]. However, after I added U= 6eV and ran the optimization, I
>> obtained a=4.655 Å and c=3.000Å, in contrast to a=4.687Å and c=3.042Å
>> for U=5 eV in [1].
>>
>> [1]
>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpubs.aip.org%2Faip%2Fjcp%2Farticle%2F135%2F5%2F054503%2F190719%2FDFT-U-calculations-of-crystal-lattice-electronic=05%7C01%7CKenneth_Park%40baylor.edu%7C9c56ac9a53554583d76b08dba79cfdd0%7C22d2fb35256a459bbcf4dc23d42dc0a4%7C0%7C0%7C638288064986024084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Kc5ldWHNNsFFyiClwl4RQsMULabwGTsSYUdmHAKjdN0%3D=0
>> >
>>
>> So I performed a systemic study using U=3, 5, 8, 10 eV as in [1] and
>> obtained the following:
>>
>> U=3a=4.650c=2.985vs U=3
>>a=4.671c=3.012 [1]
>>
>> U=5a=4.649c=2.995 vs
>> U=5   a=4.687c=3.042 [1]
>>
>> U=8a=4.652c=3.011vs
>> U=8   a=4.709c=3.081 [1]
>>
>> U=10 a=4.655c=3.021vs
>> U=10a=4.725c=3.108 [1]
>>
>> The lattice constant a is nearly constant or expanded very little
>> despite the increasing U whereas the constant c shows a similar
>> increase albeit by smaller amount. In rutile, c is the direction of
>> the Ti-Ti short chain.
>>
>> I have checked the band gaps and they are comparable with the reported
>> results.
>>
>> U=32.24 eV vs U=3  2.15 eV [1]
>>
>> U=52.42 eV vs U=5   2.3 eV
>> [1]
>>
>> U=82.72 eV vs U=8   2.7 eV [1]
>>
>> U=10 2.98 eV vs U=102.92 eV [1]
>>
>> For your information, I have copied the input 

Re: [Wien] Optimized lattice constants using pbe+U

[fabien . tran]

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 that you used the default k-mesh and gmax. You should also 
test these parameters.



On 25.08.2023 18:48, Peter Blaha wrote:

Hard to say without repeating the calculations, but:

a) I see nothing wrong in your calculation setups/procedure
b) I've seen previously VERY wrong PBE+U results using VASP in other
cases. VASP potentials have been optimized for PBE (and probably for
HSE), and those results are usually ok, but I don't know about PBE+U.
c) At the time when the rutile/anatase stability problem came up, I
let a student try if PBE+U could fix it. It did not do it. But this is
long time ago.

Maybe repeat one U value with a significantly larger RMT for Ti. Note
that the Hubbard-U is applied only within the spheres in WIEN2k and
since the Ti-3d states are not too localized, there might be an
effect.

Am 24.08.2023 um 17:55 schrieb Park, Ken:

Dear Wien2k experts,

I have been studying the effect of the Hubbard U on various phases of 
TiO2 using wien2k 23.2. I have observed that some calculated 
properties are different from those reported in literature (mostly 
with pseudopotential) and would like to get your suggestions to see if 
I have made a mistake.


For rutile TiO2 using pbe, my optimized lattice constants are a=4.648 
Å and c=2.966Å, which are close to the published result of 4.650 and 
2.968 [1]. However, after I added U= 6eV and ran the optimization, I 
obtained a=4.655 Å and c=3.000Å, in contrast to a=4.687Å and c=3.042Å 
for U=5 eV in [1].


[1] 
https://pubs.aip.org/aip/jcp/article/135/5/054503/190719/DFT-U-calculations-of-crystal-lattice-electronic 



So I performed a systemic study using U=3, 5, 8, 10 eV as in [1] and 
obtained the following:


U=3    a=4.650    c=2.985    vs U=3
   a=4.671    c=3.012 [1]


U=5    a=4.649    c=2.995     vs 
U=5   a=4.687    c=3.042 [1]


U=8    a=4.652    c=3.011    vs 
U=8   a=4.709    c=3.081 [1]


U=10 a=4.655    c=3.021    vs 
U=10    a=4.725    c=3.108 [1]


The lattice constant a is nearly constant or expanded very little 
despite the increasing U whereas the constant c shows a similar 
increase albeit by smaller amount. In rutile, c is the direction of 
the Ti-Ti short chain.


I have checked the band gaps and they are comparable with the reported 
results.


U=3    2.24 eV vs U=3      2.15 eV [1]

U=5    2.42 eV vs U=5   2.3 eV  
[1]


U=8    2.72 eV vs U=8   2.7 eV [1]

U=10 2.98 eV vs U=10    2.92 eV [1]

For your information, I have copied the input files case.inorb and 
case.indm and the top portion of the structure file.


   1  1  0 nmod, natorb, ipr

PRATT  1.0    BROYD/PRATT, mixing

   1 1 2  iatom nlorb, lorb

   1  nsic 0..AMF, 1..SIC, 2..HFM

    0.44 0.00    U J (Ry)   Note: you can also use U_eff = U-J and 
J=0


-12.  Emin cutoff energy

1   number of atoms for which density matrix is 
calculated


1  1  2  index of 1st atom, number of L's, L1

0 0   r-index, (l,s)index

TiO2

P    2

  RELA

   8.788126  8.788126  5.669865 90.00 90.00 90.00

ATOM  -1: X=0. Y=0. Z=0.

   MULT= 2  ISPLIT= 8

   -1: X=0.5000 Y=0.5000 Z=0.5000

Ti     NPT=  781  R0=0.5000 RMT=    1.7800   Z:  22.0

  0.7071068 0.7071068 0.000

     -0.7071068 0.7071068 0.000

  0.000 0.000 1.000

ATOM  -2: X=0.30509790 Y=0.30509790 Z=0.

   MULT= 4  ISPLIT= 8

   -2: X=0.69490210 Y=0.69490210 Z=0.

   -2: X=0.19490210 Y=0.80509790 Z=0.5000

   -2: X=0.80509790 Y=0.19490210 Z=0.5000

O  NPT=  781  R0=0.0001 RMT=    1.6100   Z:   8.0

  0.000-0.7071068 0.7071068

  0.000 0.7071068 0.7071068

     -1.000 0.000 0.000

   16  NUMBER OF SYMMETRY OPERATIONS

I optimized the structure with ‘runsp_lapw -p -orb -min -ec 0.1 
-cc 0.0001 -fc 1’ (or smaller fc) using rkmax 9 (or 10 to check for 
convergence) and default values such as k-mesh and gmax. I 

Re: [Wien] Speeding up calculations in parallel mose

[Victor Zenou]

Hi

I didn't use the new batch type mode, as I'm sorry to say I've never heard
about it till now.

I used 0.85, 1.0 and 1.8 RMT's for H, He and W, respectively.

Yes, no inversion symmetry as I choose primitive cell, each time filled
with 1 H atom and/or a He atom, at different location/s.

I found that 125 k-points (63 IBZ) are good enough for the convergence
criterions I wanted: 0.001 ec and 0.01 cc.



I used:

W-H: Rmt*Kmax=3

W-He: Rmt*Kmax=3*1/0.85=3.5

W: Rmt*Kmax=3*1.8/0.85=6.35





However  Rmt*Kmax for W should be ~8, In that case:

W: Rmt*Kmax=8

W-H: Rmt*Kmax=8*0.85/1.8=3.77

W-He: Rmt*Kmax=8*1/1.8=4.44





I will check the strategy you suggested, and re-check my parameters.

Thanks,

Victor

‫בתאריך שבת, 26 באוג׳ 2023 ב-15:00 מאת ‪Peter Blaha‬‏ <‪
peter.bl...@tuwien.ac.at‬‏>:‬

> Well, we get only part of the information each time.
>
> You are using a 3x3x3 W supercell with H/He interstitials.
>
> How did you initialize the calculation ?  Hopefully in the new batch
> type mode with a low precision (0 or 1) !!  If not, then:
>
> RKMAX=5.4 seems still very big for the presumably small H/He spheres.
> What are the RMTs (set by the program).
> If they are small (0.6-1.0 bohr), a much smaller RKMAX (3-4 ?) can be
> used. This may make your calculations 100 times faster.
>
> 125 k-points: are these the IBZ points (case.klist) - sounds quite too
> many-, or what you put as input to  x kgen ?
> And as was said before: Of course you should use k-parallelization.
>
> Remember: the benchmark test case has 36 atoms/cell and needs 20
> seconds/k-point. Your system is bigger (55 atoms), so make it 100
> seconds/k-point.
> No Inversion symmetry ?, low packing, .. may cost another factor of 2-4
>
> So this makes ~ 5 min/k-point, i.e. with  125 k-points and 8 cores one
> scf cycle should take roughly 1 hour.
>
> Remember the general strategy:
> First run with "minimum parameters" (init_lapw -prec 0), check timing
> and possible parallelization.
> Save the calculation, increase k-points and/or RKmax and continue (never
> do a full init_lapw again, maybe use init_lapw -prec XX -nodstart)
>
>
> Am 23.08.2023 um 07:48 schrieb Victor Zenou:
> > Dear Laurie and Pavel,
> > Thanks for your answer
> > 1. In fact I'm using RKMAX 5.4 and 125 kpts
> > 0.01 cc and 0.001 ec
> >
> >
> > 2. About my boss, it took me more than one year to get a new computer.
> > Please define "fast"!
> > Victor
> >
> >
> > ‫בתאריך יום ג׳, 22 באוג׳ 2023 ב-14:35 מאת ‪Laurence Marks‬‏
> > <‪laurence.ma...@gmail.com ‬‏>:‬
> >
> > Beyond what Pavel said, you are still talking weeks for a
> > calculation. A critical issue is whether you are using sensible
> > parameters. Maney people have used RKMAX 7 and 1000 kpts assuming
> > that those are "right" -- they are not. If your H and He have small
> > RMTs then RKMAX should also be smaller. Also, what is needed is a
> > k-point density, so the number of k-points is less for a supercell.
> >
> > I suggest that you copy your case.struct file to a new directory
> > then do init_lapw in that directory. 23.2 will pick appropriate
> > values for you, and you can then copy them over.
> >
> > Beyond that, get your boss to buy you a faster computer.
> >
> > --
> > Professor Laurence Marks (Laurie)
> > Walter P Murphy Professor Emeritus
> > Department of Materials Science and Engineering, Northwestern
> University
> > www.numis.northwestern.edu 
> > "Research is to see what everybody else has seen, and to think what
> > nobody else has thought" Albert Szent-Györgyi
> >
> > On Tue, Aug 22, 2023, 04:32 Victor Zenou  > > wrote:
> >
> > Dear Wien2k users!
> >
> > I’m investigating a 54 tungsten atoms supercell , with 1 helium
> > atom and 1 hydrogen atom (primitive cell) at different
> > interstitial sites. It takes ~ 46 hr per calculation cycle, and
> > half of it (~23 hr) in parallel mode. The Wien2k version 23.2
> > was installed on Ubuntu 22.04.2 LTS. using gfortran and I set
> > OMP_NUM_THREADS to 1, and used 2 parallel_jobs in the current
> > work. The computer is build from i7-10700 processor @ 2.90GHz (8
> > cores; 16 Threads), 32 GB memory and 500 GB SSD.
> > In the past using the same computer , it took me ~ 14 hr per
> > cycle for the same calculations, meaning 2-4 times faster than
> > today. The wien2k version was 21.1, bur I can’t remember if the
> > calculations were done in parallel, probably yes (I think the
> > number of parallel jobs was chosen automatically), and I think I
> > set OMP_NUM_THREADS to 4, but again I’m not sure.
> > How can I speed up my calculations using the same computer?
> > Best regards, Victor
> >
> > ___
> >