A possible "work-around" just came to my mind. As far as I understand, your job successfully completed the first deformation (STRAIN 1) to later fail during the next deformation (STRAIN 3) with the following error:

ERROR **** SCF **** SG_IRR ALLOCATION ERROR: ALREADY ALLOCATED

It looks like some arrays are not properly deallocated when moving from one deformation to the next. A possible work-around would be to compute each deformation in an independent calculation. You can use the DEFORM option to specify what deformations should be active. For instance with:

ELASTCON
PRINT
DEFORM
0 0 1 0 0 0
END

you would be asking to consider just the third deformation as active. With PRINT you ask for extended printing options. You will find the computed elastic constants for the third row of the elastic tensor printed in the output.

As for your calculation there are only three symmetry-independent deformations:

LIST OF ACTIVE DEFORMATIONS:
1
3
4

you could have all the elastic constants by running three calculations. One with:

ELASTCON
PRINT
DEFORM
1 0 0 0 0 0
END

a second one with

ELASTCON
PRINT
DEFORM
0 0 1 0 0 0
END

and a third with

ELASTCON
PRINT
DEFORM
0 0 0 1 0 0
END

Let me know if this helps.

Hi,

We have run your input files with CRYSTAL23 and the calculation was successful (see attached output file). Are you by any chance running an older version of the program?

Let me run some tests

Hi,

While there is no option to estimate the necessary memory, there are a couple of advanced printing options to monitor the memory used step-by-step throughout the calculation. Please, refer to the MEMOPRT and MEMOPRT2 keywords in the User's Manual.

Let me know if this helps,

Hi,

The input/output files you uploaded look fine. It is difficult for me to understand what happened.

Hi Jonas,

I see from your input that you are scanning along mode number 12 (with positive harmonic frequency of ~66 inverse centimeters). Have you tried scanning along mode 1 (with "negative" harmonic frequency of ~-14 inverse centimeters)?

Of course, in no case an isolated molecule would have access to neighboring functions. But in the crystal it does. If its own basis is not complete, a molecule in the crystal can get extra-stabilized by the neighboring functions not because of a "physical" or "chemical" interaction with neighboring molecules but because of an artifact due to the incompleteness of its basis. So if you were to compute the cohesive energy just as energy of the crystal - energy of the bare molecule, you would get an extra unphysical interaction. To make sure you get the right cohesive energy you could do one of two things: i) remove the extra interaction from the calculation on the crystal; ii) add it also to the molecular calculation so that it cancels when taking the difference (this is the MOLEBSSE strategy, also known as Boys-Bernardi counterpoise correction).

Hi Jonas,

As you correctly point out, in this case the molecular calculations are not affected by BSSE as you are extracting a single molecule (i.e. with no neighbors).

The calculation that is affected by BSSE is the one on the crystal, where each molecule within the molecular crystal could potentially "benefit" from the basis functions of the neighboring molecules if its own basis is not complete. So we use MOLEBSSE for this, to make sure we compare apples with apples (i.e. the energy of a molecule in the crystal that has access to the basis functions from neighboring molecules, with the energy of an isolated molecule that also has access to the same neighboring basis functions).

Hope this helps clarifying things a little,

Hi,

In the context of TOPOND, PS does indeed label an atom for which a PSeudopotential is used. At some point of the output the coordinates of the PS atomic center are printed, which should allow for its identification.

Hope this helps,

Excellent, thank you for the quick feedback.

Hi,

We have checked the implementation. The values printed in the output of the BETAVIB calculation for SHG and Pockels are expressed in atomic units and correspond to \( \frac{1}{2}{\boldsymbol{ \beta}} \). That is, the factor of \( \frac{2\pi}{V} \) seems to be missing to make them the d tensor. In other words, by multiplying the values in the output by \( \frac{2\pi}{V} \) you should get d.

Please, let me know if you think this makes sense based on the values you get for your system.

Sorry for the confusion.
Hope this helps,

Formally, if finite temperature effects are to be included, the internal static energy E needs to be substituted with the free energy F in the definition of the Hessian. This is easier said than done. However, for the elastic tensor, we do have an implementation to compute free energy derivatives with respect to lattice strain (i.e. thermo-elasticity). See also:

https://www.mdpi.com/2075-163X/9/1/16

