Developer group

undefined

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,

undefined

Whatever works, I guess

undefined

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.

undefined

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.

undefined

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.

undefined

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):

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

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,

undefined

Hi Job,
It seems there might be a bit of confusion regarding how to report MPI bindings, maybe we will update the tutorial to make it more clear.

To display binding information correctly, you’ll need to include the appropriate flag in your usual mpirun command. For example:

If you're using OpenMPI:

mpirun --report-bindings -np 192 Pcrystal

If you're using Intel MPI:

mpirun -print-rank-map -np 192 Pcrystal

To check which MPI implementation you're using, you can inspect the loaded modules in your environment, or simply run:

mpirun --version

If you're using a different MPI implementation, feel free to let me know. I'd be happy to help you find the right way to print the bindings.

undefined

Hi job314,

A good reference is the how to run tutorial.

In your calculation, you're using 30 k-points. Depending on system symmetry, this generates a number of symmetry-adapted Bloch functions that are then distributed across processes. This is the main parallelization bottleneck in Pcrystal: ideally, you want to use a number of MPI processes equal or lower than the number of SABFs.

However, the behavior you describe seems unusual, even in cases where the number of MPI processes exceeds the number of SABFs. It might be an inter-node communication issue.

Have you tried running other MPI programs across multiple nodes to see if the problem persists?

Also, check how MPI processes are bound to physical cores. You can control this by adding a printing flag in your mpirun command (this is also explained in the tutorial above).

Let me know if you manage to get the bindings.

undefined

Hi Danny,

From a first look at your input file, I noticed that you are performing a combined PDOS and BANDS calculation. This has not been fully tested as we prefer to run two separate jobs, one for PDOS and one for BANDS. Once the harmonic frequencies are computed, they can both be run through restarts and are both very fast.

Indeed, the PDOS calculation produces a single set of data if run without the BANDS keyword.

I therefore suggest to split your calculation in two different ones: one for PDOS and one for BANDS. You can use the RESTART keyword in the FREQCALC block to avoid recomputing the Hessian matrix (see page 219 of the User manual).

I leave here a link to a tutorial webpage that we have recently updated about computing phonon-related properties with CRYSTAL.

Let me know if this helps!

undefined

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).

Developer

Posts

Member List