ESyS-Particle

Problem with Esys-Particle installation

Asked by Yu

Hello, I tried to install Esys-Particle2.3 on Fedora.
I installed boost_1.55 and Python2.6 in /usr/local, and set environment variables in .bashrc:

export LIBRARY_PATH=/usr/local/lib/:$LIBRARY_PATH
export LD_LIBRARY_PATH=/usr/local/lib/:$LD_LIBRARY_PATH
export PYTHONPATH=/usr/local/lib/python2.6/site-packages/:$PYTHONPATH
export INCLUDE_PATH=/usr/local/include/:$INCLUDE_PATH

Then, I tried to install Esys in /root/esys-particle/ but I got following error.

sh autogen.sh
./confiugre CC=mpicc CXX=mpic++ BOOST_ROOT=/usr/local LDFLAGS=/usr/local/lib
make
...
...
.... so many /libboost_python.so: undefined reference to ' '....
/usr/local/lib/libboost_python.so: undefined reference to 'PyNumber_InPlaceAdd'
collect2: ld returned exit status
make[3]: *** [dump2geo] Error 1
make[3]: Leaving directory '/root/esys-particle/Tools/dump2geo'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/root/esys-particle/Tools'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/root/esys-particle'
make: *** [all] Error 2

There is /usr/local/lib/libboost_python.so linked to /usr/local/lib/libboost_python.so.1.55.0.
I also did
make uninstall
make distclean
before
sh autogen.sh
(although it is my first time to install Esys)
but the result was the same.

Will you give me any suggestions on how to overcome it?

Best Regards,

Yu

Question information

Language:
English Edit question
Status:
Solved
For:
ESyS-Particle Edit question
Assignee:
No assignee Edit question
Solved by:
Vince Boros
Solved:
Last query:
Last reply:
Revision history for this message
Best Vince Boros (v-boros) said : 		#1

Hello Yu.

Two things:

1/ I wonder if, from the line "/usr/local/lib/libboost_python.so: undefined reference to 'PyNumber_InPlaceAdd'", your libboost_python has been built with a version of Python other than 2.6. Since Python is used for so many things Linux systems install with a default version of it. Run "python -V", "which python" and "hash" to check version number and location. Also follow the instructions at https://answers.launchpad.net/esys-particle/+faq/1235 for bootstrapping the Boost install process, checking particularly that Python 2.6 shows in the output of booststrap.sh. (I'm assuming of course that you installed Boost 1.55 and Python 2.6 from source.)

2/ Is there more than one set of Boost libraries installed, for example a package installation in /usr/lib/? Is there any more information in the "make" output surrounding the line "so many /libboost_python.so: undefined reference to ' '"?

Can you also reply with some of the output from the ESyS-Particle configuration, specifically lines that look like this:

checking for Py_Main in -lpython2.6... yes
checking for Boost headers version >= 1.34.1... /home/vince/include
checking for Boost's header version... 1_52
checking for the toolset name used by Boost for mpic++... configure: WARNING: could not figure out which toolset name to use for mpic++

checking boost/system/error_code.hpp usability... yes
checking boost/system/error_code.hpp presence... yes
checking for boost/system/error_code.hpp... yes
checking for the Boost system library... yes
checking boost/filesystem/path.hpp usability... yes
checking boost/filesystem/path.hpp presence... yes
checking for boost/filesystem/path.hpp... yes
checking for the Boost filesystem library... yes
checking boost/python.hpp usability... yes
checking boost/python.hpp presence... yes
checking for boost/python.hpp... yes
checking for the Boost python library... yes

I am not at all sure that either 1/ or 2/ are the problem, because of your PYTHONPATH settings and the fact that "make" found /usr/local/lib/libboost_python.so. Perhaps an incompatibility has crept into Boost 1.55. I know that Python 2.6 works with Boost 1.52 (on Debian and Ubuntu), so can also try removing the current Boost and installing 1.52 with Python 2.6.

