-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I remember that at some time there were incompatibilities between the at that time current versions of two packages that PETSc both could use and that at that time you had to use the versions that PETSc tried to download. In the beginning I also tried to install the packages that I wanted to be used by PETSc seperately (it was before I even had heard of easybuild, and on BlueGene/Q we still do not use easybuild) and I always had troubles with compatibility. Thus I decided to only use download ... except for the MKL things. I only install the static version of PETSc, thus no problem with LD_LIBRARY_PATH finding the wrong packages. The only poblem I have is with our easybuild head, he thinks that it is bad to have so many versions installed, with and witout debug, with and without 8-Byte integer and with and without complex numbers as default. I use the petsc easyblock and just add the - --download... options as configopts for example
'--with-large-file-io --download-hypre=1 --download-metis=1 - --download-parmetis=1 --download-spooles=1 --download-superlu=1 - --download-superlu_dist=1 --download-mumps=1 --download-spai=1 - --download-chaco=1 --download-sundials=1 --download-triangle=1 - --download-parms=1 --download-hdf5=1' and that works. Inge On 02/22/17 07:53, Åke Sandgren wrote: > > > On 02/22/2017 03:40 AM, Maxime Boissonneault wrote: >> Thanks Robert, While I understand and am all in favor of reusing >> dependencies, most packages with dependencies do not provide >> download hooks for specific versions of their dependencies. PETSc >> is this way, I believe OpenFoam too. When the developers go >> through this trouble, I prefer to assume that they know what they >> are doing and test with specific versions of > > Unfortunately they rarely do (when it comes to HPC systems and > performance issues at least), they just know that the ordinary > user knows even less and try to make it easy for them. > >> the dependencies. If a user finds a bug, it will be that much >> simpler to diagnose if it uses the same versions as the >> developers. > > The main reason i see for NOT letting codes like PETSc do their > own download and build of sub dependencies, is that those > dependencies will not be built in the best way, i.e., they will be > suboptimal in speed and sometimes even buggy. > > But it is always a question of how much time do you have to keep > things in sync and updated... > > I usually prefer to build and test myself and then force PETSc > et.al. to use what i already have. But lately the rate of incoming > software requests for new stuff has been climbing through the roof. > The curse of having a brand new system with lots of toys... > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJYrTljAAoJEAMTTHwPbmtKeksQAJ9hF14qOmmPT0q/A3kWPsiK RWWNRu9cwFYoZNnRyICF56uFndxaRUYwqe3LopuCOb38Nn/U4ZLvwZ6bl0tXWLZD YoAYxfTdmSByEmqI97Lo7qWclijn4C1bCCpDvN3llYigy6Tmkrn8WCS5HcWCKgis AX2bl2IvTcvJgBuQsAro0AMgXjS2Vg8QbwgYVsEV4AjtDyCCnjpm2JPsUVdueZ/V 05I7zWgXkQXvSxMUJGQwTRmhi7LQbrFV4Rq77sk0xMpGdQRC29QHyxVA1WdbpNdG MmCZ/LCODofLt/AWpeFgXkfTjBNm+/UeRQ+HRtWsn9oif/7dnJA6XmpfD+4FLI99 XQ/lp/kHtvoRfh8AL4oRMhS/tu2JP9kMbmD+8nON49zQejj1Hns2G3yBzRGrSbzY s3Vqlw2foHkLlYFRBGZGCIwF3VP2EyFj5khYwdb8OMLGS3yRPTrNVROWkIqDkUlZ c/AGp7BPKPK5XZ0ObKJk52CMytsPYcc59C0kkCy7WCxwZaiyms6yuCDn/05Cfay2 R1HGKAtdpWjQ21nWgdI9x0mrwVv7X/OkniSxVvfKRdwOHdJO2xZ5w5bxtZ83wTrQ TI1w1Gq3P7QHKXnA2p2emVdCoNqjNrRnY+B+sQfJ95FNSecxXNcD4g6UnS+uvGwF /rceMXkzuruU74tuuvH7 =Bv6i -----END PGP SIGNATURE----- ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------
