Package Details: gromacs 5.1.2-1

Git Clone URL: https://aur.archlinux.org/gromacs.git (read-only)
Package Base: gromacs
Description: A versatile package to perform molecular dynamics, i.e. simulate the Newtonian equations of motion for systems with hundreds to millions of particles.
Upstream URL: http://www.gromacs.org/
Licenses: LGPL
Submitter: xyproto
Maintainer: hseara
Last Packager: hseara
Votes: 13
Popularity: 0.201397
First Submitted: 2011-12-14 17:03
Last Updated: 2016-02-16 16:04

Latest Comments

hseara commented on 2016-07-14 20:00

NOTE: PROBLEMS BUILDING GROMACS AFTER GCC6 UPDATE WITH CUDA SUPPORT

If your system has CUDA installed, gromacs installer by default will try to compile with CUDA support. Unfortunately, currently gcc6 and CUDA do not play well along and the compilation will fail. Because of this the later cuda release comes along with gcc5 package.
Using gcc5 we can again build gromacs in bash using the following commands:

export CC=gcc-5
export CXX=g++-5
makepkg

hseara commented on 2016-07-14 19:53

Sorry, I'm not sure I'm understand really your problem.
This package is the default gromacs and as such is installed in:
/usr/bin
/usr/include
/usr/lib
/usr/share
I just build the package and it works perfectly with the files
installed in above directories.

Are you sure that you are installing gromacs and not aur/gromacs-5.0-complete or aur/gromacs-4.6-complete which indeed install this version of gromacs in /usr/local. In this latter packages the intention is that they can coexist with the last stable version in case your projects still require them and because of that they are encapsulated in /usr/local/gromacs-XXX/

If your problems persist please provide more details.

epinephrine commented on 2016-07-14 08:55

Thanks for the PKGBUILD!
There's one odd thing though. Am I the only one whose installation prefix specification is totally ignored by Cmake?
In build() cmake is run with -DCMAKE_INSTALL_PREFIX=/usr/. But that is totally ignored, as is revealed during package(): gromacs was still installed into ${pkgdir}/usr/local/gromacs, not ${pkgdir}/usr, so I had to replace all instances of /usr with /usr/local/gromacs.

hseara commented on 2015-07-15 12:21

1) Now tests are run by default. If you do not want them comment out the "make check" lines.
2) License has been corrected to LGPL
3) Specific SIMD is not longer enforced. Gromacs will detect the best for your system. If you have any problem with this modify march=native in the /etc/makepkg.conf
4) I have cleaned the PKGBUILD and some options which are default
5) I will like to keep both double and single compilation together as many times double are also required especially for minimizing. In the future we might consider a separated split package.
6) I want to minimize the usage of AUR-libraries, that's why I won't make default fftw-bettersimd. You can also make another package, Eg. gromacs-fftw-bettersimd, to incorporate your changes if you want to.

hseara commented on 2015-07-15 12:20

1) Now tests are run by default. If you do not want them comment out the "make check" lines.
2) License has been corrected to LGPL
3) Specific SIMD is not longer enforced. Gromacs will detect the best for your system. If you have any problem with this modify march=native in the /etc/makepkg.conf
4) I have cleaned the PKGBUILD and some options which are default
5) I will like to keep both double and single compilation together as many times double are also required especially for minimizing. In the future we might consider a separated split package.

jbarnett commented on 2015-07-14 20:15

FYI any who are trying to enable tests replace "make test" with "make check".

jbarnett commented on 2015-07-14 20:07

Thanks for the response. Concerning the test, don't comment out "make test", because that is not the correct command. Just replace it with "make check".

hseara commented on 2015-07-11 18:27

1) Tests do not work for everybody and If you want to pass them nothing forbids you to pass them. Just edit the PKGBUILD before building
2) I want to minimize the usage of AUR-libraries, that's why I won't make default fftw-bettersimd. Still every user is free to change the dependency if he wants before deleting it. You can also make another package, Eg. gromacs-fftw-bettersimd, to incorporate your changes if you want to.
3) I will like to keep both double and single compilation together as many times double are also required especially for minimizing.
4) I will change the licence to LGPL as you say.

