On 04 Aug 2014, at 18:52, Johannes Ring <[email protected]> wrote:

> On Fri, Aug 1, 2014 at 9:54 PM, Mikael Mortensen
> <[email protected]> wrote:
>> 
>> On 01 Aug 2014, at 21:48, 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?
>> 
>> 
>> Johannes has been using hashdist/hashstack on Abel, but I don’t really
>> understand it. So I guess the smart thing to do right now is just to wait
>> for the build engineer himself to comment and I think he’s on vacation.
> 
> I have built fenics-dev on Abel and you can use it by running
> 
>  source ~johannr/fenics-dev.abel.gnu.conf

Great, that’s all I needed, thanks:-)

> 
> If you want to build your own copy of dolfin-dev, I can tell you how
> to do that with HashDist later.

Looking forward to it.

Mikael

> 
> Johannes
> 
>> Mikael
>> 
>> 
>> 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