Skip to content

World

Topics from outside of this forum. Views and opinions represented here may not reflect those of this forum and its members.

A world of content at your fingertips…

Think of this as your global discovery feed. It brings together interesting discussions from across the web and other communities, all in one place.

While you can browse what's trending now, the best way to use this feed is to make it your own. By creating an account, you can follow specific creators and topics to filter out the noise and see only what matters to you.

Ready to dive in? Create an account to start following others, get notified when people reply to you, and save your favorite finds.

Register Login
  • emmanuel.Nancy

    Hi,
    Is there a step by step up to date installation process for a one node multi core installation on a debian like linux machine ressource ?
    Best regards,
    Emmanuel


    Hi Emmanuel, For an updated guide on the installation of CRYSTAL23, please follow the instructions provided here. Specifically, to install the executable, refer to Section 1. If you need to recompile the code from object files, see Section 3. To test the parallel executable, you can refer either to Section 2, or to this tutorial. Let me know if you need further help.
  • Rams

    Hi,

    I am trying to perform a calculation to compute the defect formation energy. First I performed geometry optimization in Unit cell. Used the optimized structure to make a super cell and removed a particular atom. Due to system size and memory issue with Pcrystal, I used MPPcrystal calcualtion.

    The first SCF run was OK (in terms of atomic charges) but due to time limit the calculation was not converged. So I used fort.79 file as initial WF GUESSP to continue the SCF run. But the Total atomic charges is not right, even in the second cycle of the SCF run. As can be seen in output file, the atomic charge change from 8 to 2 in the Run2 output file. Could you kindly guide me regarding my mistake.

    Thanks for your help in advance

    INPUT_Run1.d12
    INPUT_Run2.d12
    OUTPUT_Run1.d12
    OUTPUT_Run2.d12


    Dear Rams, From your input/output files, it doesn't seem you are doing anything particularly wrong. It is more that the system is perhaps a bit more challenging. Here are a few ideas that might be of use regarding speed up and convergence: i) You are having quite large lattice parameters (15 Angstrom in each direction). In this case having a 4x4x4 mesh of k-points is perhaps even more than needed to converge the total energy, so you can try reducing it to a 3x3x3 or 2x2x2 mesh to reduce the computational cost and get some speed up (without compromising quality). You could probably go to 1 k-point just as well, but then you might not get a correct Fermi level sampled. Which brings me to the second point... ii) Do you expect your system to be metallic? If so, you can test a few values of the smearing parameter to see whether it makes a difference to the convergence behaviour. If you know you need to get a semiconductor, then you might want to try shifting the occupied states down in energy (keyword LEVSHIFT to prevent the system from getting stuck in a conducting state and causing the SCF to get stuck... iii) You have the DIISALLK keyword in your input file, have you tested that as necessary for the convergence of the undoped cell? It does increase the memory/storage requirements, so could be worth trying with just the default (gamma-point) DIIS... iv) One alternative is to turn off the DIIS convergence accelerator and revert to "classical" Fock mixing. Albeit slower in convergence than DIIS, it can stabilize the SCF procedure avoiding strong, sudden oscillation in the solution (while DIIS is turned on, the FMIXING is used only in the very first SCF step)... v) Coming back to the charge oscillations you observed, they do indeed start appearing very quickly in your second run. Here are the corresponding total energies from your OUTPUT_Run1.d12: CYC 0 ETOT(AU) -1.128999989618E+05 DETOT -1.13E+05 tst 0.00E+00 PX 1.00E+00 CYC 1 ETOT(AU) -1.129553711002E+05 DETOT -5.54E+01 tst 0.00E+00 PX 1.00E+00 CYC 2 ETOT(AU) -1.129699205883E+05 DETOT -1.45E+01 tst 7.60E-05 PX 9.78E-02 CYC 3 ETOT(AU) -1.123277877060E+05 DETOT 6.42E+02 tst 4.05E+00 PX 8.33E+00 CYC 4 ETOT(AU) -1.123934069238E+05 DETOT -6.56E+01 tst 1.68E-01 PX 6.66E+00 CYC 5 ETOT(AU) -1.128505608381E+05 DETOT -4.57E+02 tst 2.53E-01 PX 1.17E+00 CYC 6 ETOT(AU) -1.126570396187E+05 DETOT 1.94E+02 tst 1.41E-01 PX 1.13E+00 CYC 7 ETOT(AU) -1.129397986733E+05 DETOT -2.83E+02 tst 1.36E-01 PX 1.16E+00 CYC 8 ETOT(AU) -1.128184205493E+05 DETOT 1.21E+02 tst 9.81E-02 PX 6.95E-01 CYC 9 ETOT(AU) -1.129501102455E+05 DETOT -1.32E+02 tst 9.49E-02 PX 6.74E-01 CYC 10 ETOT(AU) -1.129223250516E+05 DETOT 2.78E+01 tst 5.80E-01 PX 6.62E-01 And then from OUTPUT_Run2.d12 CYC 0 ETOT(AU) -1.129223250516E+05 DETOT -1.13E+05 tst 0.00E+00 PX 1.00E+00 CYC 1 ETOT(AU) -8.145313982597E+04 DETOT 3.15E+04 tst 0.00E+00 PX 1.71E+02 CYC 2 ETOT(AU) -1.058417907360E+05 DETOT -2.44E+04 tst 2.27E+00 PX 1.71E+02 CYC 3 ETOT(AU) -7.201760490303E+04 DETOT 3.38E+04 tst 9.37E+00 PX 3.62E+02 CYC 4 ETOT(AU) -3.830339502397E+04 DETOT 3.37E+04 tst 1.36E+02 PX 7.83E+02 CYC 5 ETOT(AU) -5.612117026766E+04 DETOT -1.78E+04 tst 2.27E+01 PX 5.54E+02 CYC 6 ETOT(AU) -1.006357459536E+05 DETOT -4.45E+04 tst 3.23E+01 PX 5.67E+02 CYC 7 ETOT(AU) -1.131945182713E+05 DETOT -1.26E+04 tst 9.68E+00 PX 2.13E+02 CYC 8 ETOT(AU) -1.203304661632E+05 DETOT -7.14E+03 tst 8.51E+00 PX 1.06E+02 CYC 9 ETOT(AU) -1.148704842219E+05 DETOT 5.46E+03 tst 1.77E+01 PX 6.53E+01 CYC 10 ETOT(AU) -1.235795679474E+05 DETOT -8.71E+03 tst 2.63E+00 PX 4.40E+01 In the first run the total energy does not oscillate, hence why the atomic charges are still somewhat as expected. In the second run, the SCF solutions starts fluctuating much more (see difference in total energies) and as a result the charges get destabilized. The SCF might not recover from that at all (even though it seems it could), so I would suggest first trying speeding up the simulation to try and get the job done in one run. Alternatively you might have to go with slower mixing and more restarts, but that is not a guarantee for a solution either. Further options include increasing the DFT grid (XXLGRID, XXXLGRID) or further increasing the last number of the integral tolerance (even though yours is pretty high already). Hope any of this is helpful in the end! Cheers, Aleks
  • fabio.dellasala

    Hi, i'm running crystal OpenMP for some Hartree Fock periodic calculations.
    When I run crystal OpenMP from a script (several times , sweeping over the basis set), I get
    a strange behaviour.

    when I run directly I get (e.g.)
    ....
    CYC 5 ETOT(AU) -1.959844090722E+02 DETOT 1.01E-07 tst 1.86E-07 PX 1.17E-03
    CYC 6 ETOT(AU) -1.959844090642E+02 DETOT 7.93E-09 tst 1.14E-08 PX 2.23E-04
    CYC 7 ETOT(AU) -1.959844090650E+02 DETOT -7.24E-10 tst 1.19E-09 PX 2.23E-04

    when I run from the script I get
    CYC 5 ETOT(AU) -1.959844090722E+02 DETOT 1.01E-07 tst 1.86E-07 PX 1.17E-03
    CYC 6 ETOT(AU) -1.959844090642E+02 DETOT 7.93E-09 tst 1.14E-08 PX 2.23E-04
    CYC 7 ETOT(AU) -1.959844078015E+02 DETOT 1.26E-06 tst 1.19E-09 PX 2.23E-04

    thus everyting is the same BUT the last cycle in which the energy increases !!!

    In particular, it is the BIELET ZONE that differs

    < ::: BIELET ZONE E-E 9.2053136238046E+02
    < ::: TOTAL E-E 5.2408459522505E+01

    ::: BIELET ZONE E-E 9.2053136364389E+02
    ::: TOTAL E-E 5.2408460785929E+01

    I SUSPECT A PROBLEM IN INITIALIZATION OF SOME OPENMP VARIABILE
    BECAUSE THE VALUE OF THE FINAL TOTAL ENERGY ALSO DEPENDS ON HOW MANY TIMES
    I RUN THE SCRIPT !!!

    or which can be the explanation ?

    input follows.

    ----------input---------------
    Copper bulk
    CRYSTAL
    0 0 0
    225
    3.4
    1
    229 0. 0. 0.
    LATVEC
    40000
    END
    229 12
    INPUT
    19. 0 2 2 2 0 0
    30.220000 355.770158 0
    13.190000 70.865357 0
    33.130000 233.891976 0
    13.220000 53.947299 0
    38.420000 -31.272165 0
    13.260000 -2.741104 0
    0 0 3 2. 1.
    2.76963200000E+01 2.31132000000E-01
    1.35053500000E+01 -6.56811000000E-01
    8.81535500000E+00 -5.45875000000E-01
    0 0 1 1. 1. *
    6.000E+00 1.0
    0 0 1 0. 1. *
    2.000E+00 1.0
    0 0 1 0. 1. *
    4.000E-01 1.0
    0 0 1 0. 1. *
    2.000E-01 1.0
    0 2 2 6. 1.
    9.35043270000E+01 2.28290000000E-02
    1.62854640000E+01 -1.00951300000E+00
    0 2 1 0. 1. *
    7.000E+00 1.0
    0 2 1 0. 1. *
    2.000E+00 1.0
    0 2 1 0. 1. *
    8.000E-01 1.0
    0 3 4 10. 1.
    4.12250060000E+01 4.46940000000E-02
    1.23432500000E+01 2.12106000000E-01
    4.20192000000E+00 4.53423000000E-01
    1.37982500000E+00 5.33465000000E-01
    0 3 1 0. 1. *
    8.000E-01 1.0
    0 3 1 0. 1. *
    4.000E-01 1.0
    99 0
    END
    TOLDEE
    7
    MAXCYCLE
    25
    SHRINK
    24 48
    DIIS
    SLOSHING
    PRTDIIS
    HISTDIIS
    15
    TOLINTEG
    9 9 9 15 45
    ILASIZE
    20000
    FMIXING
    45
    FIXINDEX
    END
    GEOM
    CRYSTAL
    0 0 0
    225
    3.60
    1
    229 0. 0. 0.
    LATVEC
    40000
    END


    Hi Fabio, A few clarifications: i) I'm aware that setting KMP_DETERMINISTIC_REDUCTION=true can help, but in practice, it doesn't guarantee reproducibility on its own. Even building crystalOMP with stricter floating-point flags like -fp-model precise (or equivalent) doesn't always lead to fully consistent results, at least not in my experience with CRYSTAL. ii) Yes, MPI reductions are typically deterministic, as most implementations use pairwise summation or other stable schemes. OpenMP, on the other hand, can still introduce variability due to threading and compiler optimizations. iii) If you're seeing discrepancies around 1e-5, it's plausible that small numerical differences from OpenMP reductions are enough to drive the SCF, especially in extremely delicate cases like metallic systems treated at the HF level, toward slightly different solutions. At this point, I’ve investigated what I could from our end. If maximum reproducibility is essential, I strongly recommend sticking with MPI-only parallelism. Have a great day, Giacomo
  • R.Zosiamliana

    Dear CRYSTAL community,

    I am working on charge state calculations using CRYSTAL17 and would like clarification on how to correctly set up a system with a net charge.

    I am studying bulk hydride LiBeH3 and intend to simulate it in different charge states (e.g., [LiBeH3]+1 and [LiBeH3]-1 i.e., LiBeH3 compound with net +1 or -1 charge).

    Thank you,
    R. Zosiamliana
    PSRC, Pachhunga University College
    Mizoram, India.


    Hi, If I may, I'll add a few more lines on Alessandro's comment that might be of use (or not...) Let's say you want to change the charge state of one of the Li atoms in your cell. Assuming that it is atom number XY with atomic number 3, your input might look something like this: Title [geometry] END [basis set] ... 3 3 -> Li example basis set 0 0 6 2. 1. 700.0 0.001421 220.0 0.003973 70.0 0.01639 20.0 0.089954 5.0 0.315646 1.5 0.494595 0 0 1 1. 1. 0.5 1.0 0 2 1 0. 1. 0.6 1.0 ... 99 0 CHEMOD 1 XY -> atom number whose charge you change for the initial guess 2.0 2.0 0.0 -> electronic charge of all shells in the basis set, here you alter the initial charge guess (note that the initial configuration is 2.0 1.0 0.0, so you will end up in the "-1" charge state) CHARGED END [SCF parameters] END As usual, supercell size should be converged, localization of the defect confirmed, etc. Good luck with the defect formation energy corrections...one way to go is to use the multipole correction (aka Makov-Payne, see e.g., 2010 J. Phys.: Conf. Ser. 242 012004 or PRB 81, 205214 (2010))...or you can write your own piece of code to interface CRYSTAL's output to for example the scheme of Kumagai and Oba (Phys. Rev. B 89, 195205) ! Hope it helps. Cheers, Aleks
  • Chhatra

    Dear Developer,

    I have referred to the user manual and tutorial materials, but I am still having difficulty understanding how to correctly define the following sections when generating 2D electron density and electrostatic potential plots using CRYPLOT (Specifically following section)
    '''''''''''''
    ATOMS
    1 1 1 -1
    1 0 0 0
    1 0 0 2
    MARGINS
    2. 2. 2. 2.
    END
    ''''''''

    OR

    '''''''''''
    COORDINA
    -2.498 0.000 1.696
    -2.498 0.000 -1.696
    -1.249 -2.164 -1.696
    RECTANGU
    MARGINS
    3. 3. 3. 3.
    '''''''''

    Could you kindly explain how to determine or generate these inputs properly?

    Thank you very much for your assistance.

    Best regards,
    Chhatra Subba


    Thankyou so much. This will help me
  • Chhatra

    I am a new user of CRYSTAL17. I successfully completed a properties calculation and obtained the file fort.25, which I can visualize using CRYPLOT. However, I would like to plot the charge density in VESTA, and currently I'm not sure how to convert the output to a compatible format.

    Could you please guide me on how to:
    Convert fort.25 to a Gaussian CUBE file or any other format supported by VESTA?
    Specify the correct options using runprop17 (or any other utility) to export the 3D total charge density?

    Any help would be greatly appreciated.

    Best regards,
    Chhatra Subba


    Thankyou so much. It worked perfectly. This is a big help
  • job314

    I admit I am not very good conceptualizing these symetry unique points on Brillouin zone or expressing them in .d3 file as a path. I have two structures below that I fully optimized and calculated vibrational frequencies. Now my task is DOS/BAND. Is there a GUI that would help me read the optimized structures and prepare .d3 file? Or can I use my optimization file somehow to extract those unique points?

    SPACE GROUP (CENTROSYMMETRIC) : P 21/N

    LATTICE PARAMETERS (ANGSTROMS AND DEGREES) - CONVENTIONAL CELL
    A B C ALPHA BETA GAMMA
    7.40400 21.53400 5.65700 90.00000 91.05000 90.00000

    and

    SPACE GROUP (CENTROSYMMETRIC) : P -1

    LATTICE PARAMETERS (ANGSTROMS AND DEGREES) - CONVENTIONAL CELL
    A B C ALPHA BETA GAMMA
    10.70800 10.11400 6.41000 91.30000 88.30000 91.00000


    wonderful, thank you both
  • job314

    Hi, we synthesized a complex material something along the lines of LaFex Niy Coz Cuu Mnv O3 where x+y+z+u+n=1. I know it is not trivial, but I would like to attempt using configuration analysis in TREATMENT OF DISORDERED SYSTEMS / SOLID SOLUTIONS module to generate possible configurations. The parent compound is LaFeO3 perovskite structure. It is Pnma symmetry

    Lattice (Primitive)
    a 5.60 Å, b 5.66 Å, c 7.94 Å, α 90.00 º, β 90.00 º, ɣ 90.00 º

    Wyckoff Element x y z
    4b Fe 1/2 0 1/2
    4c La 0.009381 0.961741 3/4
    4c O 0.08612 0.478265 1/4
    8d O 0.712594 0.287975 0.453725

    so all the atom substitutions of Ni, Co, Cu and Mn will go into that 4b Fe site. From the analysis, it has 4 symmetry equivalent sites:

     5 T  26 FE    0.000000000000E+00  0.000000000000E+00 -5.000000000000E-01
    
      6 F  26 FE   -5.000000000000E-01  0.000000000000E+00 -3.095458132887E-17
    
      7 F  26 FE   -5.000000000000E-01 -5.000000000000E-01  2.220446049250E-16
    
      8 F  26 FE    0.000000000000E+00 -5.000000000000E-01 -5.000000000000E-01
    

    I know the Fe composition, it is 20 %, the rest are Ni, Co, Cu and Mn, all at the same 20 % compositions - this simplifies the problem. But then I have 4 equivalent Fe sites and 5 elements to fit. Am I correct that I need to construct a supercell here? Ultimately, I would like this module to return me possible combinations of all 20% five elements, but not sure what size of supercell to create

    see the attached test structure input.out INPUT.d12

    thank you


  • heimurinn

    Hello everyone!
    I have a systematic problem with the calculation of different hexagonal structures. Seems that the group and the geometry is interpreted correctly in all the cases however, there is the same problem on the step "SYMMETRY ADAPTION OF THE BLOCH FUNCTIONS".
    I`ve tried to change the BIPOSIZE & EXCHSIZE values smaller/larger; to vary the points of the k-space so that "DISK SPACE FOR EIGENVECTORS" becomes lower, however seems that the solution lies somewhere else.
    Below are some examples of initial & output files with the same problem.
    Can you hep me to fix it?
    Thanks in advance.

    81_from1.out 81_to1403845.out 81_to1403845.d12 81_from1.d12


    @GiacomoAmbrogio Great! It works now! Thanks a lot!
  • spiekermann

    Dear Crystal-Developers,

    the D4 dispersion correction scheme seems to have been implemented in Crystal23, but I cannot not find it documented in the manual from 31. october 2023.

    Could you please give me hint where to find information on the matter of D4?

    Thank you!
    Kind regards,
    Georg


    Hi Giacomo, thank you for your answer. You are right, D4 is mentioned in the JCTC article as "further developments to the code", which I misunderstood. The article clearly mentions it as future development, not as list of further developments not laid out in detail in the article. Thank you for your help in clarifying this. Kind regards, Georg
  • job314

    I profusely apologize, but how do I visualize vibrations on my browser using JSMol? I know it sounds silly but I have no idea how to install or launch it. Your webpage below did it very well, I can't follow any of the Java related instructions on the developers website, I would like to be able to run JSmol on my home computer on a browser, can somebody give me a brief instruction how to do that?

    Your tutorial page does that very well

    https://www.crystal.unito.it/prtfreq/jmol.html


    Dear Jonas, A good option just for visualization is using the CRYSPLOT webpage, which includes a tool for this based on JSMol and only requires your output file. Another option would be to use JMol, which requires a local installation of Java. Using JSMol locally is not an easy task, as its developed for its usage on web servers. If you really need to do so, you can find some guidance in the the following sites (it will depend on which browser you want to use, and probably also on your OS): Recent thread on usage of JSMol locally JSMol Wiki post Hope this helps. Marcos
  • job314

    Dear all, I optimized a crystal, got good gradients, but numerical displacements are already suspect as they generate lots of negative energies, it's a big system, I am still running it but decided to preemptively ask why this can be the case?

    SYMMETRY ALLOWED FORCES (COORDINATE, FORCE)

    1 -7.1019812E-07    2  2.6847537E-07    3  1.7714543E-06    4  1.5380909E-06
    5 -8.5713887E-07    6 -7.6313741E-07    7 -1.3777999E-06    8 -4.2292032E-07
    9  3.7330006E-07   10 -1.0186152E-07   11  7.8436370E-08   12 -1.0666144E-07
    

    13 7.6024231E-07 14 1.2549944E-07 15 -3.8114243E-07 16 8.3483245E-07
    17 1.2719080E-06 18 1.3589256E-07 19 -1.2770755E-06 20 -1.7657611E-06
    21 -6.7831105E-07 22 -2.8553633E-06 23 -2.5801301E-06 24 1.6190965E-06
    25 2.7986374E-07 26 1.6445538E-06 27 1.5791380E-06 28 3.4913230E-06
    29 7.5492284E-07 30 -3.2944974E-06 31 -2.9919538E-06 32 1.2296182E-06
    33 4.5466078E-07 34 -1.8564773E-07 35 9.3158783E-07 36 -1.4184621E-07
    37 2.8763484E-06 38 -1.7874331E-06 39 -3.3548919E-07 40 -1.0246636E-06
    41 7.3025290E-07 42 -7.4914105E-07 43 -1.5527795E-07 44 -5.9189571E-07
    45 1.1402401E-07 46 1.1445077E-07 47 5.0641463E-07 48 2.6720325E-07
    49 3.9382990E-07 50 1.9265418E-07 51 -5.0025563E-07 52 -1.4722329E-07
    53 -3.9032570E-07 54 -1.8660950E-07 55 -3.7294087E-08 56 2.7903845E-07
    57 -1.1262719E-07 58 -1.4056720E-06 59 -7.2814440E-07 60 -4.2360016E-07
    61 9.6760468E-07 62 -1.1476558E-06 63 5.7400637E-08 64 8.2334616E-07
    65 1.7677814E-06 66 1.1935613E-06 67 -5.3996977E-07 68 5.3577787E-07
    69 -5.5566146E-07 70 2.5231789E-07 71 -6.3487986E-07 72 7.2284427E-07
    73 -8.4328694E-08 74 -5.8224781E-07 75 -1.6946265E-07 76 1.0209263E-06
    77 2.9716506E-07 78 2.3838462E-07 79 1.7955521E-06 80 4.0804899E-07
    81 1.2100282E-07 82 -1.5099145E-06 83 2.9006726E-07 84 -2.2790446E-07
    85 1.4325087E-06 86 -6.8494225E-07 87 -3.3477344E-07 88 -2.2149944E-07
    89 1.3328321E-07 90 -1.8330282E-08

    ATOM MAX ABS(DGRAD) TOTAL ENERGY (AU) N.CYC DE SYM
    CENTRAL POINT -5.463640944184E+03 0 0.0000E+00 8
    1 O DX 6.5777E-04 -5.463640944692E+03 11 -5.0781E-07 1
    1 O DY 8.9722E-04 -5.463640943824E+03 12 3.6002E-07 1
    1 O DZ 2.7715E-03 -5.463640938222E+03 13 5.9626E-06 1
    9 O DX 1.4159E-03 -5.463640942796E+03 11 1.3886E-06 1
    9 O DY 2.4328E-03 -5.463640939470E+03 13 4.7142E-06 1
    9 O DZ 7.5341E-04 -5.463640944273E+03 10 -8.8837E-08 1
    17 N DX 3.3298E-03 -5.463640936786E+03 9 7.3979E-06 1
    17 N DY 2.6834E-03 -5.463640938932E+03 10 5.2525E-06 1
    17 N DZ 2.2061E-03 -5.463640940002E+03 10 4.1826E-06 1
    25 H DX 5.8163E-04 -5.463640944625E+03 10 -4.4035E-07 1
    25 H DY 9.7068E-04 -5.463640943311E+03 9 8.7315E-07 1
    25 H DZ 1.3265E-03 -5.463640942408E+03 11 1.7757E-06 1
    33 H DX 1.9126E-03 -5.463640940840E+03 12 3.3445E-06 1
    33 H DY 9.0051E-04 -5.463640944155E+03 9 2.8878E-08 1
    33 H DZ 6.4300E-04 -5.463640945217E+03 9 -1.0328E-06 1
    41 N DX 3.4011E-03 -5.463640936782E+03 10 7.4018E-06 1
    41 N DY 2.7133E-03 -5.463640938661E+03 12 5.5236E-06 1
    41 N DZ 2.8802E-03 -5.463640937601E+03 11 6.5830E-06 1
    49 H DX 1.5489E-03 -5.463640941848E+03 10 2.3365E-06 1
    49 H DY 3.3487E-04 -5.463640945255E+03 9 -1.0709E-06 1
    49 H DZ 8.9868E-04 -5.463640943999E+03 9 1.8543E-07 1
    57 N DX 2.4112E-03 -5.463640939472E+03 9 4.7126E-06 1
    57 N DY 3.5207E-03 -5.463640936173E+03 10 8.0110E-06 1
    57 N DZ 3.2454E-03 -5.463640936926E+03 12 7.2582E-06 1
    65 H DX 4.2444E-04 -5.463640945298E+03 10 -1.1135E-06 1
    65 H DY 1.4990E-03 -5.463640942117E+03 10 2.0672E-06 1
    65 H DZ 9.8569E-04 -5.463640943558E+03 7 6.2581E-07 1
    73 H DX 8.8996E-04 -5.463640943796E+03 11 3.8818E-07 1
    73 H DY 4.0635E-04 -5.463640945249E+03 9 -1.0646E-06 1
    73 H DZ 1.5526E-03 -5.463640941922E+03 11 2.2623E-06 1
    81 N DX 3.0237E-03 -5.463640937800E+03 12 6.3840E-06 1
    81 N DY 3.1621E-03 -5.463640937605E+03 12 6.5795E-06 1
    81 N DZ 3.3672E-03 -5.463640936782E+03 11 7.4017E-06 1
    89 H DX 3.5908E-04 -5.463640945209E+03 8 -1.0249E-06 1
    89 H DY 1.0305E-03 -5.463640943313E+03 13 8.7074E-07 1
    89 H DZ 1.3452E-03 -5.463640942571E+03 10 1.6132E-06 1
    97 H DX 1.1682E-03 -5.463640943082E+03 10 1.1022E-06 1
    97 H DY 1.4461E-03 -5.463640941923E+03 12 2.2616E-06 1

    output.out attached


    Hi Jonas, Would you mind adding the INPUT file as well, for easier checks? It generally doesn't look too bad, I would wait until the calculations finishes and see how the results look like. There is nothing obviously "wrong", but you can always try tightening the convergence criteria. See earlier post for a great overview of options (especially if you notice in the end that you have negative frequencies appearing!): Earlier post on "Imaginary frequencies", see comment by Prof. Erba I personally wouldn't run a geometry optimization together with a frequency calculation, I would split them in too, but I guess that is a matter of taste as the code can handle it : ) Cheers, Aleks
  • Gryffindor

    Hi,

    I am encountering an issue while performing a CPKS calculation on a large system. Although the calculation proceeds without errors, it eventually hits the wall time limit. Unfortunately, no restart file (Fort.31) is generated, which prevents me from restarting the calculation.

    I have attempted the calculation both with and without the DIIS keyword, but in both cases, the restart file is not written.

    Thank You

    The input and output files are attached below.
    INPUT.d12 OUTPUT.d12


    Dear Aparajita, @Gryffindor said in Problem with restarting CPKS calculation: I’m reaching out again regarding the CPKS step. After several attempts (and a fair bit of persistence!), I was finally able to complete the SCF calculations. Good! @Gryffindor said in Problem with restarting CPKS calculation: As per your previous suggestions, I ensured the SCF was converged beforehand, but unfortunately, the CPKS has never been able to finish successfully on my side. Is there a reason for switching DIIS off in your CPKS calculation? Also, you can change the convergence criterion for the CPKS with the TOLALPHA keyword. In your case, it may be enough to run it with: CPKS TOLALPHA 2 END @Gryffindor said in Problem with restarting CPKS calculation: Since I need these results quite urgently, I was wondering if you could try running it on your end to see if there's anything I'm missing? I am afraid I can not. It is a huge calculation that you are running on 800+ atoms/cell and I do not have the computing power for this.
  • Luz

    Hi, I did a properties calculation and I'm getting negative values for the density of states. Does anyone have any idea why this is happening?
    Thank you in advance
    DensityStates.outp


    Thanks a lot! I will take your advice.
  • job314

    Alessandro,

    I am making a large 450 atom supercell of MgNH4PO4*6H2O to study Fe ion incorporation. We experimntally observe about 5% Mg atoms substituted with Fe - we do not know the oxidation state. So my supercell is big and I optimize this ionic solid with PBE-D3. My question is long and related on how to obtain required electronic state and converge in some instances. See below my diagram. I am exploring 3 different substitutional scenarios.

    Scenario 1 is substituting Fe3+ and removing one proton to make it neutral. I am getting excellent SCF convergence, my guess is that this octahedral symmetry is broken somehow by removal of proton which helps SCF convergnce but crystal field with nearly 5 inpaired electrons is still preserved after the convergence with PBE-D3/pobDZVP.

    Scenario 2 is an SCF problem. To charge balance it I remove NH4+. Immediately I get problems with SCF becoming conducting, I guess it does not want to be perfectly Oh symmetry and needs some distortion. I managed to converged it with PBE-D3/STO-3G in hopes that it will optimize to some solution which I can further optimize with PBE-D3/pobDZVP. But if I wanted to bias it with EIGENSHIFT and start with a large basus set, what would be my logic here? Robert Orlando used to very elegantly explain these things to me in the past.

    Scenario 3 I haven't run yet. Seems like perfect Oh symmetry with the corresponding crystal field splitting and 4 unpaired electrons but my guess is it will run into the same problems as Scenario 2 and will need some biasing.

    efbd21d6-0f3b-4ba8-81be-e7d34bbb1b15-image.png


    Dear Jonas, first of all, 450 atoms is impressive indeed! Now moving on to a few comments/thoughts that might be of use to you. i) From your input file, it appears you still have a few symmetry operators in your simulation cell. Worth checking whether/if that applies to the atoms in the Fe-centred octahedra as that might force a particular solution to the electronic configurations. ii) Given that your octahedra are not aligned with any particular crystallographic axis in your system, it is not always straightforward to extract the (d-)orbital occupations. You can have a look at the ROTREF keyword in the manual by which you can rotate the eigenvectors in the properties calculation to orient the frame along a principal axis. iii) In Scenario 1 you are right - you removed 1 H atom, from which indeed the symmetry of the octahedron has been reduced/broken. You could test the case without "neutralization", to see whether the extra electron would stay on the site or delocalize...formation energies might be a good guide...? iv) Scenario 2 is a bit more complicated. Given that you removed a whole NH4+ tetrahedron, I would expect significant structural distortions occurring in the surrounding of the defect. From there, a conducting state might be not so unrealistic - did you optimize the atomic positions and/or cell parameters following the inclusion of that defect? If so, could be worth seeing where the metallic states originate from (e.g., in the DOS or a charge density difference plot would be sufficient...don't forget SMEAR). The question is where is the extra electron from the anticipated Fe3+ ending if you remove the whole tetrahedron? v) Finally, I guess it really depends on what you see experimentally and what would be the most representative simulation cell matching the measurements to be able to extract meaningful data for the oxidation state. What could be potentially useful is to take simple bulk structures for which you know the oxidation state of Fe (e.g., Fe2O3, Fe3O4, ...), analyse the corresponding charge densities (e.g., Mulliken) and have a reference state for comparing the charge on the Fe-ion in your Struvite structure. Hope any of this is useful. Cheers, Aleks
  • job314

    So on my main supercomputer I am getting this error during write problem. Admins do not know why it happens. It only happes with CRYSTAL and sporadically.

    CYC 23 ETOT(AU) -2.276909751322E+04 DETOT -2.19E-06 tst 4.04E-07 PX 2.29E-04
    TTTTTTTTTTTTTTTTTTTTTTTTTTTTTT DIIS TELAPSE 20527.44 TCPU 20346.34
    DIIS TEST: 0.38681E-05 AT SCF CYCLE 23 - DIIS ACTIVE - HISTORY: 23 CYCLES
    forrtl: No space left on device
    forrtl: severe (38): error during write, unit 8, file /90daydata/urea_kinetics/struvite/Fedoped/PBE_D3/2x2x2_FeOH/fort.8.pe280
    Image PC Routine Line Source
    Pcrystal 0000000007376772 Unknown Unknown Unknown
    Pcrystal 00000000073744DB Unknown Unknown Unknown
    Pcrystal 0000000001BA179E Unknown Unknown Unknown
    Pcrystal 000000000069D509 Unknown Unknown Unknown
    Pcrystal 0000000000695494 Unknown Unknown Unknown
    Pcrystal 0000000000992FCD Unknown Unknown Unknown
    Pcrystal 0000000000609584 Unknown Unknown Unknown
    Pcrystal 0000000000605881 Unknown Unknown Unknown
    Pcrystal 0000000000405540 Unknown Unknown Unknown
    Pcrystal 00000000004053FD Unknown Unknown Unknown
    libc.so.6 0000148B7AA295D0 Unknown Unknown Unknown
    libc.so.6 0000148B7AA29680 __libc_start_main Unknown Unknown
    Pcrystal 0000000000405315 Unknown Unknown Unknown


    @job314 said in No space left on device: those are huge HPC nodes… they can’t be possibly out of disk… On our cluster, although the total disk space is huge, there are limited disk quotas for each user. Maybe it is the same there for you? @job314 said in No space left on device: will it affect my convergence or calculation speed? Possibly, but not much I think.
  • job314

    HI all, I am trying to restart Raman calculation since it ran out of time. I am getting this strange error, all I did was I added RESTART keyword and initially it ran OK

    I think the problem is somewhere since I ran the frequency with full optimization calculation. Then I deleted optimization keywords from FREQCALC and added RESTART. See the files, is there a way to restart it?

    ERROR **** PGGP **** G-VECTOR NOT FOUND IN PREVIOUS DENSITY MATRIX

    HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
    FORCE CONSTANT MATRIX - NUMERICAL ESTIMATE
    HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
    MAX ABS(DGRAD): MAXIMUM ABSOLUTE GRADIENT DIFFERENCE WITH RESPECT TO
    THE CENTRAL POINT
    DE: ENERGY DIFFERENCE WITH RESPECT TO THE CENTRAL POINT
    (DE IS EXPECTED TO BE POSITIVE FOR ALL DISPLACEMENTS)

    ATOM MAX ABS(DGRAD) TOTAL ENERGY (AU) N.CYC DE SYM
    CENTRAL POINT -6.939500764932E+03 0 0.0000E+00 8
    1 P DX RESTORED FROM A PREV. HESS. MATRIX
    1 P DY RESTORED FROM A PREV. HESS. MATRIX
    1 P DZ RESTORED FROM A PREV. HESS. MATRIX
    9 O DX RESTORED FROM A PREV. HESS. MATRIX
    9 O DY RESTORED FROM A PREV. HESS. MATRIX
    9 O DZ RESTORED FROM A PREV. HESS. MATRIX
    17 O DX RESTORED FROM A PREV. HESS. MATRIX
    17 O DY RESTORED FROM A PREV. HESS. MATRIX
    17 O DZ RESTORED FROM A PREV. HESS. MATRIX
    25 O DX RESTORED FROM A PREV. HESS. MATRIX
    25 O DY RESTORED FROM A PREV. HESS. MATRIX
    25 O DZ RESTORED FROM A PREV. HESS. MATRIX
    33 O DX RESTORED FROM A PREV. HESS. MATRIX
    33 O DY RESTORED FROM A PREV. HESS. MATRIX
    33 O DZ RESTORED FROM A PREV. HESS. MATRIX
    41 O DX RESTORED FROM A PREV. HESS. MATRIX
    41 O DY RESTORED FROM A PREV. HESS. MATRIX
    41 O DZ RESTORED FROM A PREV. HESS. MATRIX
    49 N DX RESTORED FROM A PREV. HESS. MATRIX
    49 N DY RESTORED FROM A PREV. HESS. MATRIX
    49 N DZ RESTORED FROM A PREV. HESS. MATRIX
    57 N DX RESTORED FROM A PREV. HESS. MATRIX
    57 N DY RESTORED FROM A PREV. HESS. MATRIX
    57 N DZ RESTORED FROM A PREV. HESS. MATRIX
    65 C DX RESTORED FROM A PREV. HESS. MATRIX
    65 C DY RESTORED FROM A PREV. HESS. MATRIX
    65 C DZ RESTORED FROM A PREV. HESS. MATRIX
    73 H DX RESTORED FROM A PREV. HESS. MATRIX
    73 H DY RESTORED FROM A PREV. HESS. MATRIX
    73 H DZ RESTORED FROM A PREV. HESS. MATRIX
    Abort(1) on node 0 (rank 0 in comm 0): application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0


    It makes sense, thank you.
  • spiekermann

    Dear Alessandro,
    dear crystal-developers,

    do I understand correctly that the QHA in crystal is based on gamma-point phonons only?

    Thank you!
    Kind regards,
    Georg


    Dear Alessandro, thank you for this explanation! Kind regards, Georg
  • spiekermann

    Dear crystal-experts,

    I have carried out a lattice dynamics calculation within QHA and I am impressed with crystal23.

    However, my crystal strcture is monoclinic, and it seems to me that the EOS calculation prior to QHA is carried out optimizing a,b,c but not the one free angle. As if it had been written not for the most general case, but for orthogonal cases only.

    Do I understand this correct?
    If so, is there a way how to "switch on" full monoclinic optimization?

    Thank you!
    Kind regards,
    Georg Spiekermann


    Hi Alessandro, thank you very much for these detailed explanations! Crystal is an amazing program, and I am just starting to explore its powerful thermoelastic capabilities. Kind regards, Georg
  • PeterRemoto

    Hey,
    I was wondering if anyone has any advice with dealing with crystal systems with transiton metal complexes with a floating anion? Our objective is to calculate the low-frequency Raman modes of these structures and compare with experimental.
    Using PBE functional with Grimme D3 dispersion correction and the pob-TZVP-rev2 basis set
    So managed to optimise the structure - which took a while but was fine
    908892_hicnis_PBE_D3_pob-TZVP-rev2_OPTGEOM_4_4.d12

    Now I'm doing frequency calculations
    908892_hicnis_PBE_D3_POB-TZVP-REV2_FREQ_4_4.d12
    But now a bit stuck with the frequency calculations because it doesn't seem to converge for the INTCPHF structures
    908892_hicnis_PBE_D3_POB-TZVP-REV2_FREQ_4_4-69914.out
    Tried GUESSP with fort.20 (copied from fort.9) to try to speed up the some bits before I hit my cluster time limit. However, the calculation doesn't seem to properly get past the INTCPHF cycles - Electric field applied to X direction hits 200 cycles, which is what the MAXYCLES set, which is already pretty high - so I can't use fort.32 (copied from fort.31) for INTCPHF RESTART. I'm currently running a calculation with MAXCYCLES increased to 9999 but it doesn't seem to help much looking at the ongoing ouput file.

    Not sure how else to troubleshoot this properly without using up all of our cluster allocation - so very open to advice and potential solutions to try out.

    Happy to provide more input files if need be.

    Thank you for your time,
    Peter


    Hi Erba, Honestly, I have ANDERSON acceleration on because I inherited a file with these keywords written in when I was taught how to use CRYSTAL for frequency calculations - and worked pretty well so far with our other systems so I thought to leave it alone (though it was more for pharmacuetical systems). Thanks for the suggestion, I'll try it out if with the original TOLINTEG 10 10 10 10 20 and see what happens. Thanks, Peter