I had a messy problem with remaking amber last week, but there seems to be
an overall trend that I see on various systems: works at first, then over
time (months to a year or more) rebuilding, even if from a fresh clone of
the repository, becomes harder to do successfully. This happens, I am
pretty sure, as new software or versions get installed by sysadmins, and
various pointers in my environment or files that Amber depends on retain
their old settings. If you've downloaded miniconda, "make clean ; make
uninstall" doesn't get rid of it, but changing to a different compiler and
trying to rebuild might be a problem (haven't quite seen that happen, but
it's conceivable to me). The particular problem I hit was that my
$PYTHONPATH had, in front of the miniconda amber installation, a path to
another pre-installed python library, and the compilation was going there
before checking the amber-downloaded python, then hitting a problem with
intel versus gnu compiler mismatch.
Perhaps we should discuss ways to add features to the installation script
that will detect common errors or vulnerabilities we can foresee, then
prompt the user to take specific actions to rememdy them. Some of this is
already in place, such as suggestions to source ifortvars.sh and amber.sh
when encountering certain problems. In the case of my python problem, it
would have been helpful for the installation to show me my actual
$PYTHONPATH. Should we make an effort to broaden the scope of these hints?
Dave
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Feb 06 2017 - 17:00:04 PST
