allow different install locations of xtb and crest

[O2-AC]

Currently, the script sets $XTBPATH and $XTBHOME, assuming that also crest is delivered as part of xtb and thus present in those locations.

However, xtb and crest have been split and are provided as individual tools, with crest relying on the existence of the xtb command. Therefore, when using the precompiled binary of xtb without having crest in $XTBHOME it would still be possible to call runxtb -C crest some.xyz, which would fail. In addition, even with crest installed, the script would fail if run remotely. It would only run locally, if, and we should not assume this, crest is in $PATH.

The location of the crest executable (it is shipped as single binary) could be simply be part of the config file and be exported to $PATH in load_path_settings().

[polyluxus]

Yes, the script assumes that the crest binary is set-up along xtb in the same bin directory. This is basically a prerequisite since this is the way I described it in the installation guide.

The part about failing when run on queue is something I need to look into some more.

[O2-AC]

Fair enough. Should've read the installation guide...

It'll then not fail on queue, as crest is in $XTBHOME. I had my system configured differently, with crest being in my own defined $PATH and as such not available when running on compute nodes. Feel free to close.

[polyluxus]

I'm still thinking about it.

From the point of view that the versions do diverge, it'd be easier (and totally makes sense) to actually maintain these installations separately. As you would with modules, too.

I had a look at the fail condition in the produced submission script. It's not really satisfying either and should produce a real error when quitting. So it is worth thinking about it.