Dear all, I optimized a crystal, got good gradients, but numerical displacements are already suspect as they generate lots of negative energies, it's a big system, I am still running it but decided to preemptively ask why this can be the case?

SYMMETRY ALLOWED FORCES (COORDINATE, FORCE)

1 -7.1019812E-07    2  2.6847537E-07    3  1.7714543E-06    4  1.5380909E-06
5 -8.5713887E-07    6 -7.6313741E-07    7 -1.3777999E-06    8 -4.2292032E-07
9  3.7330006E-07   10 -1.0186152E-07   11  7.8436370E-08   12 -1.0666144E-07

13 7.6024231E-07 14 1.2549944E-07 15 -3.8114243E-07 16 8.3483245E-07
17 1.2719080E-06 18 1.3589256E-07 19 -1.2770755E-06 20 -1.7657611E-06
21 -6.7831105E-07 22 -2.8553633E-06 23 -2.5801301E-06 24 1.6190965E-06
25 2.7986374E-07 26 1.6445538E-06 27 1.5791380E-06 28 3.4913230E-06
29 7.5492284E-07 30 -3.2944974E-06 31 -2.9919538E-06 32 1.2296182E-06
33 4.5466078E-07 34 -1.8564773E-07 35 9.3158783E-07 36 -1.4184621E-07
37 2.8763484E-06 38 -1.7874331E-06 39 -3.3548919E-07 40 -1.0246636E-06
41 7.3025290E-07 42 -7.4914105E-07 43 -1.5527795E-07 44 -5.9189571E-07
45 1.1402401E-07 46 1.1445077E-07 47 5.0641463E-07 48 2.6720325E-07
49 3.9382990E-07 50 1.9265418E-07 51 -5.0025563E-07 52 -1.4722329E-07
53 -3.9032570E-07 54 -1.8660950E-07 55 -3.7294087E-08 56 2.7903845E-07
57 -1.1262719E-07 58 -1.4056720E-06 59 -7.2814440E-07 60 -4.2360016E-07
61 9.6760468E-07 62 -1.1476558E-06 63 5.7400637E-08 64 8.2334616E-07
65 1.7677814E-06 66 1.1935613E-06 67 -5.3996977E-07 68 5.3577787E-07
69 -5.5566146E-07 70 2.5231789E-07 71 -6.3487986E-07 72 7.2284427E-07
73 -8.4328694E-08 74 -5.8224781E-07 75 -1.6946265E-07 76 1.0209263E-06
77 2.9716506E-07 78 2.3838462E-07 79 1.7955521E-06 80 4.0804899E-07
81 1.2100282E-07 82 -1.5099145E-06 83 2.9006726E-07 84 -2.2790446E-07
85 1.4325087E-06 86 -6.8494225E-07 87 -3.3477344E-07 88 -2.2149944E-07
89 1.3328321E-07 90 -1.8330282E-08