jbarnett commented on 2015-06-25 01:27

Here's my suggested PKGBUILD:
https://gist.github.com/wesbarnett/6d521b66301ebe9eb786

Then people can follow the wiki article if the want double precsion, MPI, GPU, etc.

jbarnett commented on 2015-06-16 23:46

Sorry to keep commenting, the license should be LGPL, not GPL. Also "make check" works for me, not "make test".

jbarnett commented on 2015-06-16 23:10

A GROMACS-enhanced fftw library is now available in AUR as "fftw-bettersimd".

Also a few thoughts: GROMACS should detect the appropriate SIMD instructions for your processor, so that flag probably doesn't need to be set. Also, is -DGMX_OPENMP a real flag? I can't find it in the documentation. I also think that a better default would be better to just have it compile for single precision, since most people don't need double precision. I'm currently working on the GROMACS wiki page.

jbarnett commented on 2015-06-16 23:10

A GROMACS-enhanced fftw library is now available in AUR as "fftw-bettersimd".

Also a few thoughts: GROMACS should detect the appropriate SIMD instructions for your processor, so that flag probably doesn't need to be set. Also, is -DGMX_OPENMP a real flag? I can't find it in the documentation. I also think that a better default would be better to just have it compile for single precision, since most people don't need double precision. I'm currently working on the GROMACS wiki page [[GROMACS|here]].

jbarnett commented on 2015-06-16 22:54

One other thing - you shouldn't have to set SIMD instructions unless you get an error, so that probably should be removed. By default GROMACS chooses the best (http://www.gromacs.org/Documentation/Installation_Instructions_5.0#simd-support).

jbarnett commented on 2015-06-16 20:08

