Discrepancy in density cube files generated by xTB & Multiwfn

[cisert]

Bug Description I noticed a discrepancy in the density cube files generated either directly with GFN2-xTB or with Multiwfn from the xtb-created molden.input file. Visual difference:

To Reproduce Steps to reproduce the behaviour:

1. happens with inputs: water.txt → rename to water.sdf (Github doesn't want .sdf) xtb.txt → rename to xtb.inp (contains density=True)
2. xtb water.sdf --input xtb.inp --molden --verbose
3. output xTB: xtb_std_out.txt density_xtb.txt (rename to .cub for visualization) molden.input.txt → rename to molden.input
4. Generate the density cube file using Multiwfn, starting from the molden.input file xtb generated, and using the same grid points: Multiwfn molden.input, then options 5 (Output and plot specific property within a spatial region) > 1 (Electron density) > 8 (Use grid setting of another cube file) > density_xtb.cub > 2 (Export data to a Gaussian-type cube file in current folder)
5. output Multiwfn: density_multiwfn.txt (rename to .cub for visualization)

Expected behaviour Same cube file.

Additional context

• awvwgk mentioned via email this could be related to the xTB-produced molden-file not being standardized, resulting in incorrect basis sets and orbitals in Multiwfn.
• The comment line of the xtb-generated cube file says "xtb spin/fo density” though I requested just the density.
• I've asked the same question here in the Multiwfn forum to determine whether the issue is on their side. Multiwfn explicitly states that they support xTB-generated molden.input files (see their changelog)

Software

• xtb version 6.3.1 (conda-forge) compiled by 'runner@Mac-1389.local', running locally
• Multiwfn 3.7

[cisert]

This discussion in the Multiwfn forum revealed that the xTB-generated electron density file appears to be missing the core electrons (see response #10), while Multiwfn adds those.