Fresh builds of xTB (grimme-lab/xtb@d3f212b) and CREST (crest-lab/crest@4f0f4ab) with both GNU and Intel compilers cause the example case from the QCxMS2 docs to fail at fragment p13f1. This occurs with the latest QCxMS2 compiled from source as well as with the recent v1.1.0 release binary.
The issue seems to be related to an inconsistent number of electrons for the fragment, similar to crest-lab/crest#415. Running the example case follows the documented output until reaching fragment p13f1, which produces:
------------------------------------
| Starting fragmentation of: p13f1
------------------------------------
Average temperature set to 4641 K
Generate new fragments with CREST within energy window of 825.06 kcal/mol
crestcall is:
crest infrag.xyz --msreact --mslargeprint --msnbonds 3 --chrg 1 --uhf 0 --T 16
--gfn2 --ewin 825.05704 --msnshifts 0 --msnshifts2 0 --msattrh --msmolbar --ms
input crestms.inp > msreact.out 2>cresterror.out
The corresponding msreact.out contains:
Command line input:
$ crest infrag.xyz --msreact --mslargeprint --msnbonds 3 --chrg 1 --uhf 0 --T 16 --gfn2 --ewin 825.05704 --msnshifts 0 --msnshifts2 0 --msattrh --msmolbar --msinput crestms.inp
--chrg 1
--uhf 0
--T 16 (CPUs/Threads selected)
--gfn2 : Use of GFN2-xTB requested.
--ewin 825.05704
> Setting up backup calculator ... done.
----------------
Calculation info
----------------
> User-defined calculation level:
: xTB calculation via tblite lib
: GFN2-xTB level
: Molecular charge : 1
: Fermi temperature : 300.00000
: Accuracy : 1.00000
: max SCC cycles : 500
========================================
| |
| MSREACT |
| automated MS fragment generator |
| |
| University of Bonn, MCTC |
========================================
S. Grimme, P. Pracht, J. Gorges.
Cite work conducted with this code as
Philipp Pracht, Stefan Grimme, Christoph Bannwarth, Fabian Bohle, Sebastian Ehlert, Gereon Feldmann,
Johannes Gorges, Marcel Müller, Tim Neudecker, Christoph Plett, Sebastian Spicher, Pit Steinbach,
Patryk A. Wesolowski, and Felix Zeller J. Chem. Phys., 2024, submitted.
---------------------------
xTB Singlepoint Calculation
---------------------------
Input energy successfully calculated.
-------------------
xTB WBO Calculation
-------------------
Initial singlepoint calculation failed!
Please check your input.
And the corresponding xtb output contains:
* started run on 2025/06/21 at 17:40:16.216
ID Z sym. atoms
1 6 C 1, 2
2 1 H 3-5
3 8 O 6
-------------------------------------------------
| Calculation Setup |
-------------------------------------------------
program call : xtb infrag.xyz --sp --chrg 0 --uhf 0 --etemp 5000.0000 --gfn2
hostname : discovery2.hpc.usc.edu
coordinate file : infrag.xyz
omp threads : 16
########################################################################
[ERROR] Program stopped due to fatal error
-1- Assigned number of unpaired electrons (flag '--uhf <int>' or <int> in file '.UHF') is not consistent with the total number of electrons
########################################################################
As I mentioned in crest-lab/crest#415, the issue seems to be with the neutral wbo calculation in the get_wbo subroutine. The patch at that point (crest-lab/crest#418) addressed the bug, but added several assumptions:
!---- For the EI bond analysis the molecule has to be calculated in the neutral state. The GFN2 bond orders can be wrong after the ionization.
!---- For the CID bond analysis the molecule has to be calculated in the ionized state.
!---- calculating the remaining uhf for the wob calculation. Has to be modified when the CID mode is implemented.
!---- For EI the molecule is assumed to be in a low spin state and to be closed shell before ionization.
!---- For CID the molecule is assumed to be in a low spin state after the ionization.
This is now inconsistent with any closed shell ion fragments generated by the QCxMS2 workflow, which is why I believe the acetyl cation (CH3CO+) in p13f1 generates the error. I'm not sufficiently familiar with the workflows in QCxMS2 and CREST to determine the best course of action here, or whether the fix should be implemented in QCxMS2 or addressed further in CREST. I've recreated the problem with other test molecules, which always appears the first time a closed shell ion is fragmented.
Fresh builds of xTB (grimme-lab/xtb@d3f212b) and CREST (crest-lab/crest@4f0f4ab) with both GNU and Intel compilers cause the example case from the QCxMS2 docs to fail at fragment p13f1. This occurs with the latest QCxMS2 compiled from source as well as with the recent v1.1.0 release binary.
The issue seems to be related to an inconsistent number of electrons for the fragment, similar to crest-lab/crest#415. Running the example case follows the documented output until reaching fragment p13f1, which produces:
The corresponding
msreact.outcontains:And the corresponding xtb output contains:
As I mentioned in crest-lab/crest#415, the issue seems to be with the neutral wbo calculation in the get_wbo subroutine. The patch at that point (crest-lab/crest#418) addressed the bug, but added several assumptions:
This is now inconsistent with any closed shell ion fragments generated by the QCxMS2 workflow, which is why I believe the acetyl cation (CH3CO+) in p13f1 generates the error. I'm not sufficiently familiar with the workflows in QCxMS2 and CREST to determine the best course of action here, or whether the fix should be implemented in QCxMS2 or addressed further in CREST. I've recreated the problem with other test molecules, which always appears the first time a closed shell ion is fragmented.