One suggestion - the current PKGBUILD has both single and double precision enabled by default. I think a more "sane" default would just be single precision since according to the GROMACS site double precision is "slower, and not normally useful." (http://www.gromacs.org/Documentation/Installation_Instructions_5.0#typical-gromacs-installation)

jbarnett commented on 2015-06-15 13:44

A GROMACS-enhanced fftw library is now available in AUR as "fftw-bettersimd".

hseara commented on 2015-06-02 20:24

Thanks for the tip. I was always wondering how come none of the gromacs developers where unaware of this problem. Now, I see. The problem was in my side.
I will add this tip in the next release.

necomancer commented on 2015-05-30 03:56

@hseara

If you are using a haswell CPU, modify march=native in the /etc/makepkg.conf:

https://wiki.archlinux.org/index.php/Makepkg#Architecture.2C_compile_flags

would sovle the problem, anyway, the gromacs recommends AVX2_256 enabled if a haswell CPU was used.

jbarnett commented on 2015-05-24 02:03

5.0.5 has been released

hseara commented on 2015-01-13 12:15

IMPORTANT NOTE:
- if you have a rather new INTEL CPU you might encounter that gromacs does not compile spiting errors related to AVX2_256. They look like this:

#####
/tmp/yaourt-tmp-hector/aur-gromacs/src/gromacs-5.0.4/src/gromacs/simd/vector_operations.h:157:1: note: The ABI for passing parameters with 32-byte alignment has changed in GCC 4.6
gmx_simd_iprod_d(gmx_simd_double_t ax, gmx_simd_double_t ay, gmx_simd_double_t az,
^
In file included from /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include/immintrin.h:41:0,
from /tmp/yaourt-tmp-hector/aur-gromacs/src/gromacs-5.0.4/src/gromacs/simd/impl_x86_avx2_256/impl_x86_avx2_256.h:40,
from /tmp/yaourt-tmp-hector/aur-gromacs/src/gromacs-5.0.4/src/gromacs/simd/simd.h:118,
from /tmp/yaourt-tmp-hector/aur-gromacs/src/gromacs-5.0.4/src/gromacs/gmxlib/bondfree.c:62:
/tmp/yaourt-tmp-hector/aur-gromacs/src/gromacs-5.0.4/src/gromacs/simd/impl_x86_avx2_256/impl_x86_avx2_256.h: In function ‘gmx_simd_cvt_dib2db_avx2_256’:
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/include/avxintrin.h:1441:1: error: inlining failed in call to always_inline ‘_mm256_castpd128_pd256’: target specific option mismatch
_mm256_castpd128_pd256 (__m128d __A)
...
####

If this is your case just edit both cmake commands, one for sigle another for double precision, in the build function with:
-DGMX_SIMD=AVX_256



dotsdl commented on 2014-12-28 16:15

Thanks duca for establishing and maintaining this pkgbuild! It's been a real help. Thanks to hseara for taking it up!

duca commented on 2014-12-26 16:27

Guys, I am transfering this package to hseara. He's been doing most of the work keeping a functional pkgbuild already.

I was the first post of a pkgbuild for gromacs back in the 4.0.x days and i'm confident that it'll be on good hands.

hseara commented on 2014-12-09 10:45

Please, update the package with the fix below. Right now does not build.

poluyan commented on 2014-11-28 15:53

Thank you, eomarjee. Now it builds successfully!
Hope that the original PKGBUILD file will be modified.

eomarjee commented on 2014-11-28 10:00

47c47
< install -D -m755 ${srcdir}/${pkgname}-${pkgver}/scripts/completion.bash "${pkgdir}/usr/share/bash-completion/completions/gromacs"
---
> install -D -m755 ${srcdir}/${pkgname}-${pkgver}/src/programs/completion/gmx-completion.bash "${pkgdir}/usr/share/bash-completion/completions/gromacs"

Methylzero commented on 2014-11-07 10:59

This package has failed to build on my system. I am not sure why.

-- Installing: Creating symbolic link /tmp/yaourt-tmp-manjarouser/aur-gromacs/pkg/gromacs/usr/bin/g_wheel_d
install: cannot stat ‘/tmp/yaourt-tmp-manjarouser/aur-gromacs/src/gromacs-5.0.2/scripts/completion.bash’: No such file or directory
==> ERROR: A failure occurred in package().

duca commented on 2014-07-04 13:59

In the lab i work we dont usually even update unless an important bug is found on the one we use or some important feature is released with a new version.

Our upgrade from 3 to 4 was quite bumpy and even within the first releases of the 4 series.



Anyway thank you for your feedbacks, guys.

hseara commented on 2014-07-02 05:27

Please do not update to gromacs5 until the developers consider it suitable for production runs. Right now this is not the case. Notice for example the note in the download section where clearly states: "Please note that these are not yet regarded as production quality, pending further testing, but the code is now feature-stable."

In my humble opinion and with the experience in the transition from gromacs3 to gromacs4 it will take at least one or more releases to be safe to use for production quality runs. I think we should wait until then a bit for the update and in the mean while keep in the 4.6 branch. Soon there will be an update 4.6.6 will includes all bug fixes in gromacs5.

dotsdl commented on 2014-07-02 00:55

Gromacs 5.0 just came out a couple of days ago; no rush, but I flagged the package as out of date for this reason.

duca commented on 2013-04-26 03:06

Sorry for the delay

hseara commented on 2013-04-18 15:19

Hi, it is the second time I put out of date the package. Please update it.

Anonymous comment on 2013-04-08 08:34

Hi,
after running into some problems like missing permission to edit /pkg and folders getting created to early, i had to modify the PKGBUILD.

If anyone has similar problems, maybe this can help:
http://codepad.org/gmVjykgp

This is my first PKGBUILD, so please tell me if something could be done better.

quizzmaster commented on 2012-11-24 23:30

May you add the fix for usind do_dssp with last dssp version?

Thats the way i did it:
git clone git://git.gromacs.org/gromacs.git
git checkout --track -b release-4-5-patches origin/release-4-5-patches

duca commented on 2012-05-14 19:52

@josephgbr
Thanks for sharing the new completion directory. hseara added ckame to makedepends
completion.* is there due to gromacs dev discretion but the new package will remove them (it was like this a awhile ago).

@hseara
a) I got your point, i misread your previous pkgbuild.
b) I had this problem a while ago and never and never tried again using n>4.
c) This is not my assumption, it's an upstream assumption (just check your /etc/profile.d and you'll see only .csh and .sh files in there). I dont mind moving all GMXRC.* scripts to that location (and patch GMXRC to updated location of GMXRC.*) and let /usr/bin with only gromacs executables

