undefined
Hi Chris,
I tested the same input with properties and it starts correctly, so the input deck itself seems fine. The issue may instead be that the launch script that is not pointing to the correct input file.
Without your fort.9 I cannot test the full input, but if you share a few details on your setup and how you launch the job, it may be easier to identify the problem.
Dear Chhatra,
Unfortunately, I am not aware of a direct way to reduce the file size generated by the ORBITAL option in the properties module.
As a possible workaround, you might consider reducing the system size if feasible. Another option could be to post-process the output to extract only the relevant information before visualization.
I hope this helps.
Hi Chhatra,
the last 1 in the second line of the NEWK input
NEWK
3 3
1 1 <--- this one
67 501
...
is the number of printing options to switch on (as stated in the manual).
Thus, the following line contains the number of the print option (67: eigenvectors of the Fock - see the LPRINT appendix in the manual) and the value of that print option (501: number of vectors to print)
Hi denkos,
From what I can see in the code, the components are not sorted automatically. CRYSTAL just diagonalizes the EFG tensor and prints the three eigenvalues as AA, BB, CC with their corresponding eigenvectors.
Hi Aleksand,
We investigated the error you encountered. It was caused by a bug in the EOS option, which has been fixed in CRYSTAL23. Unfortunatly, there is no simple workaround available in CRYSTAL17.
What I can think about is to manually perform the volume-constrained geometry optimizations in separate runs and then interpolate the results manually.
Hi Aleksand,
Can you post the full output file? I just want to check in which step the error is generated.
The Department of Chemistry and the Thomas Young Centre at Imperial College London 
and the Theoretical Chemistry Group of the University of Torino 
, in collaboration with the Computational Materials Science Group of the Science and Technology Facilities Council (STFC), are organising the
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
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.
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.
You can register here!
Friday 8 May - Deadline for payment of early bird fees.
See the School website for further details.
Hi Drmajouri2025,
When performing frequency calculations, it is essential that the geometry is fully optimized with the SCF properly converged. If the structure is not at a true stationary point of the potential energy surface, the computed second derivatives (Hessian) can lead to unreliable frequencies and response properties.
Regarding the *******************, these typically means that the value exceeds the field width allocated in the printing format. In other words, the number is too large (or not representable) within the fixed output format, so it is replaced by stars.
However, in your case, since the geometry did not converge properly, the appearance of stars is very likely due to numerical problem rather than just a harmless formatting issue.
I would strongly recommend:
TOLDEE and/or TOLINTEG parameters).Hi,
I suggest you to use CRYSTALClear instead. Here you can find an installation guide, and on the GitHub page there is the documentation and some example notebooks that you can use as template.
For any question related to CRYSTALClear there is a dedicated section here on the forum.
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:
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.