[gmx-developers] Question about Gromacs BLAS / LAPACK.

[Lee-Ping Wang]

Hi Ronald,

 

Thanks for your reply!  

 

There is no intrinsic requirement for double precision and I should add the
option for single precision.  I will replace my calls to BLAS / LAPACK
following your suggestion and get back to you.

 

I understand that 5.0 is going to be in C++, and I haven't looked at the
most current revision yet.  When I do submit the code I will make sure that
it's compatible with the existing objects (e.g. if the neighbor list is now
an object).  I will consider converting the fluctuating charge code to
something that's more object-oriented, but for the purposes of compatibility
it may be okay to simply enclose all of the C code using extern "C" { } .

 

I have done some development in Q-Chem and TeraChem (commercial quantum
chemistry codes) and they have rather natural vector / matrix interfaces in
C++.  I think it's a cool idea and I'll take a look at your thread.

 

-          Lee-Ping

 

From: gmx-developers-bounces at gromacs.org
[mailto:gmx-developers-bounces at gromacs.org] On Behalf Of Roland Schulz
Sent: 10 November 2012 10:23
To: Discussion list for GROMACS development
Subject: Re: [gmx-developers] Question about Gromacs BLAS / LAPACK.

 

Hi,

 

On Sat, Nov 10, 2012 at 11:59 AM, Lee-Ping Wang <leeping at stanford.edu>
wrote:

On my local machine, I migrated my fluctuating charge code from Gromacs
4.0.7 to 4.5.5.  It took a bit of time, but I think the implementation is
now a lot cleaner.  At some point, I would like to create a branch on the
Gromacs repository, but first I need to solve a few issues with BLAS and
LAPACK.  Basically, when I was originally writing the code I used the Intel
headers and libraries, but now I want to convert this to something more
compatible.

 

If you want to submit this code at some time you will have to submit it
against the master branch which is going to be 5.0. 5.0 is suppose to be
partially migrated to C++. And I personally think that this should include a
C++ vector/matrix interface. I started this discussion here:
http://redmine.gromacs.org/issues/1017.  So the interface might be changed
when this is decided. Feel free to comment on the issue.

cblas_dgemm(101,111,111,N,N,N,1,VT,N,A1,N,0,Ai,N);

dgelss(&N,&N,&nrhs,A1,&N,x,&N,S,&rcond,&rank,work,&lwork,&info);

Is your code not accurately enough in single precision? Or could you benefit
as the rest of Gromacs from using single precision (with the user having the
choice to compile with GMX_DOUBLE)?

However, when Gromacs calls its own BLAS and LAPACK functions it looks quite
different:

 

#ifdef GMX_DOUBLE

 
F77_FUNC(dsyevr,DSYEVR)(jobz,"I","L",&n,a,&n,&vl,&vu,&index_lower,&index_upp
er,

                            &abstol,&m,eigenvalues,eigenvectors,&n,

                            isuppz,&w0,&lwork,&iw0,&liwork,&info);

#else

 
F77_FUNC(ssyevr,SSYEVR)(jobz,"I","L",&n,a,&n,&vl,&vu,&index_lower,&index_upp
er,

                            &abstol,&m,eigenvalues,eigenvectors,&n,

                            isuppz,&w0,&lwork,&iw0,&liwork,&info);

#endif

I would write a macro (untested!)

#ifdef GMX_DOUblE
#define GMX_BLAS(A,B)  F77_FUNC(d ## A, D ## B)
#else
#define GMX_BLAS(A,B)  F77_FUNC(s ## A, S ## B)
#endif

 

So that you can call it as 

GMX_BLAS(syevr,SYEVR)(jobz,"I","L",&n,a,&n,&vl,&vu,&index_lower,&index_upper
,

                            &abstol,&m,eigenvalues,eigenvectors,&n,

                            isuppz,&w0,&lwork,&iw0,&liwork,&info);

without having to worry about the #ifdef GMX_DOUBLE at the callsite. Of
course if you always want to use double you don't need to worry about it.

2)      How should I write my code so that a user can compile and link using
Intel headers / libraries if they want to?  I imagine it's related to the
--use-external-blas and --use-external-lapack command line options to the
configure script, but I don't know how to use this.

That should automatically work.

 

 

Roland



 

-- 
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20121110/28eb1f70/attachment.html>