At first i thought you were just having your time because of my comments on your package, but i do not think like this anymore. Actually i appreciate your comments, they help me improve the quality of my packages in the end.

hseara commented on 2012-05-12 08:45

Here is the new PKGBUILD with cmake in makedepends

http://codepad.org/VLnCPrEJ

PD: Our packages have been already merged

rafaelff commented on 2012-05-12 08:01

Some comments on this package:
* 'cmake' is missing in makedepends.
* if you decide to use doxygen, then add it to makedepends as well
* 'bash-completion' directory changed to /usr/share/bash-completion/completions/ (WTH is /usr/bin/completion.* doing in /usr/bin ?)

ConnorBehan commented on 2012-05-12 01:01

hseara commented on 2012-05-12 00:42

I will try to answer in order:
a) No you are wrong you don't need two copies. Cmake copies everything you need to the single and double directory. Please realize that you make make installs in them. Please read carefully the PKGBUILD I sent you because I have the feeling you did not understand the point. Moreover, I have tested it and it works perfectly. If not please let me know what is the problem.
b) Regarding -j2, David van der Spoel, Ph.D. one of the main gromacs developer compiles gromacs with 32 cores, at least it is what he always says. Myself I have always, more than 10 years, compile with the maximum amount of cores and I have never seen a problem. If you see any problem please fill a bug report upstream as it is really an important issue that no one I know so far has encounter. So unless you can backup your claim you should definitely remove "-j2".
c) Regarding GMXRC. You are assuming that everybody uses bash as a main interpreter. It is very likely that you are right but it might not be the case. The beauty of sourcing in /etc/profile.d/GMXRC is that it will select the appropriated script for the used interpreter. By the way be aware that this files are changed in the compilation to match the installation paths. That's why I use the move command. So I do not understand the problem you expose, but if you know any other better way to do the same I do not have any problem.
d) Yes, we definitely need to merge this two packages. I will ask the merge tomorrow.
Thanks, and please do not see in my comments any bad intentions. I just want to help to have the best package for everybody.

duca commented on 2012-05-11 14:56

Strange, the suffixes in this release are definatelly a typo for the first thing i did was to remove them all. I believe while i was adding the comments i brought them back.

Aesthetically i agree that the cleaner the better, not many packages out there are clean in the sense of number of lines nor in their solutions to correctly build their packages. If you follow the discussion list you have alredy read some debate. But in this case if you run cmake (and make) twice before 'make install', it will remove the previous 'make' and you lose half of the work so separating single and double sources is required.

Does it compile correctly using 12 cores? Using 8 or 16 on some of our machines the resulted binnaries were buggy and for that reason i added -j2 a long time ago before gromacs was first added to COMMUNITY (and never taken them away hehe) and kept -j'n' in makepkg.conf to build other packages that were not problematic.

I agree with the merge, but MV is not the adequate solution to send GMXRC to profile.d and GMXRC is supposed to be a script which sources GMXRC.bash or else. I could patch GMXRC to install the correct script (to profile.d) instead of sourcing it and run it using a 'post install' directive (gromacs.install) or add GMXRC.csh and GMXRC.bash to profile.d as some packages do (firefox and xorg-server for instance).

duca commented on 2012-05-11 14:48

