Feature suggestion - ALPB (or other) solvation component in UMA script

[leforesb]

Hi,

As suggested on the ORCA forum, opening this issue ticket to suggest the implementation of a solvation correction component to the UMA energies and gradients. See the corresponding forum post here.
I have implemented that on my side working on a script for ORCA 6.0.1 last month, adapted now to ORCA 6.1.0. But as i now see scripts here already exist, I wanted to avoid creating confusion with duplicates.
See the scripts and (short) documentation at my github at https://github.com/leforesb/ORCA_wrapper_UMA/.
They are perfectly functional and tested across Opt, OptTS, NEB, MD, Numfreq and GOAT calculations, but perhaps the implementation present on this repository is a better way to package all that.

Similarly to the ones already present here, there is a server side and a client side. The solvent correction is only done on the client side by launching xtb twice, in solvent and in vacuum, then the difference on energies and gradients are calculated and added to the UMA energy and gradient.

Anyway, feel free to have a browse and implement a similar correction here. Perhaps not limited to ALPB actually, GBSA is accessible through a simple keyword change in the xtb command line after all.

Let's have fun with this :)

Baptiste.

[maburs]

Hi, thank you very much for suggesting this feature, maybe @cplett can have a look on the best strategy to include this.

Best

Markus

[cplett]

Hey Baptiste,

Thank you very much for the suggestion. Combining an xtb solvation contribution with UMA sounds like a great feature!

It would be fantastic if you could open a PR with your UMA scripts so we can include them in the orca-external-tools repository. To avoid confusion with the existing scripts, I’d suggest giving them a distinct name. Something with uma_solvation would be ideal.

Also, if you could include a brief README with some basic documentation, that would be very helpful.

Christoph

[stgeo]

@cplett I agree that a simple PR into a new directory is probably the fastest way to include this feature, but eventually we should combine the two UMA/fairchem wrappers - no point having both, since the architecture is also very similar. We should however see if Baptiste's choice of socket/socketserver/multiprocess is more efficient/robust/portable than waitress+Flask/requests/threading used in the current UMA and AIMNet2 wrappers.

We probably need to refactor a lot of the wrappers anyway to remove code duplication, so maybe this deduplication could also wait until after the feature is merged, but that might also be more work than refactoring first (and possibly changing the server/client packages) and then plugging in the xtb call.

[cplett]

Good point. We should definitely look into whether the socket/socketserver/multiprocess is a better approach than the one currently implemented.
As for the two separate wrapper scripts, the original plan was to merge them during a future refactoring. However, including the solvation feature directly into the current scripts now might be a better idea to retain a clear structure.

[leforesb]

Sorry for the delayed response. I think you guys are better suited than I at evaluating the robustness of either of these approaches. I just trialled and errored my way through the script until it worked robustly on our cluster here.
Although bear in mind that the workers spawn architecture in my scripts stem from an initial attempt at making the server side carry out the xtb calculations through tblite, but there were some issues with that approach in the case of numfreq calculations and occasionally GOAT calculations. Cases where I believe near simultaneous requests are made to the server and that's what is creating the issues. In all cases I seem to recall the UMA/fairchem part of the script was fine, the tblite/xtb calculation would randomly fail. My first guess is that some part of the tblite code is not completely thread safe. Maybe also an error on my part of course. Calling the xtb binary directly and on the client script's side solved that issue anyway.

Also, my script assumes an already present and working installation of ASE/fairchem, which requires separate login with credentials anyway but perhaps that makes it less accessible to the general user. It does remove the need to create the environment every time the script is launched. There may be a better solution to get the best of both worlds.

Last point, I believe the existing script always listens on the same default port. It might be beneficial to implement a way to randomly go to different ports; the model is fast enough that it's now tempting to run many concurrent jobs on a single node, and servers won't start if they all try to go for the same port. I have a crude solution to that using the slurm job ID that works

TLDR: my spawned workers architecture might be overkill, but may or may not become relevant with, say, the future implementation of g-xtb through tblite?

In any case, I don't plan on removing the scripts or the README from my github and they'll remain available there as they are now. I'd be perfectly fine with the feature being added to your existing implementation, especially if you care about consistency across different wrappers.