Hi,

Thank you for reporting this.

While we run some tests on our cluster, may I suggest switching from a coupled-perturbed Kohn-Sham (CPKS) approach to a Berry phase (BP) approach for the IR intensities? The latter is way less computationally demanding than the former and in this case could be beneficial to the success of the calculation.

You are currently using CPKS as per your input file:

FREQCALC NOECKART INTENS INTCPHF FMIXING 60 ANDERSON MAXCYCLE 300 ENDCPHF ENDFREQ

To switch to BP, you can use instead:

FREQCALC NOECKART INTENS ENDFREQ

Let me know how this goes,

Hello!
I am struggling to understand the way in which CRYSTAL rotates the atoms. Here is my structure:
reference.f34
I want to rotate all atoms so that Mn remains in place, and oxygens NN 21&23 move to the ac (xz) plane. This, in essence, is a rotation around the axis 10Mn-12P, the result of which should be that
Y coordinate of Mn = Y(O21) = Y(O23). The angle that should work is +-24.7159 degrees, depending on the direction that CRYSTAL uses.
So, I tried

ATOMROT 0 # include all atoms 999 1 # no translation & rotation around a specified axis 10 12 # atom labels that define rotation axis +/-24.7159 # angle (degrees)

To the effect of

ALL THE 36 ATOMS IN THE REFERENCE CELL ARE MANIPULATED SELECTED ATOMS ARE ROTATED AROUND THE AXIS DEFINED BY TWO ATOMS: 10 12 (DIRECTION COSINES 0.000 0.000 -1.000) BY AN ANGLE: 24.72 ATOM 10 AT.N. 25 COORDINATES 4.46889 0.00000 2.24246 ATOM 21 AT.N. 8 COORDINATES -2.74300 2.67751 3.17915 ATOM 23 AT.N. 8 COORDINATES 3.56177 1.05955 3.17915

and

ALL THE 36 ATOMS IN THE REFERENCE CELL ARE MANIPULATED SELECTED ATOMS ARE ROTATED AROUND THE AXIS DEFINED BY TWO ATOMS: 10 12 (DIRECTION COSINES 0.000 0.000 -1.000) BY AN ANGLE: -24.72 ATOM 10 AT.N. 25 COORDINATES 4.46889 0.00000 2.24246 ATOM 21 AT.N. 8 COORDINATES -2.25530 -3.73706 3.17915 ATOM 23 AT.N. 8 COORDINATES 3.07407 0.00001 3.17915

So the second method maybe worked? Except that I have been unable to visualize/confirm it using VESTA, because the output of edited geometry section looks the same as the input*.

So, my questions are:

how to validate the result of rotation? when using ROTCRY+MATROT, where is the origin of rotation? which method of rotation I should use in this situation?

*VESTA, of course, does not open .f34 files, so my usual workflow is to convert CRYSTAL output to a VASP-POSCAR format:

Structure description line 1.0 #scaling factor [DIRECT LATTICE VECTORS CARTESIAN COMPONENTS (ANGSTROM)] List-of-elements Amounts-of-each-element Direct or Cartesian # coordinate format [list of coordinates in the selected format]

Hi GiacomoAmbrogio ,

I have attached the properties output file below so you can take a look. If there is anything else you want to check let me know.

hBN.outp

The main issue that I have is that, for instance, the set of eigenvalues at K= 91 ( 10 10 0) (which starts at line 2396 of the file) has labels that corresponds to the irrep of each band at that k point. You will find that in that same file, there is a list of character tables. However, the labels of the irreps that appear in the last character table is not the same as the labels that appear in the last set of eigenvalues. In general it seems that the n-th character table that appears does not contain the same irreps as the n-th set of eigenvalues. In other words, I do not know to what k-point each character table is referring to in order to properly identify the irreps.

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.

dmitoli Thank you, it was a formatting problem with my notebook, now the issue has been solved.

Best regards
Wang

Let me just add that we do have a development version of the code for HSE+SOC, which we plan to include in the next release.

Hello!
I found the source file. I have also learned that the .f9 was calculated with Crystal17, and that malloc happened in Props17, not in Props23 (I am likewise not sure whether the calculation that failed for my colleague was done using v17 or v23). This might have been a limitation of the machine that I was using, because the same calculation didn't crash with NEWK 36 72.
malloc.d12

I am sorry if that turns out irrelevant, and of no use in the current version of Crystal.

Hi,

