Hi,

Hmmm...even though the SI file of the paper you have shared does point to using HSE06, it remains not entirely clear whether its parameters were kept default or altered (for all systems together or individually for instance).

There are also differences between what different codes consider as "default" settings. For example, within the code used in the paper (VASP, nice code, no doubt), the defaults for HSE06 read (taken from https://www.vasp.at/wiki/index.php/List_of_hybrid_functionals) :
$$ \omega= 0.2\ \mathring{A} , \quad c = 0.25, \quad \text{correlation}=\text{PBE}, $$ with the first number reading the range separation parameter (omega) and the second the fraction of exact exchange used (c).

Within CRYSTAL (also nice code, no doubt), these read (taken from the manual, page 138):
$$ \omega= 0.11\ a_0^{-1}, \quad c = 0.25, \quad \text{correlation}=\text{PBE}, $$ adopting the same labels.

Not sure about the exact definition of units (perhaps a developer can comment if this is indeed Bohr radius as assumed?), but you can already see the subtle differences having to be taken into account when comparing between codes.

A few other thoughts worth considering:

In the paper, the structure was optimized with PBEsol and on top of that geometry HSE06 was applied as a single-point calculation. Not sure about the exact composition of those ZIFs, but the structural differences could play a significant role as well (planewave codes are very costly when optimizing a structure with hybrid functionals). Here is also a good read on this topic: doi.org/10.1088/2516-1075/aafc4b

One final small comment. Within the PAW formalism implemented in VASP, scalar relativistic effects are included in the pseudopotentials by default. No problem, cool feature, but should be taken into account when comparing results, especially for heavier elements (longer discussion found here https://blog.vasp.at/forum/viewtopic.php?t=902)

Hope this helps!

Cheers,
Aleks

Hi,

On paper, it should be possible but we've been running some tests in the last few days before answering to your question and we have been experiencing some problems with the restart option of CPHF. We are going to run more tests and we will let you know as soon as we will have some updates.

Thanks Jacques! These are very informative.
The information for specific basis sets is helpful, I will try them.

Hello Prof. Erba,

Thank you for providing the reference and relevant pages. This is very useful.

Best,
Danny

Thank you so much
this helped a lot

Thank you very much for the detailed explanation—this really helped clarify things for me! The plot and your explanation made it all very clear.

Your response is incredibly valuable—thank you so much.I suspect that the DIIS/Anderson extrapolation might have 'hit' a local minimum, so the density guess in iteration 8 happened to yield a total energy extremely close to that of the previous step, resulting in a very small ΔE.
CYC 0 ETOT(AU) -8.456120523718E+03 DETOT -8.46E+03 tst 0.00E+00 PX 1.00E+00
CYC 1 ETOT(AU) -8.390242659622E+03 DETOT 6.59E+01 tst 0.00E+00 PX 1.00E+00
CYC 2 ETOT(AU) -8.391027170997E+03 DETOT -7.85E-01 tst 3.34E-03 PX 1.13E-01
CYC 3 ETOT(AU) -8.391734802465E+03 DETOT -7.08E-01 tst 2.44E-03 PX 1.02E-01
CYC 4 ETOT(AU) -8.392064543836E+03 DETOT -3.30E-01 tst 8.38E-04 PX 4.49E-02
CYC 5 ETOT(AU) -8.392086825687E+03 DETOT -2.23E-02 tst 1.24E-04 PX 1.72E-02
CYC 6 ETOT(AU) -8.392095974656E+03 DETOT -9.15E-03 tst 2.86E-05 PX 9.66E-03
CYC 7 ETOT(AU) -8.392097542826E+03 DETOT -1.57E-03 tst 3.85E-06 PX 4.81E-03
CYC 8 ETOT(AU) -8.392097541980E+03 DETOT 8.46E-07 tst 5.41E-06 PX 3.18E-03
CYC 9 ETOT(AU) -8.392098065539E+03 DETOT -5.24E-04 tst 4.69E-06 PX 3.18E-03
While this DETOT value satisfies the default energy convergence criterion, the corresponding values suggest that the electron density had not yet fully stabilized. This aligns well with your suggestion that tightening the convergence threshold would lead to a more reliable result.
Thank you again for your guidance.

Many thanks for your detailed explanation and for checking the code — that definitely clarifies things. I really appreciate your help!

Oh yes, right. My apologies. I did not notice this. Thank you Giacomo!

Hi,

Keeping in mind that geometry optimizations (unconstrained, volume-constrained, pressure-constrained) are all numerical processes with final results that thus may depend on numerical aspects of the implemented algorithms:

If you are interested in the structure of the true minimum of the PES, the best way to get it is directly from an unconstrained optimization (either from an OPTGEOM calculation or from the PREOPTGEOM within the EOS). By definition, numerically, this is the geometry corresponding to the lowest energy. In both cases, the optimized structure (volume, lattice parameters, atomic positions) is printed in full.

If, after an EOS calculation, you are interested in getting the structure for a specific volume V (not the minimum), then the strategy you described is exactly what I would do (and I've often done): I make sure to input a structure corresponding to the desired volume (typically by manually adjusting the lattice parameters) and I run a further CVOLOPT calculation.

Note: During a CVOLOPT calculation the volume of the system is expected to remain almost constant (within a certain numerical error). So small variations may be observed. If instead you experience large variations, there may be a problem.

Hi,

Can you try to re-run the COHP calculation by using:

COHP 16 500 200 360 2 12 0

instead of

COHP 16 500 200 360 1 12 0

This should generate a file COHP.DAT
Let me know how this goes.

Hi Alessandro and Giacomo,

Thank you for the clear and helpful explanations!

I tried running the calculation with 32 cores, and it indeed helped with memory management. I’ll continue experimenting to optimize performance. Really appreciate your guidance and the references!

you're the best, thank you for going extra mile

Thank you very much, that worked (but not restart)

Dear Eleonora and Aleks,

Thank you so much for the detailed explanation and for sharing the corrected input/output file. That really clarified the issue. I tried your suggested settings with FMIXING and SPINLOCK adjustments, and the geometry optimization is running well with no errors. Have a nice day!

Best,
Aparajita

Hi,

I think that the best way to proceed in this case would be to restart the calculation one or more times. To do this, you just have to make sure that the scratch folder is not deleted when the calculation stops. Basically, you would run a first job with:

FREQCALC END

Then, after the first calculation stops (maybe because you reached a wall clock time limit) you would run a second job restarting from the first as:

FREQCALC RESTART END

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).

If needed, you can repeat this restart process multiple times until completion of the frequency calculation.

Hope this helps,

thank you

very grateful, I will run it again but not sure what to do here if it aborts again

GiacomoAmbrogio

Dear Ambrogio,

Thank you so much! the problem has been perfectly solved.

All the best,

wang

Hey,

Thank you. It works now. This Forum is a great idea!