[gmx-users] Re: [gmx-developers] Gromacs 4.6.1 ATLAS/CUDA detection problems...
On Wed, 6 Mar 2013, Christoph Junghans wrote: I had a another look at the issue and I guess cmake's blas detention is a bit flaky, when it comes to static libraries. You are using liblapack.a, which has no link information, with liblapack.so it should have worked. Anyhow, thanks for reporting the issue. There is no liblapack.so with ATLAS? Anyway, I tried to explain the issues more clearly below. I am not going to insist but it would be nice to be able to use the ATLAS library I guess... :) The following library files are available with ATLAS and your cmake config checks use f77blas;atlas libatlas.a libcblas.a libf77blas.a liblapack.a libptcblas.a libptf77blas.a libsatlas.so libtatlas.so At: http://ac-archive.sourceforge.net/ac-archive/acx_blas.html It says that you will have to use the same FORTRAN compiler to link ATLAS. However your checker is using gcc to check linking. So the first bug is because the checker is trying to link f77blas with gcc. This requires -lgfortran. You can see many related information if you do a web search for undefined reference to `_gfortran_st_write'). Otherwise you should use gfortran for the tests. Therefore it is impossible for gromacs to use ATLAS library. The second problem is because f77blas;atlas should include cblas for linking. Again, at the example which is present at: http://ac-archive.sourceforge.net/ac-archive/acx_blas.html BLAS_LIBS=-lcblas -lf77blas -latlas is used. Therefore it is again impossible to find ATLAS library even when it exists. The third problem is ambiguity in the manual at: http://www.gromacs.org/Documentation/Installation_Instructions#4.1._Configuring_with_CMake It says: A key thing to consider here is the setting of CMAKE_INSTALL_PREFIX. However it is not clear what 'setting' means in here. (Being unfamiliar with cmake, I defaulted to setting it in the environment which was wrong) Later I found out CMAKE_INSTALL_PREFIX can only be used as a cmake variable (not set in environment). But DESTDIR should be set for setting installation prefix instead ? See: http://www.cmake.org/cmake/help/v2.8.8/cmake.html#variable%3aCMAKE_INSTALL_PREFIX http://www.cmake.org/Wiki/CMake_FAQ#Does_CMake.27s_.22make_install.22_support_DESTDIR.3F I hope the problems in ATLAS detection and documentation would be fixed. Thanks for your interest in these small issues. Thanks, Evren -- gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/Search before posting! * Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
RE: [gmx-users] Re: [gmx-developers] Gromacs 4.6.1 ATLAS/CUDA detection problems...
On Thu, 7 Mar 2013, Berk Hess wrote: Hi, Note that the linear algebra in Gromacs is limited to eigenvalue solving in two analysis tools, the MD engine does not use any (large) linear algebra. So linear algebra library performance is irrelevant, except for the cases where users would want to repeated uses one of the two tools with large systems. Even then, our built-in code is not bad. Cheers, Berk Hello, I am not sure what you are suggesting as a fix to the problem? Do you mean the support for ATLAS should/will be removed as a fix because it is not very useful performancewise (and non-functional) anyway? Thanks, Evren -- gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/Search before posting! * Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
Re: [gmx-users] Re: [gmx-developers] Gromacs 4.6.1 ATLAS/CUDA detection problems...
On Thu, 7 Mar 2013, Szilárd Páll wrote: On Thu, Mar 7, 2013 at 2:02 PM, Berk Hess g...@hotmail.com wrote: Hi, This was only a note, not a fix. I was just trying to say that what linear algebra library you use for Gromacs is irrelevant in more than 99% of the cases. But having said that, the choice of library should not complicate the configure stage of Gromacs. I guess Evren assumed that GROMACS has an explicit dependency on an external linear algebra library. To be concrete, you can simply use the GROMACS internal linear algebra code by setting -DGMX_EXTERNAL_BLAS=OFF -DGMX_EXTERNAL_LAPACK=OFF. -- Szilárd PS: This issue sounds like a valid reason to consider switching external BLAS/LAPACK off by default. I actually saw that the configure said it will use internal blas/lapack. I also understand that the blas/lapack is not very relevant for gromacs. But none of these mean there is not a problem. (which is probably easy to fix anyway). In either case, I reported it so developers can be informed and I dont mind if it is fixed or not. But thanks for the feedback and information given. Thanks Evren -- gmx-users mailing listgmx-users@gromacs.org http://lists.gromacs.org/mailman/listinfo/gmx-users * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/Search before posting! * Please don't post (un)subscribe requests to the list. Use the www interface or send it to gmx-users-requ...@gromacs.org. * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