Let me just add that of course in P1 there are no special high-symmetry points to guide you in the definition of the path, so you need to be a little creative. For instance, you can start from Gamma (0 0 0) and go to the edge of the FBZ along the b1 reciprocal lattice (1/2 0 0), to then go to (1/2 1/2 0), then to (0 1/2 0) then back to Gamma (0 0 0) and then to the edge along the b3 reciprocal lattice (0 0 1/2). Or something else! 🙂

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)

If you fear that a reduced symmetry might influence the thermodynamic results, you can simply run the calculation without imposing any symmetry at all. For a 3-atom system like CO₂ the computational cost is so minimal that you can run both symmetry-free and \(D_{4h}\) calculations. Comparing the two results should give you an indication of whether the imposed symmetry has any impact on the quantities you are interested in.

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.

Dear Jonas,

I tried using pymatgen to extract the point-symmetry information from your .xyz file (see the Python script below):

from pymatgen.core import Molecule from pymatgen.symmetry import analyzer bigstructure = Molecule.from_file("yourfile.xyz") PGstructure = analyzer.PointGroupAnalyzer(bigstructure) sym_mol = PGstructure.get_equivalent_atoms() print(sym_mol["eq_sets"])

This returns a Python data structure containing the symmetry-irreducible sets of atoms (only 6 for this system, which is indeed of Ih point group!).
When preparing the CRYSTAL input, be careful with the orientation of your asymmetric unit. In my case, for example, I had to change the sign of the x and y coordinates to make the symmetry consistent with CRYSTAL’s conventions.
Icosahedral point groups are available in CRYSTAL (Ih is point group number 47 in CRYSTAL), so the input fort this molecular cage reads:

Symm. structure MOLECULE 47 6 8 2.605032231 -11.914271806 11.762689798 6 4.344538598 15.664236912 4.366798884 6 3.427479683 14.428996321 8.326818862 6 -8.906580884 1.370529673 14.411150640 1 2.632960331 14.962480562 7.832453804 5 -8.776255231 -2.916256114 14.200279302 COORPRT TESTGEOM END

aerba Christmas is already in the air indeed!

Alright, it sounds like the difficulties originate from the system itself, rather than the particular CRYSTAL input.

Thanks again for all the help!

Best regards,
Wim

aerba, Thank you very much for your reply!

Unfortunately, I don't speak English very well, which is why I may have phrased my question incorrectly.

My question was that the function OPTGEOM does not work correctly with RUNCONFS. I had already tried the steps you suggested.

However, I was able to figure out the problem. For geometric optimization, I just needed to specify the keyword more correctly:

CRYSTAL 0 0 0 194 3.065 17.656 4 22 0 0 0.5 14 0 0 0.75 22 0.666666 0.333333 0.364919 6 0.333333 0.666666 0.427507 SCELCONF 1 0 0 0 1 0 0 0 1 RUNCONFS ATOMSUBS 22 273 OPTGEOM MAXCYCLE 500 ENDOPT END END

I'll leave it here, maybe it will be useful to someone in the future.

Nevertheless, thank you very much for your responsiveness

Hi,

job314 said in SCANMODE io error Read_int_1d:

So it turns out having fort.13 and fort.20 is not optional for restart.

Yes, the lack of these two files was the origin of the I/O error.

job314 said in SCANMODE io error Read_int_1d:

PS. I would also like to ask developers to allow uploading compressed files to this forum

Now also .zip, .tar, .tgz, .tar.gz files can be uploaded.

Cheers,

Good morning, OH that’s cool ☺️, here we go and that is exactly what I want…

Thank you again Dr. Casassa

Thanks. SMEAR helped me to converge scf.

Dear George,
According to your output, you are using CRYSTAL17 to perform the HFsol-3c calculation.
Please note that HFsol-3c and the other "sol-3c" composite methods are only available in CRYSTAL23.

Best regards,
Bartolomeo

Hi Prof. Erba,

Thanks for the reply. From the file, I could see there are value from energy " -7.9324E-01" (Line No: 81826). I could plot the data using Python, Xmgrace. With CRYSPLOT somehow the data loading is slow and my browser hangs so I am not able to check it. But definitely there is data.

I requested for COHP between Ni and three nearby oxygen. In the file there are 5 columns, so if I am not mistaken it corresponds to "Energy - Next three columns in the order I request - Final Column of DOS ?" (Because the last column data when plotted matches the DOS)

Thanks & Regards,
Rams