Error in RESTART of FREQCALC calculation
-
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
-
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,
Alessandro Erba
Professor of Physical Chemistry
Department of Chemistry, University of Torino
[email protected] -
-
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.LOGAny 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 -
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=NhXhQsUsed 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
-
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,
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
-
-
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=NhXhQsUsed 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
PeterRemoto I just started running some tests on this case. I will keep you posted on how it goes.
-
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=NhXhQsUsed 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
PeterRemoto I started drafting a reply but encountered problems in uploading the files. Will try later.
Alessandro Erba
Professor of Physical Chemistry
Department of Chemistry, University of Torino
[email protected] -
PeterRemoto I started drafting a reply but encountered problems in uploading the files. Will try later.
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?
-
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.LOGAny 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
PeterRemoto I have tried to restart your calculation with CRYSTAL23 following my step-by-step recipe (described at https://forum.crystalsolutions.eu/post/339) and it worked.
This is what I did:
-
I prepared an input file to run the harmonic frequency calculation, without intensities, 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 (I can not upload it here as it exceeds the maximum allowed file size), the external unit with the density matrix, i.e. fort.13 unit, and the external unit with the wavefunction, i.e. fort.9;
-
I prepared an input file to restart the frequency calculation and provided the FREQINFO.DAT, fort.13 and the fort.9 (renamed as fort.20) files from the previous 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 with CRYSTAL23.
Hope this helps,
-
-
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?
PeterRemoto At the moment I am afraid I do not have an explanation for the difference you experienced between CRYSTAL17 and CRYSTAL23 as I am unable to reproduce the erratic behavior with CRYSTAL23.
Alessandro Erba
Professor of Physical Chemistry
Department of Chemistry, University of Torino
[email protected] -
PeterRemoto At the moment I am afraid I do not have an explanation for the difference you experienced between CRYSTAL17 and CRYSTAL23 as I am unable to reproduce the erratic behavior with CRYSTAL23.
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
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login