ATOM MAX ABS(DGRAD) TOTAL ENERGY (AU) N.CYC DE SYM
CENTRAL POINT -5.463640944184E+03 0 0.0000E+00 8
1 O DX 6.5777E-04 -5.463640944692E+03 11 -5.0781E-07 1
1 O DY 8.9722E-04 -5.463640943824E+03 12 3.6002E-07 1
1 O DZ 2.7715E-03 -5.463640938222E+03 13 5.9626E-06 1
9 O DX 1.4159E-03 -5.463640942796E+03 11 1.3886E-06 1
9 O DY 2.4328E-03 -5.463640939470E+03 13 4.7142E-06 1
9 O DZ 7.5341E-04 -5.463640944273E+03 10 -8.8837E-08 1
17 N DX 3.3298E-03 -5.463640936786E+03 9 7.3979E-06 1
17 N DY 2.6834E-03 -5.463640938932E+03 10 5.2525E-06 1
17 N DZ 2.2061E-03 -5.463640940002E+03 10 4.1826E-06 1
25 H DX 5.8163E-04 -5.463640944625E+03 10 -4.4035E-07 1
25 H DY 9.7068E-04 -5.463640943311E+03 9 8.7315E-07 1
25 H DZ 1.3265E-03 -5.463640942408E+03 11 1.7757E-06 1
33 H DX 1.9126E-03 -5.463640940840E+03 12 3.3445E-06 1
33 H DY 9.0051E-04 -5.463640944155E+03 9 2.8878E-08 1
33 H DZ 6.4300E-04 -5.463640945217E+03 9 -1.0328E-06 1
41 N DX 3.4011E-03 -5.463640936782E+03 10 7.4018E-06 1
41 N DY 2.7133E-03 -5.463640938661E+03 12 5.5236E-06 1
41 N DZ 2.8802E-03 -5.463640937601E+03 11 6.5830E-06 1
49 H DX 1.5489E-03 -5.463640941848E+03 10 2.3365E-06 1
49 H DY 3.3487E-04 -5.463640945255E+03 9 -1.0709E-06 1
49 H DZ 8.9868E-04 -5.463640943999E+03 9 1.8543E-07 1
57 N DX 2.4112E-03 -5.463640939472E+03 9 4.7126E-06 1
57 N DY 3.5207E-03 -5.463640936173E+03 10 8.0110E-06 1
57 N DZ 3.2454E-03 -5.463640936926E+03 12 7.2582E-06 1
65 H DX 4.2444E-04 -5.463640945298E+03 10 -1.1135E-06 1
65 H DY 1.4990E-03 -5.463640942117E+03 10 2.0672E-06 1
65 H DZ 9.8569E-04 -5.463640943558E+03 7 6.2581E-07 1
73 H DX 8.8996E-04 -5.463640943796E+03 11 3.8818E-07 1
73 H DY 4.0635E-04 -5.463640945249E+03 9 -1.0646E-06 1
73 H DZ 1.5526E-03 -5.463640941922E+03 11 2.2623E-06 1
81 N DX 3.0237E-03 -5.463640937800E+03 12 6.3840E-06 1
81 N DY 3.1621E-03 -5.463640937605E+03 12 6.5795E-06 1
81 N DZ 3.3672E-03 -5.463640936782E+03 11 7.4017E-06 1
89 H DX 3.5908E-04 -5.463640945209E+03 8 -1.0249E-06 1
89 H DY 1.0305E-03 -5.463640943313E+03 13 8.7074E-07 1
89 H DZ 1.3452E-03 -5.463640942571E+03 10 1.6132E-06 1
97 H DX 1.1682E-03 -5.463640943082E+03 10 1.1022E-06 1
97 H DY 1.4461E-03 -5.463640941923E+03 12 2.2616E-06 1

output.out attached

I profusely apologize, but how do I visualize vibrations on my browser using JSMol? I know it sounds silly but I have no idea how to install or launch it. Your webpage below did it very well, I can't follow any of the Java related instructions on the developers website, I would like to be able to run JSmol on my home computer on a browser, can somebody give me a brief instruction how to do that?

Your tutorial page does that very well

https://www.crystal.unito.it/prtfreq/jmol.html

Files for scenario 3
INPUT.d12
fort.f34

Hi Alessandro, working hard on this one. Scenario 3 seemed trivial (but did not converge). I assumed some JT distortion, so I used distortion along z axis argument and I shifted dxz down and assumed this is the double populated one. So far no luck in convergence

EIGSHIFT
5
1 8 1 -.5 .5
1 8 2 -.5 -.5
1 8 3 -.5 .5
1 8 4 -.5 .5
1 8 5 -.5 .5

Alessandro,

I am making a large 450 atom supercell of MgNH4PO4*6H2O to study Fe ion incorporation. We experimntally observe about 5% Mg atoms substituted with Fe - we do not know the oxidation state. So my supercell is big and I optimize this ionic solid with PBE-D3. My question is long and related on how to obtain required electronic state and converge in some instances. See below my diagram. I am exploring 3 different substitutional scenarios.

Scenario 1 is substituting Fe3+ and removing one proton to make it neutral. I am getting excellent SCF convergence, my guess is that this octahedral symmetry is broken somehow by removal of proton which helps SCF convergnce but crystal field with nearly 5 inpaired electrons is still preserved after the convergence with PBE-D3/pobDZVP.

Scenario 2 is an SCF problem. To charge balance it I remove NH4+. Immediately I get problems with SCF becoming conducting, I guess it does not want to be perfectly Oh symmetry and needs some distortion. I managed to converged it with PBE-D3/STO-3G in hopes that it will optimize to some solution which I can further optimize with PBE-D3/pobDZVP. But if I wanted to bias it with EIGENSHIFT and start with a large basus set, what would be my logic here? Robert Orlando used to very elegantly explain these things to me in the past.

Scenario 3 I haven't run yet. Seems like perfect Oh symmetry with the corresponding crystal field splitting and 4 unpaired electrons but my guess is it will run into the same problems as Scenario 2 and will need some biasing.

I mean… those are huge HPC nodes… they can’t be possibly out of disk… But certainly I will try this, will it affect my convergence or calculation speed?

Thank you Alessandro

