On Fri, Aug 1, 2014 at 9:48 PM, Jan Blechta <[email protected]> wrote:
> On Fri, 1 Aug 2014 20:23:04 +0100
> "Garth N. Wells" <[email protected]> wrote:
>
>>
>> On 1 Aug 2014, at 19:54, Mikael Mortensen
>> <[email protected]> wrote:
>>
>> > Thank you both for the tips. I’ll look into it some more. BTW, do
>> > you create your own modules for all dependencies Garth? The module
>> > system is used on our cluster, but I have never tried to create
>> > modules of my own.
>> >
>>
>> I haven’t done it, but have seen colleagues do it for FEniCS (on
>> workstations and on clusters). It’s easy.
>
> Yes, that's like a fenics.conf file but just in different language. And
> it may handle dependencies.
>
> But creating a module does not resolve these linking problems. You
> should solve there an original issue - FEniCS stable and libraries
> (which could be reused) are installed in the same place.
>
> Currently we are thinking here in Prague before ugrading to Ubuntu
> Trusty how to handle installation and usage of packages. Our homobrewn
> system written in Make is getting out of hands with growing number of
> different PETScs, FEniCSes, BLAS, debug/nodebug combinations... Not
> talking how to handle smart pulling dev versions by pushing a button.
>
> We've heard about hashdist https://github.com/hashdist/hashdist,
> https://github.com/hashdist/hashstack. I think Johannes is somewhat
> involved. Do you have some experience with this?

Yes, I have been working on HashDist [1] for a while and I hope it can
replace Dorsal for building FEniCS in the not so distant future.

[1] https://hashdist.github.io

Johannes

> Other alternative seems to be http://hpcugent.github.io/easybuild/.
>
> Jan
>
>>
>> Dorsal should create module files.
>>
>> Garth
>>
>>
>> > Best regards
>> >
>> > Mikael
>> >
>> > On 01 Aug 2014, at 18:20, Garth N. Wells <[email protected]> wrote:
>> >
>> >> Use the 'module' system to support multiple installations on a
>> >> cluster.
>> >>
>> >> Garth
>> >>
>> >> On Fri, 1 Aug, 2014 at 3:36 PM, Jan Blechta
>> >> <[email protected]> wrote:
>> >>> On Fri, 1 Aug 2014 16:16:38 +0200
>> >>> Mikael Mortensen <[email protected]> wrote:
>> >>>> Hi,
>> >>>> I'm trying to install master version of fenics on top of a stable
>> >>>> version installed by Johannes on the Abel cluster. Johannes has
>> >>>> more or less everything, including dolfin, installed under
>> >>>> /usit/abel/u1/johannr/nobackup/src/hashstack/default/, which is
>> >>>> on my path. The stable version here works just fine. I now want
>> >>>> to use all the dependencies here and build a master version, so
>> >>>> I'm using dorsal with unstable for fiat/ffc/ufl/instant, and
>> >>>> install in my own folder. I then clone dolfin in a different
>> >>>> directory and run cmake.local. It stops at
>> >>>> MultiMeshAssembler.cpp because for some reason it picks up ufc.h
>> >>>> from the stable and not the unstable branch, even though the
>> >>>> unstable is sourced last. From my .bashrc:
>> >>>> source /usit/abel/u1/johannr/fenics-1.4.0-gcc.conf  # stable
>> >>>> everything
>> >>>> source /usit/abel/u1/mikaem/Fenics/fenics-1.4/share/fenics/fenics.conf
>> >>>> # unstable fiat/ffc/ufl/instant/ufc.h With some hacking of paths
>> >>>> I am able to fix MultiMeshAssembler and everything compiles just
>> >>>> fine. However, the python version still does not work and I find
>> >>>> that it is because the module-libraries are picking up the
>> >>>> stable dolfin version. Here is ldd of dolfin/cpp/_common.so:
>> >>>> [mikaem@login-0-0 ~]$ ldd
>> >>>> /usit/abel/u1/mikaem/Fenics/dolfin/local.master/lib/python2.7/site-packages/dolfin/cpp/_common.so
>> >>>>    linux-vdso.so.1 =>  (0x00007fff7816d000)
>> >>>>    libdolfin.so.1.4 =>
>> >>>> /usit/abel/u1/johannr/nobackup/src/hashstack/default/lib/libdolfin.so.1.4
>> >>>> (0x00007fb14c5ee000)
>> >>>>    libpython2.7.so.1.0 =>
>> >>>> /usit/abel/u1/johannr/nobackup/src/hashstack/default/lib/libpython2.7.so.1.0
>> >>>> (0x00007fb14c1e7000)
>> >>>> ...
>> >>>> Evidently _common.so has picked up the stable libdolfin.so.1.4.
>> >>>> Any hints at how this can be fixed? An alternative I don't like
>> >>>> is to give up Johannes' dependencies all together and install
>> >>>> everything for myself.
>> >>> You should not use Johannes' fenics.conf, it probably sets
>> >>> LD_LIBRARY_PATH. Linker can't distinguish between stable and
>> >>> unstable as they have same name libdolfin.so.1.4. Rather you
>> >>> should tell to DOLFIN's CMake about all the dependencies which
>> >>> you want to use from Johannes. Or maybe try a little bit messy
>> >>> solution, keep the build you have and then get rid of Johannes'
>> >>> LD_LIBRARY_PATH in your own fenics.conf a check what linker says.
>> >>> Generally, it will be everytime tricky. You should convince
>> >>> Johannes to install dependencies you need separately from stable
>> >>> FEniCS. (You could simulate this with symlinks.)
>> >>> Jan
>> >>>> Thanks for any help.
>> >>>> Best regards
>> >>>> Mikael
>> >>> _______________________________________________
>> >>> fenics-support mailing list
>> >>> [email protected]
>> >>> http://fenicsproject.org/mailman/listinfo/fenics-support
>> >>
>> >
>>
>> _______________________________________________
>> fenics-support mailing list
>> [email protected]
>> http://fenicsproject.org/mailman/listinfo/fenics-support
>
_______________________________________________
fenics-support mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics-support

Reply via email to