Re: [moose-generic] MOOSE_installation_problem

[Vadim A <ast...@nc...>]

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