aerba I've noticed for my systems, these SCF convergence issues appear when I try to compute for intensities in a restart job. Then when removing intensities, they converge fine and progress forward.

Is it possible to finish the frequency calculations first and then compute for the Raman intensities afterwards? Would that be a work around? Maybe with RAMANREA - because I have the TENS_RAMAN.DAT, but it just gets stuck at some point during HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
FORCE CONSTANT MATRIX - NUMERICAL ESTIMATE
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
and doesn't progress with restarts

aerba I saw it earlier and glad that a nice solution was found. Thank you so much - this has actually stumped me months ago before getting busy with other projects. I was wondering though, any thoughts on why this frequency restart issue is happening to a handful of structures for CRYSTAL23 but then the restarts worked fine for 17?

Hi Erba,
Honestly, I have ANDERSON acceleration on because I inherited a file with these keywords written in when I was taught how to use CRYSTAL for frequency calculations - and worked pretty well so far with our other systems so I thought to leave it alone (though it was more for pharmacuetical systems). Thanks for the suggestion, I'll try it out if with the original TOLINTEG 10 10 10 10 20 and see what happens.

Thanks,
Peter

Just an update on this - so I've tightened the TOLINTEG from 10 10 10 10 20 to 12 12 12 12 24 and it seemed to progressed the calculation beyond "Electric field applied to X direction" and now at XX direction. Will see how far it progresses and yet to see what happens when I use GUESSP and INTCHPF RESTART.

Sure, I've uploaded the files input files in this link because it exceeded the file size limit to upload them in this comment:
https://otagouni-my.sharepoint.com/:f:/g/personal/rempe782_student_otago_ac_nz/EmtG3VsEJYJArghuK_IF1x0BvJNBiYsE1mrbQELFWOE1-A?e=NhXhQs

Used the same inputs (.d12, fort.9, fort.13, fort.20, FREQINFO.DAT) for to do the frequency calculation restarts for CRYSTAL17 and 23

Thanks heaps

Hey,
I was wondering if anyone has any advice with dealing with crystal systems with transiton metal complexes with a floating anion? Our objective is to calculate the low-frequency Raman modes of these structures and compare with experimental.
Using PBE functional with Grimme D3 dispersion correction and the pob-TZVP-rev2 basis set
So managed to optimise the structure - which took a while but was fine
908892_hicnis_PBE_D3_pob-TZVP-rev2_OPTGEOM_4_4.d12

Now I'm doing frequency calculations
908892_hicnis_PBE_D3_POB-TZVP-REV2_FREQ_4_4.d12
But now a bit stuck with the frequency calculations because it doesn't seem to converge for the INTCPHF structures
908892_hicnis_PBE_D3_POB-TZVP-REV2_FREQ_4_4-69914.out
Tried GUESSP with fort.20 (copied from fort.9) to try to speed up the some bits before I hit my cluster time limit. However, the calculation doesn't seem to properly get past the INTCPHF cycles - Electric field applied to X direction hits 200 cycles, which is what the MAXYCLES set, which is already pretty high - so I can't use fort.32 (copied from fort.31) for INTCPHF RESTART. I'm currently running a calculation with MAXCYCLES increased to 9999 but it doesn't seem to help much looking at the ongoing ouput file.

Not sure how else to troubleshoot this properly without using up all of our cluster allocation - so very open to advice and potential solutions to try out.

Happy to provide more input files if need be.

Thank you for your time,
Peter

Hey, just to add onto this, I'm getting a similar error where the SCF won't wouldn't converge upon restart - but only occurs with certain structures.
When I do with the restart with CRYSTAL17, it works perfectly - it's odd that it only happens on restart because when I lower the criteria, it doesn't need a restart and completes the calculation - but I can't keep lowering the tolerance criteria when I encounter this issue.

CRYSTAL17 succesful restart:
BLACTO_PBE_D3_AhTZVP_FREQ_4_4-53910034 - CRYSTAL17 success..out
CRYSTAL23 unsucessful restart + SCFOUT:
BLACTO_PBE_D3_AhTZVP_FREQ_4_4-53437836.out
SCFOUT.LOG

Any ideas around this?

I've also included a plot of the DETOT from the SCFOUT.LOG files - where the successful one was from CRYSTAL17

The then rest from CRYSTAL23
detot_vs_cycle_CRYSTAL23_FAIL_CYC0tomax.png

Our HPC platform provider said it was not an issue on their end and advised to seek support from the CRYSTAL team. Just to add on, our HPC platform provider also said I can't use the CRYSTAL17 anymore because they can't build the architecture on their new upgrade which, honestly, I don't really understand why.

Happy to discuss,
Peter