Hi,

The CPKS implementation in PCRYSTAL is parallelized according to a replicated-data strategy, which means that each process has a copy of the main arrays. Assume that each process (usually coinciding with each CPU core) allocates X GB of memory. If you run the job over n CPU cores in the same node, the total amount of required memory on the node will be nX.

So, one way to reduce the memory requirement of a replicated-data calculation is to lower the number of used CPU cores per node.

As an example, if you have a node with 128 CPU cores, try running the calculation on just 64 or 32 cores, making sure no other processes are executed on the node at the same time. This would effectively increase the available memory.

Hope this helps.

Hi,

We have found a workaround that allows you to visualize animations of normal modes from CRYSPLOT also from a FRAGMENT calculation.

1. Go to CRYSPLOT and from the "Make a Plot" menu select "Geometry Structure" (bottom-right)

2. Select and upload your output file (.out)

3. By right-clicking with your mouse select "Vibration" and set it to "On":

4. At this point, by right-clicking with your mouse select "Model x/23" and select desired Mode from list to animate it:

Hope this helps

job314 only for FRAGMENT calculations. See my reply below/above.

Hi,

We've been running some tests. This is what we found: Vibration Mode Animations on CRYSPLOT are run through JSmol, which does not seem to correctly read a CRYSTAL output file if the option FRAGMENT is used. Without FRAGMENT everything works fine.

We could read your FRAGMENT output file and correctly visualize animations of the modes by using the MOLDRAW package instead.

Hi,

I think that the best way to proceed in this case would be to restart the calculation one or more times. To do this, you just have to make sure that the scratch folder is not deleted when the calculation stops. Basically, you would run a first job with:

FREQCALC
END

Then, after the first calculation stops (maybe because you reached a wall clock time limit) you would run a second job restarting from the first as:

FREQCALC
RESTART
END

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

If needed, you can repeat this restart process multiple times until completion of the frequency calculation.

Hope this helps,

Hi,

I have looked at the code and figured out what is going on. Let me explain what is happening first. I'll then offer a solution below.

You are running a pre-optimization within a frequency calculation + Raman intensity calculation (via the CPHF/KS approach):

FREQCALC
FRAGMENT
19
9 106 131 175 191 192 193  194 195 196 197 198 199 200 201 202 203 204 205
PREOPTGEOM
RESTART
MAXCYCLE
700
ATOMONLY
END
INTENS
INTRAMAN
INTCPHF
END
END

It turns out that the same variable is used in the code to define the maximum number of optimization steps and the maximum number of cycles in the CPHF/KS process. The default maximum number of cycles for CPHF/KS for intensity calculations is 200. Thus what happens is that with MAXCYCLE you set it to 700 but when the INTCPHF keyword is read it is internally re-set to the default of 200.

Clearly, this is not ideal! We are going to fix it in future versions.

Luckily, there is a simple workaround. Everything is fine if you run a geometry optimization first, then followed by a subsequent frequency calculation starting from the optimized geometry.

The first calculation would look something like:

OPTGEOM
ATOMONLY
MAXCYCLE
700
END

And the second one (from the optimized geometry obtained at the previous step) would be:

FREQCALC
FRAGMENT
19
9 106 131 175 191 192 193  194 195 196 197 198 199 200 201 202 203 204 205
INTENS
INTRAMAN
INTCPHF
END
END

Hope this helps

Hi,

If you want to specify an anisotropic shrinking factor, the syntax in CRYSTAL is slightly different. In your case it would be:

SHRINK
0 0
3 2 2

Please, take in mind that the anisotropic shrinking factor in CRYSTAL does not work properly for those calculations where the symmetry of the system may change (for instance in frequency calculations, FREQCALC, where displaced nuclear configurations are explored, or elastic calculations, ELASTCON, where the lattice is strained, etc.).

However, for symmetry-preserving calculations (such as SCF, OPTGEOM, EOS) the use of an anisotropic shrinking factor should be fine.

