{toolchain} foss 2016.07#3517
Conversation
|
934 self.assertEqual(ec[key], dumped_ec[key]) 935AssertionError: [{'external_module_metadata': {}, 'full_mod_name': 'OpenBLAS/0.2.18-gompi-2016.07-LAPACK-3.6.1', 'toolchain': {'version': '2016.07', 'name': 'gompi'}, 'name': 'OpenBLAS', 'dummy': False, 'short_mod_name': 'OpenBLAS/0.2.18-gompi-2016.07-LAPACK-3.6.1', 'external_module': False, 'versionsuffix': '-LAPACK-3.6.1', 'version': '0.2.18', 'toolchain_inherited': False, 'hidden': False, 'build_only': False}] != [{'external_module_metadata': {}, 'full_mod_name': 'OpenBLAS/0.2.18-gompi-2016.07-LAPACK-3.6.1', 'toolchain': {'version': '2016.07', 'name': 'gompi'}, 'name': 'OpenBLAS', 'dummy': False, 'short_mod_name': 'OpenBLAS/0.2.18-gompi-2016.07-LAPACK-3.6.1', 'external_module': False, 'versionsuffix': '-LAPACK-3.6.1', 'version': '0.2.18', 'toolchain_inherited': True, 'hidden': False, 'build_only': False}] The difference between them seems to be 'toolchain_inherited', what does this indicate? Is it something to do with OpenBLAS being built with gompi 2016.07 which is included in the commit instead of already being in the repo? |
|
OpenMPI 1.10.4, bugfix release is out since yesterday. If one includes a new version, should one not move this forward? |
|
Yes, that would be good to do in due time but I have been using this toolchain for a few weeks to do builds and since the release of the GCC 6 fixes, this toolchain should be buildable using just easyconfigs (as I had to handbuild GCC 6 into our EasyBuild tree to get it to work before). It's more so for compatibility with what I have already built so far. |
|
|
||
| versionsuffix = "-%s-%s%s" % (blaslib, blasver, blassuff) | ||
|
|
||
| dependencies = [(blaslib, blasver, blassuff, ('gompi', '2016.07'))] |
There was a problem hiding this comment.
@AFCJamie the error in the tests is because you're hardcoding the toolchain to use for this dep to the same toolchain used in this easyconfig, so please change this to:
dependencies = [(blaslib, blasver, blassuff)]There was a problem hiding this comment.
@boegel Ohh, okay, no worries - I'll change that now and push.
|
@jhein32 I agree with @AFCJamie on this one, if this is a well-tested combination of toolchain components, it's good to go in as-is A toolchain bump to |
| @@ -0,0 +1,455 @@ | |||
| # All mpfr patches as of 2016-08-04, from same pull request for GCC 6.2.0 | |||
There was a problem hiding this comment.
@AFCJamie why are you duplicating this patch? There's no need to since this only patches MPFR itself, nothign in GCC, just use the existing patch for mpfr-3.1.4?
There was a problem hiding this comment.
@boegel I've removed it now, I'm not sure why I thought it'd be specific to the GCC version.
|
Test report by @boegel |
|
Test report by @boegel |
|
@AFCJamie next to the comments above, please also add an easyconfig for HPL v2.2 as a test case for using this toolchain |
Changed Open MPI version to 1.10.3, removed duplicate patch, removed mirror link and fixed some style issues.
|
@boegel Working on HPL now. |
|
This looks good to me now, thanks for your efforts @AFCJamie! W.r.t. OpenMPI 2.x: it's definitely worth considering already (for In any case, jumping to OpenMPI 2.x or not is a decision we'll need to make for the 'common' |
|
Test report by @boegel |
|
Test report by @boegel |
|
@boegel No worries! Thanks for the guidance. Okay, that sounds like a fair plan of action. With regard to the GCC aspect, is it not feasible to have 2 'common' foss toolchains but the only difference is one uses GCC 6 and the other GCC 5? (e.g. foss 2017a-GCC-6.x.x and foss-2017a-GCC-5.x.x) |
|
@AFCJamie The whole point with the common toolchains is that we have a reasonably tested stable toolchain composition that we can rely on for a while (~6 months, sometimes longer). So, we should pick either GCC 5.x or 6.x for That doesn't mean there can't be other |
|
lgtm |
|
Going in, thanks @AFCJamie! |
|
@boegel Okay, that makes sense. Thanks for merging! |
|
Hi James and Kenneth Right now, I have no opinion on OpenMPI 2.0.x v OpenMPI 1.10.x. This is a major version bump. What I was keen on, what the x. The OpenMPI 1.10.2, used here, is two bugfix releases old with 1.10.3 being out for a long time. 1.10.x is still maintained and the latest bugfix release only came out 4 days ago. I am a bit opposed to having fossils in newly included stuff. Regarding 2.0.x, there is now also a 2.0.1, came out last week. For newly added toolchains I would see whether one could have 2.0.1 instead of 2.0.0 now. In general I think EB needs to get foss toolchains out with gcc 6.x and openmpi 2.0.x out, to give it exposure asap. That way, we have will a better idea on what to put in foss/2017a. Having said this, I noted activity regarding gcc 6 and openmpi 2 in the git repository and (so far) choose to invest my time in other places. In that view, for foss, the year.month naming is perhaps not the best. One has the version bumps (minor version) in the current stuff and issue of major version progression. In that view I really like the 2016a, 2016b, 2017a, … concept. EB seal of approval: good reliable choices that should build almost any package, free from experimental stuff. Okay that was a bit an opinion piece. Best wishes On 03 Sep 2016, at 12:47, James Birch <[email protected]mailto:[email protected]> wrote: @boegelhttps://github.com/boegel @jhein32https://github.com/jhein32 If there's going to be a toolchain bump to 2016.09 in the near future, could it be worth jumping to Open MPI 2.0.0? Or is it worth waiting a couple more months before using the next major version? — |
|
@jhein32 just to be clear, we did bump OpenMPI to 1.10.3 here, which aligns with the I agree that defining a |
|
Apologies, the 1.10.2 -> 1.10.3 version bump bypassed me. |
An update to foss which includes using GCC 6.1.0. All the easyconfigs included are relevant dependencies.
foss 2016.07 includes:
1.10.21.10.3EDIT:
Also contains HPL 2.2 as a test for the toolchain.