Dear Jacques,

Thank you for your reply which indeed solve the problem.

Best regards
Xavier

Thank you Giacomo Ambrogio.
I am greatful to the CRYSTAL code forum
This will help alot.

Best Wishes

thank you

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.

Thank you Jacques for your kind help.
This will solve multiple problems of my current work

Regards
R.Zosiamliana

Thank you sir for your kind reply...

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.

Sorry, I have been working fiercely on these cases, must have overwritten many times. Several EOS cases run out of cycles such as this after 102 cycles abive, including this one when I start range at 0.92 lattice constant (according to the online manual examples). Some of these problems went away when I narrowed the range, e.g. start at 0.96

thank you

Hi,

In CRYSTAL23, the anharmonicity of a given vibration mode - or of a set thereof - can be computed via: I) the evaluation of cubic and quartic interatomic force constants (in the basis of the normal modes) followed by II) the solution of the nuclear Schroedinger equation with either the vibrational self-consistent field (VSCF) or vibrational configuration interaction (VCI) method.

Details on the actual implementation of steps I) and II) can be found here:

I) Anharmonic force constants

II) VSCF and VCI for solids

Step-by-step, the procedure is as follows:

Geometry optimization to fully relax atomic positions within the cell (OPTGEOM keyword); Harmonic frequency calculation (FREQCALC keyword); Selection of the normal modes for which the anharmonic correction is to be computed (for instance, in your case, those corresponding to C-H stretching vibrations); Calculation of cubic and quartic interatomic force constants for the selected modes + VSCF (or VCI) calculation of anharmonic states.

As an example, let' s assume that C-H stretching vibrations correspond to modes 15-20 in the list generated from the harmonic calculation (that is, there are 6 different C-H stretching modes). The input for steps 3. and 4. above would read:

FREQCALC RESTART ANHAPES 6 15 16 17 18 19 20 3 0.9 VSCF END

that is, we restart the harmonic frequency calculation, and where 6 is the number of modes, 15 16 17 18 19 20 are the selected modes, and 3 0.9 are two parameters specifying the numerical approach used for the evaluation of cubic and quartic force constants.

Please, note that with such a calculation not only the "intrinsic" anharmonicity of each selected mode is evaluated but also the couplings among all selected modes. If, instead, one just wants to compute the "intrinsic" anharmonicity with no couplings, independent calculations can be run, one per each selected mode.

Visit this page for a tutorial on anharmonic calculations in CRYSTAL

Hi,

The presence of imaginary frequencies is a sign that the geometry is not a minimum of the potential energy surface (PES). In general, this may due to two main factors:

1) A somewhat loose overall numerical precision in the geometry optimization + harmonic frequencies calculation. Here, it seems that you have already explored a few parameters. We can distinguish between parameters governing the overall numerical precision of the SCF + forces calculations, and those that are specific to the evaluation of the Hessian:

1.1) Precision of SCF+forces

One may increase a bit the thresholds for the screening of two-electron integrals (TOLINTEG keyword), switch-off the bipolar approximation (NOBIPOLA keyword), increase the shrinking factor (SHRINK keyword), use a denser grid for numerical integration of the exchange-correlation term (see XLGRID, XXLGRID keywords), tighten the convergence criteria for the SCF (setting TOLDEE to 10 or 11 for instance), tighten the convergence criteria for the geometry optimization step (see TOLDEG and TOLDEX keywords).

1.2) Numerical evaluation of the Hessian

In many cases, a more numerically stable evaluation of the Hessian is achieved by use of a two-sided finite difference approach (rather than the default one-sided approach). This can be activated with the NUMDERIV keyword within the FREQCALC input block as follows:

FREQCALC NUMDERIV 2 ENDFREQ

2) The presence of symmetry-constraints that prevent the optimizer to get to the minimum of the PES. If this is the case, removing symmetry constraints may be key to reach the minimum. This can be done by use of the SYMMREMO keyword (to be inserted in the geometry input block).

Dear Giacomo, it worked fine. Thank you very much!

Thank you very much for your kind response.

Hi,

By default, thermodynamic properties on top of harmonic frequencies are computed at room temperature. Different values of temperature can be explored by use of the TEMPERAT keyword. To restart the harmonic frequency calculation, use the RESTART keyword. An example is given below:

FREQCALC RESTART TEMPERAT 5 200 600 END

With the input above, thermodynamic properties will be computed and printed at 5 temperatures, equally spaced in the range 200-600 K.

Here is a nice paper for the SCF (spin-current fan) inside you!

https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.96.076604

No problem. Hope it helps.

Hi Antonio,
Unfortunately, I don't think there is any specific print statement in the .out file that indicates if the calculation was run using either SDFT or SCDFT formalism. Maybe in newer versions of the code, we will add more information about this!

I guess the only way to tell is by looking at the input file. A good practice could be to print the input file at the top of the output in your launch script, so that you always have a reference to your input for each output you generate.