Package Details: gromacs 2023.2-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/
Keywords: chemistry science simulations
Licenses: LGPL
Submitter: xyproto
Maintainer: hseara (vedranmiletic)
Last Packager: vedranmiletic
Votes: 24
Popularity: 0.000342
First Submitted: 2011-12-14 17:03 (UTC)
Last Updated: 2023-08-04 19:09 (UTC)

Dependencies (11)

Required by (1)

Sources (1)

Latest Comments

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

hseara commented on 2012-05-09 08:55 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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.

hseara commented on 2012-02-15 10:58 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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

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