issues with xtb-torsiondrive

[selimsami]

@xiki-tempula I am trying to use the xtb-torsiondrive interface and I'm having some issues/questions:

• The correct version of the torsiondrive only seems to be available in a specific branch of your company's github. Is there a way to make this more available? Perhaps include it as a requirement for Q-Force? I saw that you already submitted a PR - maybe one could insist on this a bit?
• Is there a way currently to do QM single point or geometry optimizations on torsiondrive geometries? I have not managed this.
• I believe we should add dihedral_scanner to the _method list. Currently I'm having issues that if I have already scan output files in my directory and then I switch to xtb-torsiondrive, it tries to read my Gaussian output as Torsiondrive.
• How difficult was it to implement Torsiondrive for xTB? I'm thinking it might make sense to do this for GROMACS as well - so that the QM vs MM comparison is fair.

Thanks!

[xiki-tempula]

The correct version of the torsiondrive only seems to be available in a specific branch of your company's github. Is there a way to make this more available? Perhaps include it as a requirement for Q-Force? I saw that you already submitted a PR - maybe one could insist on this a bit?

I have sent the author a email when I submit the PR but got no reply. I was hoping that it will get merged soon but I guess this might be problematic. I have pinged the author again in the PR.
We could do
torsiondrive @ git+https://github.com/Exscientia/torsiondrive.git@xtb in https://github.com/selimsami/qforce/blob/master/setup.cfg

Is there a way currently to do QM single point or geometry optimizations on torsiondrive geometries? I have not managed this.

Sorry, I wonder what do you mean by QM single point or geometry optimizations on torsiondrive geometries?
Do you mean a QM single point on the geometry optimised structures?

How difficult was it to implement Torsiondrive for xTB? I'm thinking it might make sense to do this for GROMACS as well - so that the QM vs MM comparison is fair.

Do you mean like implement the Gromacs engine for the Torsiondrive?

[selimsami]

Sorry, I wonder what do you mean by QM single point or geometry optimizations on torsiondrive geometries?
Do you mean a QM single point on the geometry optimised structures?

Yes, right now with xtb-torsiondrive, we have to use xTB energies - but this might not be great. One could take structures torsiondrive have chosen and do either single point or opt QM calculations on them.

Do you mean like implement the Gromacs engine for the Torsiondrive?

yes

[xiki-tempula]

@selimsami

Yes, right now with xtb-torsiondrive, we have to use xTB energies - but this might not be great. One could take structures torsiondrive have chosen and do either single point or opt QM calculations on them.

I think we had this discussion in #39 where it is unclear what is the best way to set API. If the API is there, the implementation for ORCA should be pretty easy.

Do you mean like implement the Gromacs engine for the Torsiondrive?

If we have the "correct" Gromacs topology file, the implementation shouldn't be difficult.
The issue is that we did Torsiondrive before the fitting of dihedral so the geometry optimisation will be based on the "wrong" topology, which will give us wrong results.

[selimsami]

I think we had this discussion in #39 where it is unclear what is the best way to set API.

Aha... I will have to think about this then :-) I have some plans to add more "stages" to qforce, maybe in that scheme it will be easier.

If we have the "correct" Gromacs topology file, the implementation shouldn't be difficult.
The issue is that we did Torsiondrive before the fitting of dihedral so the geometry optimisation will be based on the "wrong" topology, which will give us wrong results.

I don't mean changing the QM torsiondrive in any way. But additionally performing torsiondrive-MD calculations instead of the relaxed scan that we are currently doing.

[xiki-tempula]

Aha... I will have to think about this then :-) I have some plans to add more "stages" to qforce, maybe in that scheme it will be easier.

Just ping me when you got this sorted and I could add ORCA.

I don't mean changing the QM torsiondrive in any way. But additionally performing torsiondrive-MD calculations instead of the relaxed scan that we are currently doing.

I think in this case, it is a chicken and egg issue. We do the torsiondrive-MD because we want to get the correct MM topology.
To get the correct torsiondrive-MD result, we need the correct MM topology, which I don't think we have after QM hessian.

[selimsami]

I think in this case, it is a chicken and egg issue.
To get the correct torsiondrive-MD result, we need the correct MM topology, which I don't think we have after QM hessian.

That's why we have iterations for the dihedral scan :-) conceptually nothing changes right? only the MD relaxed scans would be replaced with MD torsiondrive scans.

I am still not 100% sure this is a great idea - but just wondering about it.

[xiki-tempula]

@selimsami I can see your points now.

Originally we did QM hessian first, then we did the relaxed surface scan, then we got the topology.

The aim of the relaxed surface scan is to get a series of sensible geometries where the torsion of interest has been changed. My original question is whether the MD topology that we got before the dihedral scan is good enough to give us sensible geometries.

The argument is that even if in the first round the MD topology is not good enough to get the sensible geometries. If we do this many times, the MD topology will become good enough.

I can see that this could work but I'm not too convinced that this is the best possible way.

With regard to the implement the Gromacs engine for the Torsiondrive, you could check my PR lpwgroup/torsiondrive#74, it is just 100 lines of code.