Hi,

Indeed, to restart an INTCPHF intensity calculation, the INTCPHF keyword must be kept.

In your case, the restart input would look something like:

FREQCALC
INTENS
INTRAMAN
INTCPHF
ENDCPHF
RESTART
ENDFREQ

Hi,

The two options you are using, FIELDCON and FIELD, apply a finite electric field along non-periodic and periodic directions, respectively. Thus, FIELDCON can be used for low-dimensional systems (1D, 2D) only.

When the finite electric field is applied along a periodic direction (FIELD option), a supercell must be built along that direction, which requires additional input parameters with respect to the FIELDCON option. A complete input in your case would look something like:

FIELD
0.00194467
0 0 1
4 1
40 1

where 4 is the supercell expansion factor along the periodic direction of the field and 40 is the number of Fourier terms for the triangular potential expansion.

For a detailed description of the use of FIELD and FIELDCON, please refer to this tutorial page.

Note

Please, be aware that a more analytical approach is available in CRYSTAL to compute the optical dielectric tensor of a system - that does not require any supercell to be built - through the coupled-perturbed Kohn-Sham (CPKS) method. The input for this option is simply:

CPKS
END

to be inserted before the END of the geometry input block.

You can find a tutorial page on CPKS here.

We do strongly encourage to use CPKS rather than FIELD unless strictly needed.

Hi,

After running a few tests, we found a bug towards the end of the EOS module due to the size mismatch of different arrays (specifically, in the full list of direct lattice vectors of the equilibrium configuration and maximally compressed configuration). While this requires an actual fix to the code, we also found a workaround solution for you. Indeed, if the maximally compressed configuration has the same list as for the equilibrium configuration, everything is fine. Thus, in your case, it was enough to explore a maximum compression of 5% (rather than 8%) to be able to run smoothly the job.

Please, find here a working input file (where we have also reduced the number of explored volumes to 4+1 to speed up the calculation without resulting in any significant loss of accuracy).

job314 I wouldn't be THAT optimistic

Dear CRYSTALlers,

The Theoretical Chemistry Group of the University of Torino and the Department of Chemistry and the Thomas Young Centre at Imperial College London are organising the

MSSC2025 Summer School on Ab initio Modelling in Solid State Chemistry

to be held in Torino (Italy), 8-12 September 2025. The School is designed for Master and Ph.D. students, as well as for post-docs and researchers who have an interest in getting or strengthening a background in Computational Solid State Chemistry, Physics, Materials Science, Surface- and Nano-Science.

The week-long School consists of morning lectures and afternoon hands-on tutorial sessions, where the formal framework and functionalities of the CRYSTAL electronic structure package will be explored.

Registration opens on March 15 2025. See the School website for further details.

The School takes place in the elegant city of Torino (Italy):

­
While we strongly encourage in-person participation, we also offer the possibility to attend remotely through streaming of morning lectures and afternoon hands-on tutorials.

Participants will have the opportunity to present their research at a poster session.

See you in Torino!

job314 Yes, it should print the geometry of the last optimization step. Please, be aware that the CIFPRT and CIFPRTSYM options are not as general as one would like them to be. For systems where the primitive and crystallographic cells differ, they may result in an incomplete list of atoms. In those cases, I recommend switching symmetry off with the SYMMREMO option in combination with TESTGEOM, just to generate the .cif files correctly.

Hi,

Elastic constants of a 3D lattice in CRYSTAL are defined and computed as:

$$
C_{ij}^\textup{3D} = \frac{1}{V} \left( \frac{\partial^2 E}{\partial \eta_i \partial \eta_j}\right)
$$

where the strain \( \eta \) is dimensionless and thus the elastic constants have units of \( \textup{energy/length}^3 \), which corresponds to force/surface (i.e. a pressure).

