Dear CRYSTAL community,

The CRYSTAL Team is heading to Brazil!
Next week (26th Jan – 29th Jan 2026), we will be in Volta Redonda (Rio de Janeiro state) for the

QMMC 2026 will be hosted at the Universidade Federal Fluminense and it will be an exciting journey through quantum modelling of materials, covering a wide range of topics in computational chemistry and condensed matter physics.

We are truly excited to be in Volta Redonda and to share knowledge, experience, and, of course, to spread the CRYSTAL verb!

More information about the school can be found on the event website.

See you in Brazil!

Hi DLP,

NEWK
0 n

is used to specify an anisotropic shrinking factor. However in you input you are not providing the three parameters required for this, which makes the usage unclear.

Could you please attach the output file you are referring to, so that I can take a closer look?

Hi Jack,
compiling from objects on Apple Silicon is possible, but there are two critical requirements:

• You must use OpenMPI built with the same GNU Fortran version used to compile the object files (in particular gfortran 12.1)

• You must use the MPI compiler wrappers (mpif90, mpicc, mpicxx) instead of the plain compilers for the final linking stage

The default include file is almost correct. The only necessary changes are the compiler definitions. Replace the first lines with:

F90     = mpif90
LD      = $(F90)
PLD     = mpif90

Keep the rest unchanged.

Important notes

The OpenMPI you use must be built against gfortran 12.1. You can check with:

mpif90 --show

or

mpif90 --version

and verify that it points to gfortran-12.

Do not mix different GNU Fortran versions (e.g. gfortran 13 or Apple clang).
A mismatch here is the most common cause of runtime failures.

Hi Jack,

the parallel version of CRYSTAL23 shipped for Apple Silicon is built with OpenMPI 4.1.1, therefore it is essential that the code is executed using the same mpirun version (or at least the same major version, ie 4.x.x).

If a different OpenMPI installation is used (for example the Homebrew 5.x one), the program may start but fail internally, leading to errors such as the abnormal SCF termination you originally observed.

Concerning the message ls: No match. this is just a standard shell warning printed when the ls command does not find the files it is looking for.
It is probably produced by the run script when it tries to list some output or scratch files that may not exist (for example if the job stops before all files are written).

It is not an error of CRYSTAL itself.

You may try searching inside the run script to locate the line containing the ls command. From the path and filename it is trying to list, you can understand whether the file is genuinely not produced or if the script is looking in the wrong path.

Hope this helps.

Hi masoud37,
Unfortunately, range separated hybrids (as HSE06) are not supported in two-components calculations (ie SOC), as stated at page 166 of the User manual.

Please consider using a global hybrid instead, as PBE0 or any other "custom" percentage of exact exchange in any GGA functional using the keyword HYBRID (refer to page 135 of the manual).

Hope this helps.

Hi andrejsc,
There is no "hardcoded" switch in the TOLINTEG keyword, I suspect that the quote from the manual comes from the "old days", when a threshold of \( 10^{-20} \) was considered absurdly small. However, with advances in hardware and the increasingly complex structures we want to compute, such thresholds are sometimes necessary.

A small note: don't warry about going past machine precision with these small numbers. All evaluations of integral thresholds in the code are performed at the logaritmic level (ie only on the exponent), so you should be fine even with a value of 1 million in TOLINTEG (though maybe not fine in terms of computation time)

Hi Orion,
Looking at your input, I think you want to plot the orbital projected electronic DOS (in CRYSTAL this is done with the DOSS keyword, PDOS in CRYSTAL normally refers to phonon DOS).

To obtain separate px py pz projections, the correct approach is:
set the first parameter of DOSS to 2 (because you want two separate projections).
After the main DOSS line, you must then add one line per projection, specifying which atomic orbitals (AOs) belong to each projection.
Each line has the form:

n AOs    index_1    index_2    ...    index_n

The AO indices correspond to the ones printed in the CRYSTAL output. To find them, search in the SCF output for "LOCAL ATOMIC FUNCTIONS BASIS SET", you will see a table with all the basis set, that will look like this:

*******************************************************************************
   ATOM   X(AU)   Y(AU)   Z(AU)  N. TYPE  EXPONENT  S COEF   P COEF   D/F/G COEF
*******************************************************************************
  1 O   -2.793  -4.838  -4.110
                                 1 S
                                        8.589E+03 1.895E-03 0.000E+00 0.000E+00
                                        1.297E+03 1.439E-02 0.000E+00 0.000E+00
                                        2.993E+02 7.073E-02 0.000E+00 0.000E+00
                                        8.738E+01 2.400E-01 0.000E+00 0.000E+00
                                        2.568E+01 5.948E-01 0.000E+00 0.000E+00
                                        3.740E+00 2.808E-01 0.000E+00 0.000E+00
                          2-     5 SP
                                        4.212E+01 1.139E-01 3.651E-02 0.000E+00
                                        9.628E+00 9.208E-01 2.372E-01 0.000E+00
                                        2.853E+00-3.274E-03 8.197E-01 0.000E+00
                          6-     9 SP
                                       9.057E-01 1.000E+00 1.000E+00 0.000E+00
                         10-    13 SP
                                        2.556E-01 1.000E+00 1.000E+00 0.000E+00
                         14-    18 D
                                        1.292E+00 0.000E+00 0.000E+00 1.000E+00

The indeces are the numbers befor each orbital shell (1 2-5 6-9 10-13 14-18).
The notation 2-5 means indices 2 through 5, because that shell contains 4 AOs.
From these blocks you must identify the p-type orbitals for each atom (Zn and Cl). The p shells will appear in groups of three basis functions (px, py, pz).

So, in your system:

• Locate the Zn atom in this printed basis list
• Identify the block corresponding to its p orbitals
• Extract the AO indices for px, py, pz
• Do the same for Cl

Then you define one projection per line. For example, structurally something like:

NEWK
12 12
1 0
DOSS
2 100 3 6 1 12 0
3 <list of Zn p AOs>
3 <list of Cl p AOs>
END

Keep in mind that, if your basis is double- or triple-Z, each p shell appears as a separate triplet of AOs (one triplet per Z). To correctly project all p you must include the corresponding AOs from every p-shell triplet for that atom.

Let me know if you manage to do this, or if you need further help.

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.