Hi,

I am quite familiar with that error message myself: it pops up when the fort.9 unit provided upon the restart is the wrong one (i.e. does not match with the current calculation).

Let me make a general comment on how to best approach these frequency calculations with CRYSTAL based on my experience.

I noticed that you tend to use the PREOPTGEOM option within FREQCALC. Now, this is a very nice feature of CRYSTAL that allows you to run a single job where everything is fully automated: the structure gets optimized, the numerical Hessian computed and diagonalized. Not many programs can do that, to the best of my knowledge. At the same time, while this is very convenient if you can indeed run everything in a single job, it complicates things if you then need to do a restart from a previous incomplete calculation.

If you envisage that this could be the case (maybe because of a wall clock limit on the cluster) then it is preferable (to put it mildly) to do things step by step:

• You first run a geometry optimization with something like:

[initial geometry]

OPTGEOM
END

• You prepare a new input file where you insert the optimized geometry from the previous run as a starting point, and perform a frequency calculation, with something like:

[optimized geometry]

FREQCALC
END

• If this calculation stops, you can now restart it easily with:

[optimized geometry]

FREQCALC
RESTART
END

by providing the required restart files (FREQINFO.DAT from the first frequency calculation, fort.13 unit, and fort.9, to be renamed fort.20 in the new scratch folder).

Personally, I always do things separately, running first the geometry optimization and then the frequency calculation in two separate jobs.

Hope this clarifies things a little,

Whatever works, I guess

The point that you make about the geometry may also be relevant. Given that your original calculation was also performing a geometry optimization, when you do the restart calculation you must ensure that the geometry specified in the new input is the optimized one from the previous run.

Hi,

Let's try to fix one of these restart issues at a time.

As you know (I put it here for other readers as well), to restart a FREQCALC calculation we need the RESTART keyword, as below:

FREQCALC
RESTART
END

All keywords related to the calculation of the intensities from the initial job should be kept in the new input as well.

In order to make this restart work, you need a few files from the previous job to be placed in the scratch folder of the new job: FREQINFO.DAT, fort.13 and fort.9 (to be renamed fort.20 in the new folder).

As such, I am unable to try to restart your job because I need these three files from the previous run. If you have them you can try to restart and/or send me the files.

Let's see how this goes.

Hi,

The MP2 option is no longer supported in recent versions of the CRYSTAl program. If you are interested in a periodic MP2 calculation, my suggestion is to contact Lorenzo Maschio ([email protected]) and Denis Usvyat ([email protected]) directly, who may provide guidance in the use of the CRYSCOR program.

Hi,

Let me try to rationalize what you observe as follows: In CRYSTAL, interatomic force constants for phonon dispersion are computed with a direct space approach within a supercell. Because of the reciprocity relation between direct and reciprocal lattices, the number of k-points for which phonons can be computed is determined by the expansion factor of the supercell relative to the primitive cell. For instance, with your 2x2 supercell expansion for a 2D system, you get to compute phonons at just 4 k-points. In order to get the phonons at more k-points you can do one of two things (or both):

1. Increase the supercell expansion (i.e. increase the size of the supercell). Going to 3x3 gives you phonons at 9 k-points, 4x4 gives you phonons at 16 k-points, and so on. This is done through the SCELPHONO keyword:

SCELPHONO
6 0
0 6

2. Interpolate the interatomic force constants to evaluate the dynamical matrices at additional k-points with respect to those determined by the expansion matrix of the supercell. This can be done through the INTERPHESS option as follows:

INTERPHESS
8 8
0

NOTE 1: This interpolation is safe only if the interatomic force constants vanish within the supercell. This usually requires the supercell to have a radius of at least 10-15 Angstroms (i.e. the supercell has to be large).

NOTE 2: This interpolation is used when phonon bands are computed with BANDS. Thus, the starting supercell has to be large to compute phonon bands safely.

In your case, what you observe is the following: when you do the BANDS calculation you are doing the interpolation. When you do the PDOS calculation you are not. To add the interpolation in your PDOS calculation (and get a phonon density-of-states that matches that of the phonon band plot) you need to add the INTERPHESS option.

But, and this is an important but, in this way you would get matching results but they are likely to be both wrong because the supercell you are starting from is too small. To get more reliable results, you need to significantly increase the supercell expansion matrix.

Hope this helps,

For the purpose of finding the minimum energy structure to then do Raman calculations, it is.

EOS gives you much more than that of course: the p(V) or, equivalently, V(p) relation (i.e. structure as a function of pressure), the bulk modulus K(p), and allows to compute the enthalpy H(p).

Absolutely yes, the optimized structure you get from OPTGEOM (i.e. a full optimization of both atomic coordinates and cell shape/volume, in CRYSTAL) is very very very close the minimum from fitted EOS, and if they differ I would blame EOS over OPTGEOM (meaning that maybe more points in the EOS scan would be required). Additionally, OPTGEOM is much much faster than EOS as only 1 versus N optimization processes are actually performed.

So, to get the fully relaxed structure, I strongly recommend to use OPTGEOM in CRYSTAL. This is what I usually do before running frequency and Raman calculations.

