Hi! I attached a ebuild for GROMACS 3.3 which is the current version of GROMACS. The existing ebuild has old dependencies. From the gromacs homepage: "You need an FFT library to perform Fourier transforms. Gromacs-3.3 and later versions support FFTW-2.1.x, FFTW-3.x (different interface from version 2), Intel Math Kernel library version 6.0 and later, and we also have a slower built-in version of FFTPACK in case you really don't want to install a good (free) library. [...] Starting with Gromacs-3.3 we no longer rely on the FFTW version of parallel transforms, so you don't need to worry about MPI versions of the libraries." I updated all dependencies to the recomended versions. Also i deleted configure options, which are not supported any more. Rene
Created attachment 76647 [details] the updated ebuild
Could you please attach a diff against the original ebuild?
Created attachment 76688 [details] the diff file this is the diff to the gromacs-3.3.ebuild; the fftw 2.1 dependencie is not needed, because if fftw3 is installed the configure script uses fftw3; about the patch im not sure, but the file does not exist any more in the new version. i think this patch applys only to gromacs 3.2
Whoa, I'm sorry I forgot to mention it but can you please use the unified diff format (diff -u)? It's actually readable.
Created attachment 76697 [details] diff -u output
Hi, Some comments: Why dep change from >=sys-devel/binutils-2.10.91.0.2 to >=sys-devel/binutils-2.16? + $(use_enable 3dnow ia32-3dnow) \ + $(use_enable sse2 ia32-sse) \ ^^ Will obviously be broken on the other archs that gromacs works for and sse2/3dnow aren't in use.mask (in other words, amd64, which requires different assembly). Also why did you remove the other arch-specific optimization? - $(use_enable alpha axp-asm) || die "configure failed" Thanks!
ok, you are right. binutils 2.16 may be too new as requirement. gromacs suggests 2.12 for SSE in linux "Since Gromacs 3.3 includes some code to prepare for multithreading parallelization, we need a slightly newer binutils than before. The configuration script will check this for you, and complain load if your version is too old. GNU Binutils 2.12 and later are know to work, but some earlier ones might also be OK - it is checked by the configuration script, which will complain loud if there is a problem." because binutils is at least 2.14 in portage now this will not be an issue. i will change this. now the optimizations: $(use_enable alpha axp-asm) deleted because there is no configuration option in the configure script and configure --help says: "--enable-fortran use fortran (default on sgi,ibm,sun,axp)" the assembler optimisations of the other archs: possible assembler optimisation flags are: --enable/disable-ia32-3dnow 3DNow! assembly loops on ia32 --enable/disable-ia32-sse SSE/SSE2 assembly loops on ia32 --enable/disable-ppc-altivec Altivec loops on PowerPC these options are covered by the ebuild. if you have a look in /usr/portage/profiles/use.desc you will find: 3dnow - Adds support for 3dnow multimedia processor instructions altivec - Adds support for optimizations for G4 and G5/ppc970 processors sse - fast floating point optimization for PentiumIII+ class chips sse2 - faster floating point optimization for SSE2 capable chips but you are right there are two additional configure options: --enable/disable-x86-64-sse SSE assembly loops on X86_64 --enable/disable-ia64-asm build assembly loops on ia64 these are not covered by the ebuild. but they are not covered by the old ebuild too. we have two possibilities now. let the configure script detect all optimisations or change the method for setting configure options in the ebuild. i will attach a solution for the second possibilitie. rene
Created attachment 76717 [details] ebuild with fixed assembler optimisation for all arch
Created attachment 76718 [details] the diff -u output
i also integrated the ia64 assembly loops flag in the new ebuild but i can only test x86 rene
i found another problem in the 3.3 version of the gromacs ebuild. if we use the --datadir option to configure the topology files are not installed in the place where gromacs expects them. the files are in /usr/share/gromacs-3.3/gromacs and gromacs searces in /usr/share/gromacs. if we do not specify --datadir=/usr/share/${P} everything works fine. also the html docs are not moved to the right place. rene
Created attachment 77009 [details] gromacs-3.3-r1.ebuild this ebuild fixes the datadir problem, docs are now in doc directory. it runs all benchmarks from the gromacs homepage on x86 with mpi and without mpi
Created attachment 77010 [details] diff -u output
Created attachment 78732 [details] gromacs-3.3-r1 with threads and double precision Gromacs support threads and can be compiled in double precision Now It can be enabled with use flags On x86 and em64t xeons works fine see atachment
By the way how about qmmm implentation in gromacs via use flags. For example with mopac7?
Sorry for the delay on this, I've been sidetracked with other work.
the threads use flag should work and is in use.desc, but i dont know how it works with mpi. can you use threading together with mpi? how do you tell gromacs how to split systems? there is no double use flag. is it allowed to create new use flags?
/usr/portage/profiles/use.local.desc:dev-games/ode:double-precision - more precise calculations at the expense of speed /usr/portage/profiles/use.local.desc:dev-games/ogre:double-precision - more precise calculations at the expense of speed /usr/portage/profiles/use.local.desc:sci-chemistry/eden:double-precision - more precise calculations at the expense of speed
ok, there are local use flags for double. i will change the ebuild to use the flag 'double-precision'. but there is still the question with threads and mpi. how does it work together?
Created attachment 78790 [details] ebuild with use 'double-precision threads'
i tryed to install with USE='threads', but it fails. i686-pc-linux-gnu-gcc -O3 -march=pentium4 -mfpmath=sse -msse -msse2 -mmmx -pipe -o mdrun glaasje.o gctio.o init_sh.o ionize.o do_gct.o relax_sh.o repl_ex.o xutils.o md.o mdrun.o genalg.o ../mdlib/.libs/libmd.a ../gmxlib/.libs/libgmx.a -lnsl /usr/lib/libfftw3f.so -lm /usr/lib/libXm.so -lXmu -lXt -lSM -lICE -lXext -lXp -lX11 ../gmxlib/.libs/libgmx.a(nb_kernel010_c.o): In function `nb_kernel010': nb_kernel010_c.c:(.text+0x39): undefined reference to `gmx_thread_mutex_lock' nb_kernel010_c.c:(.text+0x6a): undefined reference to `gmx_thread_mutex_unlock' ../gmxlib/.libs/libgmx.a(nb_kernel010_c.o): In function `nb_kernel010nf': nb_kernel010_c.c:(.text+0x35a): undefined reference to `gmx_thread_mutex_lock' nb_kernel010_c.c:(.text+0x389): undefined reference to `gmx_thread_mutex_unlock' ../gmxlib/.libs/libgmx.a(nb_kernel020_c.o): In function `nb_kernel020': nb_kernel020_c.c:(.text+0x39): undefined reference to `gmx_thread_mutex_lock' nb_kernel020_c.c:(.text+0x68): undefined reference to `gmx_thread_mutex_unlock' ../gmxlib/.libs/libgmx.a(nb_kernel020_c.o): In function `nb_kernel020nf': .... nb_kernel410_c.c:(.text+0x5f3): undefined reference to `gmx_thread_mutex_lock' nb_kernel410_c.c:(.text+0x624): undefined reference to `gmx_thread_mutex_unlock' ../gmxlib/.libs/libgmx.a(nb_kernel430_c.o): In function `nb_kernel430': nb_kernel430_c.c:(.text+0x60): undefined reference to `gmx_thread_mutex_lock' nb_kernel430_c.c:(.text+0x8f): undefined reference to `gmx_thread_mutex_unlock' ../gmxlib/.libs/libgmx.a(nb_kernel430_c.o): In function `nb_kernel430nf': nb_kernel430_c.c:(.text+0x681): undefined reference to `gmx_thread_mutex_lock' nb_kernel430_c.c:(.text+0x6b0): undefined reference to `gmx_thread_mutex_unlock' collect2: ld returned 1 exit status make[3]: *** [mdrun] Error 1 make[3]: Leaving directory `/var/tmp/portage/gromacs-3.3-r1/work/gromacs-3.3/src/kernel' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/gromacs-3.3-r1/work/gromacs-3.3/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/tmp/portage/gromacs-3.3-r1/work/gromacs-3.3/src' make: *** [all-recursive] Error 1 !!! ERROR: sci-chemistry/gromacs-3.3-r1 failed. !!! Function src_compile, Line 71, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message. ...done! >>> emerge (1 of 1) sci-chemistry/gromacs-3.3-r1 to / >>> md5 files ;-) gromacs-3.3-r1.ebuild >>> md5 files ;-) files/digest-gromacs-3.3-r1 >>> md5 src_uri ;-) gromacs-3.3.tar.gz i will look into this
According to gromacs mailing list threading is not implemented at the moment. I removed the thread use flag and the --enable-thread during configure. I changed the way, how the use flags are handled. By default the application is build in single precision without mpi. If USE="mpi" is set, only the executable mdrun is build and installed aditionaly with suffix "_mpi". This seems more sophisticated to me. mdrun is the only program in this package, which depends on mpi. If USE="double-precision" is set, all programs in this package are built in double precision and installed with suffix _d additionally to the single precision binarys. The double precision mdrun with mpi support is called "mdrun_mpi_d". I tested this ebuild on x86. Everything works fine for me.
Created attachment 79223 [details] gromacs-3.3 ebuild
I would suggest to use either the CVS-Version or to add a patch which corrects a serious error in PME that puzzled me for two days now. I found this in the gromacs mailing list: http://www.gromacs.org/pipermail/gmx-users/2006-January/019195.html I used your ebuild then to compile the latest CVS checkout and now I'm able again to calculate with PME. Mathias
i created a patch as suggested on the mailing list. mathias could you please test the new ebuild with the patch. thanks
Created attachment 79235 [details, diff] the pme patch
Created attachment 79236 [details] ebuild including the patch
(In reply to comment #25) > i created a patch as suggested on the mailing list. mathias could you please > test the new ebuild with the patch. thanks I tested it (without mpi,single prec.) on two machines (athlon xp and pentium 4) and my test job (protein in a membrane with PME) is still running (thats good). If I find some time I will also test mpi runs. I think you should put at least some "einfo" into the ebuild about fftw. I recognized that you didn't specify "--with-fft=fftw3" but configure found it anyway. But if you don't have fftw installed the ebuild should issue a warning or something similar (although gromacs would run without fft - but without PME) Maybe one could switch through some USE-flags like "fttw2, fftw3, fftpack, mkl"?
(In reply to comment #28) > I think you should put at least some "einfo" into the ebuild about fftw. I > recognized that you didn't specify "--with-fft=fftw3" but configure found it > anyway. But if you don't have fftw installed the ebuild should issue a warning > or something similar (although gromacs would run without fft - but without PME) > > Maybe one could switch through some USE-flags like "fttw2, fftw3, fftpack, > mkl"? Is there any actual reason to use fftw2 instead of 3? I don't see a good reason to not just hard-dep on version 3. What would you do with the mkl flag?
(In reply to comment #29) > (In reply to comment #28) > > Maybe one could switch through some USE-flags like "fttw2, fftw3, fftpack, > > mkl"? >Is there any actual reason to use fftw2 instead of 3? I don't see a good reason > to not just hard-dep on version 3. Ok, fftw3 is seriously better than fftw2 and fftpack - you are right. > What would you do with the mkl flag? Gromacs allows for the use of Intels MKL >= version 6 instead of fftw. The configure switch would be --with-fft=mkl I haven't tested it yet, but to have gromacs optimized as much as possible is really important to my group, as a job can run for a month or longer
if your are interested in the performance of fftw3 you can check out http://www.fftw.org/benchfft/ . fftw3 performs better on pentium4 and athlon64 in nearly all benchmarks(intel mkl 8.x is included). there should be no need to worry about the fft implementation. fftw3 is a good choice. and i think we need no einfo about fftw3, because fftw is in the dependencies of the ebuild. but maybe we need an einfo about the names of the executables.
gromacs version 3.3.1 was released on April 5, 2006. please find the ebuild for the new version attached. the PME patch is included in this release.
Created attachment 84258 [details] gromacs-3.3.1.ebuild
Could you attach a unified diff against the current ebuild in portage?
Created attachment 84350 [details] diff against gromacs-3.3.ebuild from portage
Created attachment 84370 [details] case-break.sh Some comments and questions on the ebuild: Where has the ~ia64 keyword come from? We can't add that until we test on it. Instead of using the flag variable and usev() (which shouldn't be used, use() instead), you can just use the ${ARCH} variable in the case statement. Also new gromacs works w/ fftw-2 or -3, right? But with fftw-2, don't we still need to do the fftw with mpi check? Why has the minimum binutils version changed? How does --enable-fortran ever get enabled on any keyworded arch? bash case statements have an implied break. I attached a sample script. The die()'s could use better messages (or in some case, messages at all) to go along with them, e.g. die "single-precision emake failed". Specific is the key, if there are 4 configures, then a "configure failed" doesn't narrow things down enough. Why do the mdrun make's use 'make' rather than 'emake'? Thanks!
Thanks for your comments. > Where has the ~ia64 keyword come from? We can't add that until we test on it. My fault. It is not allowed to put KEYWORDS for not tested arch in the ebuild. I'll remove this. But maybe we can let the configuration part of ia64 as comment in the ebuild. If someone tests on ia64 it would default to --enable-fortran, which is slower. If its not allowed to have code in the ebuild, which would never be reached on the keyworded arch, we'll have to delete the default case too. But i think every case statement should have a default branch. > Instead of using the flag variable and usev() (which shouldn't be used, use() > instead), you can just use the ${ARCH} variable in the case statement. ${ARCH} was not documented in gentoo Ebuild HOWTO. I'll change this. Is there a better source of documentation? > Also new gromacs works w/ fftw-2 or -3, right? But with fftw-2, don't we still > need to do the fftw with mpi check? Do we really need to mess around with fftw-2? the gromacs developer had a lot of work to port this to fftw-3. and fftw-3 is available for all keyworded arch. > Why has the minimum binutils version changed? The gromacs installation instructions homepage suggests binutils-2.12 for SSE support. But binutils is at least 2.14 in portage. I think we can remove the binutils dependencie. I got a question to dependencies. There is no clear statement about this in the gentoo Ebuild HOWTO. If my package depends on foo and foo depends on bar, do i need to put bar in DEPEND of my package? If not we can remove binutils from DEPEND, because we need binutils for gcc and gcc for nearly all packages. > How does --enable-fortran ever get enabled on any keyworded arch? bash case > statements have an implied break. I attached a sample script. first answer... > The die()'s could use better messages (or in some case, messages at all) to go > along with them, e.g. die "single-precision emake failed". Specific is the key, > if there are 4 configures, then a "configure failed" doesn't narrow things down > enough. I'll add better descriptions. > Why do the mdrun make's use 'make' rather than 'emake'? There is no reason. i'll change this i'll add a corrected version and a diff against the ebuild in portage
Created attachment 84429 [details] diff against gromacs-3.3.ebuild from portage
Created attachment 84430 [details] gromacs-3.3.1.ebuild
(In reply to comment #37) > Thanks for your comments. > > Instead of using the flag variable and usev() (which shouldn't be used, use() > > instead), you can just use the ${ARCH} variable in the case statement. > ${ARCH} was not documented in gentoo Ebuild HOWTO. I'll change this. Is there a > better source of documentation? Doubtful. Just some things haven't ever been documented because they're rarely used, not favored, etc. > > Also new gromacs works w/ fftw-2 or -3, right? But with fftw-2, don't we still > > need to do the fftw with mpi check? > Do we really need to mess around with fftw-2? the gromacs developer had a lot > of work to port this to fftw-3. and fftw-3 is available for all keyworded arch. Then let's change the dep to minimum of 3. > > Why has the minimum binutils version changed? > The gromacs installation instructions homepage suggests binutils-2.12 for SSE > support. But binutils is at least 2.14 in portage. I think we can remove the > binutils dependencie. I got a question to dependencies. There is no clear > statement about this in the gentoo Ebuild HOWTO. If my package depends on foo > and foo depends on bar, do i need to put bar in DEPEND of my package? Not unless you need a newer version of bar than foo requires.
Does this new ebuild fix this problem i'm having with the current gromacs-3.3 ebuild in portage: --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/var/log/sandbox/sandbox-sci-chemistry_-_gromacs-3.3-28332.log" symlink: /usr/lib/libgmxana.a -------------------------------------------------------------------------------- ?
im not sure. but as a quick workaround you can unmerge your old gromacs before mergeing the new one.
I thought about doing that, but I saw that file doesn't even exist currently where it said there was a clash.
hi, this note is for the maintainer of the gromacs package. the ebuild in portage does note take care about the things i have pointed out here. it still depends on fftw2, which is not necessary. it wastes performance by not using the asm optimisation. the asm optimised versions compile fine with gcc4. i will atach a version which checks the fortran compiler in cases, where it is needed.
Created attachment 96153 [details] ebuild for gromacs-3.3.1
Hallo Rene As you noted in your ebuild all AMD64 processors are capable of sse (and sse2). Moreover all mmx, 3dnow, sse and sse2 use flags are automatically filtered out and therefore your "if use sse" does not work and we end up with the fortran setup (which fails for gcc-4.1 because g77 is not detected). So this check for sse has to be removed. I've attached an fixed ebuild for amd64
Created attachment 96728 [details] ebuild fixed for amd64 with sse
hi mathias, you are right. thank you for fixing. hopefully one lucky day one of the gentoo developer will see this.
(In reply to comment #48) > you are right. thank you for fixing. hopefully one lucky day one of the gentoo > developer will see this. We're training a new developer right now who uses gromacs regularly.
Created attachment 98768 [details] Another gromacs ebuild Another gromacs ebuild with mpich enabled all binaries have no suffix
gromacs-3.3.1 (08 Aug 2006) 08 Aug 2006; Markus Dittrich <markusle@gentoo.org> +gromacs-3.3.1.ebuild: Version bump. Ebuild now inherits the fortran.eclass and forces the use of g77 since gfortran is presently missing some of the fortran intrinsics needed by gromacs. See bug #141672. So, what's this bug about now, actually?
Jeffrey, can you have a look at this? I understand you're pretty familiar with gromacs.
Okay, I'll have a look later tonight and tomorrow morning.
(In reply to comment #53) > Okay, I'll have a look later tonight and tomorrow morning. > That would be great! Thanks in advance! Best, Markus
Created attachment 103874 [details] gromacs-3.3.1-r1.ebuild Would you guys mind testing out gromacs-3.3.1-r1.ebuild? Thanks!
GMXLIB may have changed for some of you...make sure you set: export GMXLIB="/usr/share/gromacs/top" in your ~/.bashrc
Created attachment 103918 [details, diff] gromacs-3.3.1.diff diff from 3.3.1 and 3.3.1-r1
i had a look in the ebuild and i tested it on amd64 with and without mpi. and i will test it on x86 later today. i think depend should look like this: DEPEND=">=sci-libs/fftw-3.0.1 mpi? ( || ( virtual/mpi >=sys-cluster/lam-mpi-7.0.6 ) ) app-shells/tcsh X? ( || ( (x11-libs/libXext x11-libs/libXp) virtual/x11) virtual/motif) mopac7? ( sci-chemistry/mopac7 ) sparc? ( =sys-devel/gcc-3* )" there is no need to depend on lam-mpi exclusively. i tested it with openmpi and it works. the new mpi ebuilds provide virtual/mpi. the oldest version of binutils in portage is 2.14. do we realy need to put binutils in depend? the X-apps also work with openmotif. why depend on lesstif and not on virtual/motif. I can not tell anything about the qm/mm part, but i think the option to configure should be --with-qmmm-mopac. I think the check for use mpi in fftw is not necessary. fftw3 does not support mpi and the ebuild has no use flag mpi. The ppc64-altivec.patch will fail, because the files are not there. i can not test ppc so i can not tell if this patch is needed. and now two cases, where this ebuild is wrong. in case of x86 without sse and 3dnow it should default to fortran. but who wants to run gromacs on such a slow computer. so maybe this could be ignored. if one try to install gromacs on a x86 or amd64 computer where ifort is the default fortran compiler the ebuild will stop, because it expects gfortran or g77. but fortran is not needed. i dont know how to fix this in the ebuild. i will attach a version of this ebuild which works for me.
Created attachment 103944 [details] gromacs-3.3.1-r1.ebuild
You're right about mopac, and I'll look into the mpi issue with fftw and your other points tomorrow. Thanks!
from http://www.gromacs.org/gromacs/documentation/prerequisites.html "Starting with Gromacs-3.3 we no longer rely on the FFTW version of parallel transforms, so you don't need to worry about MPI versions of the libraries." More later...
(In reply to comment #61) > from http://www.gromacs.org/gromacs/documentation/prerequisites.html > > "Starting with Gromacs-3.3 we no longer rely on the FFTW version of parallel > transforms, so you don't need to worry about MPI versions of the libraries." > > More later... > this is what i reported in the first post.
Created attachment 104110 [details] gromacs-3.3.1-r1.ebuild revised to default to fortran if no sse sse2 or 3dnow. I'm interested in expanding fortran.eclass to include portland compilers, so I'll address the ifort issue later. Thanks!
hmm....I have a local copy of mopac libs that work with gromacs, but the site with files for everyone else is down for a couple of days now... http://rugmd4.chem.rug.nl/~groenhof/qmmm.html I hope it comes back soon or else mopac7 may be broken.
added gromacs-3.3.1-r1.ebuild
