On Tue, 2014-10-07 at 19:42 +0300, Fabian Glaser wrote:
> Dear Dan,
>
> Thanks for your quick reply here there is a link to both files with the
> configure and make outputs, please let me know if you can access them.
>
> https://www.dropbox.com/sh/njtid64ckc1qrmb/AABMlxfmEYLB_JS7eSpE2V_6a?dl=0
The first thing I see is the problem with updating:
Available AmberTools 13 patches:
update.1, update.2, update.3, update.4, update.5, update.6, update.7, update.8, update.9, update.10,
update.11, update.12, update.13, update.14, update.15, update.16, update.17, update.18, update.19, update.20,
update.21, update.22, update.23, update.24, update.25, update.26
Traceback (most recent call last):
File "./update_amber", line 23, in <module>
app.mainloop()
File "/usr/local/amber12/updateutils/main.py", line 467, in mainloop
self.check_updates()
File "/usr/local/amber12/updateutils/main.py", line 175, in check_updates
self.verbose) + '\n')
File "/usr/local/amber12/updateutils/repos.py", line 185, in patch_details
return PatchRepository.patch_details(self, first, verbose)
File "/usr/local/amber12/updateutils/repos.py", line 59, in patch_details
progs = self.patch_list.programs(i)
File "/usr/local/amber12/updateutils/patchlist.py", line 237, in programs
return self._info_wrapper(idx, 'programs')
File "/usr/local/amber12/updateutils/patchlist.py", line 355, in _info_wrapper
return getattr(self._instantiate(idx), attr)()
File "/usr/local/amber12/updateutils/downloader.py", line 98, in new_fcn
return fcn(*args, **kwargs)
File "/usr/local/amber12/updateutils/patchlist.py", line 337, in _instantiate
self.sizere.findall(urlopen(self.names[idx]).info())[0])
TypeError: expected string or buffer
This indicates that your system Python is Python 3. This is getting
more and more common, but was quite unusual even 1 or 2 years ago. The
updating script of the current version of AmberTools (14) supports all
Python versions from 2.4 through 3.4+.
Since it is pretty clear that you have Python 2 on your system (as
evidenced by the next line in your config_mpi.log file), replace the
"#!/usr/bin/env python" with "#!/usr/bin/env python2" to make sure a
compatible Python version is used for the updating script. [1]
This is important, since it seems from the output that not a single
update has been applied (and many bugs have been fixed).
As for the compilation error:
/usr/local/intel/impi/4.0.3.008/intel64/lib/libmpigf.so: undefined reference to `MPIR_Err_return_comm'
/usr/local/intel/impi/4.0.3.008/intel64/lib/libmpigf.so: undefined reference to `MPIR_Grequest_set_lang_f77'
/usr/local/intel/impi/4.0.3.008/intel64/lib/libmpigf.so: undefined reference to `MPIR_CommSetAttr'
/usr/local/intel/impi/4.0.3.008/intel64/lib/libmpigf.so: undefined reference to `MPIR_Keyval_set_proxy'
/usr/local/intel/impi/4.0.3.008/intel64/lib/libmpigf.so: undefined reference to `MPIR_CommGetAttr'
/usr/local/intel/impi/4.0.3.008/intel64/lib/libmpigf.so: undefined reference to `MPID_Datatype_mem'
...
It seems like your cluster has the Intel MPI installed, but they are not
using it? In particular, I thought that the Intel MPI compiler wrappers
were mpiicc and mpiifort (rather than mpicc and mpif90 like it is with
every other MPI).
What I *think* is happening is that the mpicc and mpif90 wrappers that
are in the PATH are not actually part of the impi installation. But
they still accidentally link some of the impi libraries because the
environment puts them in the LD_LIBRARY_PATH first and they have the
same name as the libraries that mpicc/mpif90 were configured to use.
But they don't link all of the libraries that the Intel MPI wrappers
link, hence the undefined references.
It's also possible that the wrappers aren't linking all of the libraries
that it needs to (to check this, they can use the nm program to look for
the libraries that contain the MPIR_Err_return_comm and other missing
symbols and use "mpicc -show" to verify that the wrapper is indeed not
linking that library).
In any case, this parallel build issue is either caused by the naming
issue I first alluded to (and is simply fixed in config.h), or it is not
an Amber problem at all.
HTH,
Jason
[1] The best solution would be to simply update to AmberTools 14 where
this is no longer a problem. Indeed, Amber 14 has a "-intelmpi" flag
that would support users that had Intel MPI installed.
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Oct 07 2014 - 11:00:02 PDT
