Skip to content

GROMACS easyblock updated for version 5#513

Merged
boegel merged 11 commits intoeasybuilders:developfrom
wpoely86:gromacs
May 13, 2015
Merged

GROMACS easyblock updated for version 5#513
boegel merged 11 commits intoeasybuilders:developfrom
wpoely86:gromacs

Conversation

@wpoely86
Copy link
Copy Markdown
Member

@wpoely86 wpoely86 commented Dec 2, 2014

Small fix in sanity check but it doesn't work everywhere: get_platform_name() doesn't always return the correct string...

@hpcugentbot
Copy link
Copy Markdown

Test PASSed.

@sbecuwe
Copy link
Copy Markdown
Contributor

sbecuwe commented Jan 10, 2015

This gromacs.py did not succeed in installing GROMACS 5.0.4 on SL 6.6.
Error: Sanity check failed: no file of ('lib/x86_64-unknown-linux/libgromacs_mpi.a', 'lib64/x86_64-unknown-linux/libgromacs_mpi.a')
FYI: our installation has no x86_64-unknown-linux/ subdirectory of lib64

@wpoely86
Copy link
Copy Markdown
Member Author

@sbecuwe do you mean that those files are directly under lib64? Or is the platform name incorrectly detected on SL 6.6?

@sbecuwe
Copy link
Copy Markdown
Contributor

sbecuwe commented Jan 10, 2015

It is installed directly under lib64. (In our 4.6.1 tree, files were directly installed under lib.)
The platform name returned is x86_64-unknown-linux indeed.

@wpoely86
Copy link
Copy Markdown
Member Author

Okay, it seems to do the same thing on one of my test machines. It's bizar that the install dir changed on my system on some point. Might have something to do with plumed.

I'm gonna drop this PR for the time being.

@wpoely86 wpoely86 closed this Jan 11, 2015
@wpoely86
Copy link
Copy Markdown
Member Author

OK, closed a bit too soon. The situation is:

  • On RHEL & derivatives the libs end up under lib.
  • On Debian based systems, they end up under lib/x86_64-linux-gnu.

A check on Linux distro could fix this. Or figuring out why autoconf/libtool want to use a platform name subdir. The latter is probably the preferred but hardest option. If I find the time, I will have a look.

Don't merge this for the moment.

@wpoely86 wpoely86 reopened this Jan 11, 2015
@hpcugentbot
Copy link
Copy Markdown

Test PASSed.

@pescobar
Copy link
Copy Markdown
Member

I tried this one and is working great for gromacs 5.0.4. Thanks @wpoely86 !!

@wpoely86
Copy link
Copy Markdown
Member Author

@pescobar on what distro did you try it?

Comment thread easybuild/easyblocks/g/gromacs.py Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GROMACS 5.x includes a gmx binary that should be used as main program; in 5.0 these are symlinks, in 5.1 the symlinks are gone, so just check for gmx in 5.x

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

feedback provided by @rapostolo, he had more suggestions for improvements, more info later...

@rpstlv
Copy link
Copy Markdown

rpstlv commented May 8, 2015

Regarding the library installation directory have a look at Gromacs commit gromacs/gromacs@d5c5abd. There we started using the cmake GNUInstallDirs to set paths on multiarch systems.

Comment thread easybuild/easyblocks/g/gromacs.py Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

line too long

@boegel
Copy link
Copy Markdown
Member

boegel commented May 12, 2015

@rapostolo: with respect to GROMACS 5.x support, we're seeing something weird...

For me, on Scientific Linux 6, the GROMACS installation is producing files like $prefix/lib64/libgromacs.a and $prefix/bin/gmx.

For @wpoely86 on Debian on the other hand, the library is going to $prefix/lib/x86_64-linux-gnu/libgromacs.a.

Do you have any idea why the library is one level deeper on Debian? This makes sanity checking, and including the right prepend-path statements in module files quite tricky...

@rpstlv
Copy link
Copy Markdown

rpstlv commented May 12, 2015

@boegel : the different paths are likely due to the GNUInstallDirs cmake module (http://www.cmake.org/cmake/help/v3.0/module/GNUInstallDirs.html) for settings paths on multiarch systems. Probably Debian reports x86_64-linux-.., while SL6 reports lib64

@boegel
Copy link
Copy Markdown
Member

boegel commented May 12, 2015

@rapostolo: thanks for the feedback; another reason to despise CMake... ;)

@rpstlv
Copy link
Copy Markdown

rpstlv commented May 12, 2015

There might be something in python that works the same way as GNUInstallDirs??

@boegel
Copy link
Copy Markdown
Member

boegel commented May 12, 2015

@rapostolo: I'll let the easyblock just figure out where libgromacs.a is located, and use that path. I'm not keen on figuring out what kind of magic CMake pulls to decide one the library subdirectory. I don't care really, as long as the library is there, and EasyBuild can figure out where it went to (so $LIBRARY_PATH and co can be set correctly in the module).

detect library subdirectory in GROMACS easyblock (+ sync with develop)
@hpcugentbot
Copy link
Copy Markdown

Refer to this link for build results (access rights to CI server needed):
https://jenkins1.ugent.be/job/easybuild-easyblocks-pr-builder/956/
Test PASSed.

fix libname in lib detection performed after installation
@hpcugentbot
Copy link
Copy Markdown

Refer to this link for build results (access rights to CI server needed):
https://jenkins1.ugent.be/job/easybuild-easyblocks-pr-builder/957/
Test PASSed.

boegel and others added 2 commits May 12, 2015 16:29
@hpcugentbot
Copy link
Copy Markdown

Refer to this link for build results (access rights to CI server needed):
https://jenkins1.ugent.be/job/easybuild-easyblocks-pr-builder/958/
Test PASSed.

@hpcugentbot
Copy link
Copy Markdown

Refer to this link for build results (access rights to CI server needed):
https://jenkins1.ugent.be/job/easybuild-easyblocks-pr-builder/959/
Test PASSed.

@boegel
Copy link
Copy Markdown
Member

boegel commented May 13, 2015

well-tested with easybuilders/easybuild-easyconfigs#1221 and easybuilders/easybuild-easyconfigs#1599, both on Debian & RedHat systems (which matters a lot for this easyblock)

all existing GROMACS easyconfigs were retested, see https://gist.github.com/4db020f79ec7ef3f1651

going in, thanks @wpoely86 for kicking this off!

boegel added a commit that referenced this pull request May 13, 2015
GROMACS easyblock updated for version 5
@boegel boegel merged commit aebeb0a into easybuilders:develop May 13, 2015
@wpoely86 wpoely86 deleted the gromacs branch May 13, 2015 07:36
boegel added a commit to boegel/easybuild-easyblocks that referenced this pull request May 16, 2015
GROMACS easyblock updated for version 5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants