Spin-polarized xTB in ASE calculator about tblite HOT 5 CLOSED

Yes, the changes are limited to the ASE calculator. I would only activate two spin channels if explicitly requested. This could be done by adding an option for this or creating a new method called spGFN2-xTB which is translated internally to GFN2-xTB with spin polarization.

from tblite.

Thanks for the interest. The addition of interactions is currently not forwarded in the ASE calculator. If you like to propose an API for this, you are welcome to send a patch.

from tblite.

Great, I will try to do so. The new spin polarization features don't seem to be in the docs but I'll go through your commit to follow the logic.

from tblite.

@awvwgk: I see that there is currently the ability to do Calc.add("spin_polarization") to activate the spin polarization.

With that being said, it seems like the only change that really needs to be made is in the tblite.ase.TBLite class, correct?

In this case, it seems like adding spin_polarization: bool = False as a parameter would be wise. However, a question remains: by default, if the Atoms object has magnetic moments or uhf is set to indicate unpaired electrons, do we auto-set spin_polarization as well? This would be a breaking change but at the same time is perhaps what a user might expect. I'm interested to get your suggestions on this.

On an unrelated side-note, I see that charge has a float type-hint throughout. Is this correct, or should it be int like uhf?

from tblite.

I suppose if the spin polarization is only applicable for GFN2, then having an option called spin_polarization might be misleading. In that case, it might make more sense to define a new method like you suggested.

Only downside: If there is ever a GFN3, GFN4, etc though then that means there would need to parallel methods for those in the future, which could get clunky. The alternative is to use a spin_polarization kwarg and raise a NotImplementedError if spin_polarization is used with an incompatible method.

from tblite.