Posts

• ---

  SOC-compatible basis sets for transition metals
  undefined GiacomoAmbrogio

  The block

  TWOCOMPON
  SOC
  END
  

  can be inserted anywhere in the third section of the INPUT file. It is common practice for us to place it at the top of this section, but this is not strictly required.

• ---

  SOC-compatible basis sets for transition metals
  undefined GiacomoAmbrogio

  Hi Chris,

  Not quite, the pob-DZVP and pob-TZVP basis sets are all-electron valence basis sets, thus they are not paired with relativistic pseudopotentials. This means they cannot be used directly for spin–orbit coupling calculations in CRYSTAL.

  For Nickel and Cobalt I suggest you to use the COLUSC ECP paired with the basis set that you can find here for Ni (the one under "Nickel Relativistic Effective Potential and Basis set including the 3s and 3p subshells...") and here for Co (the one under "Cobalt Relativistic Effective Potential and Basis set including the 3s and 3p subshells...").

  You just need to convert the valence basis set in the CRYSTAL format.

• ---

  Discrepency between MPP and Pcrytsal
  undefined GiacomoAmbrogio

  Hi Rams,

  The need for relatively high values of FMIXING is not unusual, so what you are observing is expected. That said, you are correct that if FMIXING is set extremely high (close to 100%), there is a risk that the SCF procedure may reach converge before reaching the "true" ground state. This is not unique to your system, it is a general trade-off with strong damping.

  To improve robustness while still guiding the calculation toward the correct solution, you can try:

  • Increasing TOLDEE: this tightens the SCF energy convergence criterion and will allow the SCF to continue reaching the minimum even with high FMIXING. Keep in mind, however, that this will typically require many more SCF cycles.
  • Combining mixing with other stabilization strategies, such as level shifting (LEVSHIFT) or electronic smearing (SMEAR) (if applicable to your system), which often reduce the need for such extreme damping.

• ---

  SOC-compatible basis sets for transition metals
  undefined GiacomoAmbrogio

  Hi Chris,

  For SOC calculations in CRYSTAL, you cannot use all-electron basis sets directly (such as your cc-pVDZ-DK). SOC in CRYSTAL is implemented through the use of relativistic effective core potentials (ECPs), which already incorporate scalar-relativistic and spin-orbit effects for the core electrons. Thus, at least one pseudopotential is required in your system (usually on transition metals and heavier elements).

  The INPSOC keyword can be used to manually insert an ECP, but the associated basis set must be designed to describe only the valence electrons that remain after introducing the pseudopotential.

  I recommend checking the CRYSTAL basis set library, where you’ll find pseudopotentials and corresponding valence basis sets that are already formatted for SOC calculations in CRYSTAL. These can be used directly without modification and will ensure consistency between the basis and the relativistic treatment. However, we don't have a SOC basis set for evry element.

  In the case you are interested in a specific element for wich we don't have the SOC basis, you can try using one of the internal ECP options (see page 88-92 of the manual) and combine it with a molecular basi set.
  For example, you can find the basis set for the Stuttgart ECPs (STUTSC and STUTLC keyword in CRYSTAL) here. Or here for the COLUSC and COLULC ECPs.

• ---

  Extracting eigenvalues for a certain high-symmetry path
  undefined GiacomoAmbrogio

  Hi Chris,

  You’re right that the code uses the symmetry of the crystal to reduce the number of k-points it actually computes. That’s why you don’t see all 216 k-points from the 6×6×6 Monkhorst-Pack grid: only the irreducible k-points are listed, since the energies at the symmetry-equivalent points can be obtained by applying the crystal’s symmetry operations.

  That said, one important distinction: the program does not literally “reuse” the eigenvalues from one representative k-point for its equivalents, it only knows that due to symmetry, those results will be the same, so it avoids recalculating them.

  For band structure plots along a high-symmetry path (e.g. Gamma-X-K-Gamma), the reduced k-point mesh from the SCF run is not sufficient. Instead, you should perform a separate band structure calculation (BAND keyword in PROPERTIES, page 309 of the user manual). In this type of calculation, you explicitly define the path through reciprocal space, and PROPERTIES computes eigenvalues along that path directly, without relying on the Monkhorst-Pack grid.

  Let me know if you have any truble running the properties calculation.

• ---

  Discrepency between MPP and Pcrytsal
  undefined GiacomoAmbrogio

  Hi Rams,

  I’ll look into this issue further, but in the meantime, could you please try running the MPP version with the same input, just without the DIIS keyword, and let me know if that converge?

• ---

  What are qualities in parenthesis in the Gamma tensor?
  undefined aerba

  Hi,

  I understand your confusion as this is not clearly explained anywhere in the output. The values within parentheses are those obtained as such from the CPHF/KS calculation. The values outside the parentheses are those obtained with an a posteriori symmetrization.

  In your case above, the large components are not affected by the symmetrization, which only helps "cleaning" the vanishing components (i.e. they become cleaner "zeros").

  Hope this clarifies things a little,

• ---

  Unexpectedly cannot get the geometry after optimization: KEYWORD EXTPRT NOT ALLOWED
  undefined GiacomoAmbrogio

  Hi esmuigors,

  When you run a geometry optimization (within the OPTGEOM block), CRYSTAL will always produce a fort.34 file (that contains the optimized structure and can be used in a subsequent calculation with the EXTERNAL keyword).
  If you don’t see it after the run, a common cause is that it wasn’t copied back by the script used to manage scratch directories for the execution as the runCRY script provided with the code.

  As for the error that you get, the issue is that EXTPRT should be placed outside the OPTGEOM block, as in this input.d12 example.

  If you prefer, you can also extract the optimized geometry manually from the .out file. However, note that you must take both the final cell parameters (and angles, if present) and the final fractional atomic coordinates from the “FINAL OPTIMIZED GEOMETRY” section (those in the primitive cell), using only updated cell parameters without matching coordinates will lead to inconsistencies and errors like the ones you saw.

  Let me know if you manage to get the optimized structure.

• ---

  SCF fails spinlock with POB-DZVP-REV2
  undefined GiacomoAmbrogio

  Hi jquertin,
  As Aleks correctly pointed out, it’s better not to use DIIS (which is active by default) when using SPINLOCK.
  A good way to combine the two is like this:

  SPINLOCK  
  1  
  -2  
  THREDIIS  
  0.005
  

  This way, DIIS is only activated when SPINLOCK is turned off.

  However, I tried running your input, and it’s likely that this is actually a bug. Unfortunately, I don’t have a better solution at the moment other than changing the functional.

• ---

  Which keywords can help the geometry optimization to what you expected ?
  undefined aerba

  Hi,

  The FINALRUN option works fine in P-CRYSTAL: that sentence in the Manual must be a leftover from the past, sorry for that.

  Can you elaborate on how the optimized structures are unreasonable? Is it just for the underestimation of the computed band gap or also for some structural aspects? In this case, it would help if you could show us the "expected" structure, as well as the one you obtain from the optimization.