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

From: Lin Fu <linfu3200.gmail.com>
Date: Thu, 17 Mar 2011 02:31:45 -0400

Hi Jason,

In this version of ambertools all modules except mtkpp, mdgx, and
xtalutil have been passed with pgi compiler . As for the *xtalutil* and *
mdgx*, the problem relates with some "inline" in the *SpecialMath.c,
Thermostats.c* and *CrdManip.c* in the mdgx/ and *crdmanip.c* in the
xtalutil/Clibs/, which could be removed and optimized directly by the pgi
compiler flag "-Mipa=fast,inline", or the Conditional compilation symbols
could be added in these c source file. Therefore these modules could be also
compiled with this solution. As for the mtkpp, there are lots of compiler
error with pgi even if the removing of "-Wall" and some modification of
head file, which invovles redefintion of some variables, which has been
already defined in the include/ folder of pgi installation directory. Hope
Ben will give patch about it. The serial version of ambertools compiled with
pgi passed all the tests in the amber11/AmberTools/test. it should be noted
that the mdgx and mtkpp may be not included.

All the tests has been in the Finished test suite for AmberTools at Thu Mar
17 00:26:36 CST 2011.

505 file comparisons passed
0 file comparisons failed
0 tests experienced errors
Test log file saved as logs/test_at_serial/2011-03-16_23-45-21.log
No test diffs to save!

I am not sure whether I have permission to upload it or not. Thus I attached
the new configuration file in this email. you can also have a try on the
athena or kraken which have pgi compiler.

Best Regards,
Lin
2011/3/16 Jason Swails <jason.swails.gmail.com>

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


_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers

Received on Thu Mar 17 2011 - 00:00:02 PDT
Custom Search