Skip to content
  • Home
  • Recent
Collapse
Brand Logo
CRYSTAL23
Latest v1.0.1
Tutorials Try the Demo Get a License
Tutorials Try the Demo Get a License Instagram
aerbaundefined

Alessandro Erba

@aerba
Developer
About
Posts
71
Topics
1
Groups
1
Followers
8
Following
8

Posts

Recent Best Controversial

  • Negative value in the SCF of an anion vacancy
    aerbaundefined aerba

    Hi,

    Would you please share your full input file?


  • Problem with restarting CPKS calculation
    aerbaundefined aerba

    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.


  • Problem with restarting CPKS calculation
    aerbaundefined aerba

    Dear Aparajita,

    It is strange that the fort.9 unit is empty. May it be a problem of the script in copying back that unit from the scratch folder to the working directory?

    Anyway, you can try to trick CRYSTAL in this way:

    • By inspection of your output file:
    CYC  13 ETOT(AU) -1.952535840054E+05 DETOT -1.58E-05
    

    the energy difference is down to 10^-5 at cycle 13. So, you can try to run the calculation with a low energy convergence threshold of just 10^-4 with something like this:

    TOLDEE
    4
    

    and the SCF would be considered as converged for the program. In this way the calculation is not killed and probably you will get your fort.9 unit,;

    • you can then use it to do a restart calculation with the GUESSP keyword (and by tightening the energy convergence threshold to something like TOLDEE 7, or 8):
    GUESSP
    TOLDEE
    7
    

    Hope this helps,


  • No space left on device
    aerbaundefined aerba

    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.


  • No space left on device
    aerbaundefined aerba

    I can not tell the origin of the problem for sure but one thing you could try is to use the HISTDIIS keyword to set a lower maximum number of Fock matrices to be stored on disk for the DIIS convergence accelerator.

    You could try with something like:

    HISTDIIS
    10
    

    or less.

    Indeed, this piece of your output suggests that all Fock matrices from all previous SCF iterations are stored:

    job314 said in No space left on device:

    DIIS ACTIVE - HISTORY: 23 CYCLES

    When the system size is large and the SCF takes many iterations to converge, this may require lots of data to be stored on disk.

    Let me know if this helps.


  • Negative density of states
    aerbaundefined aerba

    Hi,

    From what I see you get very few negative values. Typically, it is an artifact of the interpolation method. Sampling the DOSS at more energy points and/or changing the number of Legendre polynomials used in the DOSS expansion solves the problem.


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

    job314 Yes, this makes sense now that I think about it. Still, it would be advisable to restart the frequency job from the optimized geometry for one technical - and yet important - reason: the so-called FIXINDEX strategy used in CRYSTAL.

    In the evaluation of the integrals, a list of interactions to be computed is defined at the beginning of the calculation and kept constant (the list, not the interactions) throughout the calculation to ensure numerical smoothness. This list is generated from the starting geometry in the input. It is better for it to be the optimized one. In many cases this may not be critical but it could lead to numerical issues if the inputed geometry is far from the equilibrium one.


  • Error in RESTART of FREQCALC calculation
    aerbaundefined aerba

    PeterRemoto At the moment I am afraid I do not have an explanation for the difference you experienced between CRYSTAL17 and CRYSTAL23 as I am unable to reproduce the erratic behavior with CRYSTAL23.


  • Error in RESTART of FREQCALC calculation
    aerbaundefined aerba

    PeterRemoto I have tried to restart your calculation with CRYSTAL23 following my step-by-step recipe (described at https://forum.crystalsolutions.eu/post/339) and it worked.

    This is what I did:

    • I prepared an input file to run the harmonic frequency calculation, without intensities, I ran it and I killed it in the middle of the construction of the Hessian. From this incomplete frequency calculation, I obtained the FREQINFO.DAT file (I can not upload it here as it exceeds the maximum allowed file size), the external unit with the density matrix, i.e. fort.13 unit, and the external unit with the wavefunction, i.e. fort.9;

    • I prepared an input file to restart the frequency calculation and provided the FREQINFO.DAT, fort.13 and the fort.9 (renamed as fort.20) files from the previous step, and ran it. The calculation of the Hessian restarted correctly, with the new SCFs converging nicely (see the attached SCFOUT.LOG file). I then stopped the calculation not to use too much compute power on my cluster.

    If you follow this step-by-step process you'll be able to safely restart your frequency calculations with CRYSTAL23.

    Hope this helps,


  • Error in RESTART of FREQCALC calculation
    aerbaundefined aerba

    PeterRemoto I started drafting a reply but encountered problems in uploading the files. Will try later.


  • Error in RESTART of FREQCALC calculation
    aerbaundefined aerba

    PeterRemoto I just started running some tests on this case. I will keep you posted on how it goes.


  • QHA-LD with phonons from entire Brillouin zone
    aerbaundefined aerba

    Dear Georg,

    It is correct. Note that of course if you build a supercell, band folding will bring back at Gamma phonons that would be formally assigned to other k points, which in the end allows for QHA calculations also with phonons out of Gamma.

    For instance with something like:

    SUPERCEL
    2 0 0
    0 2 0
    0 0 2
    QHA
    END
    

    you would be building a 2x2x2 supercell (relative to the primitive one), and performing a QHA on it (i.e. from harmonic frequencies computed on the supercell, and thus equivalent to phonons at 8 k points).

    Hope this sheds some light on the matter,


  • QHA in monoclinic system with non-constant angle
    aerbaundefined aerba

    Hi Georg,

    In the .out output file you can find the optimized structures at different volumes from the EOS. By searching for "CELL DEFORMATION" you will get to the point of the output where a deformation (compression/expansion) is applied. The corresponding strain matrix is printed right below. Something like:

    ********************************************************************************
    CELL DEFORMATION
    *******************************************************************************
    
        ELASTIC STRAIN MATRIX (ADIMENSIONAL)
    
        1   -0.0101017008   -0.0000000000   -0.0000000000
        2   -0.0000000000   -0.0101017008   -0.0000000000
        3   -0.0000000000   -0.0000000000   -0.0101017008
    

    From there, by searching for "OPT END" you will get to the point where the constant-volume optimization ended. Something like this:

     ******************************************************************
     * OPT END - CONVERGED * E(AU):  -1.385471079118E+04  POINTS   16 *
     ******************************************************************
    

    Right below this, you will find the optimized structure. First a list of atomic neighbors and then the actual lattice parameters and atomic coordinates right below the string "FINAL OPTIMIZED GEOMETRY".

    From here, by searching again for "CELL DEFORMATION" you will get to the second explored volume, and so on and so forth.

    In this way you can check how all structural parameters (including the beta angle) evolve with volume.

    It is true that at the end of the QHA calculation, CRYSTAL is currently not computing the thermal expansion coefficients for the lattice angles. I initially coded just the volumetric thermal expansion coefficient, then added the three linear coefficients for the lattice vectors. I may have to add those for the angles as well.

    Still, there should be the necessary information in the output to evaluate it. EOS gives you the dependence of beta on the volume (see above) and QHA the dependence of the volume on temperature.

    Hope this helps,


  • QHA in monoclinic system with non-constant angle
    aerbaundefined aerba

    Hi Georg,

    The EOS/QHA algorithm in CRYSTAL is general (i.e. with no particular restrictive assumptions on the space group) so I would expect it to find the optimal structure at each explored volume by fully relaxing all symmetry-allowed structural degrees of freedom.

    Is beta not changing at all or "just" not as much as expected?

    Happy to have a look at your input/output files if you think it could help.


  • Advice on frequency calculations on large solid systems -
    aerbaundefined aerba

    Hi,

    Thanks for the update! I still hadn't had the time to look carefully into this. Now, by looking at your input file, I just noticed that you are using ANDERSON for the INTCPHF step instead of DIIS, which is the default option in CRYSTAL23. Can I ask you why you decided to switch to ANDERSON? Was DIIS not converging? If you instead used ANDERSON straight away, may I suggest to remove it and thus use DIIS and see how it behaves as a test?


  • Problem with restarting CPKS calculation
    aerbaundefined aerba

    Hi,

    You are running a quite large calculation here, with 800+ atoms/cell!

    You are not getting the fort.31 unit to restart the CPKS step because your calculation did not make it to the CPKS step 🙂

    Let me explain: before getting to the CPKS step, an SCF is performed. Your calculation stopped at cycle 14 of the SCF. By looking at your input/output file, I can suggest four things:

    • In the output, you can find this warning:

    WARNING **** GENBUD **** COUL. BIPO BUFFER TOO SMALL - TO AVOID I/O SET BIPOSIZE = 14808875

    which means that the program is swapping to disk. To avoid this and make things faster, you can insert the following keywords in the input file:

    BIPOSIZE
    14808875
    
    • I noticed you inserted the NODIIS keyword in the third block of the input. This is switching DIIS off for the SCF, not for the CPKS step. If this is what you want, ok then. Otherwise, I suggest you remove this keyword from there to keep DIIS active for the SCF.

    • If you want, you can restart the SCF by use of the GUESSP keyword, to start from the last density matrix of the previous incomplete job (through the fort.9 unit, to be renamed as fort.20).

    • remove the RESTART keyword from the CPKS block because, effectively, there is nothing to be restarted there.

    If you do these four things, your input would look like:

    ZIF-90_VOCs
    EXTERNAL
    CPKS
    END
    BASISSET
    mybasis
    DFT
    HSE06
    END
    SCFDIR
    TOLINTEG
    7 7 7 7 14
    TOLDEE
    7
    SHRINK
    1 1
    FMIXING
    90
    BIPOSIZE
    14808875
    GUESSP
    END
    

    Hope this helps,


  • pov-TZVP vs old school basis sets
    aerbaundefined aerba

    Yes, indeed, the d-type shell is missing. This is so unfortunate....

    Worst case scenario is the only possible scenario it seems...

    Although it is difficult to predict what effect this missing d orbitals will have on the computed frequencies, it may be significant.

    Ok, so, you'll need to insert the basis set explicitly in the input for all elements in your system. That is, in the standard way, without the BASISSET keyword. For S, the complete pob-tzvp-rev2 basis is:

    16 10
    0 0 7 2.0 1.0
    60700.928104 0.00054695944225
    9102.6106854 0.00422972245570
    2071.4166009 0.02174782415900
    586.02476821 0.08510005358900
    190.55395021 0.24799128459000
    67.630384260 0.46703640406000
    25.127306905 0.36434587550000
    0 0 3 2.0 1.0
    112.57463010 0.02167004024000
    34.795554217 0.09360230176000
    6.5115556215 -0.26068001422000
    0 0 2 2.0 1.0
    3.2399032261 1.28420894350000
    1.5477160881 0.66036416584000
    0 0 1 0.0 1.0
    0.4487335200 1.00000000000000
    0 0 1 0.0 1.0
    0.1553457200 1.00000000000000
    0 2 5 6.0 1.0
    564.36716027 0.00247967963170
    133.42624379 0.01967793025000
    42.468271189 0.08998000825800
    15.616527580 0.25705880575000
    6.1093988469 0.43515167292000
    0 2 1 4.0 1.0
    2.0359436000 1.00000000000000
    0 2 1 0.0 1.0
    0.4337928300 1.00000000000000
    0 2 1 0.0 1.0
    0.1305009100 1.00000000000000
    0 3 1 0.0 1.0
    0.4107010100 1.0000000000000

    You can find the other basis sets and copy-paste them here

    Although this is not my personal fault, I feel very sorry for this ugly bug.


  • pov-TZVP vs old school basis sets
    aerbaundefined aerba

    Hi,

    Before sharing my general thoughts about POB versus "old school" basis sets, let me ask if you are using POB-TZVP or POB-TZVP-REV2 for your Sulfur-containing systems.

    It was brought to my attention just a couple of days ago that the POB-TZVP-REV2 basis for Sulfur (S) is missing a whole d-type shell in the internal libraries in CRYSTAL and is thus not to be trusted, unless explicitly inserted in the input file as copy-pasted from the website!!!


  • Projected DOS on atoms
    aerbaundefined aerba

    Hi,

    The first data series corresponds to the first set and the second to the second.
    If you need more insight on the specifics of your calculation, please share your files.

    Hope this helps,


  • PBEsol vs PBEsolxc
    aerbaundefined aerba

    Hi,

    In CRYSTAL, the most general syntax to specify exchange-correlation (xc) functionals is, within the DFT input block through the EXCHANGE and CORRELAT keywords as:

    DFT
    EXCHANGE
    label of exchange functional (e.g. VBH, BECKE, PBE, ...)
    CORRELAT
    label of correlation functional (e.g. VWN, LYP, PBE, ...)
    ENDDFT
    

    For certain standard combinations of exchange and correlation functionals, we have implemented single keywords. For instance:

    DFT
    BLYP
    ENDDFT
    

    is equivalent to

    DFT
    EXCHANGE
    BECKE
    CORRELAT
    LYP
    ENDDFT
    

    Another example (here the "XC" letters are appended at the end of the name to reflect that the functional is used for both the exchange and correlation part):

    DFT
    PBESOLXC
    ENDDFT
    

    is equivalent to

    DFT
    EXCHANGE
    PBESOL
    CORRELAT
    PBESOL
    ENDDFT
    

    For PBE, there are three equivalent ways to define it in CRYSTAL:

    DFT
    PBEXC
    ENDDFT
    

    or

    DFT
    PBE
    ENDDFT
    

    or

    DFT
    EXCHANGE
    PBE
    CORRELAT
    PBE
    ENDDFT
    

    There isn't a general rule, I'm afraid. This syntax aspects are discussed at page 134 of CRYSTAL23 User's Manual.

    Hope this clarifies things a little,

  • Login

  • Don't have an account? Register

  • Login or register to search.
  • First post
    Last post
0
  • Home
  • Recent