ERROR **** PGGP **** G-VECTOR NOT FOUND IN PREVIOUS DENSITY MATRIX

job314 · wrote on 17 May 2025, 17:45

HI all, I am trying to restart Raman calculation since it ran out of time. I am getting this strange error, all I did was I added RESTART keyword and initially it ran OK

I think the problem is somewhere since I ran the frequency with full optimization calculation. Then I deleted optimization keywords from FREQCALC and added RESTART. See the files, is there a way to restart it?

HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
FORCE CONSTANT MATRIX - NUMERICAL ESTIMATE
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
MAX ABS(DGRAD): MAXIMUM ABSOLUTE GRADIENT DIFFERENCE WITH RESPECT TO
THE CENTRAL POINT
DE: ENERGY DIFFERENCE WITH RESPECT TO THE CENTRAL POINT
(DE IS EXPECTED TO BE POSITIVE FOR ALL DISPLACEMENTS)

ATOM MAX ABS(DGRAD) TOTAL ENERGY (AU) N.CYC DE SYM
CENTRAL POINT -6.939500764932E+03 0 0.0000E+00 8
1 P DX RESTORED FROM A PREV. HESS. MATRIX
1 P DY RESTORED FROM A PREV. HESS. MATRIX
1 P DZ RESTORED FROM A PREV. HESS. MATRIX
9 O DX RESTORED FROM A PREV. HESS. MATRIX
9 O DY RESTORED FROM A PREV. HESS. MATRIX
9 O DZ RESTORED FROM A PREV. HESS. MATRIX
17 O DX RESTORED FROM A PREV. HESS. MATRIX
17 O DY RESTORED FROM A PREV. HESS. MATRIX
17 O DZ RESTORED FROM A PREV. HESS. MATRIX
25 O DX RESTORED FROM A PREV. HESS. MATRIX
25 O DY RESTORED FROM A PREV. HESS. MATRIX
25 O DZ RESTORED FROM A PREV. HESS. MATRIX
33 O DX RESTORED FROM A PREV. HESS. MATRIX
33 O DY RESTORED FROM A PREV. HESS. MATRIX
33 O DZ RESTORED FROM A PREV. HESS. MATRIX
41 O DX RESTORED FROM A PREV. HESS. MATRIX
41 O DY RESTORED FROM A PREV. HESS. MATRIX
41 O DZ RESTORED FROM A PREV. HESS. MATRIX
49 N DX RESTORED FROM A PREV. HESS. MATRIX
49 N DY RESTORED FROM A PREV. HESS. MATRIX
49 N DZ RESTORED FROM A PREV. HESS. MATRIX
57 N DX RESTORED FROM A PREV. HESS. MATRIX
57 N DY RESTORED FROM A PREV. HESS. MATRIX
57 N DZ RESTORED FROM A PREV. HESS. MATRIX
65 C DX RESTORED FROM A PREV. HESS. MATRIX
65 C DY RESTORED FROM A PREV. HESS. MATRIX
65 C DZ RESTORED FROM A PREV. HESS. MATRIX
73 H DX RESTORED FROM A PREV. HESS. MATRIX
73 H DY RESTORED FROM A PREV. HESS. MATRIX
73 H DZ RESTORED FROM A PREV. HESS. MATRIX
Abort(1) on node 0 (rank 0 in comm 0): application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0

job314 · wrote on 17 May 2025, 17:48

here are the files, again original run was FREQCALC with geometry optimization, for restart I deleted optimization keywords and added RESTART
optc045.f34
INPUT.d12
output.out

aerba · wrote on 22 May 2025, 15:27

Hi,

Let's try to fix one of these restart issues at a time.

As you know (I put it here for other readers as well), to restart a FREQCALC calculation we need the RESTART keyword, as below:

FREQCALC
RESTART
END

All keywords related to the calculation of the intensities from the initial job should be kept in the new input as well.

In order to make this restart work, you need a few files from the previous job to be placed in the scratch folder of the new job: FREQINFO.DAT, fort.13 and fort.9 (to be renamed fort.20 in the new folder).

As such, I am unable to try to restart your job because I need these three files from the previous run. If you have them you can try to restart and/or send me the files.

Let's see how this goes.

aerba · wrote on 22 May 2025, 15:31

The point that you make about the geometry may also be relevant. Given that your original calculation was also performing a geometry optimization, when you do the restart calculation you must ensure that the geometry specified in the new input is the optimized one from the previous run.

job314 · wrote on 23 May 2025, 06:15

I just go impatient and started the calculation from scratch again... It's about to finish... That has been my general experience with restarts, something goes wrong and it is easier to restart the whole calculation... This is because when I restart - and I just tried that for a different job - SCFOUT calculations become conducting and won't converge anymore whereas if I start form scratch, everything works

aerba · wrote on 23 May 2025, 10:13

Whatever works, I guess

job314

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

job314

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

aerba

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.

job314

It makes sense, thank you.