Package Details: gromacs 2020.4-1

Git Clone URL: https://aur.archlinux.org/gromacs.git (read-only, click to copy)
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: 20
Popularity: 0.000872
First Submitted: 2011-12-14 17:03
Last Updated: 2020-10-14 19:35

Dependencies (12)

Required by (1)

Sources (1)

Latest Comments

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

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.