Re: [moose-generic] MOOSE_installation_problem

[Subhasis R. <ray...@gm...>]

Yes, the GCC compiled numpy should be in LD_LIBRARY_PATH and in the
makefile.




On Sat, Apr 6, 2013 at 11:22 PM, Vadim Astakhov <ast...@nc...>wrote:

> Hi.
> Our python is GCC not intell
> Only numpy was intell but we now install new numpy compiled by gnu. My
> question is should I add path to this new compiled numpy to your Make file ?
> Thanks a lot in advance for clarification.
>
> Vadim.
>
>
> Subhasis Ray <ray...@gm...> wrote:
>
> Dear Vadim,
>  I am not familiar with such cluster environment. But from what I gather
> on the Internet, it seems that the issue is possibly a mismatch of
> compilers and libraries. If your default compiler is intel, then loading
> python before gnu perhaps loads a Python compiled with intel compiler your
> default. Can you see if changing the order of loading modules helps? i.e.
>
> module load gnu/4.6.1
> module load python
> ...
>
>
> Also, you can run `ldd` on generated _moose.so to list the linked
> libraries and add the paths to the directories containing those libraries
> to your LD_LIBRARY_PATH environment variable.
>
> hth,
>   Subha
>
>
>
>
> On Sat, Apr 6, 2013 at 12:35 AM, Vadim A <ast...@nc...> wrote:
>
>> Hi,
>>
>> numpy has been compiled with gnu on our cluster and to access bumpy  we
>> do the following:
>>
>> module load python
>> module load gnu/4.6.1
>> export
>>
>> PYTHONPATH=/home/diag/opt/python2.7/gnulib/lib/python2.7/site-packages:$PYT
>> HONPATH
>>
>>
>>
>> Should I also adjust   Makefile for MOOSE  to make sure that proper
>> "numpy" library will be used during compilation step ?
>>
>> Thanks a lot in advance for information.
>>
>> Vadim.
>>
>>
>>
>>
>> On Mar 28, 2013, at 2:13 AM, Subhasis Ray wrote:
>>
>> > First please confirm that Python and numpy were also compiled with gcc.
>> >
>> > If so, then best option could be to allow somebody from here (niraj or
>> > me) to login to your system (via some portal as Amitava mentioned
>> > earlier in this thread) and run gdb as we cannot reproduce the error
>> > on our system.
>> >
>> > On 3/28/13, Vadim A <ast...@nc...> wrote:
>> >>
>> >>
>> >> On Mar 28, 2013, at 12:15 AM, Subhasis Ray wrote:
>> >>
>> >>> Hi,
>> >>> On 3/28/13, Vadim A <ast...@nc...> wrote:
>> >>>> When I compile, I always see lines with g++
>> >>>>
>> >>>>
>> >>>> g++ -g -pthread -fpermissive -fno-strict-aliasing -fPIC
>> >>>> -fno-inline-functions -Wall -Wno-long-long -pedantic -DDO_UNIT_TESTS
>> >>>> -DUSE_GENESIS_PARSER -DSVN_REVISION=\"4401M\" -DLINUX -DUSE_GSL -I
>> >>>> /home/diag/opt/gsl/1.15/gnu/include/    basecode/_basecode.o
>> msg/_msg.o
>> >>>> shell/_shell.o biophysics/_biophysics.o hsolve/_hsolve.o
>> >>>> randnum/_randnum.o
>> >>>> scheduling/_scheduling.o builtins/_builtins.o device/_device.o
>> >>>> kinetics/_kinetics.o ksolve/_ksolve.o regressionTests/_rt.o
>> >>>> utility/_utility.o geom/_geom.o mesh/_mesh.o manager/_manager.o
>> >>>> signeur/_signeur.o     -L/usr/lib -L/usr/local/lib -lpthread -L/lib64
>> >>>> -L/usr/lib64 -L/usr/lib -L/home/diag/opt/gsl/1.15/gnu/lib/ -lgsl
>> >>>> -lgslcblas
>> >>>> -lm -o moose
>> >>>>
>> >>>>
>> >>>>
>> >>>> That tells me that I am using g++ (which is gcc) but not Intel
>> compiler,
>> >>>> right ?
>> >>>
>> >>> Yes, moose is being compiled by g++
>> >>>
>> >>>>
>> >>>> So, I kind of confused what should I do here.
>> >>>>
>> >>>
>> >>> But what about Python libs? In your previous mail
>> >>>
>> >>> ----8<----------------->8---
>> >>> gdb -c core.8851 /home/diag/opt/python2.7/bin/python
>> >>>
>> >>> Reading symbols from
>> >>> /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_core.so...(no
>> >>> debugging symbols found)...done.
>> >>> Loaded symbols for
>> >>> /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_core.so
>> >>> Reading symbols from
>> >>> /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_sequential.so...(no
>> >>> debugging symbols found)...done.
>> >>> Loaded symbols for
>> >>> /opt/intel/Compiler/11.1/072/mkl/lib/em64t/libmkl_sequential.so
>> >>> Reading symbols from
>> >>> /opt/intel/Compiler/11.1/072/lib/intel64/libpdbx.so.5...(no debugging
>> >>> symbols found)...done.
>> >>> Loaded symbols for
>> /opt/intel/Compiler/11.1/072/lib/intel64/libpdbx.so.5
>> >>> Reading symbols from
>> >>>
>> /home/diag/opt/python2.7/lib/python2.7/site-packages/scipy/sparse/sparsetools/_coo.so...(no
>> >>> debugging symbols found)...done.
>> >>> Loaded symbols for
>> >>>
>> /home/diag/opt/python2.7/lib/python2.7/site-packages/scipy/sparse/sparsetools/_coo.so
>> >>> Reading symbols from
>> >>> /home/diag/opt/python2.7/lib/libpython2.7.so.1.0...done.
>> >>> Loaded symbols for /home/diag/opt/python2.7/lib/libpython2.7.so.1.0
>> >>>
>> >>> ----8<----------------->8---
>> >>>
>> >>> shows that several libraries from intel compiler are being loaded
>> >>> before scipy/sparse/sparsetools/_coo.so and libpython2.7.so.
>> >>>
>> >>> Did you compile Python in
>> >>> /home/diag/opt/python2.7/lib/libpython2.7.so.1.0 and/or numpy/scipy
>> >>> from source? In that case, did you use intel compiler to compile them?
>> >>>
>> >>> Though this could be red herring, I do not see any reason for the
>> >>> control to reach basecode/SetGet.h:289. May be a debugging session
>> >>> could help.
>> >>>
>> >>> Best,
>> >>>  Subha
>> >>>
>> >>
>> >>
>> >
>>
>>
>