Package Details: gromacs 2024.4-2

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-2.1-only
Submitter: xyproto
Maintainer: hseara (vedranmiletic)
Last Packager: vedranmiletic
Votes: 23
Popularity: 0.000001
First Submitted: 2011-12-14 17:03 (UTC)
Last Updated: 2024-11-08 05:39 (UTC)

Dependencies (14)

Required by (1)

Sources (1)

Latest Comments

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

duca commented on 2012-05-11 14:56 (UTC)

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).

hseara commented on 2012-05-10 14:44 (UTC)

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

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

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 (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.

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