The elastic tensor is not defined for 0D systems, where you could just explore the "dynamical stability" in terms of the vibration frequencies.

Hi,

Stability is a broad concept that can be interpreted and analyzed in many ways. One way to look at it is the following: checking whether or not the Hessian of second energy derivatives is positive-definite (all eigenvalues are positive) or not, i.e. if the structure is a local minimum of the potential energy surface (PES). Indeed if small structural perturbations produce an energy decrease rather than increase (that is if some of the eigenvalues are negative) the structure can not be considered "stable".

Two types of Hessian matrix can be considered, which correspond to two types of stability:

• Hessian with respect to atomic displacements within a fixed cell for dynamical (phonon) stability. This corresponds to checking if all harmonic frequencies are positive.

• Hessian with respect to lattice distortions for mechanical stability (so-called Born stability conditions). This corresponds to checking if all the eigenvalues of the elastic tensor are positive.

Hope this helps,

Hi,

Could you please share your CRYSTAL output file from the BETAVIB calculation? In case you also computed just the electronic term, could you share those output files as well?

The first link you give looks broken: 404 page not found.
Thanks,

Hi Jonas,

When computing thermodynamic properties, we should set up a canonical partition function over all vibrational states of the lattice, which includes phonons at all k points within the first Brillouin zone in principle. The partition function, and thus thermodynamic properties, tend to converge as the sampling of phonons at different k points improves.

As an example, consider what happens for the specific heat and vibrational entropy of MgO in the picture below, where lines of increasing thickness correspond to calculations on larger supercells (i.e. to richer k sampling):

As you see, thermodynamic values change and eventually converge!

So, depending on the size of the original cell, phonon dispersion can have a very large effect on computed thermodynamic properties. This is particularly evident for MgO where the original cell is very small.

So, going back to one of your questions: "how large should the supercell be?" You should use the smallest cell that allows you to get converged results. How to determine it? By progressively increasing the size and by checking your results.

The rule of thumb you suggest of using supercells for different systems containing a similar number of atoms is a good guideline for consistent expansions across different systems.

Hope this helps,

Hi,

To analyze conduction bands I can recommend a couple of options:

• Decomposition of selected bands into leading AO contributions. This option allows to characterize the nature of a band at a given k point in terms of the main AOs contributing to it. From the PROPERTIES module, refer to the ANBD keyword, see page 307 of the User's Manual.

• 3D plotting of crystalline orbitals. From the PROPERTIES module, refer to the ORBITALS keyword, see page 347 of the User's Manual.

Hope this helps,

Hi,

Indeed, columns of the TENS_RAMAN.DAT file correspond to xx, ..., zz components of the polarizability tensor \( \alpha \). However, rows correspond to the 3N atomic Cartesian displacements. Indeed, the Raman tensor reported in this file corresponds to the following quantity:
$$
R_{ac,ij} = \frac{\partial^3 E}{\partial u_{a,c} \partial \varepsilon_i \partial \varepsilon_j} = \frac{\partial \alpha_{ij}}{\partial u_{a,c} }
$$
where \( \varepsilon_i \) is a Cartesian component of the electric field, and \( u_{a,c} \) is an atomic displacement of atom \( a \) along the \( c\)-th Cartesian direction. The values are reported in atomic units.

Hope this helps,

Hi,

With CRYSTAL (from the PROPERTIES module actually) one can output the Hartree+EN potential in the all-electron case in 2D or 3D grids with POTM and POT3 keywords, respectively. In the latter case, the output is in .cube format. But I am afraid that currently there is no keyword to plot the XC part of the potential on a grid.

Hi,

You can do this using the PROPERTIES module. The PBAN option [see CRYSTAL23 User's Manual at page 348] allows you to build a density matrix from a user-defined subset of electronic bands. This partial density matrix is used for subsequent calculations. The ECH3 option can then be used to evaluate the associated electron density on a user-defined 3D grid of points, to be stored in .cube format, which can then be plotted in 3D isosurfaces with standard visualizers, such as VESTA.

A template .d3 PROPERTIES input file for this would look something like:

NOSYMADA
NEWK
24 24
1 0
PBAN
1
14
ECH3
80
RANGE
-10 10
END

where in PBAN as an example I have selected just 1 band, number 14 in the list.

Hope this helps,

It was a great week! Let me share a group picture from the event: