Bug Reports

JohnKendrick
I have had the same problem in a slightly different task. I have found a solution, but it may not work for your particular task: I have reduced the number of k-points.
I am modelling Mn5+ ion in a AlPO4 cell in which one P is replaced by Mn.
My input is

EXTERNAL FREQCALC ANALYSIS INTENS INTRAMAN INTCPHF END END BASISSET POB-TZVP-REV2 DFT WC1LYP SPIN END EXCHSIZE 44000000 BIPOSIZE 44000000 SHRINK 6 6 TOLINTEG 9 9 9 12 20 MAXCYCLE 400 TOLDEE 10 SPINLOCK 2 -6 ATOMSPIN 1 10 1 SLOSHING END

The same input with

SHRINK 8 8

Produced the same error as yours, regardless of convergence tools (DIIS / NODIIS (in CPHF block) / buffer sizes / etc):

ELECTRIC FIELD APPLIED ALONG CARTESIAN DIRECTIONS XX [some lines omitted] BECKE WEIGHT FUNCTION RADSAFE = 2.00 TOLERANCES - DENSITY:10**- 6; POTENTIAL:10**- 9; GRID WGT:10**-14 RADIAL INTEGRATION - INTERVALS (POINTS,UPPER LIMIT): 1( 75, 4.0*R) ANGULAR INTEGRATION - INTERVALS (ACCURACY LEVEL [N. POINTS] UPPER LIMIT): 1( 4[ 86] 0.2) 2( 8[ 194] 0.5) 3( 12[ 350] 0.9) 4( 16[ 974] 3.5) 5( 12[ 350]9999.0) TTTTTTTTTTTTTTTTTTTTTTTTTTTTTT MOQGAD TELAPSE 7695.33 TCPU 7664.63 forrtl: severe (67): input statement requires too much data, unit 81, file /scratch/tmp_p267436_student/fort.81.pe11

All running on a single machine: Dell EMC C6400 Server (2x20-Core Intel XEON Gold 6148 2.40GHz, 192GB RAM, 3x480GB SSD).

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 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,

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,

very grateful, I will run it again but not sure what to do here if it aborts again

thank you