XTB updates#250
Conversation
|
At least one test of pysis is failing now. I will collect them and figure out what to do :) |
|
I just spent half of yesterday packaging these also, good job; one slight concern on my end was that even though everything compiled; generating the python libs ended up failing the checks with which made me doubt their lib-export setup; will try again against your tree |
There are 4 mismatches between atoms and None type errors now in pysisyphus now. Thus, unfortunately not only numerical deviations. I will talk with @eljost what to do. @ryanswrt cool that you find it useful! 😊 I haven't even attempted to build the tblite python bindings, only xtb-python and this is already not the greatest experience. The previous version (before this MR) needed to copy shared object files manually into the proper places as the meson instructions were broken. |
|
@ryanswrt I was able to build the tblite python bindings. Seems to work from a python3 shell. |
|
pysisiphus fails on Hydra: |
Yup, these are the exact four errors we also get. (See #250 (comment)). Working on it ... |
|
The failing tests are quite strange. They are complete numerical nonsense when run as is. Interestingly this does not seem to happen with the statically linked executable from the XTB repo. Now, even more interestingly, the problem only happens when Here is one of the examples that fails in pysisyphus:
It runs perfectly fine without |
|
Is it built with the |
Hm, couldn't find anything like it in the cmake flags |
|
Meh, here we go, even happens when completely following the toolchain of upstream XTB. That is, it even happens when building in a plain debian pod with fully embracing the cmake build system and building everything with buildtime downloads of deps. So sudo apt install gfortran cmake build-essential git libopenblas-dev
git clone https://github.com/grimme-lab/xtb.git && cd xtb
cmake -B build -DCMAKE_BUILD_TYPE=Release
make -C build
make -C build testIn this case tblite also fails one test. Anyway, the behaviour is exactly the same. I would consider this an upstream bug. Should we open a bug report? |
That would be good.
It could potentially also be a dependency of XTB that is built with |
I have checked in tblite, mctc-lib and mstore. There were none. |
|
With the tooling for XTB in place, major parts of the DFTB+ infrastructure is also here. I've added those packages, also. This is unrelated to the numerical XTB problems, of course. |
|
I have removed the |
|
Even more: outside of the sandbox omitting the |
|
For the moment I would assume that the XTB fix could take some time. The behaviour is rather strange, depends on fortran optimisation level, does not happen with IFort, is sensitive against parameters that have nothing to do with the actual calculation and so on. On a sidenote: Do you know why the flang compiler is not part of the llvm packages in nixpkgs? It would be quite interesting to see if FLang would give an executable with correct behaviour. |
We can wait a little for a proper fix?
I would guess that Fortran is not popular enough in the Nix community. No one just made the effort yet? Integrating compilers into the nixpkgs is no easy task. |
|
OK, let's wait then until we know more.
It does unfortunately not help. On Debian I've used Debian's gfortran 10.2.1 and the issue is the same.
Hm, actually just found NixOS/nixpkgs#163878 |
|
The bug has been fixed upstream and I could build pysisyphus without errors now. Should be ready :) |
dftd4: blas lapack ILP64 assertions
multicharge: blas lapack ILP64 assertions
simple-dftd3: blas lapack ILP64 assertions
tblite: fix meta
xtb: blas lapack ILP64 assertions
xtb: use final patch version
tblite: blas lapack ILP64 assertions
fypp: remove leftovers
mpifx: remove leftovers
scalapackfx: check for ILP64 scalapackfx: blas lapack ILP64 assertions
dftbplus: blas lapack ILP64 assertions
pysisyphus: fix xtb patch pysisyphus: remove xtb workaround again
3 participants
There is a new major release of the XTB programme. The surrounding infrastructure grew somewhat and XTB depends now on a lot of fortran libraries. The Fortran package manager seems to bring a modern build experience and package management to Fortran, finally ... :) However, I am a little bit worried about all the updates these many packages will require. Maybe we should also look into something like r-ryantm's automatic update bot. 😅
Also nearly all of them did some cmake mistake and require patching of the generated package-config files. At least the fix is quite easy.