Open O2-AC opened 3 months ago
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.
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.
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.
Currently, the script sets
$XTBPATH
and$XTBHOME
, assuming that alsocrest
is delivered as part ofxtb
and thus present in those locations.However,
xtb
andcrest
have been split and are provided as individual tools, withcrest
relying on the existence of thextb
command. Therefore, when using the precompiled binary ofxtb
without havingcrest
in$XTBHOME
it would still be possible to callrunxtb -C crest some.xyz
, which would fail. In addition, even withcrest
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
inload_path_settings()
.