Cp2k: protocols revision #263
Conversation
yakutovicha
force-pushed
the
cp2k/protocols-revision
branch
from
f6abed9 to
f363b97
Compare
1. Set the electronic temperature to 710.5 K 2. Set MGRID CUTOFF to 1800. 3. Set REL_CUTOFF to 80. 4. Set NGRIDS to 4. 5. Remove initial magnetisation of the atoms (not used).
* Add MOLOPT basis sets from UZH * Update to the file version from CP2K release 9.1 * Update CP2K input generator - Reshuffle database files and add new ones - Use ScaLAPACK as diagonalization library - Switch CHOLESKY OFF - Switch to RUN_TYPE ENERGY, because ENERGY_FORCE does not print the atomic forces currently * Revise CP2K settings for protocol precise - Use cutoff 1200 Ry with 4 multi-grids and a relative cutoff of 80 - Use MO instead of MO_CUBES section for MO output - Remove the MAP_CONSISTENT keyword which has been removed in CP2K v7.1 already * Update potentials and basis sets - Use UZH TZV2P MOLOPT basis sets for H-Xe - Use semi-core GTH PPs for some elements * Change k point distance to 0.06 - Use a less tight SCF convergence (EPS_SCF 1.0E-7)
In addition, one can link basis set/pseudo specification in the protocol definition. This will allow specifying multiple protocols that differ only by the choice of basis set/pseudo.
* Always use ScaLAPACK for matrix multiplications instead of the default ELPA * Write wavefunction restart file after each 5 SCF iteration steps (instead of 20) * Add revised GTH PPs (GTH_POTENTIALS_PSI). * Add protocol and database file for the revised GTH pseudopotentials * Set EXTENDED_FFT_LENGTHS to `True`. * Increase CUTOFF from 1200 to 2400 * Write notification about restarting file operations (LOG_PRINT_KEY).
yakutovicha
force-pushed
the
cp2k/protocols-revision
branch
from
cb7fb94 to
930c385
Compare
|
|
||
| ## Lowering runtime by 5 minutes to let CP2K gracefully finish the calculation. | ||
| walltime = engines['relax']['options']['max_wallclock_seconds'] | ||
| walltime = max(300, walltime - 300) |
There was a problem hiding this comment.
Can we add CP2K specific parameters such that a user using the common workflows can override it easily?
There was a problem hiding this comment.
I would say this is for a different PR. The big idea of ACWF is having the same input for different codes. I am not sure whether code-fine-tuning options are welcome at all.
Maybe @sphuber can comment on this.
|
@dev-zero @yakutovicha since the paper is now accepted and we are ready for final answer to reviewer, it became quite urgent to make a release with all the elements to reproduce the results of the caper. Could you please finish up this PR within the week? Thanks! |
Co-authored-by: Tiziano Müller <tm@dev-zero.ch>
| 'fast', 'moderate', 'precise', 'verification-PBE-v1-DZVP-GTH', 'verification-PBE-v1-DZVP-GTH-rev', | ||
| 'verification-PBE-v1-TZV2P-GTH' |
There was a problem hiding this comment.
Should we also no have verification-pbe-v1 here, for consistency with all the others? Could just function as an alias if it really points to one of the specific versions you already have added here. I take it the verification study was run with just one of these protocols? Or do you need all of them depending on the structure you are running?
There was a problem hiding this comment.
I will double-check, but I guess the protocol that was used for the final calculation is verification-PBE-v1-TZV2P-GTH - I can rename it to "verification-pbe-v1".
The other two "verification-PBE.." could probably be removed. They were used while testing different parameters.
There was a problem hiding this comment.
Just got the confirmation - indeed, only verification-PBE-v1-TZV2P-GTH was used to produce the final results.
Co-authored-by: Tiziano Müller <tm@dev-zero.ch>
…m/aiida-common-workflows into cp2k/protocols-revision
dftd3.datandxTB_parameters.