f-in-core in CREST 3.0.1

[corinwagen]

xTB uses the f-in-core approximation, meaning that the actual multiplicity and the multiplicity used for xTB are different. Using CREST 2.12 from conda-forge, I can run csearches on Ce-containing complexes using the true multiplicity and CREST runs just fine.

crest Ce_NTf2_3_H2O_3.xyz --noreftopo --chrg 0 --uhf 1 --gfn2

This is structure Ce-2 from Grimme et al 2017. Ce has an unpaired f electron, so multiplicity is 2, but with the f-in-core approx this electron is ignored...

Using CREST 3.0.1, this now doesn't work anymore:

      ╔════════════════════════════════════════════╗
       ║            ___ ___ ___ ___ _____           ║
       ║           / __| _ \ __/ __|_   _|          ║
       ║          | (__|   / _|\__ \ | |            ║
       ║           \___|_|_\___|___/ |_|            ║
       ║                                            ║
       ║  Conformer-Rotamer Ensemble Sampling Tool  ║
       ║          based on the xTB methods          ║
       ║                                            ║
       ╚════════════════════════════════════════════╝
       Version 3.0.1, Mon May  6 18:43:33 UTC 2024
       commit (1782d7d) compiled by 'runner@fv-az772-53'

   Cite work conducted with this code as

   • P.Pracht, F.Bohle, S.Grimme, PCCP, 2020, 22, 7169-7192.
   • S.Grimme, JCTC, 2019, 15, 2847-2862.
   • P.Pracht, S.Grimme, C.Bannwarth, F.Bohle, S.Ehlert,
     G.Feldmann, J.Gorges, M.Müller, T.Neudecker, C.Plett,
     S.Spicher, P.Steinbach, P.Wesołowski, F.Zeller,
     J. Chem. Phys., 2024, 160, 114110.

   for works involving QCG cite

   • S.Spicher, C.Plett, P.Pracht, A.Hansen, S.Grimme,
     JCTC, 2022, 18 (5), 3174-3189.
   • C.Plett, S. Grimme,
     Angew. Chem. Int. Ed. 2023, 62, e202214477.

   for works involving MECP screening cite

   • P.Pracht, C.Bannwarth, JCTC, 2022, 18 (10), 6370-6385.

   Original code
     P.Pracht, S.Grimme, Universität Bonn, MCTC
   with help from (alphabetical order):
     C.Bannwarth, F.Bohle, S.Ehlert, G.Feldmann, J.Gorges,
     S.Grimme, C.Plett, P.Pracht, S.Spicher, P.Steinbach,
     P.Wesolowski, F.Zeller

   Online documentation is available at
   https://crest-lab.github.io/crest-docs/

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
   GNU Lesser General Public License (LGPL) for more details.

 Command line input:
 $ /app/src/peregrine/utils/binaries/crest_3_0_1 data/Ce.xyz --noreftopo --chrg 0 --uhf 1 --gfn2

  --chrg 0
  --uhf 1
  --gfn2               : Use of GFN2-xTB requested.

> Setting up backup calculator ... done.
 ----------------
 Calculation info
 ----------------
> User-defined calculation level:
 : xTB calculation via tblite lib
 : GFN2-xTB level
 :   Molecular charge    : 0
 :   UHF parameter       : 1
 :   Fermi temperature   : 300.00000
 :   Accuracy            : 1.00000
 :   max SCC cycles      : 500
 :   Read dipoles?       : yes
 :   Weight              : 1.00000


 -----------------------------
 Initial Geometry Optimization
 -----------------------------

  Initial geometry optimization failed!
  Please check your input.

The code runs just fine if I set --uhf 0, which I interpret as meaning that I now need to keep track of the number of f electrons myself. I find this a little frustrating as an end user, because now I have to guess what math xTB is doing internally. (e.g. Eu theoretically has a 4f6 5d1 6s2 configuration but apparently actually has a 4f7 6s2 configuration - what's xTB doing here?)

Is there a reason this has changed, and is it possible to revert to the old behavior here?

Ce_NTf2_3_H2O_3.xyz:

55
title
Ce       -0.00060368 -0.00144576 -0.87247846
O       1.49149903 0.40152452 -3.09481871
C       3.69421489 -2.90394304 -0.85397356
F       3.37670339 -3.78652632 -1.79999436
F       4.31182609 -1.88242376 -1.45631104
F       4.56282939 -3.47731977 -0.03167491
S       2.14362695 -2.23981026 0.00772834
O       1.48936085 -1.59738226 -1.12232192
O       1.55234018 -3.40566601 0.56744490
N       2.79912553 -1.20278541 0.98872867
S       2.54817842 0.30727802 0.62731184
O       1.23805415 0.77475481 1.00578200
O       2.86944711 0.58820728 -0.74630849
C       3.83922167 1.15596204 1.72109711
F       3.27019150 1.76095426 2.74816955
F       4.57452590 2.01973643 1.04511224
F       4.66976773 0.23492097 2.20856701
H       2.32692097 0.57336961 -2.63386177
H       1.54098551 -0.49428099 -3.46484418
O       -1.12984221 1.12689724 -3.06093260
C       0.65351356 4.64457368 -0.84763622
F       1.62583267 4.85066051 -1.73437754
F       -0.50008644 4.62248795 -1.52376208
F       0.62202438 5.68337367 -0.02302144
S       0.86380534 2.97574888 0.02490508
O       0.62082306 2.08382198 -1.09930328
O       2.17490193 3.05148775 0.56949616
N       -0.35223102 3.02523121 1.01758247
S       -1.53568149 2.05228161 0.65914661
O       -1.26550273 0.67840421 1.00397309
O       -1.96991224 2.21602550 -0.70179001
C       -2.89393775 2.71214446 1.80081025
F       -3.10443319 1.88889981 2.81231452
F       -4.02700065 2.92997966 1.15864862
F       -2.50454369 3.88028060 2.31015433
H       -1.69298596 1.75194365 -2.57842224
H       -0.39081364 1.63175436 -3.43569537
O       -0.44319866 -1.50858223 -3.07510678
C       -4.35907560 -1.74717541 -0.80629275
F       -5.05807852 -0.99974236 -1.65847951
F       -3.77179742 -2.71505546 -1.51837591
F       -5.21163657 -2.32013451 0.03332007
S       -3.00457559 -0.73510946 0.04908198
O       -2.12903237 -0.49113273 -1.08750772
O       -3.71560488 0.35861879 0.61441876
N       -2.42489631 -1.81929982 1.02663569
S       -0.99637585 -2.35754150 0.64756221
O       0.06465086 -1.44251167 0.98963189
O       -0.93752589 -2.79921775 -0.71965148
C       -0.88141828 -3.87720401 1.77071190
F       -0.05300317 -3.66285003 2.77695972
F       -0.51393342 -4.96083548 1.11167033
F       -2.08384900 -4.12590585 2.28829297
H       -0.70507537 -2.31574938 -2.60585889
H       -1.24999427 -1.10549116 -3.43364003

[pprcht]

Since CREST doesn't know anything about the electronic structure and simply passes the parameters to tblite (or xtb) it might be worth checking with the tblite developers, rather than here.
Upon quickly testing it with the tblite app I can confirm that both

crest Ce_NTf2_3_H2O_3.xyz --sp --gfn2 --uhf 0
tblite run --method gfn2 --spin 0 -- Ce_NTf2_3_H2O_3.xyz

work fine and give the same energy, while

crest Ce_NTf2_3_H2O_3.xyz --sp --gfn2 --uhf 1
tblite run --method gfn2 --spin 1 -- Ce_NTf2_3_H2O_3.xyz

fail completely.

So there might be a difference in the implementations. Unfortunately I don't know the details. Asking either in the xtb or tblite issues should get you to the right people.

[corinwagen]

done, thanks for the fast response here. (I found that tblite runs either way for me, which is puzzling.)