Developer group

undefined

Hi heimurinn,

The error you're seeing is not actually related to the symmetry adaptation of the Bloch functions. What’s happening is that the error is triggered by another processor before the one responsible for writing the output reaches the actual failure point.

If you run the same calculation on one single process (serial mode), you should see the real error, which (for 81_from1.d12, I didn’t try 81_to1403845.d12, but I suspect it will be the same) is:
ERROR **** GROTA1 **** ERROR IN SYMMETRY EQUIVALENCE - CHECK INPUT COORDINATES

This issue is likely related to symmetry. One thing you can try is to follow the structure standardization procedure described in this thread.

If you have any questions or need further help, feel free to ask!

undefined

Hi Georg,

As far as I know, the D4 dispersion scheme is not yet implemented in the public version of CRYSTAL. It’s likely planned for a future release, but not currently available.

Where did you come across information that D4 has been implemented?

undefined

Dear Aparajita,

Gryffindor said in Problem with restarting CPKS calculation:

I’m reaching out again regarding the CPKS step. After several attempts (and a fair bit of persistence!), I was finally able to complete the SCF calculations.

Good!

Gryffindor said in Problem with restarting CPKS calculation:

As per your previous suggestions, I ensured the SCF was converged beforehand, but unfortunately, the CPKS has never been able to finish successfully on my side.

Is there a reason for switching DIIS off in your CPKS calculation?

Also, you can change the convergence criterion for the CPKS with the TOLALPHA keyword. In your case, it may be enough to run it with:

CPKS
TOLALPHA
2
END

Gryffindor said in Problem with restarting CPKS calculation:

Since I need these results quite urgently, I was wondering if you could try running it on your end to see if there's anything I'm missing?

I am afraid I can not. It is a huge calculation that you are running on 800+ atoms/cell and I do not have the computing power for this.

undefined

Dear Aparajita,

It is strange that the fort.9 unit is empty. May it be a problem of the script in copying back that unit from the scratch folder to the working directory?

Anyway, you can try to trick CRYSTAL in this way:

By inspection of your output file:

CYC  13 ETOT(AU) -1.952535840054E+05 DETOT -1.58E-05

the energy difference is down to 10^-5 at cycle 13. So, you can try to run the calculation with a low energy convergence threshold of just 10^-4 with something like this:

TOLDEE
4

and the SCF would be considered as converged for the program. In this way the calculation is not killed and probably you will get your fort.9 unit,;

you can then use it to do a restart calculation with the GUESSP keyword (and by tightening the energy convergence threshold to something like TOLDEE 7, or 8):

GUESSP
TOLDEE
7

Hope this helps,

undefined

job314 said in No space left on device:

those are huge HPC nodes… they can’t be possibly out of disk…

On our cluster, although the total disk space is huge, there are limited disk quotas for each user. Maybe it is the same there for you?

job314 said in No space left on device:

will it affect my convergence or calculation speed?

Possibly, but not much I think.

undefined

I can not tell the origin of the problem for sure but one thing you could try is to use the HISTDIIS keyword to set a lower maximum number of Fock matrices to be stored on disk for the DIIS convergence accelerator.

You could try with something like:

HISTDIIS
10

or less.

Indeed, this piece of your output suggests that all Fock matrices from all previous SCF iterations are stored:

job314 said in No space left on device:

DIIS ACTIVE - HISTORY: 23 CYCLES

When the system size is large and the SCF takes many iterations to converge, this may require lots of data to be stored on disk.

Let me know if this helps.

undefined

Hi,

From what I see you get very few negative values. Typically, it is an artifact of the interpolation method. Sampling the DOSS at more energy points and/or changing the number of Legendre polynomials used in the DOSS expansion solves the problem.

undefined

job314 Yes, this makes sense now that I think about it. Still, it would be advisable to restart the frequency job from the optimized geometry for one technical - and yet important - reason: the so-called FIXINDEX strategy used in CRYSTAL.

In the evaluation of the integrals, a list of interactions to be computed is defined at the beginning of the calculation and kept constant (the list, not the interactions) throughout the calculation to ensure numerical smoothness. This list is generated from the starting geometry in the input. It is better for it to be the optimized one. In many cases this may not be critical but it could lead to numerical issues if the inputed geometry is far from the equilibrium one.

undefined

PeterRemoto At the moment I am afraid I do not have an explanation for the difference you experienced between CRYSTAL17 and CRYSTAL23 as I am unable to reproduce the erratic behavior with CRYSTAL23.

undefined

PeterRemoto I have tried to restart your calculation with CRYSTAL23 following my step-by-step recipe (described at https://forum.crystalsolutions.eu/post/339) and it worked.

This is what I did:

I prepared an input file to run the harmonic frequency calculation, without intensities, I ran it and I killed it in the middle of the construction of the Hessian. From this incomplete frequency calculation, I obtained the FREQINFO.DAT file (I can not upload it here as it exceeds the maximum allowed file size), the external unit with the density matrix, i.e. fort.13 unit, and the external unit with the wavefunction, i.e. fort.9;
I prepared an input file to restart the frequency calculation and provided the FREQINFO.DAT, fort.13 and the fort.9 (renamed as fort.20) files from the previous step, and ran it. The calculation of the Hessian restarted correctly, with the new SCFs converging nicely (see the attached SCFOUT.LOG file). I then stopped the calculation not to use too much compute power on my cluster.

If you follow this step-by-step process you'll be able to safely restart your frequency calculations with CRYSTAL23.

Hope this helps,

Developer

Posts

Member List