Hi,
On Wed, Sep 16, 2009 at 10:56:02PM -0400, Volodymyr Babin wrote:
> > 1. The fortran versions were the "original" ones, and the C versions are
> > translations. But there should not be any real functional difference. In
> > fact, either can be replaced with other libraries (like MKL or Goto).
But I've heard that not all such libraries support CBLAS, e.g.,
ACML. I havent tested this.
> IMHO the proper way to go is to offload this to the user and use
> whatever blas/lapack the user wants amber to use.
We went this route in COLUMBUS in 2005. Our reasoning was that most
real computers would have blas and lapack available, and that for other
computers this would be a tiny hurdle for the serious COLUMBUS user.
(Non serious COLUMBUS users will find many big and scary hurdles.)
Except for the small issue below this has worked fine for our limited
audience.
However, I do not think the same reasoning applies to AmberTools users.
In addition, the costs for slow blas's etc are much less for AmberTools
than for COLUMBUS.
The small issue :
# libg2c may be necessary to resolve references to z_abs, c_sqrt, z_exp, c_exp,
# z_sqrt, s_cat, and c_abs in libblas if libblas was built with g77
# which it is on for example:
# Red Hat Enterprise Linux AS release 3 (Taroon Update 3)
# So try the build without it:
#LIBS=-lblas -llapack
# or define LIBG2C_HOME; to find the path try: locate libg2c.a
LIBS=-lblas -llapack -L$(LIBG2C_HOME) -lg2c
> > 2. The C versions require f2c, which leads to some problems with complex
> > variables; the f2c headers may be in conflict with <complex.h>, which has
> > already lead to some problems. Basically, complex data types (both real and
> > double precision) are better establshed in the Fortran community than in the C
> > one.
icc -c -Dflex -O2 -DBINTRAJ -o nmode.o nmode.c
../f2c/f2c.h(21): error: _Complex can only be used with float, double, or long double types typedef struct { real r, i; } complex;
But the fix for this looks like the f2c.h include was superfluous.
One would hope that a C interface would not have such a basic flaw.
> 3. The fortran routines are easier to read and understand (and potentially to
> modify, although I doubt that we would be doing that...these are *standard*
> libraries, after all.)
Sidebar: has anyone ever tuned a lapack via ILAENV ?
http://www.netlib.org/lapack/lug/node140.html
> > 4. If we stick with C, then some things like nab could still work even for
> > machines that don't have a Fortran compiler.
This might be nice for DOCK since the dock6 exe does not now need fortran.
You say nab but probably mean sff.
On the other hand gfortran will be ~omnipresent soon.
And sff probably can be easily stripped of lapack for DOCK.
> > 5. We could, of course, continue to distribute both, but I'd prefer not to
> > do
> > that, since it increases out testing burden. But I'd be interested in
> > arguments in favor of this, if they are out there.
But since nab has used clapack and Amber has used lapack,
the path of least testing burden is to continue to distribute both.
In this instance I think the change will produce a greater burden
than any differential testing coverage.
I vote for distributing both in 1.3.
This seems best on balance vis-a-vis your issues,
and furthermore we are about one month from release
which is already too close for new changes to get thorough usage -
nevermind that this one has no functional advantage.
Scott
> IMHO, this (distributing both) would be the next to ideal (distributing
> none) solution. Next option, IMHO, would be the fortran alone. OTOH,
> some additional libraries (parts of the fortran compiler used to
> compile blas/lapack) may be needed to link the c/c++ programs with
> (causing yet another headache).
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Sep 17 2009 - 01:00:02 PDT