Strange, the suffixes in this release are definatelly a typo for the first thing i did was to remove them all. I believe while i was adding the comments i brought them back.

Aesthetically i agree that the cleaner the better, not many packages out there are clean in the sense of number of lines nor in their solutions to correctly build their packages. If you follow the discussion list you have alredy read some debate. But in this case if you run cmake (and make) twice before 'make install', it will remove the previous 'make' and you lose half of the work so separating single and double sources is required.

Does it compile correctly using 12 cores? Using 8 or 16 on some of our machines the resulted binnaries were buggy and for that reason i added -j2 a long time ago before gromacs was first added to EXTRA (and never taken them away hehe) and kept -j'n' in makepkg.conf to build other packages that were not problematic.

I agree with the merge, but MV is not the adequate solution to send GMXRC to profile.d and GMXRC is supposed to be a script which sources GMXRC.bash or else. I could patch GMXRC to install the correct script (to profile.d) instead of sourcing it and run it using a 'post install' directive (gromacs.install) or add GMXRC.csh and GMXRC.bash to profile.d as some packages do (firefox and xorg-server for instance).

hseara commented on 2012-05-10 14:44

Regarding the doxygen documentation, I will definitely make a different package. The issue is that I'm not sure if there is any official rules for placing such documentation. So I guess any guess that you make is as good as mine.

hseara commented on 2012-05-10 14:40

I have revised your changes and simplified some redundant lines and clean all commented code of from the PKGBUILD. You can find the PKGBUILD in the following link:

http://codepad.org/3AYnhgHC

Just a note. In AUR the packages should be as clean as possible and you must agree that this is much more clean that yours (Easy to read). Besides, the part you commented out is never going to be used by anybody, at least in my opinion, and difficult significantly the reading. Most likely, nobody will even understand what is the propose of this lines besides you and me. If you really want to make it useful I think you should better consider to make different packages for each of the gromacs versions available as I have done. Still I continue saying that putting suffixes is a pretty bad idea as you limit the usage of scripts and changing between gromacs versions is as easy as sourcing the correspondent GMXRC file.

I have also taken away the -j2 from the make line as this has to be configured in /etc/makepkg.conf and changes with each one computer. For example, with your setup I only use two cores out of the 12 that my computers have :).

You don't have to copy the data to a different directory. cmake does everything for you.

I moved GMXRC to /etc/profile.d/ after compilation. This is very important as will certainly set properly all the libraries, otherwise in certain occasion I get some compiling errors when programming against gromacs. Moreover, it allows you to reset the gromacs in case you use different versions: "source /etc/profile.d/GMXRC"

If you agree with all this changes I will merge the gromacs-complete package with yours as they will be now completely equivalent and there is not sense to maintain both. Thanks in advance.

duca commented on 2012-05-09 14:55

Hello hseara, i appreciate the comments and i understand your concerns. To address each one

I was trying to find a way to let users update their packages without having to uninstall the previous one, since i did not find anything (nor had the time to search decently for a solution) i agree the scheme is convoluted and, therefore, unnecessary but i'll leave some of the original lines commented as reference in case someone (as i will probably do) decides to install different versions in /usr/local.

Being the main package (i am not very fond of the term) it is required to be under /usr (not /usr/local) so you are right about this one. And what about the doxygen documentation?

hseara commented on 2012-05-09 08:55

After the recent changes in your package is not really usable for many of us. I hope I can make myself clear.

First you have added suffixes to the binaries. This detail that you might find important to identify the used version lead to two problems. A) The most important, scrips calling the executable by their normal names do not work, e.i. mdrun->mdrun_455. So I'm afraid I will have to continue using my own versions of gromacs for real job, I don't want to have to edit the scripts every time there is a new gromacs version. B) The people that installs the package and do not know what you have in mind gets confuse by the strange naming scheme, e.i. They can not follow any gromacs tutorial. And aside is not really needed because gromacs when you execute any of its executables tells which version is being used.

