As a general suggestion, I would recommend adding SMEAR, and possibly enabling DIIS, which can also be helpful. However, when using SPINLOCK, be careful, you should only turn DIIS on after SPINLOCK is disabled, so make sure to use THREDIIS instead.

You can also try increasing FMIXING to around 90 or 95, and using slightly higher TOLINTEG values.

Additionally, increasing SHRINK to 2 2 could be helpful. If the system goes through a metallic state, this adjustment can improve the Fermi surface (computational cost should not increase significantly).

The input file should be similar to this: INPUT.d12

As an additional note, targeting a high-spin state with all Fe atoms having +5 spin may not be physically reasonable for this type of MOF. Such a configuration could lead to severe instability in the electronic structure, which often manifests as SCF convergence issues. It might be worth checking whether a lower or mixed-spin configuration is more appropriate for the system.

Hi Wim,

Could you please provide the geometry of your system? An output file would also be very helpful.

In the meantime, please have a look at this thread.

Hi similt,

The convergence difficulties you're facing are likely related to the more complex electronic structure of metallic states. These issues arise when the system is metallic, but they can also appear in insulating systems if the SCF goes through some metallic states, and usually it can be stuck there (as seems to be happening in your case).

• The general suggestion is to use the SMEAR keyword , that can help a lot when dealing with metallic states.

• Also I would suggest to remove the BROYDEN convergence accelerator; and use the default option DIIS.

• For metaGGA functionals such as M06, it’s also a good idea to increase the integration grid size (by defayult it should be raised to XXXLGRID, but you can push it further using HUGEGRID)

Following these points, I tried running your calculation on our cluster, and it converged nicely in 12 cycles, giving a bandgap of 3.29 eV with PBE0.
Indeed, during cycle 1 and 2, the system shows metallic behaviour, but from cycle 3 onward it becomes insulating.

Here there is the input file I used: inputPBE0.d12

Let me know if you need further help.

Hi Ilias,

Even though it’s not documented in the manual, you can use the SMALLDIST keyword (in gemetry section of the input) to convert that error into a warning and allow the calculation to proceed. However, please note that atoms placed very close together can lead to numerical instabilities and linear dependencies in the basis set. Therefore, it’s important to carefully check your geometry and computational setup (i.e., basis set, TOLINTEG, etc.) before continuing.

Hi Chris,

The reason you only see a few k-points printed is indeed that the printing options are not fully supported in parallel execution. In a parallel run, each MPI process handles a subset of the k-points, and only process 0 writes to the output file. As a result, you’ll only see the k-points assigned to process 0, which can be just a few, or even none, depending on how they are distributed.

By default, the code distributes k-points in a round-robin fashion starting from the last process, so the gamma point is typically assigned to the last process and therefore never printed in a parallel execution.

This behavior applies to both options 66 and 67.

Try running the following input:

NEWK
4 4
1 2
66 999
67 999
END

However, you’ll need to run it on a single process for the eigenvectors to be printed correctly.

If the calculation is too expensive to run on a single process, we may need to find an alternative approach to extract those values (though that won’t be straightforward).

Hi,

We provide a distribution of precompiled object files that can be linked on this architecture. You should be able to build and run CRYSTAL23 successfully using those.

We do not have specific performance optimization data or configuration recommendations for the KNL platform. Performance is highly dependent on the system setup and workload characteristics, so we recommend running a few short benchmarks to identify the best configuration for your case.

As regards OpenMP, the optimal number of threads depends on your memory limitations; however, we recommend not exceeding 8 threads per MPI process.

Let me know if you have any further questions.

The AVX (or AVX2/AVX512) option can indeed cause compatibility issues with old processors. Since the object files you are using for compilation were built with AVX2 enabled, there is no way to remove that option and make those files work on processors without AVX support.

However, for this exact reason, we also provide object files compiled without AVX enabled. You should download the appropriate version of the distribution from the CRYSTAL Solutions website (should be named CRYSTAL23 - Precompiled object files for parallel version no avx2) and compile it using the same .inc file you provided.

Let me know if you manage to do it.

Hi,
The intel oneAPI toolkit should in principle be compatible with any Xeon processor, have you compiled the code from the object files or have you used directly the executables distributed?

In the first case, could you provide the .inc file that you used for the compilation?

Dear CRYSTAL community,

From Monday 15 to Thursday 18 December 2025, the 39th Winter School in Theoretical Chemistry will take place in Helsinki, Finland.
This year’s focus is on Electronic Structure Theory! The School is organised by the Department of Chemistry, University of Helsinki, and is open to everyone in academia: students, postdocs, and professors. Best of all, it’s free of charge!

Location:
Helsinki - Finland
City Center Campus of the University of Helsinki

Lecturers:
Jacques Desmarais [Jacques] (University of Turin)
Janus Juul Eriksen (Technical University of Denmark)
Arno Förster (VU Amsterdam)
Christof Holzer (Karlsruhe Institute of Technology)
Ida-Marie Høyvik (Norwegian University of Science and Technology)
Stanislav Komorovsky (Slovak Academy of Sciences)
Frank Neese (Max Planck Institut für Kohlenforschung)

More info & Registration:
For full details, registration form, and updates, please check the official Winter School page.

Don’t miss this opportunity to meet leading experts, learn the latest in electronic structure theory, and connect with fellow scientists from around the world!

Hi Chris,

The error comes from the missing END line that should close the NEWK block.

As for print option 67: it should work in properties as well as in crystal. That said, these print flags are not very well tested, and some of them may have broken in newer versions. I took a look in the code, and I can confirm that the -505 trick will not work here. Instead, you should set the value to 999 to get the maximum possible output (ie all the virtual states, or 499 for just the occupied states).

