TURBOMOLE support?

[mkrompiec]

Any plans for supporting TURBOMOLE? For GGAs and density fitting, TURBOMOLE is probably the fastest code available...

[leeping]

Hello Michal,

I'd be happy to support TURBOMOLE, but the last time I used it was almost 10 years ago as a graduate student. I currently don't have time to write the code to make a good interface, but if you could contribute any codes I'd be glad to work with you on merging it.

Thanks,

• Lee-Ping

[eljost]

I got a fully working TURBOMOLE wrapper in my own code (https://github.com/eljost/pysisyphus/blob/dev/pysisyphus/calculators/Turbomole.py) that supports dscf/ridft/grad/rdgrad/egrad/ricc2 and can parse energies and gradients.

The class basically needs a path to a TURBOMOLE calculation that is already set up (control, basis and so on) and works from this directory, reusing old orbitals and so on. The actual calcuations are run in a TEMPDIR, so the original files don't get overwritten.

Depending on the featureset you need (hessians?) I could try to refactor the class for the use in geomeTRIC (dervied from Engine and so on ...). The parsers are implemented with pyparsing (https://github.com/eljost/pysisyphus/blob/dev/pysisyphus/calculators/parser.py), so this would be an additional dependency ... I guess it would be possible to drop pyparsing and reimplement the relevant parts using only regular expressions.

@leeping, what is your though on this?

[dgasmith]

We have been attempting to consolidate Engine into the MolSSI project QCEngine which provides a consistent interface to a number of codes. It would be great to steer you in this direction so that in general we can:

1. Keep these drivers located in a central place and build off the work of others.
2. Have an organization like MolSSI be the long term keeper of something like this to ensure continued maintenance.
3. Have a uniform IO so that you can quickly switch to new codes.

We would be very happy to help you get this into to QCEngine!

[mkrompiec]

@eljost it would be great if you could interface your code with geomeTRIC, perhaps through QCEngine. However, won't the requirement for having a set-up calculation violate the principle of having a uniform interface (independent of actual compute engine)? Just a thought. BTW, what I actually need is to be able to use TURBOMOLE in TorsionDrive, so perhaps the fastest way forward is to write a quick and dirty "native" TorsionDrive interface.

[leeping]

Hello @eljost and @mkrompiec ,

Thanks for the nice discussions. I strongly support the QCEngine project and I think the best solution for a geomeTRIC-TurboMole interface would be to have TurboMole supported by QCEngine, then I think everything will work on the geomeTRIC side of things. You would also benefit by having the codes maintained by MolSSI and use TurboMole in everything the QCArchive can do (including but not limited to torsion drives). If you're okay with this, then I imagine the next steps would be that @dgasmith would work directly with you to develop this feature.

I agree with you that another way to run these calculations is to write a "native" TorsionDrive-TurboMole interface. In a separate case, a collaborator has done this for Gaussian because we did not want to inadvertently create any impression that we were making comparisons with its native geometry optimizer. I doubt this would be any easier than writing a geomeTRIC interface, because the TorsionDrive interface would require setting up and running a constrained geometry optimization, whereas the geomeTRIC interface needs a single-point gradient calculation. To me, the single-point calculation sounds easier. Please let me know what you decide.

Thanks,

• Lee-Ping

[eljost]

So the idea would be to implement the TM-interface in MolSSI/QCEngine then I guess. I'm ok with this.

[eljost]

So the Turbomole wrapper is now merged into QCEngine master...

[leeping]

Are you able to run optimizations through the QCArchive ecosystem now?

I actually don't know how to use QCEngine outside of QCArchive and I'm not sure if it was designed to work that way. @dgasmith might have some useful suggestions.

[jthorton]

Just wondering what the progress of adding Turbomole is? Also @leeping and @dgasmith, would it be suitable to move the other qm interfaces to use qcengine as well?

[dgasmith]

Turbomole has been integrated, we should try a few runs to make sure it works for you. In general, I suggest adding to QCEngine as the goto place for building out additional functionality.

[leeping]

Hello Josh,

I'm open to implementing additional functionality into QCEngine and to duplicate all of the functionality in the existing Engine classes in QGEngine. As the existing Engine class is used by my group and possibly others as well, I think we should keep them.

• Lee-Ping

[leeping]

Closing this issue because there are no needed development tasks. To use Turbomole with geomeTRIC, it is recommended to use the interface to QCEngine.