For 1D and 2D periodic lattices, as the volume \(V\) is not defined, one may divide by the length \(l \) and area \( A\) of the lattice cell instead:

$$
C_{ij}^\textup{1D} = \frac{1}{l} \left( \frac{\partial^2 E}{\partial \eta_i \partial \eta_j}\right) \qquad \textup{and} \qquad C_{ij}^\textup{2D} = \frac{1}{A} \left( \frac{\partial^2 E}{\partial \eta_i \partial \eta_j}\right)
$$

However, in CRYSTAL for 1D and 2D lattices we do not divide by \(l \) or \( A\) , and just define and compute the elastic constants as:

$$
C_{ij}^\textup{1D and 2D} = \left( \frac{\partial^2 E}{\partial \eta_i \partial \eta_j}\right)
$$

with units of energy. So, starting from the constants printed in the CRYSTAL output all you have to do is divide by the area of the 2D cell if you need them expressed in \( \textup{energy/length}^2 \).

We are running some tests and I think we are close to identifying the problem. We’ll probably have a solution by the beginning of next week.

job314 Good point! About the shrinking factor: the anisotropic shrinking factor in CRYSTAL does not work properly for those calculations where the symmetry of the system may change (for instance in frequency calculations, FREQCALC, where displaced nuclear configurations are explored, or elastic calculations, ELASTCON, where the lattice is strained, etc.). So in general, I personally tend to avoid using an anisotropic shrinking factor.

However, for symmetry-preserving calculations (such as SCF, OPTGEOM, EOS) the use of an anisotropic shrinking factor should be fine.

job314 I have checked your attached output files. The OPTGEOM calculation converges to the optimized structure in 29 steps. The PREOPTGEOM calculation within the EOS option converges to the same optimized structure in 25 steps. A lower number of steps in EOS is likely due to the higher accuracy of the computed forces because of tighter default settings in EOS than in OPTGEOM (for instance, TOLDEE is set to 8 in EOS and to 7 in OPTGEOM).

The EOS.out file you shared looks perfectly fine. I can not find any failed geometry optimizations there. After the pre-optimization, the actual constant-volume optimizations are performed (converged in 40, 19, 16, 16, 8 steps, respectively). The output is not complete because I guess the calculation was still running.

Hi,

Find below a modified input file for which the SCF converges in 25 iterations:

Na2Si2O5, Rakic Physics and Chemistry of Minerals 29 (2002) 477-484 - Ale mod
CRYSTAL
0 0 0
14
4.725582 23.296569 7.936255 90.15
18
11 .2299 .26138 .5247
11 .2743 .51408 .3548
11 .2534 .47281 -.1019
11 .7548 .28108 .2783
14 .2961 .36325 .1966
14 .6843 .34077 .6429
14 .1831 .40821 .5373
14 .7948 .38941 -.0185
8 .1210 .3844 .0352
8 .2339 .3015 .2523
8 .6209 .3690 .1429
8 .2440 .4105 .3392
8 .7431 .3414 -.1590
8 .7456 .2819 .5655
8 .3573 .3561 .6162
8 -.1423 .3920 .5597
8 .2452 .4667 .6166
8 .7336 .4511 -.0767
EOS
RANGE
0.95 1.05 8
PREOPTGEOM
MAXCYCLE
500
END
BASISSET
POB-TZVP-REV2
DFT
cam-B3LYP
XLGRID
END
TOLINTEG
10 10 10 10 20
SHRINK
6 6
BIPOSIZE
11202400
EXCHSIZE
11202400
MAXCYCLE
200
END

We have increased the values of TOLINTEG, used an isotropic shrinking factor, and re-activated the DIIS accelerator.

job314 I see, interesting! I don't seem to be able to find the input/output files

Yes, the pre-optimization of the EOS is indeed a full structural relaxation where cell/volume/atomic positions are all relaxed at once. If you want me to have a closer look at this case, please send me the input/output files.