One more note: in the NEWK section this option was never extended to parallel execution, so you’ll need to run it on a single CPU core if you want it to print.

Hope this helps.

Hi Chris,

If you want to switch on printing options 66 and 67, your input should be:

NEWK
6 6
1 2
66 xxx
67 yyy

where xxx and yyy are the numbers "N" specified in the manual (see page 443, column input)

Let me know if you manage to get the correct printings

The block

TWOCOMPON
SOC
END

can be inserted anywhere in the third section of the INPUT file. It is common practice for us to place it at the top of this section, but this is not strictly required.

Hi Chris,

Not quite, the pob-DZVP and pob-TZVP basis sets are all-electron valence basis sets, thus they are not paired with relativistic pseudopotentials. This means they cannot be used directly for spin–orbit coupling calculations in CRYSTAL.

For Nickel and Cobalt I suggest you to use the COLUSC ECP paired with the basis set that you can find here for Ni (the one under "Nickel Relativistic Effective Potential and Basis set including the 3s and 3p subshells...") and here for Co (the one under "Cobalt Relativistic Effective Potential and Basis set including the 3s and 3p subshells...").

You just need to convert the valence basis set in the CRYSTAL format.

Hi Rams,

The need for relatively high values of FMIXING is not unusual, so what you are observing is expected. That said, you are correct that if FMIXING is set extremely high (close to 100%), there is a risk that the SCF procedure may reach converge before reaching the "true" ground state. This is not unique to your system, it is a general trade-off with strong damping.

To improve robustness while still guiding the calculation toward the correct solution, you can try:

• Increasing TOLDEE: this tightens the SCF energy convergence criterion and will allow the SCF to continue reaching the minimum even with high FMIXING. Keep in mind, however, that this will typically require many more SCF cycles.
• Combining mixing with other stabilization strategies, such as level shifting (LEVSHIFT) or electronic smearing (SMEAR) (if applicable to your system), which often reduce the need for such extreme damping.

Hi Chris,

For SOC calculations in CRYSTAL, you cannot use all-electron basis sets directly (such as your cc-pVDZ-DK). SOC in CRYSTAL is implemented through the use of relativistic effective core potentials (ECPs), which already incorporate scalar-relativistic and spin-orbit effects for the core electrons. Thus, at least one pseudopotential is required in your system (usually on transition metals and heavier elements).

The INPSOC keyword can be used to manually insert an ECP, but the associated basis set must be designed to describe only the valence electrons that remain after introducing the pseudopotential.

I recommend checking the CRYSTAL basis set library, where you’ll find pseudopotentials and corresponding valence basis sets that are already formatted for SOC calculations in CRYSTAL. These can be used directly without modification and will ensure consistency between the basis and the relativistic treatment. However, we don't have a SOC basis set for evry element.

In the case you are interested in a specific element for wich we don't have the SOC basis, you can try using one of the internal ECP options (see page 88-92 of the manual) and combine it with a molecular basi set.
For example, you can find the basis set for the Stuttgart ECPs (STUTSC and STUTLC keyword in CRYSTAL) here. Or here for the COLUSC and COLULC ECPs.

Hi Chris,

You’re right that the code uses the symmetry of the crystal to reduce the number of k-points it actually computes. That’s why you don’t see all 216 k-points from the 6×6×6 Monkhorst-Pack grid: only the irreducible k-points are listed, since the energies at the symmetry-equivalent points can be obtained by applying the crystal’s symmetry operations.

That said, one important distinction: the program does not literally “reuse” the eigenvalues from one representative k-point for its equivalents, it only knows that due to symmetry, those results will be the same, so it avoids recalculating them.

For band structure plots along a high-symmetry path (e.g. Gamma-X-K-Gamma), the reduced k-point mesh from the SCF run is not sufficient. Instead, you should perform a separate band structure calculation (BAND keyword in PROPERTIES, page 309 of the user manual). In this type of calculation, you explicitly define the path through reciprocal space, and PROPERTIES computes eigenvalues along that path directly, without relying on the Monkhorst-Pack grid.

Let me know if you have any truble running the properties calculation.

Hi Rams,

I’ll look into this issue further, but in the meantime, could you please try running the MPP version with the same input, just without the DIIS keyword, and let me know if that converge?

Hi esmuigors,

When you run a geometry optimization (within the OPTGEOM block), CRYSTAL will always produce a fort.34 file (that contains the optimized structure and can be used in a subsequent calculation with the EXTERNAL keyword).
If you don’t see it after the run, a common cause is that it wasn’t copied back by the script used to manage scratch directories for the execution as the runCRY script provided with the code.

As for the error that you get, the issue is that EXTPRT should be placed outside the OPTGEOM block, as in this input.d12 example.

If you prefer, you can also extract the optimized geometry manually from the .out file. However, note that you must take both the final cell parameters (and angles, if present) and the final fractional atomic coordinates from the “FINAL OPTIMIZED GEOMETRY” section (those in the primitive cell), using only updated cell parameters without matching coordinates will lead to inconsistencies and errors like the ones you saw.

Let me know if you manage to get the optimized structure.

Hi jquertin,
As Aleks correctly pointed out, it’s better not to use DIIS (which is active by default) when using SPINLOCK.
A good way to combine the two is like this:

SPINLOCK  
1  
-2  
THREDIIS  
0.005

This way, DIIS is only activated when SPINLOCK is turned off.

However, I tried running your input, and it’s likely that this is actually a bug. Unfortunately, I don’t have a better solution at the moment other than changing the functional.

Hi Emmanuel,

For an updated guide on the installation of CRYSTAL23, please follow the instructions provided here.
Specifically, to install the executable, refer to Section 1. If you need to recompile the code from object files, see Section 3.

To test the parallel executable, you can refer either to Section 2, or to this tutorial.

Let me know if you need further help.