Re: [AMBER-Developers] Second release candidate for AmberTools 1.5

From: Jason Swails <jason.swails.gmail.com>
Date: Wed, 16 Mar 2011 16:16:43 -0700

Hi Lin,

If you can modify the configure script such that it works with PGI, then
that's great (as long as it doesn't break gcc/icc). You'd have to actually
change the bz2 tarball, though, since that's the only thing distributed with
AmberTools (many versions of VIM have plugins that allow you to edit files
directly in these zipped archives and save the result as a new bzip file).

I still don't have access to a PGI machine, so I can't really try much out.

Thanks,
Jason

On Wed, Mar 16, 2011 at 4:11 PM, Lin Fu <linfu3200.gmail.com> wrote:

> Hi Jason,
>
> It seems that python could be compiled with pgi compiler as long as
> we change the compiler flag " -Xlinker -export-dynamic ", which is the
> defaut option in the GNU environment. I have tried some other available
> options in the configuration file shown below. if the option *
> LINKFORSHARED="-Wl,--export-dynamic"* mentioned in the *line 7503* was
> choosen, compilation of python with PGI will be completed successfully.
> Please have a try.
> *[lin.comp Python-2.6.6]$ vim configuration*
> 7472 if test -z "$LINKFORSHARED"
> 7473 then
> 7474 case $ac_sys_system/$ac_sys_release in
> 7475 AIX*) LINKFORSHARED='-Wl,-bE:Modules/python.exp -lld';;
> 7476 hp*|HP*)
> 7477 LINKFORSHARED="-Wl,-E -Wl,+s";;
> 7478 # LINKFORSHARED="-Wl,-E -Wl,+s
> -Wl,+b\$(BINLIBDEST)/lib-dynload";;
> 7479 BSD/OS/4*) LINKFORSHARED="-Xlinker -export-dynamic";;
> * 7480 Linux*|GNU*) LINKFORSHARED="-Xlinker -export-dynamic";;
> * 7481 # -u libsys_s pulls in all symbols in libsys
> 7482 Darwin/*)
> 7483 # -u _PyMac_Error is needed to pull in the mac toolbox glue,
> 7484 # which is
> 7485 # not used by the core itself but which needs to be in the
> core so
> 7486 # that dynamically loaded extension modules have access to
> it.
> 7487 # -prebind is no longer used, because it actually seems to
> give a
> 7488 # slowdown in stead of a speedup, maybe due to the large
> number of
> 7489 # dynamic loads Python does.
> 7490
> 7491 LINKFORSHARED="$extra_undefs"
> 7492 if test "$enable_framework"
> 7493 then
> 7494 LINKFORSHARED="$LINKFORSHARED
> "'$(PYTHONFRAMEWORKDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK)'
> 7495 fi
> 7496 LINKFORSHARED="$LINKFORSHARED";;
> 7497 OpenUNIX*|UnixWare*) LINKFORSHARED="-Wl,-Bexport";;
> 7498 SCO_SV*) LINKFORSHARED="-Wl,-Bexport";;
> 7499 ReliantUNIX*) LINKFORSHARED="-W1 -Blargedynsym";;
> * 7500 FreeBSD*|NetBSD*|OpenBSD*|DragonFly*)
> 7501 if [ "`$CC -dM -E - </dev/null | grep __ELF__`" != "" ]
> 7502 then
> 7503 LINKFORSHARED="-Wl,--export-dynamic"
> 7504 fi;;
> * 7505 SunOS/5*) case $CC in
> 7506 *gcc*)
> 7507 if $CC -Xlinker --help 2>&1 | grep export-dynamic
> >/dev/null
> 7508 then
> 7509 LINKFORSHARED="-Xlinker --export-dynamic"
> 7510 fi;;
> 7511 esac;;
> 7512 CYGWIN*)
> 7513 if test $enable_shared = "no"
> 7514 then
> 7515 LINKFORSHARED='-Wl,--out-implib=$(LDLIBRARY)'
> 7516 fi;;
> 7517 QNX*)
> 7518 # -Wl,-E causes the symbols to be added to the dynamic
> 7519 # symbol table so that they can be found when a module
> 7520 # is loaded. -N 2048K causes the stack size to be set
> 7521 # to 2048 kilobytes so that the stack doesn't overflow
> 7522 # when running test_compile.py.
> 7523 LINKFORSHARED='-Wl,-E -N 2048K';;
>
> Best Regards,
> Lin
> 2011/3/16 Jason Swails <jason.swails.gmail.com>
>
> > Hi Lin,
> >
> > I don't think Python is compiled in static, but I don't think this should
> > be
> > an issue for a couple reasons.
> >
> > Most of the PGI users, I think, will have GCC readily available (even
> many
> > systems using modules, like Kraken and Athena) with libraries in standard
> > locations so that you don't have to load a new module to compile python,
> > then have it break after you unload it.
> >
> > Also, if this all fails, then you can use -nopython to force Amber to use
> > the system python instead of the one that came bundled with AmberTools.
> > All
> > of this should be handled automatically at compile time, so the user
> > doesn't
> > have to actually *see* any of this going on.
> >
> > I think Ross has a system here with PGI compilers that I can test some
> > stuff
> > out on, so I'll report back on my findings.
> >
> > All the best,
> > Jason
> >
> > On Wed, Mar 16, 2011 at 11:31 AM, Lin Fu <linfu3200.gmail.com> wrote:
> >
> > > Hi Jason,
> > >
> > > You mean the python compiled here is static version, which will not be
> > > dynamically linked to any gnu stuff. If both python here in the amber
> and
> > > sander are static version, it will be fine since it is only system
> level
> > > call instead of source code level call. but If both are only dynamical
> > link
> > > version, it might cause problem. since we might need to load both gnu
> and
> > > pgi stuff, which is usually excluded by module on the cluster. please
> > > correct me if it is not. Thanks.
> > >
> > > Best Regards,
> > > Lin
> > > 2011/3/16 Jason Swails <jason.swails.gmail.com>
> > >
> > > > It should make no difference. The python interpreter can be compiled
> > > with
> > > > GCC, and it can run any python script. MMPBSA.py calls sander via a
> > > system
> > > > call, so as long as it's *installed*, it'll work.
> > > >
> > > > Also keep in mind that MMPBSA.py is not compiled, since python is an
> > > > interpreted language. We can get away with this because Python
> doesn't
> > > > actually *link* to anything, it's just used to interpret python
> > > > programs/scripts.
> > > >
> > > > --Jason
> > > >
> > > > On Wed, Mar 16, 2011 at 10:39 AM, Lin Fu <linfu3200.gmail.com>
> wrote:
> > > >
> > > > > Hi Jason,
> > > > >
> > > > > >It doesn't seem like there's really any way around this. What do
> > > people
> > > > > think about letting Python just use GCC if it can find it in case
> > > someone
> > > > > chooses pgi at configure time?
> > > > > Not sure whether it will make the user confusing or not. Will the
> > > > MMPBSA.py
> > > > > be compatible with the MPI with different compilers if user runs in
> > > > > parallel. Another problem is that on most clusters Environment
> Module
> > > is
> > > > > used to manage the different enviroment of compiler, such as module
> > > load
> > > > > intel/pgi/gnu. some options are exclusive. Can gnu-compiled
> MMPBSA.py
> > > > > invoke
> > > > > the pgi-compiled serial version of sander, which is called by the
> > > > > MMPBSA.py.
> > > > > >if you can reconfigure using -nopython, and run it again to see if
> > > there
> > > > > are any errors elsewhere that would be great.
> > > > > It seems that mtkpp can also not pass the pgi compiler even after
> > > > excluding
> > > > > the python module due "-Wall" problem, but Ben said that he will
> give
> > > an
> > > > > solution about that.
> > > > >
> > > > > Best Regards,
> > > > > Lin
> > > > >
> > > > > 2011/3/15 Jason Swails <jason.swails.gmail.com>
> > > > >
> > > > > > Hi Lin,
> > > > > >
> > > > > > It doesn't seem like there's really any way around this. What do
> > > > people
> > > > > > think about letting Python just use GCC if it can find it in case
> > > > someone
> > > > > > chooses pgi at configure time?
> > > > > >
> > > > > > It won't cause any incompatibilities with anything else (as it's
> > > quite
> > > > > > isolated), and I think that getting it to compile correctly with
> > PGI
> > > is
> > > > > > going to be difficult.
> > > > > >
> > > > > > We already have to force Python to use a different (xcode)
> compiler
> > > > when
> > > > > > building on Mac OS X, so I don't think this is really going to
> > cause
> > > > any
> > > > > > issues.
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > And Lin, if you can reconfigure using -nopython, and run it again
> > to
> > > > see
> > > > > if
> > > > > > there are any errors elsewhere that would be great.
> > > > > >
> > > > > > Thanks!
> > > > > > Jason
> > > > > >
> > > > > > On Tue, Mar 15, 2011 at 4:42 PM, Lin Fu <linfu3200.gmail.com>
> > wrote:
> > > > > >
> > > > > > > Hi Jason,
> > > > > > >
> > > > > > > I have tried to compile this version of ambertools with pgi,
> but
> > it
> > > > > > failed
> > > > > > > to compile python module since "-Xlinker and -export-dynamic"
> can
> > > not
> > > > > be
> > > > > > > recognized by pgcc. Not sure whether you got similar error.
> > > > > > > pgcc -Xlinker -export-dynamic -o python \
> > > > > > > Modules/python.o \
> > > > > > > libpython2.6.a -lpthread -ldl -lpthread
> > > > -lutil
> > > > > > > -lm
> > > > > > > pgcc-Error-Unknown switch: -Xlinker
> > > > > > > pgcc-Error-Unknown switch: -export-dynamic
> > > > > > > make[1]: *** [python] Error 1
> > > > > > >
> > > > > > > Best Regards,
> > > > > > > Lin
> > > > > > >
> > > > > > > 2011/3/14 Jason Swails <jason.swails.gmail.com>
> > > > > > >
> > > > > > > > If anyone has access to the PGI compilers, bits of AmberTools
> > > > aren't
> > > > > > > > compiling for me out-of-the-box on athena, but there are
> enough
> > > > > > > > Cray-specific idiosyncrasies that I'm not confident enough to
> > > label
> > > > > > them
> > > > > > > > PGI
> > > > > > > > problems.
> > > > > > > >
> > > > > > > > Also, for those of you who will try building this alongside
> > > Amber11
> > > > > > > (dirty
> > > > > > > > or clean), don't forget to apply the script AT15_Amber11.py
> > after
> > > > > > > configure
> > > > > > > > (from any directory, it just uses absolute paths based on
> > > > AMBERHOME).
> > > > > > > > Configure should print a warning message about this in any
> > case.
> > > > > > > >
> > > > > > > > All the best,
> > > > > > > > Jason
> > > > > > > >
> > > > > > > > On Mon, Mar 14, 2011 at 12:03 PM, David A Case <
> > > > > > case.biomaps.rutgers.edu
> > > > > > > > >wrote:
> > > > > > > >
> > > > > > > > > Hi everyone:
> > > > > > > > >
> > > > > > > > > The second "release candidate" for AmberTools 1.5 is here:
> > > > > > > > >
> > > > > > > > > http://ambermd.org/downloads/AmberTools.14mar11.tar.bz2
> > > > > > > > >
> > > > > > > > > Please test this out:
> > > > > > > > >
> > > > > > > > > a. on its own
> > > > > > > > > b. in conjunction with Amber11 (either in a clean
> install,
> > > or
> > > > > > > untarred
> > > > > > > > > on top of a working, "dirty" directory already
> > > containing
> > > > AT
> > > > > > > 1.4.)
> > > > > > > > >
> > > > > > > > > It is better to test this than the at15-with-patches
> branch,
> > > > since
> > > > > > this
> > > > > > > > is
> > > > > > > > > what users would actually be getting. No GEM here yet, but
> > > other
> > > > > > > things
> > > > > > > > > should be getting close.
> > > > > > > > >
> > > > > > > > > ...thx...dac
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > AMBER-Developers mailing list
> > > > > > > > > AMBER-Developers.ambermd.org
> > > > > > > > > http://lists.ambermd.org/mailman/listinfo/amber-developers
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Jason M. Swails
> > > > > > > > Quantum Theory Project,
> > > > > > > > University of Florida
> > > > > > > > Ph.D. Candidate
> > > > > > > > 352-392-4032
> > > > > > > > _______________________________________________
> > > > > > > > AMBER-Developers mailing list
> > > > > > > > AMBER-Developers.ambermd.org
> > > > > > > > http://lists.ambermd.org/mailman/listinfo/amber-developers
> > > > > > > >
> > > > > > > _______________________________________________
> > > > > > > AMBER-Developers mailing list
> > > > > > > AMBER-Developers.ambermd.org
> > > > > > > http://lists.ambermd.org/mailman/listinfo/amber-developers
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Jason M. Swails
> > > > > > Quantum Theory Project,
> > > > > > University of Florida
> > > > > > Ph.D. Candidate
> > > > > > 352-392-4032
> > > > > > _______________________________________________
> > > > > > AMBER-Developers mailing list
> > > > > > AMBER-Developers.ambermd.org
> > > > > > http://lists.ambermd.org/mailman/listinfo/amber-developers
> > > > > >
> > > > > _______________________________________________
> > > > > AMBER-Developers mailing list
> > > > > AMBER-Developers.ambermd.org
> > > > > http://lists.ambermd.org/mailman/listinfo/amber-developers
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Jason M. Swails
> > > > Quantum Theory Project,
> > > > University of Florida
> > > > Ph.D. Candidate
> > > > 352-392-4032
> > > > _______________________________________________
> > > > AMBER-Developers mailing list
> > > > AMBER-Developers.ambermd.org
> > > > http://lists.ambermd.org/mailman/listinfo/amber-developers
> > > >
> > > _______________________________________________
> > > AMBER-Developers mailing list
> > > AMBER-Developers.ambermd.org
> > > http://lists.ambermd.org/mailman/listinfo/amber-developers
> > >
> >
> >
> >
> > --
> > Jason M. Swails
> > Quantum Theory Project,
> > University of Florida
> > Ph.D. Candidate
> > 352-392-4032
> > _______________________________________________
> > AMBER-Developers mailing list
> > AMBER-Developers.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber-developers
> >
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>



-- 
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Mar 16 2011 - 16:30:04 PDT
Custom Search