Activity for Ronald Cohen
-
Ronald Cohen posted a comment on discussion Elk Users
<meta http-equiv="content-type" content="text/html; charset=utf-8">Oh! I wonder if it is possible to implement an error message! Also is it possible to restart an exact exchange calculation? Thanks,Ron—On Jul 19, 2024, at 04:43, J. K. Dewhurst <jkdewhurst@users.sourceforge.net> wrote:Hi Ronald, The HSE functionals require the long- and short-range Hartree-Fock exchange terms. These have not been implemented in Elk as this would require modifying the Poisson solver (zpotcoul.f90) to use the short-range...
-
Am I the only one who has trouble with hybrid calculations?
-
Here is the PBE0 run
-
I have been having no success for HSE06 with elk. I am running elk-9.6.8 with the latest oneapi intel compilers. I have tried about everything , and then I tried PBE0 and it runs. So I tried the hybrid libxc example and it runs fine: elk-9.6.8/examples/hybrids/Si-libxc$ Absolute change in total energy (target) : 0.1512153949E-04 ( 0.1000000000E-03) Energy convergence target achieved +--------------------+ | Loop number : 6 | +--------------------+ Energies : Fermi : 0.211681362873 sum of eigenvalues...
-
Dear Kay, Thank you so much! I had tried this earlier (you can see the commented out line in my elk.in). However I tried exactly your input file, and it does not work for me. The PBE converges fine, but the HF part task 5 does as follows. The target goes like this: rep target HF_INFO.OUT Absolute change in total energy (target) : 4.699178223 ( 0.1000000000E-03) Absolute change in total energy (target) : 6.524259950 ( 0.1000000000E-03) Absolute change in total energy (target) : 9.371628272 ( 0.1000000000E-03)...
-
The only hope that the runs are OK it seems to me is if elk disregards states that are already included in the core by setting a window and ignoring states below the window. This is how old LAPW codes worked. But I don't see that in elk--or is it? Thank you! Ron Ron Cohen recohen3@gmail.com https://recohen.blogspot.com On Mon, May 13, 2024 at 9:53 AM Ronald Cohen recohen3@gmail.com wrote: Dear Kay, Thank you so much! I had tried this earlier (you can see the commented out line in my elk.in). However...
-
I have having a problem with Lu that core states appear in hybrid calculations like PBE0. It is fine in PBE, but with iterations 4p and 4d are found in the valence. Warning(occupy): minimum eigenvalue less than minimum linearisation energy : -14.22326255 -4.238300000 EVALCORE.OUT Species : 1 (Lu), atom : 1 n = 1, l = 0, k = 1 : -2320.822586 n = 2, l = 0, k = 1 : -394.4288090 n = 2, l = 1, k = 1 : -376.4056102 n = 2, l = 1, k = 2 : -335.3327253 n = 3, l = 0, k = 1 : -89.02595660 n = 3, l = 1, k =...
-
I am wondering about the definiation of the two Broyden parameters in broydpm. Broyden mixing parameters α and w0 real (0:4; 0:15) The first I think is the mixing parameter (like for the first iteration) but I am not clear about the second. In my tests increasing it to 0.5 or 0.6 sometimes increases stability, but the examples of hard to converge cases in the forum seem to use small numbers like 0.01 for the second parameter which does not seem to help for me. I also don't understand why I find that...
-
I have been having trouble getting OEP to work for a couple different systems, so I went back to the Si example in elk-9.5.1 and it also doesn't converge: RMS change in Kohn-Sham potential (target) : 11.58361336 ( 0.1000000000E-05) RMS change in Kohn-Sham potential (target) : 13.28714671 ( 0.1000000000E-05) RMS change in Kohn-Sham potential (target) : 10.69694822 ( 0.1000000000E-05) RMS change in Kohn-Sham potential (target) : 9.276959330 ( 0.1000000000E-05) RMS change in Kohn-Sham potential (target)...
-
I spoke with the pyprocar developers and they promise to fix (write a new parser) for elk in pyprocar, and verified it is not working now. Ron On Apr 14, 2024, at 5:00 AM, J. K. Dewhurst jkdewhurst@users.sourceforge.net wrote: That link appears to be dead. Elk is still listed among the supported codes here: https://github.com/romerogroup/pyprocar Regards, Kay. pyprocar for elk? https://sourceforge.net/p/elk/discussion/897820/thread/96d66b3602/?limit=50#85c0 Sent from sourceforge.net because you indicated...
-
Pyprocar is listed on the elk website, but when I try to use pyprocar it fails for elk, and elk is not listed anymore in its list of parsers at https://romerogroup.github.io/pyprocar/api/io/index.htm . Does anyone know how to use pyprocar for elk? Is there another package or script which will plot nice labeled dos's from elk? Thanks! Sincerely, Ron
-
My apologies on this whole thread! The code is fine. It was the compilation that failed--a typo in my make.inc! Ron On Apr 1, 2024, at 1:58 PM, Ronald Cohen recohen3@users.sourceforge.net wrote: scratch that--looking some more. May be a complicatino problem! Ron On Apr 1, 2024, at 1:45 PM, Ronald Cohen recohen3@users.sourceforge.net recohen3@users.sourceforge.net wrote: It seems intel will not use OMP parallelization for this loop in oepvcl.f90: $OMP PARALLEL DO DEFAULT(SHARED) & !$OMP NUM_THREADS(nthd)...
-
scratch that--looking some more. May be a complicatino problem! Ron On Apr 1, 2024, at 1:45 PM, Ronald Cohen recohen3@users.sourceforge.net wrote: It seems intel will not use OMP parallelization for this loop in oepvcl.f90: $OMP PARALLEL DO DEFAULT(SHARED) & !$OMP NUM_THREADS(nthd) SCHEDULE(DYNAMIC) do ik=1,nkpt ! distribute among MPI processes if (mod(ik-1,np_mpi) /= lp_mpi) cycle !$OMP CRITICAL(oepvcl_) write(*,'("Info(oepvcl): ",I6," of ",I6," k-points")') ik,nkpt !$OMP END CRITICAL(oepvcl_) call...
-
It seems intel will not use OMP parallelization for this loop in oepvcl.f90: $OMP PARALLEL DO DEFAULT(SHARED) & !$OMP NUM_THREADS(nthd) SCHEDULE(DYNAMIC) do ik=1,nkpt ! distribute among MPI processes if (mod(ik-1,np_mpi) /= lp_mpi) cycle !$OMP CRITICAL(oepvcl_) write(*,'("Info(oepvcl): ",I6," of ",I6," k-points")') ik,nkpt !$OMP END CRITICAL(oepvcl_) call oepvclk(ik,vclcv(:,:,:,ik),vclvv(:,:,ik)) end do !$OMP END PARALLEL DO On Apr 1, 2024, at 1:03 PM, Ronald Cohen recohen3@users.sourceforge.net...
-
No I am running this test on a single node. I tried both ifx and ifort compilers. It is going to exactly 100%--one thread--not a hair over. Ron On Apr 1, 2024, at 11:59 AM, J. K. Dewhurst jkdewhurst@users.sourceforge.net wrote: Hi Ron, Are you running on multiple nodes? If so then it could be a filesystem bottleneck. Performance Regression v8->v9 https://sourceforge.net/p/elk/discussion/897820/thread/e2b34b6191/?limit=50#1e5c Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/elk/discussion/897820/...
-
I added this as you suggest, but still does the same thing: 1328993 rcohen 20 0 245532 26640 12616 S 0.0 0.0 0:00.00 elk 1328993 rcohen 20 0 20.3g 435384 33416 R 2338 0.3 3:54.26 elk 1328993 rcohen 20 0 20.4g 505088 33416 R 3189 0.4 9:14.43 elk 1328993 rcohen 20 0 20.6g 603700 34152 R 1361 0.5 11:30.97 elk 1328993 rcohen 20 0 20.6g 603700 34152 R 99.7 0.5 11:40.96 elk 1328993 rcohen 20 0 20.6g 603700 34152 R 99.6 0.5 11:50.94 elk 1328993 rcohen 20 0 20.6g 603712 34164 R 99.5 0.5 12:00.92 elk 1328993...
-
This only happenes when I try OEP! If I change: xctype -20 to xctype 20 I get the expected performance: carnegie/nobackup/users/rcohen/ELK/LuH2/Fluorite/OEP/LuH3/chgexs0.5$ grep elk log.dat 1323034 rcohen 20 0 241676 26352 12400 S 0.0 0.0 0:00.00 elk 1323972 rcohen 20 0 241680 26204 12200 S 0.0 0.0 0:00.00 elk 1323972 rcohen 20 0 20.3g 448988 32644 R 2230 0.3 3:43.48 elk 1323972 rcohen 20 0 20.3g 500520 32648 R 2782 0.4 8:22.20 elk 1323972 rcohen 20 0 20.4g 551672 33500 R 2934 0.4 13:16.14 elk 1323972...
-
and 8.7.10. Very strange.
-
Actually I have this same problem with 8.8.26: grep elk log.dat 1318993 rcohen 20 0 245608 28360 12288 S 0.0 0.0 0:00.00 elk 1318993 rcohen 20 0 20.3g 440452 32700 R 2341 0.3 3:54.60 elk 1318993 rcohen 20 0 20.4g 507720 32776 R 3187 0.4 9:13.97 elk 1318993 rcohen 20 0 20.4g 557324 32776 R 2774 0.4 13:52.18 elk 1318993 rcohen 20 0 20.6g 635700 33488 R 99.7 0.5 14:02.17 elk 1318993 rcohen 20 0 20.6g 635700 33488 R 99.8 0.5 14:12.17 elk 1318993 rcohen 20 0 20.6g 635700 33488 R 99.7 0.5 14:22.16 elk...
-
Actually I have the same problem with elk 9.4.2. Here is a log showing cpu usage on a n excusive node: /carnegie/nobackup/users/rcohen/ELK/LuH2/Fluorite/OEP/LuH3/chgexs0.5$ grep elk log.dat 1382219 rcohen 20 0 245536 26620 12600 S 0.0 0.0 0:00.02 elk 1382219 rcohen 20 0 20.5g 547880 35964 R 2307 0.2 3:51.64 elk 1382219 rcohen 20 0 20.6g 620884 36120 R 3183 0.2 9:10.89 elk 1382219 rcohen 20 0 20.8g 721564 37108 R 1701 0.3 12:01.70 elk 1382219 rcohen 20 0 20.8g 721564 37108 R 99.7 0.3 12:11.71 elk...
-
I am having a similar problem to this, with the number of threads used dropping to 1 per process after a short time. I am running though 9.5.1 so it is not this problem but perhaps something similar somewhere else. The problem occurs during the very first k-point. Here is my input:
-
<meta http-equiv="content-type" content="text/html; charset=utf-8">Thank you do much!Yes, scf seems fine. But the bands are wrong. Maybe it is only a problem with the band part task 20 etc. Sincerely,Ron—On Mar 10, 2024, at 16:13, J. K. Dewhurst <jkdewhurst@users.sourceforge.net> wrote:I also ran your input file, and all seems fine. With bfcmt in the z-direction the moment is 0.988977 and the total energy is -9364.65282064 Ha. In the x-direction the moment is 0.9855975 and the total energy is -9364.65275900...
-
Finally, for the line M' - Gamma - M, that is -1/2 1/2 0 to 000 to 1/2 1/2 0. it is clear with moment along BX the bands are completely wrong, and correct for BZ. I think all this means that elk has a problem for moments not along Z. I consider this a bug, not a problem with my physics understanding! But please convince me otherwise as needed!
-
Finally, for the line M' - Gamma - M, it is clear with moment along BX the bands are completely wrong, and correct for BZ. I think all this means that elk has a problem for moments not along Z. I consider this a bug, not a problem with my physics understanding! But please convince me otherwise as needed!
-
When I do spin-orbit, I get agreeement with the bands for Z non-relativistic, but disagreement for X and XYZ! This is particularly apparent at the M point.
-
When I do spin-orbit, I get agreeement with the bands for Z non-relativistic, but disagreement for X and XYZ! This is particularly apparent at the M point.
-
So I am a bit bamboolzed. If I use a initial magnetic field along X, Z, or XYZ I gtet the same energy as expected when the field is removed, but the bands are different. For X there is no altermagnetic effect. For Z and XYZ there is, but the bands seem different. Something must be wrong with my understanding! Can anyone clarify? INFOX.OUT: total energy : -9364.65275944 INFOXYZ.OUT: total energy : -9364.65272507 INFOZ.OUT: total energy : -9364.65269883 Moments: INFOX.OUT- species : 1 (Ru) INFOX.OUT-...
-
So yes RuO2 needs U to et a moment like Ali said above (and the literature!). But in any case I ran FeO2 and the original problem still stands with elk--if I set the mooment along z I see the spin splitting but a moment along x doesn't, and in the non-relativistic case it shouldn't matter. So I am still puzzled.
-
Yes, it is me! Thanks for your suggestion--it worked! But I still don't understand why. In SYMCRYS.OUT I get all 16 operations 16 : nsymcrys regardless of the chosen field direction. But the results are "correct" only if I choose z. Ron
-
So I ran FeO2 by mistake! But indeed the spin directiuno did matter! When I put the moment in the z direction I got the splitting but not in the x direction. That doesn't make sense for me for non-relativistic! What am I missing. Thank you! Ron
-
There should be spin-splitting of the up and down bands in antiferromagnetic RuO2 (see for example Fedchenko et al.Sci Adv 10, eadj4883, doi:10.1126/sciadv.adj4883 2024). However I get no spin splitting--compare with their Fig. 1. I also tried running with no symmetry using reduceh .false. reducek 0 . Also, a side issue is that I was surprised to see that the spacegroup utility put the c axis first (see attached). I changed it to the 3rd axis so band plots come out correctly. I wonder whjy it chooses...
-
There should be spin-splitting of the up and down bands in antiferromagnetic RuO2 (see for example Fedchenko et al.Sci Adv 10, eadj4883, doi:10.1126/sciadv.adj4883 2024). However I get no spin splitting--compare with their Fig. 1. I also tried running with no symmetry using reduceh .false. reducek 0 . Also, a side issue is that I was surprised to see that the spacegroup utility put the c axis first (see attached). I changed it to the 3rd axis so bank plot come out correctly. I wonder whjy it chooses...
-
Thank you so much! I do have access to large machines, but the otyher problem I have is that the convergence oscillates like this: bsolute change in total energy (target) : 6.554113021 ( 0.1000000000E-03) total energy : -28399.1499896 Absolute change in total energy (target) : 6.553441428 ( 0.1000000000E-03) total energy : -28405.7057107 Absolute change in total energy (target) : 6.555721077 ( 0.1000000000E-03) total energy : -28399.1489469 Absolute change in total energy (target) : 6.556763823 (...
-
I am trying to understand the implementation of OEP and HF in elk. In Betzinger et al PRB 2011 on OEP it seems the equations are all diagonal in k (unless I missed something), but in the code it seems there is a sum over k and k' (gridk and gridq . (Is this right). Where does the sum over k' come from? Is there a better reference? (It would be very useful to have a list of references for different techniques in ELK. Is there? ) Also it is not clear to me the inner loop and why so many iterations...
-
I am trying to understand the implementation of OEP and HF in elk. In Betzinger et al PRB 2011 on OEP it seems the equations are all diagonal in k (unless I missed something), but in the code it seems there is a sum over k and k' (gridk and gridq . (Is this right). Where does the sum over k' come from? Is there a better reference? (It would be very useful to have a list of references for different techniques in ELK. Is there? ) Also it is not clear to me the inner loop and why so many iterations...
-
It is not clear how to continue a Hartree-Fock (HF) or Hybrid run. When I continue with task 5 it starts over. Is there a way to continue? These runs can be very slow and take more than the queue time limit to converge. Thank you, Sincerely, Ron Cohen
-
Meant to add this, Ron
-
In answer o my own question, it seems to work.
-
For a hybrid DOS, can I just use tasks 0 5 10 xctype 20 hybrid .true. dos 500 100 0 -1.2 1.0 It is not clear. Thank you, Ron mCohen
-
For a hybrid DOS, can I just use tasks 0 5 10 xctype 20 hybrid .true. dos 500 100 0 -1.2 1.0 It is not clear. Thank you, Ron mCohen
-
Thanks so much! I was using the wrong version of this libxcf90! Ron -- Ron Cohen recohen3@gmail.com On May 2, 2022, 2:30 PM -0400, J. K. Dewhurst jkdewhurst@users.sourceforge.net, wrote: Hi Ron, These files are deliberately not included. libxcf90.f90 should correspond to the version of libxc used. The current version of libxc (5.2.2) is incompatible with libxcf90.f90 from version 5.1.2, so we felt it was better to require the user to copy the file from the installed libxc package. mkl_dfti.f90 cannot...
-
It seems like libxcf90.f90 mkl_dfti.f90 etc are not included in the distribution? Ron
-
Py_InitModule not present in python3
-
I am finding that the built in wc xc potential xctype 26 gives different results than libxc xctype 100 118 130 I am not sure which is correct--is this due to cutoffs near nucleus and for large gradients? Attached are my inputs for lapw for PbTiO3. I get for libxc wc first iteration (QE structure) total energy : -22006.0584575 converged structure c/a=1.10 volume=424.6327 for internal wc first iteration (QE structure) total energy : -22001.4159822 c/a=1.10 Unit cell volume : 420.3772172 For reference...
-
OK--I am feeling very stupid. Maybe my cats modified the code. Anyway something was corrupted and it is OK now also with 6.8.4. Egg on my face.
-
OK--I am feeling very stupid. Maybe my cats modified the code. Anyway something was corrupted and it is OK now also with 6.8.4. Egg on my face.
-
I downloaded a fresh copy of 6.8.4 and will build that. Maybe something in mine got corrupted. If so, sorry for all the trouble! Ron
-
I also built both versions the same way with the same make.inc . etc.
-
Dear Kay, No of course not. And I have run on two computers with 4 compilers. My bad result is reproducible. Ron
-
OK! it is a problem with 6.8.4. 6.9.14 gives the correct dos! Ron
-
Thank you. I would try 6.9.14. I do not see that on the web site. Could I try? Thanks, Ron
-
I mean I recompiled with gnu gfortran and ran this code and also increased the stack size for both gnu and intel compiled executables, and got the same bad results.
-
It is very strange. I ran with gnu compilers instead of intel, and set export OMP_STACKSIZE=128M, and I still get the bad DOS. ulimit -a shows: core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 385808 max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) 98826240 open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size...
-
That is very interesting! I will try on a different computer and compiler ! Ron -- Ron Cohen recohen3@gmail.com skypename: ronaldcohen twitter: @recohen3 On Jan 3, 2021, 5:42 AM -0500, John Kay Dewhurst jkdewhurst@users.sourceforge.net, wrote: Dear Ron, I ran the calculation with your input file and obtained the following total and partial DOS: Everything seems fine: the Fermi energy lies right in the middle of the gap. Regards, Kay. Fermi Level Incorrect, Failure of Second Variation? Sent from sourceforge.net...
-
Sorry—typo—yet the DOS looks like attached. -- Ron Cohen recohen3@gmail.com skypename: ronaldcohen twitter: @recohen3 On Jan 2, 2021, 6:40 PM -0500, Ronald Cohen recohen3@users.sourceforge.net, wrote: So again, the INFO.OUT shows: Density of states at Fermi energy : 0.5010895651E-08 Yes, the DOS looks like attached. Attachments: • badDOS.png (162.2 kB; image/png) Fermi Level Incorrect, Failure of Second Variation? Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/elk/discussion/897820/...
-
So again, the INFO.OUT shows: Density of states at Fermi energy : 0.5010895651E-08 Yes, the DOS looks like attached.
-
Dear Kay, Yes, I understand all that, but it is incorrect. This is an insulator, and the mode 0 calculation gives an insulator. But the mode 10 dos or band calculation gives a metal, with the supposed Fermi level in the middle of the valence bands, not in the gap. Sincerely, Ron
-
To repeat the inssue and add to it: OK--something is dreadfully wrong for both my APW and LAPW calculations. Although SCF seems OK (task 0) tasks that do second variation seem messed up. This is not just an optics problem. When I compute the dos or band structure the fermi level is in the wrong place and there are incorrect Pb s states showing. For example (this is APW+LO). The fermi level should be at 0.18 and the big Pb s state doesn't belong. The Fermi level is correct and that s state is not...
-
Please see https://sourceforge.net/p/elk/discussion/897820/thread/bb74d3f6/#27b6
-
OK--something is dreadfully wrong for both my APW and LAPW calculations. Although SCF seems OK (task 0) tasks that do second variation seem messed up. This is not just an optics problem. When I compute the dos or band structure the fermi level is in the wrong place and there are incorrect Pb s states showing. For example (this is APW+LO). The fermi level should be at 0.18 and the big Pb s state doesn't belong. The Fermi level is correct and that s state is not there when I do scf I believe, but appears...
-
FOR APW almost no difference with etol=1e-4 or 1e-6. But lapw totally different.
-
Changing etoil did change results a little, but SHG for lapw is still orders of magnitude smaller than for APW.
-
OK, so now I can get consistent results on different machines and compilers! However, I am finding something very strange. I have done both APW+LO and LAPW and get totally different SHG by a factor of 10! Is there some reason that nonlinear optics in elk should not work for LAPW? These are for the same structures.
-
Thank you very much for this. I will try it. However I was not seeing random results, but consistently wrong ones. I know what is the correct result by getting the same result with multiple compilers on multiple systems. But on two Crays I get consistently wrong results with the available intel compiler (2018).
-
Thank you so much. I am also getting wrong answers with Intel 2018 compilers on Cray XC 40/50's. And crashes with gnu compilers on Crays. I get correct results on KNL and Skylake clusters with Intel compilers including 2020 and also correct with gnu con the KNL and Skylake. It seems to be architecture dependent. However, are you saying that the task 0 run must be done in the same run with the optics? I am not sure I have seen that. Also a few minor changes to nonlinear speed it up a factor of 100...
-
OK--I am finding that different computers give different results for nlo with the same inputs. All the outputs agree exactly except CHI*OUT and PMAT.OUT, though the latter is hard to tell sinceit is binary unformatted. Two Carys with intel compilers give the same results, and a knl cluster with different intel compilers versions 2018-2020 with optimizations of -O1 and -O2 and +/--xknl give a totally different result. It is puzzling. The results do not vary with use use of OMP or not. They only vary...
-
OK, I found this and it indeed gives 24.42 as conversion for the nlo coefficients in CHI_123.OUT: https://sourceforge.net/p/elk/discussion/897820/thread/0434e469/#3d29 so for some reason I am getting very small number for PbTiO3. I will work on it! The GaAs example gives like 2.16 in au, but I am getting orders of magnitude smaller for PbTiO3.
-
This does not seem right to me. Shouldn't 1au=5.14 x 10 9 V/cm = 5.14e11 V/m or conversion of 1.945 to pm/V? But then I get very small numbers for PbTiO3 which are not correct. Apologies if I am confused--in which case what is the correct factor?
-
Dear Andrew, Yes, gladly. First, in terms of the original code. The strains 2 and up did not conserve volume, so with latvopt=2, volume changed so was not a constant volume optimization, and there was no way to do so. Secondly, the original code quit and said it was converged when the stress did not change in two steps, even if it were far from zero. The strains were added rather than multiplied as they should be. So, I changed it as follows: The lattice is strained by: A’=(I+t1strain(i))/(I+t1strain(i))...
-
I haven’t changed that. It optimizes the atomic positions and then one lattice optimization step. It is quite inefficient, but at least seems correct now. Ron Ron Cohen recohen3@gmail.com recohen3@gmail.com skypename: ronaldcohen twitter: @recohen3 On 8. Nov 2020, at 12:12, Andrew Shyichuk andrewshyichuk@users.sourceforge.net wrote: Dear Ronald, How many lattice position optimization steps does your code make per one cell vector optimization step? Thank you, Andrew new strain optimization code https://sourceforge.net/p/elk/discussion/897822/thread/b0aad65b48/?limit=25#e425...
-
I found that the strain optimization code was not working correctly, especially for latvopt=2 (the volume was changing), and I could not understand the way the strain was done. So I have recoded it and it seems to work OK. The steepest descent in Elk is still quite inefficient. It would be much better to implement a quasi-Newton scheme, simultaneouslyfor strains (lattice) and atomic positions, which can be highly correlated. Here is the modified code though with steepest descent.
-
This is wild—it gets worse with higher rkmax (rgkmax) ! I think the problem is overcompletness of the basis set. The Cholesky gets illdetermined if rkmax is too high and this depends also onthe number of local orbitals. For PbTiO3 with rkmax=7 the charge is better and it converges in 24 iterations. total calculated charge : 128.0138943 with rkmax=9 The charge is wrong and it doesn’t converge in 200 iterations! total calculated charge : 124.7882743 even rkmax=8 seems too high total calculated charge...
-
Increasing lmax lmaxapw to 12 from 8 also doesn't help.
-
I also find this problem with elk version 6.3.2, but with the same input the errors are different: cohen@tomcat:/home/beegfs/rcohen/ELK/PTO/WCP0/WClibXC/static$ grep "total calculated" INFO.OUT.6.8.3 | head total calculated charge : 128.0155108 total calculated charge : 128.0155731 total calculated charge : 128.0155682 total calculated charge : 128.0156023 total calculated charge : 128.0155967 total calculated charge : 128.0144846 total calculated charge : 128.0171201 total calculated charge : 127.9950034...
-
Hello! I am finding that Elk (6.8.4) prints finds the incorrect total charge. At first I thought it was an input problem, or a compiler problem, but I have now tested with a number of systems including examples that come with elk and with different compilers and on different computers and find the same thing. I was not able to find this in the forum, but maybe I missed it? So for example, with the BaTiO3 example using the species files that come with elk, I find in INFO.OUT:EIGVAL.OUT: 25 0.3179749728...
-
Bug in CIF input and monoclinic space groups
1