Periodic support in ASE calculator

[rlaplaza]

Hello,

I was trying to use the ASE calculator in PBC with XTB using the GFN0-xTB parameters, which seem to work OK for the systems that I am studying.

The ASE calculator is, as far as I understand, not supporting such info because the cell and pbc info in the Atoms object are not parsed, but should be quite straightforward to pass to the underlying Calculator that connects with the XTB API. Actually, this seems to work if I do it directly with a simple wrapper.

I wondered why (if there is a reason) this has not been done yet. I might do it myself, which I guess would only require a bunch of pure python in the ASE calculator file.

I might also want to have a verbosity flag passed to the ASE calculator so that it is not actually mute, because sometimes I might care about the outputs of the XTB part. Again, does not seem to be a lot of work and I could do it myself by passing a verbosity attribute in the Atoms object. Does that seem reasonable?

In any case, thank you and the group for this mighty, mighty effort.

[awvwgk]

The setup of the xtb API objects is currently done here:

xtb-python/xtb/ase/calculator.py

Lines 188 to 206 in fdaa42b

	_cell = self.atoms.cell
	_periodic = self.atoms.pbc
	_charge = self.atoms.get_initial_charges().sum()
	_uhf = int(self.atoms.get_initial_magnetic_moments().sum().round())
	calc = Calculator(
	_method,
	self.atoms.numbers,
	self.atoms.positions / Bohr,
	_charge,
	_uhf,
	_cell / Bohr,
	_periodic,
	)
	calc.set_verbosity(VERBOSITY_MUTED)
	calc.set_accuracy(self.parameters.accuracy)
	calc.set_electronic_temperature(self.parameters.electronic_temperature)
	calc.set_max_iterations(self.parameters.max_iterations)
	calc.set_solvent(get_solvent(self.parameters.solvent))

I thought I managed the periodic case as well by passing the cell object, but I may be mistaken.

Also, feel free to share any improvements to the ASE calculator.

[rlaplaza]

I was wrongly assuming stuff.

The passing seems to be proper, but atoms near the PBC borders experience weird forces (as described in grimme-lab/xtb#257 ), which sometimes lead to immediate segfaults on the xtb side (think about explicit solvent more than solid state stuff, which is more well-behaved). In this sense, I think the possibility of passing other verbosity settings to the ASE calculator is desirable (e.g. this), as it was very revealing in this case.

I think the GFN0-xTB hamiltonian has some symmetry issues. The activation energy of my rusty Fortran coding skills is too high for the time being, but I am pretty sure that simulations with xtb 6.2 did not have this issue, so the key diff might be in between. I'll test more thoroughly.

On that note, I wonder whether you guys feel like this is a priority for the team at the moment or the whole PBC issue is "not urgent".

[awvwgk]

On that note, I wonder whether you guys feel like this is a priority for the team at the moment or the whole PBC issue is "not urgent".

Sorry, “the team” is mostly just me and I currently can't say when I'm able to allocate the necessary time to focus on the PBC implementation again.

[rlaplaza]

Just a quick update: it's definitely still breaking in 6.2.0, therefore its a more intricate thing for sure. Whenever you tackle it, let me know and I'll try to help with testing and examples.

Sorry, “the team” is mostly just me and I currently can't say when I'm able to allocate the necessary time to focus on the PBC implementation again.

You are doing a great job! Courage!

[rlaplaza]

Some tests for the record, all with the GFN0 hamiltonian:

• In XTB 6.2.0, displacing a geometry wrt the cell does not result in changes in the initial gradient, but somehow does result in different optimizations. There must be some instability in the optimizer(s) in this version. See attached files in xtb-6.2.0_tests.tar.gz (initial gradients, gradient norms and optimization logs). Note how the optimization is fine in the first cases because the displacement is small and no atoms approach the boundary.

• In XTB 6.3.3, displacing a geometry wrt the cell does result in changes in the initial gradient as atoms approach the boundaries. The difference seems to be in the dispersion term. Hence, the instability is now at least in the forces; cannot determine if the optimizer is fixed.

xtb-6.3.3_tests.tar.gz

xtb-6.2.0_tests.tar.gz

Thus, i'd say that some of the updates between 6.2.0 and 6.3.3 messed up something in the dispersion term for this hamiltonian at least. As there was a bugfix before, i'd say that the bugfix has a bug itself. The optimizer issue, tho, I have no idea.