Thank you very much for the detailed explanation—this really helped clarify things for me! The plot and your explanation made it all very clear.

Your response is incredibly valuable—thank you so much.I suspect that the DIIS/Anderson extrapolation might have 'hit' a local minimum, so the density guess in iteration 8 happened to yield a total energy extremely close to that of the previous step, resulting in a very small ΔE.
CYC 0 ETOT(AU) -8.456120523718E+03 DETOT -8.46E+03 tst 0.00E+00 PX 1.00E+00
CYC 1 ETOT(AU) -8.390242659622E+03 DETOT 6.59E+01 tst 0.00E+00 PX 1.00E+00
CYC 2 ETOT(AU) -8.391027170997E+03 DETOT -7.85E-01 tst 3.34E-03 PX 1.13E-01
CYC 3 ETOT(AU) -8.391734802465E+03 DETOT -7.08E-01 tst 2.44E-03 PX 1.02E-01
CYC 4 ETOT(AU) -8.392064543836E+03 DETOT -3.30E-01 tst 8.38E-04 PX 4.49E-02
CYC 5 ETOT(AU) -8.392086825687E+03 DETOT -2.23E-02 tst 1.24E-04 PX 1.72E-02
CYC 6 ETOT(AU) -8.392095974656E+03 DETOT -9.15E-03 tst 2.86E-05 PX 9.66E-03
CYC 7 ETOT(AU) -8.392097542826E+03 DETOT -1.57E-03 tst 3.85E-06 PX 4.81E-03
CYC 8 ETOT(AU) -8.392097541980E+03 DETOT 8.46E-07 tst 5.41E-06 PX 3.18E-03
CYC 9 ETOT(AU) -8.392098065539E+03 DETOT -5.24E-04 tst 4.69E-06 PX 3.18E-03
While this DETOT value satisfies the default energy convergence criterion, the corresponding values suggest that the electron density had not yet fully stabilized. This aligns well with your suggestion that tightening the convergence threshold would lead to a more reliable result.
Thank you again for your guidance.

Hi all,

According to the CRYSTAL manual, for optimal parallel performance when using Pcrystal, the number of MPI processes should ideally not exceed the total number of irreducible representations associated with the k-points (assuming symmetry is applied).

However, after going through the output file from a recent run, I wasn’t able to find this number explicitly printed.Would there be a recommended way to extract or compute this value within CRYSTAL?
Or is it typically something one estimates manually based on the symmetry and k-point grid? Any guidance would be greatly appreciated!

Many thanks for your detailed explanation and for checking the code — that definitely clarifies things. I really appreciate your help!

GiacomoAmbrogio Thank you for your helpful suggestion earlier! I've carefully reviewed the .out file. After adding NOSYMADA, the calculation stopped at step 9:

CYC 9 ETOT(AU) -8.392098065539E+03 DETOT -5.24E-04 tst 4.69E-06 PX 3.18E-03

== SCF ENDED - CONVERGENCE ON ENERGY E(AU) -8.3920980655389E+03 CYCLES 9

ENERGY EXPRESSION = HARTREE + FOCK EXCH * 0.00000 + (HSESOL EXCH) * 1.00000 + PBESOL CORR
As I mentioned in the input file I shared earlier, I didn’t manually modify any convergence thresholds. I was therefore surprised to see the SCF deemed converged when DETOT = -5.24E-04. From what I understand, the default SCF energy convergence criterion is 1.0E-7, so I’m wondering whether I may have missed something here. Would you mind helping me take a quick look, or point me in the right direction? Many thanks in advance! Added_NOSYMADA.out

Thank you for your explanation. I’d like to ask: when using RESTART to continue a geometry optimization, is it still necessary to include the HESSOPT keyword? In other words, does the .optinfo file contain Hessian information? Also, when using RESTART, is it unnecessary to manually save the final optimized structure from the previous run as the new input?

This issue is now resolved. I repeated the same steps, but this time I changed to a different compute node, and everything ran smoothly. It seems the previous error (MPI_ABORT) was likely related to the configuration or environment of the specific node, rather than the input file or the use of the RESTART keyword itself.

"Added NOSYMADA"
CZ_DBF
EXTERNAL
BASISSET
SOLDEF2MSVP
DFT
HSESOL3C
ENDDFT
NOSYMADA
SHRINK
0 5
1 5 5
TOLINTEG
7 7 7 7 14
END
Added_NOSYMADA.out

"No NOSYMADA"
CZ_DBF
EXTERNAL
BASISSET
SOLDEF2MSVP
DFT
HSESOL3C
ENDDFT
SHRINK
0 5
1 5 5
TOLINTEG
7 7 7 7 14
END
No_NOSYMADA.out
CZ_DBF.cif

GiacomoAmbrogio Thank you for your reply. When performing k-point convergence tests with anisotropic meshes, I noticed that the inclusion or omission of the NOSYMADA keyword — which controls whether symmetry is applied — results in slight differences in total energy.

For the same system, I obtained two different convergence outcomes:

With NOSYMADA, the convergence was reached with a 1×5×5 grid;

Without NOSYMADA, the result suggested 1×7×7.

Since the use of symmetry affects the total energy, my questions are:

Which setup yields a more reliable and physically meaningful result for k-point convergence in this case?

Hello, I have a question regarding the use of the NOSYMADA keyword in CRYSTAL.

While reading the CRYSTAL manual, I came across the note that “User defined anisotropic net is not compatible with SABF (Symmetry Adapted Bloch Functions). See NOSYMADA, page 122.” (page 126).

However, I noticed that in the following example: https://wiki.aalto.fi/pages/viewpage.action?pageId=180298659, the author performed geometry optimization for Sr₅(BO₃)₃H using an anisotropic k-point grid, but did not include the NOSYMADA keyword.

I also did a test myself: I defined an anisotropic k-point mesh (1×5×5) and did not use NOSYMADA. In the .out file, I still see the line:
“NUMBER OF SYMMETRY OPERATORS : 2”,
which suggests that symmetry was not automatically disabled despite using an anisotropic grid.

So my question is:
When using a user-defined anisotropic k-point grid in CRYSTAL, is it necessary to explicitly include the NOSYMADA keyword?