The second problem is the installation path. You are now putting everything in "/usr/local" as I'm doing. As you know that goes against the arch ways.

I would like to propose you the following: let's keep your package as the main one containing the latest version installed in "/usr" and without sufixes (Only "_d"), and aside we can make new packages with different gromacs versions that can be installed in "/usr/local" and therefore do not interfere with the main package, your package. In this way I guess everybody will be happy as to use them you only have to source /usr/local/gromacs/gromacs-x.x.x/bin/GMXRC.{bash,sh,zsh}. What do you think?

duca commented on 2012-04-11 17:32

Now gromacs is installed on a private directory under /usr/local/gromacs_version with custom binary and scripts names (bash completion and profile). It does not make use of mpi in this version, only threads.

duca commented on 2012-02-16 20:30

Actually I included the hseara changes and added a few improvements of my own a while back. Unless i forgot something and it this is the case, point me to what i missed :)

xyproto commented on 2012-02-15 16:43

Great initiative hseara. Just leave a comment to me on either package if you come to an agreement with duca, and I can merge them. For the record, I'm for /usr and against /usr/local, if that is possible, since that's the standard for Arch packages, if that does not inconvenience the user too much.

xyproto commented on 2012-02-15 16:43

Great initiative hseara. Just leave a comment to me on either package if you come to an agreement with duca, and I can merge them. For the record, I'm for /usr and against /usr/local, if that is possible, since that's the standard for Arch packages.

xyproto commented on 2012-02-15 16:19

Great initiative hseara. Just leave a comment to me on either package if you come to an agreement with duca, and I can merge them.

hseara commented on 2012-02-15 10:58

Hi, I did not realized until now that gromacs was kick out from [community].Why don't we merge both packages, mine[gromacs-complete] and yours [gromacs].
In this case, I don't see any inconvenient to change the intallation directory to /usr instead of /usr/local that right now point out my configuration file. Have a look in my PKGBUILD if you agree and we can arrange the details of the merge. I personally prefer to have both single and double precision. Also might be interesting to add the doxygen documentation or this as well as the sources can be a different package.

duca commented on 2012-01-05 21:47

Perhaps you should document better (by a .install script maybe?) how you switch between versions because there's an expected set of locations and what you used. Please take no offense in my previous message cause i dont mean any. How most of 'normal' users use gromacs (and i work with it for a long time by now) is not subject to assumption. Populating /usr/local is not against the fhs as AL implements it. NOTE ASIDE: I dont recal my different installed versions interfering with each other (i have 3.3.3 and 4.0.7 on most of the lab machines).

hseara commented on 2011-12-27 09:24

There are two reasons. The first is to make it compatible with the community gromacs package. This package installs both single and double precision executable. Therefore the single precision executables will conflict with the official gromacs package. Right now I do not want to add this package as a replace or conflict of the community package. Still just to be consistent between installed versions of single and double precision I want to install both. The second reason is that I use intensively gromacs for my work and because of its porpoise I often require to have installed different versions (most of normal users have this need). I want to remind at this point that this is a publication quality scientific software and changing the versions inside a given project can introduce some uncertainties when comparing between systems (That's a pity but it is the reality). Having it as a whole in /usr/local/gromacs/gromacs-x.x/ allows you to use a given version easy by sourcing the /usr/local/gromacs/gromacs-x.x/bin/GMXRC.bash file, this file in the community gromacs version is deleted. This difficult significantly the usage of different gromacs versions and for normal users the workflow in general. NOTE ASIDE: My installer uses CMAKE for building and not MAKE which is deprecated and might disappear at any time in a future version.

duca commented on 2011-12-26 21:05

Hello hseara,
Is there any particular reason to prefix it to /usr/local when the archlinux default is /usr.

xyproto commented on 2011-12-14 17:26

Moved from [community] in connection with the Christmas Cleanup https://wiki.archlinux.org/index.php/Christmas_Cleanup.