RE: Intel MPI 5.1.0 (was Re: [easybuild] next EasyBuild conf call: Wed July 8th, 3pm CET)
Hey Kenneth, Thanks for checking it out. I suppose this means Intel will come out with another version in the near future fixing at least this. -Eric From: easybuild-requ...@lists.ugent.be [easybuild-requ...@lists.ugent.be] on behalf of Kenneth Hoste [kenneth.ho...@ugent.be] Sent: Tuesday, July 14, 2015 11:33 AM To: easybuild@lists.ugent.be Subject: Re: Intel MPI 5.1.0 (was Re: [easybuild] next EasyBuild conf call: Wed July 8th, 3pm CET) Hi Eric, On 09/07/15 16:48, Gregory, Eric wrote: > Has anyone tried building this impi yet? > > For me it fails with a message: > > Failed to move contents of > /usr/local/software/jureca/Stage2/software/Toolchain/iccifort/2015.3.187/impi/5.1.0.038/impi/5.1.0.038 > to > /usr/local/software/jureca/Stage2/software/Toolchain/iccifort/2015.3.187/impi/5.1.0.038: > [Errno 2] No such file or directory. > > That is, the source directory: > ... iccifort/2015.3.187/impi/5.1.0.038/impi/5.1.0.038/ > > does not exist but the installer has built a directory: > > .../iccifort/2015.3.187/impi/5.1.0.038/impi/5.1.0.079 > > I wonder if Intel got the version number internally inconsistient somehow. > > > It seems to work if i rename the source and change the version from > > "5.1.0.038" -> 5.1.0.079 > > Does anyone else have this experience? I just gave this a spin too, seems like Intel screwed up the version in the tarball... The actual version should be 5.1.0.079 (.038 makes no sense, since the previous version was 5.0.3.048). Here's the easyconfig I'm using now, this works: https://github.com/hpcugent/easybuild-easyconfigs/pull/1793 regards, Kenneth > > -Eric > > > --- >> We (EB) really need to come up with a more timely manner of >> declaring toolchains. >> >> It's interesting... while reading this morning's mail (probably >> while the telecon was going on across the pond), I noticed a >> notification from Intel for a new MPI release. > It is always tempting to wait 'just a little bit' for that just > released or soon to be released change, but that often leads to even > more 'just a bit longer' (I do this far too often myself). > > For our users who want to chase version numbers, I leave that to them > as something they can build privately. > >> The immediate question that arose was "oh shit, now WTF do I call a >> toolchain with this change?". >> >> To which, there is no clear answer. > I think the answer it to not worry the details and not over think > toolchains. I don't really want to chase toolchain components but > instead want a tested and fairly stable toolchain. Preferably with > just one or two updates a year (versus the CentOS 6 toolchain which is > several years old). > > I'm looking forward to foss-2015b whether it has GCC 5.1, 5.2 or even > 4.X. Based strictly on version numbers (without any insight as to > significant differences), I would suggest GCC 5.1 as something stable. > > I could probably live with foss-2015a which seems to work well and > wait until the November hack-a-thon for foss-2015b. > >> Note: intel-2015b, if I decide to use it, will likely be 2015B with >> GCC 4.9.2 or 4.9.3. > You might try naming your site specific toolchains tamu-intel-2015X so > as to more visibly indicate they are site specific. > >> Of course, with Intel's new MPI this morning, I need something new. > Do you actually really need to instantly upgrade to the latest intel > compiler? There might be some practical reasons (especially if Intel > does not leave older versions around). > >> I just wish y'all had all the answers for me before I had the >> question. :) > They do have a good number of answers to questions I'm glad I don't > even need to think about asking. > > I'm mostly an easybuild freeloader. I thank the easybuild developers > who do monitor the toolchain and other software changes and do a lot > of testing and validation of the easyconfig files. This saves me a > lot of work determining which toolchain components to use. > > Stuart > -- > I've never been lost; I was once bewildered for three days, but never lost! > -- Daniel Boone > > > > > Forschungszentrum Juelich GmbH > 52425 Juelich > Sitz der Gesellschaft: Juelich > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 > Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher > Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), > Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, > Prof. Dr. Sebastian M. Schmidt > > >
Re: Intel MPI 5.1.0 (was Re: [easybuild] next EasyBuild conf call: Wed July 8th, 3pm CET)
Hi Eric, On 09/07/15 16:48, Gregory, Eric wrote: Has anyone tried building this impi yet? For me it fails with a message: Failed to move contents of /usr/local/software/jureca/Stage2/software/Toolchain/iccifort/2015.3.187/impi/5.1.0.038/impi/5.1.0.038 to /usr/local/software/jureca/Stage2/software/Toolchain/iccifort/2015.3.187/impi/5.1.0.038: [Errno 2] No such file or directory. That is, the source directory: ... iccifort/2015.3.187/impi/5.1.0.038/impi/5.1.0.038/ does not exist but the installer has built a directory: .../iccifort/2015.3.187/impi/5.1.0.038/impi/5.1.0.079 I wonder if Intel got the version number internally inconsistient somehow. It seems to work if i rename the source and change the version from "5.1.0.038" -> 5.1.0.079 Does anyone else have this experience? I just gave this a spin too, seems like Intel screwed up the version in the tarball... The actual version should be 5.1.0.079 (.038 makes no sense, since the previous version was 5.0.3.048). Here's the easyconfig I'm using now, this works: https://github.com/hpcugent/easybuild-easyconfigs/pull/1793 regards, Kenneth -Eric --- We (EB) really need to come up with a more timely manner of declaring toolchains. It's interesting... while reading this morning's mail (probably while the telecon was going on across the pond), I noticed a notification from Intel for a new MPI release. It is always tempting to wait 'just a little bit' for that just released or soon to be released change, but that often leads to even more 'just a bit longer' (I do this far too often myself). For our users who want to chase version numbers, I leave that to them as something they can build privately. The immediate question that arose was "oh shit, now WTF do I call a toolchain with this change?". To which, there is no clear answer. I think the answer it to not worry the details and not over think toolchains. I don't really want to chase toolchain components but instead want a tested and fairly stable toolchain. Preferably with just one or two updates a year (versus the CentOS 6 toolchain which is several years old). I'm looking forward to foss-2015b whether it has GCC 5.1, 5.2 or even 4.X. Based strictly on version numbers (without any insight as to significant differences), I would suggest GCC 5.1 as something stable. I could probably live with foss-2015a which seems to work well and wait until the November hack-a-thon for foss-2015b. Note: intel-2015b, if I decide to use it, will likely be 2015B with GCC 4.9.2 or 4.9.3. You might try naming your site specific toolchains tamu-intel-2015X so as to more visibly indicate they are site specific. Of course, with Intel's new MPI this morning, I need something new. Do you actually really need to instantly upgrade to the latest intel compiler? There might be some practical reasons (especially if Intel does not leave older versions around). I just wish y'all had all the answers for me before I had the question. :) They do have a good number of answers to questions I'm glad I don't even need to think about asking. I'm mostly an easybuild freeloader. I thank the easybuild developers who do monitor the toolchain and other software changes and do a lot of testing and validation of the easyconfig files. This saves me a lot of work determining which toolchain components to use. Stuart -- I've never been lost; I was once bewildered for three days, but never lost! -- Daniel Boone Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
RE: [easybuild] next EasyBuild conf call: Wed July 8th, 3pm CET
Has anyone tried building this impi yet? For me it fails with a message: Failed to move contents of /usr/local/software/jureca/Stage2/software/Toolchain/iccifort/2015.3.187/impi/5.1.0.038/impi/5.1.0.038 to /usr/local/software/jureca/Stage2/software/Toolchain/iccifort/2015.3.187/impi/5.1.0.038: [Errno 2] No such file or directory. That is, the source directory: ... iccifort/2015.3.187/impi/5.1.0.038/impi/5.1.0.038/ does not exist but the installer has built a directory: .../iccifort/2015.3.187/impi/5.1.0.038/impi/5.1.0.079 I wonder if Intel got the version number internally inconsistient somehow. It seems to work if i rename the source and change the version from "5.1.0.038" -> 5.1.0.079 Does anyone else have this experience? -Eric --- > We (EB) really need to come up with a more timely manner of > declaring toolchains. > > It's interesting... while reading this morning's mail (probably > while the telecon was going on across the pond), I noticed a > notification from Intel for a new MPI release. It is always tempting to wait 'just a little bit' for that just released or soon to be released change, but that often leads to even more 'just a bit longer' (I do this far too often myself). For our users who want to chase version numbers, I leave that to them as something they can build privately. > The immediate question that arose was "oh shit, now WTF do I call a > toolchain with this change?". > > To which, there is no clear answer. I think the answer it to not worry the details and not over think toolchains. I don't really want to chase toolchain components but instead want a tested and fairly stable toolchain. Preferably with just one or two updates a year (versus the CentOS 6 toolchain which is several years old). I'm looking forward to foss-2015b whether it has GCC 5.1, 5.2 or even 4.X. Based strictly on version numbers (without any insight as to significant differences), I would suggest GCC 5.1 as something stable. I could probably live with foss-2015a which seems to work well and wait until the November hack-a-thon for foss-2015b. > Note: intel-2015b, if I decide to use it, will likely be 2015B with > GCC 4.9.2 or 4.9.3. You might try naming your site specific toolchains tamu-intel-2015X so as to more visibly indicate they are site specific. > Of course, with Intel's new MPI this morning, I need something new. Do you actually really need to instantly upgrade to the latest intel compiler? There might be some practical reasons (especially if Intel does not leave older versions around). > I just wish y'all had all the answers for me before I had the > question. :) They do have a good number of answers to questions I'm glad I don't even need to think about asking. I'm mostly an easybuild freeloader. I thank the easybuild developers who do monitor the toolchain and other software changes and do a lot of testing and validation of the easyconfig files. This saves me a lot of work determining which toolchain components to use. Stuart -- I've never been lost; I was once bewildered for three days, but never lost! -- Daniel Boone Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
Re: [easybuild] next EasyBuild conf call: Wed July 8th, 3pm CET
On Wed, 8 Jul 2015 at 11:58 -, Jack Perdue wrote: > We (EB) really need to come up with a more timely manner of > declaring toolchains. > > It's interesting... while reading this morning's mail (probably > while the telecon was going on across the pond), I noticed a > notification from Intel for a new MPI release. It is always tempting to wait 'just a little bit' for that just released or soon to be released change, but that often leads to even more 'just a bit longer' (I do this far too often myself). For our users who want to chase version numbers, I leave that to them as something they can build privately. > The immediate question that arose was "oh shit, now WTF do I call a > toolchain with this change?". > > To which, there is no clear answer. I think the answer it to not worry the details and not over think toolchains. I don't really want to chase toolchain components but instead want a tested and fairly stable toolchain. Preferably with just one or two updates a year (versus the CentOS 6 toolchain which is several years old). I'm looking forward to foss-2015b whether it has GCC 5.1, 5.2 or even 4.X. Based strictly on version numbers (without any insight as to significant differences), I would suggest GCC 5.1 as something stable. I could probably live with foss-2015a which seems to work well and wait until the November hack-a-thon for foss-2015b. > Note: intel-2015b, if I decide to use it, will likely be 2015B with > GCC 4.9.2 or 4.9.3. You might try naming your site specific toolchains tamu-intel-2015X so as to more visibly indicate they are site specific. > Of course, with Intel's new MPI this morning, I need something new. Do you actually really need to instantly upgrade to the latest intel compiler? There might be some practical reasons (especially if Intel does not leave older versions around). > I just wish y'all had all the answers for me before I had the > question. :) They do have a good number of answers to questions I'm glad I don't even need to think about asking. I'm mostly an easybuild freeloader. I thank the easybuild developers who do monitor the toolchain and other software changes and do a lot of testing and validation of the easyconfig files. This saves me a lot of work determining which toolchain components to use. Stuart -- I've never been lost; I was once bewildered for three days, but never lost! -- Daniel Boone
RE: [easybuild] next EasyBuild conf call: Wed July 8th, 3pm CET
Hello Jack, all, > a notification from Intel for a new MPI release. > The immediate question that arose was "oh shit, now WTF do > I call a toolchain with this change?". I can tell you what I do: In effect, I assume I can baptize toolchains for my own private use and then issue a PR on github. At that moment, it becomes Kenneth's problem (boegel on github), since he is the release manager. It would be great to setup a (community-helpful) rule that new toolchains get a "naming advice" within 48 hours. That helps to remove unnecessary load to the submittor. (I've been there: you may have to rename 100s of easyconfigs as a consequence, if not so) Also, this would have the nice incentive that people now have a cause to *share early* their toolchains. Your take? > But that was never clear and I'm glad that EB > has moved toward a YEARrelease numbering scheme. It is great to have it, however it's not panacea for all use(r)s (esp. with current usual assumption of including latest and greatest). > Also entwined in the issue is the preferred GCC. At present, > as I see it, there are three releases that should be supported: You pretty much described it right about 4.8/4.9/5.x, I and some others share that view. > goolf-1.7.20 - GCC-484/OpenMPI-184/OpenBLAS-0213/FFTW-334/ScaLAPACK-202 IMHO, as of today, the above is the best vehicle for bio* codes and related paraphernalia. > intel-2015B - GCC-484/iccifort-2015.3.187/impi-5.0.3.048/imkl-11.2.3.187 The alternative capitalization signifies move conservative choices? in fact, this direction is interesting! > Of course, with Intel's new MPI this morning, I need something new. > And the intro of gcc 5 just adds to the chaos. You'll eventually get used to this chaos :) > xyzzy-20150708 That's why EB is there: you can *make* and *share* xyzzy today. > I don't have a solution. Wish I did. I'm still trying to figure out easybuild+git PRs are your friends; that's where it goes. If you can share bits and pieces before they become mature PRs, that also helps. > what to call a toolchain with GCC/MPICH2/OpenBLAS/FFTW/ScaLAPACK > for use on the BG/Q (its partial to MPICH2). gmolf, perhaps? Remember, names are mostly there to help the human; For EB itself, it only matters then how the --try-toolchain, --try-software-version options function. > Keep up the good work and I promise at least three pints Watch out, participation will go up with these offers ;-) cheers, F. -- echo "sysadmin know better bash than english" | sed s/min/mins/ \ | sed 's/better bash/bash better/' # Yelling in a CERN forum
Re: [easybuild] next EasyBuild conf call: Wed July 8th, 3pm CET
On Wed, Jul 8, 2015 at 5:58 PM, Jack Perdue wrote: > But _something_ needs to be done to make sure that toolchains > in EB can keep up with compiler/MPI/mathlib releases. So basically you would like a way to generate a toolchain with the gcc, icc, ifort, imkl, impi, ... of your choice? We could write a script for that. It's not hard to make a custom toolchain, just tedious. The problem is of course the infinite number of possible combinations. --try-toolchain will get you far but merging these easyconfigs back to the main tree will be trouble. Ward
Re: [easybuild] next EasyBuild conf call: Wed July 8th, 3pm CET
Howdy EBers, re: toolchains First, let me state that I am most appreciative of the EB people who make things happen and guide the rest of us. I am so very grateful to have a project like EasyBuild and even more grateful to the people that keep it going day after to day. And I promise I will try harder to contribute more (and learn git) once we get a hold of the 5 clusters (x86, p7 HPC, p7 BigData, BG/Q and cloud) that were suddenly dumped on our porch last year... without any additional personnel to make them go. Without EB, we'd have a much bigger mess on our hands. However, that being said We (EB) really need to come up with a more timely manner of declaring toolchains. It's interesting... while reading this morning's mail (probably while the telecon was going on across the pond), I noticed a notification from Intel for a new MPI release. The immediate question that arose was "oh shit, now WTF do I call a toolchain with this change?". To which, there is no clear answer. The old toolchain "heuristic" (of sorts), implied maybe bumping a minor number. e.g ictce-7.1.2 might become ictce-7.2.2. Similar heuristics apply to the goolf chain when a new version of OpenMPI shows up. But that was never clear and I'm glad that EB has moved toward a YEARrelease numbering scheme. Two schemes for 'release' have been attempted, both with merits and problems. - using letters (perhaps ABCD for 1st-4th quarter of a year) - using the month (e.g. intel-2015.02) Also entwined in the issue is the preferred GCC. At present, as I see it, there are three releases that should be supported: - 4.8.x - a very stable, time-tested version that is know to behave well with HPC - 4.9.x - a less stable version for HPC but yet has important C++ extensions to support newer C++ standards, and - 5.x - an untested, bleeding edge update that has all kinds of promise, but as yet isn't ready for prime-time Now then, here at TAMU, I've given up on ictce... I really don't see a need to support a compiler based on ancient GCCs (4.4.7 on RHEL6 and 4.1.2 on our old RHEL5 cluster) Here at TAMU, I currently concentrate on the following: goolf-1.7.20 - GCC-484/OpenMPI-184/OpenBLAS-0213/FFTW-334/ScaLAPACK-202 foss-2015a - GCC-492/same as goolf-1.7.20 intel-2015a - GCC-492/iccifort-2015.1.133/impi-5.0.2.044/imkl-11.2.1.133 intel-2015A - GCC-484/same as 2015a intel-2015B - GCC-484/iccifort-2015.3.187/impi-5.0.3.048/imkl-11.2.3.187 Note: intel-2015b, if I decide to use it, will likely be 2015B with GCC 4.9.2 or 4.9.3. Of course, with Intel's new MPI this morning, I need something new. And the intro of gcc 5 just adds to the chaos. I don't know where I'm going with this. Pardon the rant if that's how it comes off. I'm just slightly frustrated/disappointed that NO decision was made this morning on the topic. Personally, I would've preferred y'all said something like "fuck it, these are the versions our there today and are most likely to work... lets put them together and call them xyzzy-20150708" and be done with it. Then at least there would be _something_ defined in terms of newer tools. Where's the love for GCC 4.8.5 and 4.9.3??? I could give a rat's ass about the 5.x series at this point. I don't have a solution. Wish I did. I'm still trying to figure out what to call a toolchain with GCC/MPICH2/OpenBLASS/FFTW/ScaLAPACK for use on the BG/Q (its partial to MPICH2). But _something_ needs to be done to make sure that toolchains in EB can keep up with compiler/MPI/mathlib releases. Sorry if I seem unappreciative. I'm not. I just wish y'all had all the answers for me before I had the question. :) Keep up the good work and I promise at least three pints (and maybe dinner at The Roaring Fork) to all that show up for the hackathon @ TACC in November. Jack Perdue Lead Systems Administrator High Performance Research Computing TAMU Division of Research j-per...@tamu.eduhttp://sc.tamu.edu SC Helpdesk: h...@sc.tamu.edu On 07/08/2015 09:10 AM, Kenneth Hoste wrote: Notes are available at https://github.com/hpcugent/easybuild/wiki/Conference-call-notes-20150708 On 08/07/15 00:10, Kenneth Hoste wrote: Hi EasyBuilders, The next EasyBuild conf call is planned for Wednesday July 8th 2015, 3pm CET. Topics I have in mind include: * 2015b common toolchains: GCC 5.1 or 5.2? * making --robot aware of subtoolchains (update by Alan) * outlook to EasyBuild v2.2.0 (Kenneth) Suggestions for additional topics are welcome. More information about the EasyBuild conference calls is available at https://github.com/hpcugent/easybuild/wiki/Conference-calls. Please let me know if you're planning to attend. regards, Kenneth
Re: [easybuild] next EasyBuild conf call: Wed July 8th, 3pm CET
Notes are available at https://github.com/hpcugent/easybuild/wiki/Conference-call-notes-20150708 On 08/07/15 00:10, Kenneth Hoste wrote: Hi EasyBuilders, The next EasyBuild conf call is planned for Wednesday July 8th 2015, 3pm CET. Topics I have in mind include: * 2015b common toolchains: GCC 5.1 or 5.2? * making --robot aware of subtoolchains (update by Alan) * outlook to EasyBuild v2.2.0 (Kenneth) Suggestions for additional topics are welcome. More information about the EasyBuild conference calls is available at https://github.com/hpcugent/easybuild/wiki/Conference-calls. Please let me know if you're planning to attend. regards, Kenneth
[easybuild] next EasyBuild conf call: Wed July 8th, 3pm CET
Hi EasyBuilders, The next EasyBuild conf call is planned for Wednesday July 8th 2015, 3pm CET. Topics I have in mind include: * 2015b common toolchains: GCC 5.1 or 5.2? * making --robot aware of subtoolchains (update by Alan) * outlook to EasyBuild v2.2.0 (Kenneth) Suggestions for additional topics are welcome. More information about the EasyBuild conference calls is available at https://github.com/hpcugent/easybuild/wiki/Conference-calls. Please let me know if you're planning to attend. regards, Kenneth
