Hi,

Would you please share your full input file?

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.

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,

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.

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.

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.

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.

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.

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,

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

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

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,

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,

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.

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?

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,

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.

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!!!

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,

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,