Hello, dear developers,
I appreciate the avo_xtb plugin for the semiempirical DFT method xtb.
However, the xtb program contains also Force Field method, GFN-Force-Field (GFN-FF) — xtb doc 2023 documentation , labeled as GFN-FF .
Would it be please possible to run also GFN-FF functionality in Avogadro 2 ?
Seems that the avo_xtb plugin is hardcoded only for the semiempirical GFN#-xTB method ?
Best,
Miro
You can add --gfnff to the field “Extra command line options for xtb” in the plugin’s configuration dialog and that seems to override the usual optimization method and use the force field instead. In my quick test, anyway 
I didn’t add GFN-FF to the list of methods in the plugin for a few reasons, one being that the plugin’s commands are collected under “semi-empirical QM” and it would then maybe be a bit misleading.
A second reason is that Avogadro’s built-in force field framework has GFN-FF already. Using that might be a better option for you, depending on exactly what you are looking for? I don’t quite know what you need to do in order to make GFN-FF actually available to choose - @ghutchis will be more help there.
I would potentially reconsider adding proper support, but I’d more likely pursue an alternative xtb interface for the force field framework.
Yeah, the better option might be the separate library: GitHub - pprcht/gfnff: A standalone library of the GFN-FF method. Extracted in large parts from the xtb program.
Hello,
thanks for the hint, --gfnff extra command helps.
This could be a quick workaround.
Instead of “semi-empirical QM” how about to have both of xtb, something like “SQM and FF of xtb external program” ?
Glad to hear it!
Well the main intention of the plugin is to provide a built-in semi-empirical method in the same way that PM6 and friends are so conveniently available in SPARTAN, and to be positioned very much in contrast to the force field methods as a distinct ladder on the rung with a fundamentally different model and better accuracy. So I’m not keen to muddy the waters too much, as it were, as it makes it less clear which tool should be used for which job.
Geoff did a fair bit of work to implement the force field framework as a nice abstraction around any and all force fields, and building on top of it further (e.g. enabling “live” optimization) is planned. So it wouldn’t make a lot of sense to implement GFN-FF support in the plugin as an alternative to the xTB methods instead of in the force field framework.
What I could do would be to add an interface between the plugin and the force field framework, so that the former could run calculations using GFN-FF via the plugin. At the moment though a plugin can only provide one “type” of functionality, so that would have to wait until after the intended (by me) redesign of the plugin API.
The other problem with that is that it’s kind of too slow anyway, because the FFF wants to get a gradient for every step which means loading the plugin and doing the file I/O and executing xtb for every step, which is inefficient.
Now that there’s even the standalone version of GFN-FF available that @ghutchis linked, a better approach would be to make use of that and get it nicely integrated with the FFF the same way that UFF soon will be.
I took out the Python scripts with the recent release - I need to clean them up a bit for a plugin, but maybe I’ll just create a GitHub repo for people to finish (e.g., adding a requirements.txt or whatever for xtb-python)
Currently that’s the main pre-requisite. If you have the xtb-python package installed, you can optimize with GFN-FF, GFN0, GFN2, etc.
@Miroslav_Ilias Out of interest – because I’m keen to understand what people want to use the plugin for – what’s your use-case here? Why is it that GFN-FF support in the plugin would be useful to you?
In particular I’m wondering:
xtb program itself?Hi @matterhorn103 ,
We are studying systems like this https://www.tandfonline.com/doi/full/10.1080/00268976.2023.2293229 . For that, we need quick structure preoptimization.
Avogadro 2 is good for drawing also periodic structures. Superheavies in the structure can be replaced by elements with Z<=86. Plus we need the periodicity.
GFN-FF method is working with periodic systems, as stated GFN-Force-Field (GFN-FF) — xtb doc 2023 documentation.
Working GFN-FF would make Avogadro2 perfect tool for periodic systems geometry preoptimization.
I would also welcome xtb with periodicity, but this does not work yet, it is functional only in DFTB+ (based on Periodic Boundary Conditions — xtb doc 2023 documentation )
PS: Also, I am writing teaching text on molecular modelling, so I am testing current Avogadro 2 functionalities. Here xtb working for molecular calcs is welcome.
Periodic structures can be optimized with the GFN-xTB methods too, though?
Yes, but outside xtb, Periodic Boundary Conditions — xtb doc 2023 documentation.
I believe the docs are simply out of date on that point, tblite was integrated into xtb two years ago.
Briefly testing myself, optimization of periodic structures is definitely possible with the original GFN-xTB. I can’t get it to work with GFN2-xTB (though the issue for it was closed a long time ago, so you’d think it ought to be supported).
From what I can tell the support for PBCs with GFN-FF then actually came later, in xtb 6.7.0.
Certainly xtb is happy to read geometry files with periodic structures.
I had the plugin set up to run calculations on periodic structures prior to v0.5, I think with --gfn 1.
Ok, no, you can use GFB2-xTB with PBCs as well, you just have to enable the tblite backend with the --tblite flag.