Hi Bob,
In terms of building PMEMD in AMBER 11 the standard build (serial or MPI)
should work with all of the compilers that the standard
amber11/src/configure script supports. This includes gnu,intel and pgi.
Maybe some others. PGI I have not tested because I do not have a copy. Gnu
and Intel I test regularly.
My intention is that the pmemd.cuda version can be built with either gnu or
Intel. Any other compiler options the configure script should reject if you
specify -cuda on the command line.
As for building PMEMD on its own all the original build scripts are still
there and one just needs to use configure.advanced and makefile.advanced in
the pmemd directory.
E.g.
cd $AMBERHOME/src/pmemd/
./configure.advanced linux_em64t ifort mvapich pubfft bintraj
make -f Makefile.advanced
This is, and should remain for this release, undocumented since it is meant
only for developers and advanced users and the build scripts need a lot of
work to update them for current generation machines and compilers.
Things like IBM etc can still be used if one uses the advanced Makefile.
It could be done in the standard AMBER 11 build configure script but this
needs someone who has both the time and access to the hardware to volunteer
to do it.
All the best
Ross
> -----Original Message-----
> From: amber-developers-bounces.ambermd.org [mailto:amber-developers-
> bounces.ambermd.org] On Behalf Of Robert Duke
> Sent: Monday, March 29, 2010 10:45 AM
> To: AMBER Developers Mailing List
> Subject: Re: [AMBER-Developers] Help with NVIDIA Compilation using
> ifort
>
> Yes, but those are not the two compilers I am worried about... We
> really
> need to understand what compilers we intend to support in this release,
> and
> what the impact of the various c preprocessors would be. If we make a
> decision to support, say, gcc, intel, pgi, and ibm (the minimal list I
> can
> come up with - I have not a clue about mac's, or how you guys do
> anything
> with cygwin), then so be it. But we should have a list. I used to
> support
> a wide range of stuff for pmemd; I am aware that a lot of those
> platforms,
> especially the risc stuff, are now effectively dead. It would be my
> guess
> that we could use stringizing, but should check it out on all the above
> stuff at a minimum (pretty sure no issues with intel or gcc; ibm you
> never
> know). I consider it a clean and good solution, as long as the
> preprocessors are there. I suppose one could also insist that on
> non-compliant platforms, folks just have to use the gcc preprocessor.
> But
> it has to be worked out...
> Scott, do you or does some collective somebody have access to
> everything
> "supported", is there a "supported" list, etc. It would be pretty easy
> to
> check stringizing on some small list of platforms, if you have them...
> Regards - Bob
> ----- Original Message -----
> From: "Volodymyr Babin" <vbabin.ncsu.edu>
> To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
> Sent: Monday, March 29, 2010 1:32 PM
> Subject: Re: [AMBER-Developers] Help with NVIDIA Compilation using
> ifort
>
>
> > Just out of curiosity I tried to compile the following:
> >
> > example.cc:
> >
> > extern "C" {
> >
> > int serious_subroutine() {
> > for (int i = 0; i < 1000000; ++i) {
> > int j = i*i;
> > }
> > return 8;
> > }
> >
> > int serious_subroutine_() __attribute__ ((weak, alias
> > ("serious_subroutine")));
> > int serious_subroutine__() __attribute__ ((weak, alias
> > ("serious_subroutine")));
> >
> > } // extern "C"
> >
> > using g++ 3.4.6 and icpc 10.1.022 -- in both cases I got
> >
> > nm example.o
> > 00000000 T serious_subroutine
> > 00000000 W serious_subroutine_
> > 00000000 W serious_subroutine__
> >
> > which means that icpc does understand __attribute__ (...) and,
> > consequently, this can be probably given a try if the problem
> > is "to be able to use either gnu or intel compilers to build
> > pmemd with CUDA support".
> >
> > Best,
> >
> > Volodymyr
> >
> > On Mon, March 29, 2010 13:03, Robert Duke wrote:
> >> Yeah, that is what I am worried about - vendor compilers don't
> >> necessarily
> >> conform to gcc, so finding stuff to use in gcc is not a great idea.
> >> Adhering to certain c standards is a better idea, but I know that at
> >> least
> >> in the past, the functionality found in c preprocessors was still
> "hit
> >> and
> >> miss", to describe it kindly. So we just need to look out for this.
> If
> >> anyone is still using something old, they might try it and see what
> >> happens.
> >> I used to hit old ibm and and sgi machines for this purpose, but I
> don't
> >> have them anymore.
> >> Regards -Bob
> >>
> >> ----- Original Message -----
> >> From: "Volodymyr Babin" <vbabin.ncsu.edu>
> >> To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
> >> Sent: Monday, March 29, 2010 12:37 PM
> >> Subject: Re: [AMBER-Developers] Help with NVIDIA Compilation using
> ifort
> >>
> >>
> >>>> The only issue I can think
> >>>> of is if there is a c preprocessor out there somewhere that can't
> >>>> handle
> >>>> stringizing - that may be why I avoided doing this in the first
> pass.
> >>>
> >>> A good point to look for a quite portable solution is "gmacros.h"
> from
> >>> glib (http://library.gnome.org/devel/glib/), I believe.
> >>>
> >>> Another way would be to use gcc's "alias" __attribute__
> >>>
> >>> http://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Function-
> Attributes.html#Function-Attributes
> >>>
> >>> alias ("target")
> >>> The alias attribute causes the declaration to be emitted as an
> alias
> >>> for another symbol, which must be specified. For instance,
> >>>
> >>> void __f () { /* Do something. */; }
> >>> void f () __attribute__ ((weak, alias ("__f")));
> >>>
> >>>
> >>> defines `f' to be a weak alias for `__f'. In C++, the mangled
> name
> >>> for
> >>> the target must be used. It is an error if `__f' is not defined in
> the
> >>> same translation unit.
> >>>
> >>> Not all target machines support this attribute.
> >>>
> >>> Just random comments,
> >>>
> >>> Volodymyr
> >>>
> >>>> Some
> >>>> folks who use a wider variety of platforms than I do might want to
> >>>> comment
> >>>> on that.
> >>>> Regards - Bob
> >>>> ----- Original Message -----
> >>>> From: "Volodymyr Babin" <vbabin.ncsu.edu>
> >>>> To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
> >>>> Sent: Monday, March 29, 2010 12:18 PM
> >>>> Subject: RE: [AMBER-Developers] Help with NVIDIA Compilation using
> >>>> ifort
> >>>>
> >>>>
> >>>>> One could possibly use a macro like
> >>>>>
> >>>>> #ifdef ASSUME_JUST_ONE_TRAILING_UNDERSCORE
> >>>>> # define FORTRANIZE(name) name##_
> >>>>> #else
> >>>>> # define FORTRANIZE(name) name##___
> >>>>> #endif
> >>>>>
> >>>>> or something like that.
> >>>>>
> >>>>> Best,
> >>>>>
> >>>>> Volodymyr
> >>>>>
> >>>>> On Mon, March 29, 2010 11:59, Ross Walker wrote:
> >>>>>> Hi Tim
> >>>>>>
> >>>>>> We already have something similar to this in
> >>>>>> src/pmemd/src/cuda/gpu.cpp
> >>>>>>
> >>>>>> extern "C" void gpu_dump_dval_(double* pDouble)
> >>>>>> {
> >>>>>> ...
> >>>>>> }
> >>>>>>
> >>>>>> I was hoping to find a way to do this without having to go
> through
> >>>>>> and
> >>>>>> make
> >>>>>> additional copies of everything for Intel.
> >>>>>>
> >>>>>> All the best
> >>>>>> Ross
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: amber-developers-bounces.ambermd.org [mailto:amber-
> developers-
> >>>>>>> bounces.ambermd.org] On Behalf Of Timothy J Giese
> >>>>>>> Sent: Friday, March 26, 2010 4:15 PM
> >>>>>>> To: AMBER Developers Mailing List
> >>>>>>> Subject: Re: [AMBER-Developers] Help with NVIDIA Compilation
> using
> >>>>>>> ifort
> >>>>>>>
> >>>>>>> I've only done a few things with cuda/fortran, but I basically
> >>>>>>> treat it like how I treat c/fortran, i.e., in C, create
> >>>>>>> subroutine_ and have it simply call subroutine.
> >>>>>>>
> >>>>>>> I've never really thought about pros and cons of this.
> >>>>>>>
> >>>>>>> For example
> >>>>>>>
> >>>>>>> void init_template_kernel_drv(int &, int &, int &);
> >>>>>>> void free_template_kernel_drv();
> >>>>>>> void run_template_kernel_drv(int &, double *);
> >>>>>>>
> >>>>>>> extern "C"
> >>>>>>> {
> >>>>>>> void init_template_kernel_(int &, int &, int &);
> >>>>>>> void free_template_kernel_();
> >>>>>>> void run_template_kernel_(int &, double *);
> >>>>>>> }
> >>>>>>>
> >>>>>>>
> >>>>>>> void init_template_kernel_(int & max_blocks,int &
> threads_per_block,
> >>>>>>> int
> >>>>>>> & buflen)
> >>>>>>> {
> >>>>>>> init_template_kernel_drv(max_blocks, threads_per_block,
> buflen);
> >>>>>>> }
> >>>>>>>
> >>>>>>> void free_template_kernel_()
> >>>>>>> {
> >>>>>>> free_template_kernel_drv();
> >>>>>>> }
> >>>>>>>
> >>>>>>>
> >>>>>>> void run_template_kernel_(int & na, double * A)
> >>>>>>> {
> >>>>>>> run_template_kernel_drv(na, A);
> >>>>>>> }
> >>>>>>>
> >>>>>>>
> >>>>>>> I found some discussion on the intel boards. Not sure how
> >>>>>>> useful it is.
> >>>>>>>
> >>>>>>> http://software.intel.com/en-us/forums/showthread.php?t=56872
> >>>>>>>
> >>>>>>> -Tim
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> 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
> >>>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> >
> >
> > _______________________________________________
> > 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
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Mar 29 2010 - 11:30:03 PDT