So on my main supercomputer I am getting this error during write problem. Admins do not know why it happens. It only happes with CRYSTAL and sporadically.

CYC 23 ETOT(AU) -2.276909751322E+04 DETOT -2.19E-06 tst 4.04E-07 PX 2.29E-04
TTTTTTTTTTTTTTTTTTTTTTTTTTTTTT DIIS TELAPSE 20527.44 TCPU 20346.34
DIIS TEST: 0.38681E-05 AT SCF CYCLE 23 - DIIS ACTIVE - HISTORY: 23 CYCLES
forrtl: No space left on device
forrtl: severe (38): error during write, unit 8, file /90daydata/urea_kinetics/struvite/Fedoped/PBE_D3/2x2x2_FeOH/fort.8.pe280
Image PC Routine Line Source
Pcrystal 0000000007376772 Unknown Unknown Unknown
Pcrystal 00000000073744DB Unknown Unknown Unknown
Pcrystal 0000000001BA179E Unknown Unknown Unknown
Pcrystal 000000000069D509 Unknown Unknown Unknown
Pcrystal 0000000000695494 Unknown Unknown Unknown
Pcrystal 0000000000992FCD Unknown Unknown Unknown
Pcrystal 0000000000609584 Unknown Unknown Unknown
Pcrystal 0000000000605881 Unknown Unknown Unknown
Pcrystal 0000000000405540 Unknown Unknown Unknown
Pcrystal 00000000004053FD Unknown Unknown Unknown
libc.so.6 0000148B7AA295D0 Unknown Unknown Unknown
libc.so.6 0000148B7AA29680 __libc_start_main Unknown Unknown
Pcrystal 0000000000405315 Unknown Unknown Unknown

It makes sense, thank you.

aerba I do not think this is true now that I have spent so much time restarting. I tried restarting frequency job with the old input (e.g. if I do PREOPTGEOM and it is optimized) and restart normally proceeds. I can take the last coordinate file and do EXTARENAL in the restart but in my experience did not matter, frequency restart always proceeds either way

Alessandro, the setback is temporary. What I really appreciate is that you gave CRYSTAL more life via user support than it ever had. I am very grateful for it

59 S 0.802 -8.631 2.894
567 S
6.070E+04 5.470E-04 0.000E+00 0.000E+00
9.103E+03 4.230E-03 0.000E+00 0.000E+00
2.071E+03 2.175E-02 0.000E+00 0.000E+00
5.860E+02 8.510E-02 0.000E+00 0.000E+00
1.906E+02 2.480E-01 0.000E+00 0.000E+00
6.763E+01 4.670E-01 0.000E+00 0.000E+00
2.513E+01 3.643E-01 0.000E+00 0.000E+00
568 S
1.126E+02 2.167E-02 0.000E+00 0.000E+00
3.480E+01 9.360E-02 0.000E+00 0.000E+00
6.512E+00-2.607E-01 0.000E+00 0.000E+00
569 S
3.240E+00 1.284E+00 0.000E+00 0.000E+00
1.548E+00 6.604E-01 0.000E+00 0.000E+00
570 S
4.487E-01 1.000E+00 0.000E+00 0.000E+00
571 S
1.553E-01 1.000E+00 0.000E+00 0.000E+00
572- 574 P
5.644E+02 0.000E+00 2.480E-03 0.000E+00
1.334E+02 0.000E+00 1.968E-02 0.000E+00
4.247E+01 0.000E+00 8.998E-02 0.000E+00
1.562E+01 0.000E+00 2.571E-01 0.000E+00
6.109E+00 0.000E+00 4.352E-01 0.000E+00
575- 577 P
2.036E+00 0.000E+00 1.000E+00 0.000E+00
578- 580 P
4.338E-01 0.000E+00 1.000E+00 0.000E+00
581- 583 P
1.305E-01 0.000E+00 1.000E+00 0.000E+00

ahem
pob-TZVP-rev2

aerba said in Error in RESTART of FREQCALC calculation:

Hi,