I hope that something in this reply helps you.

Regards,

Vince

Revision history for this message
Yu (y-k) said : 		#2

Hello Vince, thank you for your reply.
Checking the output from Esys configuration, I found the line:

checking for Py_Main in -lpython2.6... no
(all lines about Boost below said yes)

I just tried Boost 1.52 following https://answers.launchpad.net/esys-particle/+faq/1235
and can resolve the problem.
I didn't add '--enables-shared' and 'link=shared' to configurations last time,
so I wonder if Boost 1.55 is ok after all. But anyway I can go through the installation.
Thank you for your help!

Unfortunately, I have another problem with running a test program following the tutorial.
I made bingle.py, and did

mpirun -np 2 /usr/local/bin/esyspartcile bingle.py

Then I got following error:

CSubLatticeControler: : initMPI()
slave started at local/global rank 0/1
Fatal error in PMPI_Bcast: Other MPI error, error stack:
PMPI_Bcast(1525)....: MPI_Bcast(buf=0x8310c88, count=16, MPI_PACKED, root=0, MPI_COMM_WORLD) failed
MPIR_Bcast_impl(1369):
MPIR_Bcast_intra(1160):
MPIR_SMP_Bcast(1077)..: Failure during collective

I'm running it on a single machine with 4 cores, using MPICH3.
(I can run "hello world" test program with <mpirun -np 2>)

I reinstalled Esys following the instrucution in https://bugs.launchpad.net/esys-particle/+bug/414248,
(I did <make uninstall> and <make distclean> in the first place)
but the result was the same.
I think it's the problem of my MPI configuration, but I'm not quite familiar with MPI.
I really appreciate if you give any advice about this problem.

Best regards,

Yu

Revision history for this message
Vince Boros (v-boros) said : 		#3

Hi Yu.

Regarding your current problem, I have no experience with MPICH. I hope that some others in the community can give you a quick answer before I try using it myself. Are you able to use openmpi?

I am glad that your first problem was resolved with Boost 1.52, but the configure output "checking for Py_Main in -lpython2.6... no" tells me that the trouble was with locating the Python library, libpython2.6.so. A failure at this point means a build failure. So libboost_python may or may not also have been the problem. If you initially did not use "--enable-shared" when configuring the Python build, I wonder if the lack of a .so file caused the configuration test to use the shared library of another (system) version of Python; but I have not played around with the option for a long time.

Regards,

Vince

Revision history for this message
Yu (y-k) said : 		#4

Hello, Vince.
I can't figure out how I can manage with MPICH3,
but I just replaced it with OpenMPI and I think I got the right results.

**bingle.py**
mpirun -np 2 esysparticle bingle.py

CSubLatticeControler: : initMPI()
slave started at local/global rank 0/1

**bingle_output.py**
mpirun -np 2 esysparticle bingle_output.py

CSubLatticeControler::initMPI()
slave started at local/global rank 0 / 1

0 -4.999 4.999 -4.999 4.999 4.999 4.999
100 -4.899 4.899 -4.899 4.899 4.899 4.899
200 -4.799 4.799 -4.799 4.799 4.799 4.799
300 -4.699 4.699 -4.699 4.699 4.699 4.699
400 -4.599 4.599 -4.599 4.599 4.599 4.599
500 -4.499 4.499 -4.499 4.499 4.499 4.499
600 -4.399 4.399 -4.399 4.399 4.399 4.399
700 -4.299 4.299 -4.299 4.299 4.299 4.299
800 -4.199 4.199 -4.199 4.199 4.199 4.199
900 -4.099 4.099 -4.099 4.099 4.099 4.099
1000 -3.999 3.999 -3.999 3.999 3.999 3.999
...
9900 -10.4873 -4.901 -10.4873 2.79316 -4.901 2.79316

Thanks a lot again!

Revision history for this message
Yu (y-k) said : 		#5

Thanks Vince Boros, that solved my question.