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

Hi,

jquertin said in SCF fails spinlock with POB-DZVP-REV2:

In the case of SPINLOCK, the manual clearly explain that the NSPIN value is the difference in number of alpha and beta electrons. For SPINLOC2, the text only refers to the spin while the table gives the same definition for SPIN as for NSPIN (in SPINLOCK).

The argument SPIN of SPINLOC2 still represents a number of electrons, as in SPINLOCK.

jquertin said in SCF fails spinlock with POB-DZVP-REV2:

Furthermore, in the calculation, if using SPINLOC2 with 6 or 6.0 as the spin (as defined in the table), crystal defaults to SPINLOCK.

That's right. SPINLOC2 requires a non integer argument. For integer arguments it reduces to SPINLOCK.

jquertin said in SCF fails spinlock with POB-DZVP-REV2:

In short, if I define SPINLOC2 SPIN as 3 (1/2 * 6) or 3.0, crystal defaults to SPINLOCK with NSPIN 3 which is actually half of what I want.

In both SPINLOCK and SPINLOC2, the argument is meant as a number of electrons. Thus, if you have 6 extra up electrons with respect to down electrons, the input value should be 6, not 3. For integer values, SPINLOC2 is of no use.

Hope this clarifies things a little,

Thank you, Dr. Alessandro Erba, for the helpful suggestion regarding the use of the COORDINA option. Your example for defining the XY plane was clear and easy to follow — I’ll definitely apply this approach in my setup.

Thanks again for your guidance!
Cheers

Everything works with mpiifx, thank you very much!

Hi Giacomo,

Many thanks for your answer and suggestions.
It works and will do a double check for the geometry.

Have a good day,
Ilias

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).

Dear prof. Erba,

Have You got any time to look into the source maybe? 🙂
Quite interestingly, I have recently noticed that in some other QC code values for the components change a lot (by up to 60%) from run to run, except for the dipole orientation (when the molecular dipole is aligned with z axis). Is (or could be) the reorientation You are referring to connected with this? Seems like something similar to the struggle fir gauge invariance in NMR calculations...

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.

Thank you!

Hi Alessandro,

Thank you for your reply. I will use an isotropic shrink. I find it strange, though, to have the warning message as the structure was optimised. Anyway, I will rerun that.

Kind regards,
Pierre

Either way, seems you got your geometry for further optimization 🙂
Cheers,
A

Hi,

There may not be an option to "plot" orbital-resolved bands directly, but there is an option to compute and print principal atomic orbitals contributions to selected eigenvectors. See the ANBD keyword of the PROPERTIES module (page 307 of the CRYSTAL23 User's Manual).

Yes, if your system is 2D, you can use the usual BAND keyword of the PROPERTIES module to define a 2D path to compute and plot the band structure (page 309 of the CRYSTAL23 User's Manual).

If you need help on a specific system, just let me know

Thanks Giacomo, much appreciated,

Chris

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.