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.

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.

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

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.

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.

Hi Giacomo,

That's a very useful answer, thank you!

Chris

Dear esmuigors
esmuigors said in Unexpectedly cannot get the geometry after optimization: KEYWORD EXTPRT NOT ALLOWED:

Should I only take the atoms labelled by "T" if the lattice is tetragonal, and which ones are to be taken in case of an orthorombic one? Or does "T"'and "F" stand just for "TRUE"'and "FALSE"?

You are correct T and F stand for 'TRUE' and 'FALSE'.

esmuigors said in Unexpectedly cannot get the geometry after optimization: KEYWORD EXTPRT NOT ALLOWED:

I am actually talking about the standard runPcry23 script. Perhaps it should not be like that? Or should I modify this script?

That script already contain the few line of codes I suggested you, if not feel free to modify it and add those lines.

esmuigors said in Unexpectedly cannot get the geometry after optimization: KEYWORD EXTPRT NOT ALLOWED:

Actually, I have now tried using only the "T"-labeled atoms and got this error:

ERROR **** geometry **** FORMAT ERROR IN INPUT DECK

I checked the input on top of the CS2_B1WC.pob_tzvp_rev2_gamma_onlyT.out file it seems like you are defining six atoms in the asymmetric unit, but only two atomic positions are specified in the input.

CRYSTAL 0 0 0 64 6.34350113 5.54788046 9.71085545 6. ! Definitions of the number of atoms in the asymmetric unit 6 0.000000000000e+00 0.000000000000e+00 -5.000000000000e-01 16 2.303037287581e-17 3.119080311720e-01 1.207617820468e-01 ATOMSYMM ...

The number of atoms in the asymmetric unit and the position specified should always match.

I hope this helps you,

Best,

Hi,
Yes, of course. Sorry for not including them earlier.
Best,
Jean
metcofs-2d-pc-co-prist-ils35-opt-pob_dzvp_rev2.d12
metcofs-2d-pc-co-prist-ils35-opt-pob_dzvp_rev2.out

eascrizzi Thank you for your help.

Sure. I will try it. Thankyou so much.

Thanks for your response, aerba.
ATOMREMO works but when you calculate the defect formation energies you end with values (for anion vacancies) that are higher than with using GHOSTS or the ATOMSUBS, with the latter values agreeing more with published defect formation energies.

aerba I've noticed for my systems, these SCF convergence issues appear when I try to compute for intensities in a restart job. Then when removing intensities, they converge fine and progress forward.

Is it possible to finish the frequency calculations first and then compute for the Raman intensities afterwards? Would that be a work around? Maybe with RAMANREA - because I have the TENS_RAMAN.DAT, but it just gets stuck at some point during HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
FORCE CONSTANT MATRIX - NUMERICAL ESTIMATE
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
and doesn't progress with restarts