Package Details: gromacs 2019.3-2

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: 19
Popularity: 0.344272
First Submitted: 2011-12-14 17:03
Last Updated: 2019-06-26 15:38

Pinned Comments

hseara commented on 2019-04-15 20:13

Installation notes

With cmake update to v3.14.x, gromacs is no longer capable of identifying correctly the CPU and therefore the appropriated SIMD level for compilation. If you want to compile gromacs with SIMD while the problem is not solved add the following option to PKGBUILD:

-DGMX_SIMD={AVX_128_FMA, AVX_256, AVX2_256, AVX2_128, AVX_512}

The KEYWORD depends on the SIMD support provided by your CPU.

Usage notes
source /etc/profile.d/GMXRC.bash

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 Next › Last »

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?