I have run some calculations on your case following my step-by step recipe (as described at https://forum.crystalsolutions.eu/post/339, which I have now edited to include the intensity step), and the restart now works just fine (i.e. without the annoying "possibly conducting state", and with a nice convergence of the further SCFs upon restart).

This is what I did:

• I took the optimized geometry from your original output file and I created a new input file for a single-point calculation. I ran it and obtained the wavefunction external file (i.e. fort.9 unit);

• I prepared an input file to run the harmonic frequency calculation, 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 and the external unit with the density matrix, i.e. fort.13 unit;

• I prepared an input file to restart the frequency calculation and provided the FREQINFO.DAT and fort.13 files from the previous step and the fort.9 (renamed as fort.20) from the first 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.

Hope this helps,

thank you and I am trying to do that

My current activity on this forum is due to the need to calculate Raman spectra. This one is not a problem but more of an observation. For the longest time I thought that CRYSTAL had a basis set problem where basis sets were seemingly randomly optimized and there were many falvors of them and they wer nore standartized in terms of contractions (e.g. 6-31G*). I was very happy to find out that standard basis sets by Peintinger were created, e.g. pob-TZVP which I can simply specify with BASISSET. So in all of my recent work on Raman spectra I used them for simplicity and uniformity.
Fast forward, my calculated Raman peaks just do not have the right position. I understand there will be an intrinsic error in the calculated peak positions, but the peaks ere 150-200 cm-1 too low for a sulfate ion. So I looked back at CRYSTAL references that did Raman including Roberto's and noticed at that time they still used these old school basis sets. I was curious and for B3LYP-D3 (I have molecular crystals or ionic crystals) with pob-TZVP I recalculated everything with these large 8611 basis sets. Much to my dismay, these old school basis sets yielded calculated Raman peaks in the vicinity of the experimental, e.g. 150-200 cm-1 higher than pob-TZVP with everything else in the input the same.
This is not a cimplaint, I understand that frequency outcome will depend on the calculation setup, e.g. functional and basis set, but why would pob-TZVP be so spectacularly bad at these Raman vibrations?
See attached, blue is 86111 old school basis set and orange is pob-TZVP basis set - I have much more data with pob-TZVP (unfortunately).
Experimental SO4 vibration is around 920 cm-1 in this particular mineral

Hi all, it's more of an functional question. I noticed that only limited subset of functionals is available for Raman intensity calculations. I have a molecular crystal and trying all of it, started with range separated, then hybrid... Now I found that PBE can be combined with D3 and trying that one. So my question is - what is the difference between PBE and PBEXC or PBEsol and PBEsolXC?

Turn out I can simply specify

DFT
PBE-D3
END

but not

DFT
PBEsol
END

the latter aborts and I can only make it work if I specify otherwise it returns an error

DFT
PBEsolxc
END

(EXCHANGE)[CORRELATION] FUNCTIONAL:(PBEsol GGA)[PBEsol]

The former, however, still returns

(EXCHANGE)[CORRELATION] FUNCTIONAL:(PERDEW-BURKE-ERNZERHOF)[PERDEW-BURKE-ERNZERHOF]

I guess my question is why PBE can specified as a single keyword but not PBEsol which needs to be PBEsolXC. What is the significance of xc addition here?

thank you

Whew... At least you got it... It is uncanny how a normally job, aborted, can't be restarted since it can't converge SCF all of a sudden...

Alessando, can I send you the files above so you can please try a restart? My restarts end up being conducting state and do not converge

Alessandro, to prove the point how difficult these restarts are, I copied FREQINFO.DAT from the first frequency calculation, fort.13 unit, and fort.9, renamed fort.20 in the new scratch folder, grabbed the last optc file from the converged geometry optimization. Tried the restart with GUESSP since I am getting conducting state otherwise. Right away I have problems where my old and new vectors via GUESSP are different. why?

INFORMATION FROM INTEGRAL EVALUATION

RESTART FROM A PREVIOUS RUN FOCK MATRIX - DEP ACTIVE
NUMBER OF COUPLE SETS (NEW, OLD, FOUND): 50745 15118 15039
NUMBER OF IRREDUCIBLE G VECTORS : 71990 64543 63141

SCFOUT becoming conducting drives me crazy, normal frequency calculation that run perfectly, after restart, becomes conducting and stops converging SCF

It is tough, Alessandro. Restarting frequency calculations (or just running them) is unpredictable. It runs normally, then if it stops out of time and is restarted, many times it does not run for one reason or the other - see a random restart abort below. It is tough, perhaps I will learn something by doing them but I now normally just start form scratch

DIIS TEST: 0.85073E-04 AT CPHF CYCLE 9 - DIIS ACTIVE - HISTORY: 9 CYCLES
CYCLE 9 ALPHA 278.474328 EPSILON 2.093136 DELTA 4.8487E-04
forrtl: severe (256): unformatted I/O to unit open for formatted transfers, unit 85, file /dev/null
Image PC Routine Line Source
Pcrystal 0000000007374206 Unknown Unknown Unknown
Pcrystal 0000000001BA179E Unknown Unknown Unknown
Pcrystal 0000000000A8038B Unknown Unknown Unknown