Maybe I understand where the confusion may come from. Till CRYSTAL09, the OPTGEOM option corresponded to a geometry optimization of just the atomic coordinates within a fixed cell. Since CRYSTAL14 (and thus in versions 14, 17 and 23) the OPTGEOM option corresponds to a full geometry optimization (i.e. OPTGEOM is now equivalent to FULLOPTG).

So, OPTGEOM provides the minimum energy structure.

I would need to better understand what you mean by systematic scanning of lattice parameters to comment on that point.

Let me just reiterate on the numerical nature of both the OPTGEOM and EOS options: the minimum structure from both approaches should be the same. If they differ, it is just due to numerical reasons and, personally, I would tend to trust OPTGEOM better.

Hi,

I think that my point is that if you want to find the minimum of the PES you really do not need to run an EOS calculation. You can simply run an OPTGEOM calculation. EOS is useful if you need to take the pressure into explicit account and/or compute the bulk modulus.

If you have already run an EOS calculation with the PREOPTGEOM option, the structure corresponding to the minimum is the one obtained at the end of the pre-optimization, thus before all the various 0.94, 0.96, etc. compressions/expansions are explored. So in this case, all you need to do is look in your output file for the first occurrence of the "OPT END" string. You will find the optimized structure printed in its vicinity.

Hope this helps,

Good! The clean way is:

CRYSTAL
1 0 0
P 21/A

I guess the extra "1"s you put are safe as they correspond to the identity operator.

Hi,

I think it was just a syntax problem on the way the symbol of the space group was inputted. This is how it should look like in this case:

TEST
CRYSTAL
1 0 0
P 21/A
9.383 12.669 6.220 107.05
20
7 0.1321 0.3509 0.3611
1 0.058 0.337 0.225
1 0.208 0.305 0.394
1 0.095 0.344 0.487
1 0.174 0.421 0.346
12 0 0 0
8 0.1603 -0.1094 -0.0307
8 0.1685 0.1042 0.1656
8 -0.0017 -0.0687 0.2986
1 0.2 0.091 0.317
1 0.227 0.134 0.116
1 0.252 -0.096 0.059
1 0.143 -0.176 -0.008
1 -0.097 -0.066 0.341
1 0.027 -0.135 0.325
16 0.0953 -0.3605 0.2575
8 -0.0469 -0.4174 0.2116
8 0.2185 -0.4328 0.3718
8 0.1185 -0.3211 0.0456
8 0.0951 -0.2702 0.4089
CIFPRT
TESTGEOM
END
END

For future reference, the syntax for space group symbols in CRYSTAL is discussed at pages 22-23 of the CRYSTAL23 User's Manual (see screenshot below):

We ran a test and the structure built from CRYSTAL looks reasonable:

Hope this helps,

Hi,

As there are different ways to compute phonons in CRYSTAL, can you share your input and output files to better understand what is computed and printed?

Hi,

Can you tell me if the "published reference values" you are comparing with are computational from other HSE06 implementations (if yes, which one) or experimental or computational from different functionals?

Thanks

Hi,

On paper, it should be possible but we've been running some tests in the last few days before answering to your question and we have been experiencing some problems with the restart option of CPHF. We are going to run more tests and we will let you know as soon as we will have some updates.

Hi,

Section 6 of Chapter 2 of this book addresses these aspects into some detail:

Pisani, C.; Dovesi, R.; Roetti, C. Hartree-Fock Ab Initio Treatment of Crystalline solids; Lecture Notes in Chemistry Series; Springer Verlag: Berlin, 1988; Vol. 48.

I have extracted the relevant pages here.

Hi,

The SCF converged because at cycle 8 the energy change with respect to the previous cycle was below the default threshold of 1.0E-6:

CYC 8 ETOT(AU) -8.392097541980E+03 DETOT 8.46E-07

By inspection of this specific SCF, I would suggest to re-run it by tightening the convergence criterion a little, for instance with:

TOLDEE
8

Hope this clarifies things a little

Hi,

In the current implementation in CRYSTAL, SOC is described through relativistic effective core pseudo-potentials (RECPs) and thus is not included if all-electron basis sets are used.

However, there are two important points to be stressed:

1. It is possible to run a SOC calculation where RECPs are used on a subset of elements while all-electron basis sets are used on remaining atoms (this is the case of the input file you initially shared, where you had RECPs on Pt and all-electron basis sets for Mg and Si).

2. Some POB basis sets (i.e. those of heavy elements) do make use of RECPs that can be used for SOC calculations in CRYSTAL. These basis sets are labeled with a _SOC at the end of their name. Please, refer to this page:

https://www.crystal.unito.it/basis_sets.htm

By clicking on an element (Iodine for instance), you'll get the list of available basis sets already in CRYSTAL format:

In this example, the last one is a POB basis set that can be used for SOC calculations.

Hope this helps

Hi,

Hessian information is indeed contained in the OPTINFO.DAT file, as is information on the last geometry of the previous run so that it is indeed unnecessary to manually update the geometry in the new input.

This is not so clear from the documentation: I had to check in the code

Hope this clarifies things a little

Hi,

Good to know it now works. Just for future reference, to restart a geometry optimization in CRYSTAL, the input looks like:

OPTGEOM
RESTART
END

In order to make this restart work, you need just a couple of files from the previous job to be placed in the scratch folder of the new job: OPTINFO.DAT, and fort.9 (to be renamed fort.20 in the new folder).