Error in RESTART of FREQCALC calculation

job314

HI all, admittedly I am running these large frequency jobs and they run out of queue and I can't restart them, there is always some problem, this one is io error, hard to troubleshoot

FREQINFO.DAT output.out TENS_RAMAN.DAT INPUT.d12

aerba

Hi,

I am quite familiar with that error message myself: it pops up when the fort.9 unit provided upon the restart is the wrong one (i.e. does not match with the current calculation).

Let me make a general comment on how to best approach these frequency calculations with CRYSTAL based on my experience.

I noticed that you tend to use the PREOPTGEOM option within FREQCALC. Now, this is a very nice feature of CRYSTAL that allows you to run a single job where everything is fully automated: the structure gets optimized, the numerical Hessian computed and diagonalized. Not many programs can do that, to the best of my knowledge. At the same time, while this is very convenient if you can indeed run everything in a single job, it complicates things if you then need to do a restart from a previous incomplete calculation.

If you envisage that this could be the case (maybe because of a wall clock limit on the cluster) then it is preferable (to put it mildly) to do things step by step:

You first run a geometry optimization with something like:

[initial geometry]

OPTGEOM
END

You prepare a new input file where you insert the optimized geometry from the previous run as a starting point, and perform a frequency calculation, with something like:

[optimized geometry]

FREQCALC
END

If this calculation stops, you can now restart it easily with:

[optimized geometry]

FREQCALC
RESTART
END

by providing the required restart files (FREQINFO.DAT from the first frequency calculation, fort.13 unit, and fort.9, to be renamed fort.20 in the new scratch folder).

Personally, I always do things separately, running first the geometry optimization and then the frequency calculation in two separate jobs.

Hope this clarifies things a little,

job314

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

job314

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