[easybuild] Re: Module naming schemes
Hi, After a install the first problem was fixed. The problem of the modules not being found with the Hierarchical MNS still persists. I've done a clean install of applications for foss and intel toolchain using the default EasyBuildMNS naming scheme. Now I want to create a HMNS module tree using the MigrateFromEBToHMNS naming scheme and using the --module-only option. When doing so I get: == 2017-12-15 10:20:04,365 build_log.py:157 ERROR EasyBuild crashed with an error (at easybuild/EasyBuild/3.4.0/lib/python2.6/site-packages/vsc_base-2.5.8-py2.6.egg/vsc/utils/exceptions.py:124 in __init__): Module command 'module load M4/1.4.17' failed with exit code 1; stderr: Lmod has detected the following error: The following module(s) are unknown: "M4/1.4.17" Please check the spelling or version number. Also try "module spider ..." It is also possible your cache file is out-of-date; it may help to try: $ module --ignore-cache load "M4/1.4.17" Also make sure that all modulefiles written in TCL start with the string #%Module ; stdout: false This is because the M4/1.4.17 module only exists in a subdirectory Core. Is there a configuration option I'm missing to help EasyBuild and/or Lmod to search the proper location for the modulefiles? Or should symlinks have been created at that level? Thanks in advance. Kind regards, Erik On Tue, Dec 12, 2017 at 10:56 AM, Erik Smeets wrote: > Hi all, > > Currently we are looking into moving to lmod. As we want to easily switch > between toolchains, I wanted to try the different module naming schemes and > see how they work with lmod. I'm now however facing some issues. > > For testing I'm using EB 3.4.0 and install everything from scratch in > seperate directories and limit installation to the foss and intel > toolchains, both version 2016a. > When using the HierarchicalMNS and then using "module avail" shows: >all/Core/foss/2016aall/foss/2016atoolchain/foss/2016a >all/Core/intel/2016a > > Anyone have an idea why the intel toolchain is not showing up in the all > and toolchain directories? > > > Then when using CategorizedHMNS EasyBuild fails with the installation of > the foss and/or intel toolchains, because lmod cannot load the M4/1.4.17 > module, as it is located in Core/devel subdirectory. Probably some > misconfiguration for EB that I currently use, but I couldn't find > documentation on use and how to configure then. Any pointers here are > appreciated. > > Thanks in advance. > Kind regards, > Erik > >
[easybuild] Module naming schemes
Hi all, Currently we are looking into moving to lmod. As we want to easily switch between toolchains, I wanted to try the different module naming schemes and see how they work with lmod. I'm now however facing some issues. For testing I'm using EB 3.4.0 and install everything from scratch in seperate directories and limit installation to the foss and intel toolchains, both version 2016a. When using the HierarchicalMNS and then using "module avail" shows: all/Core/foss/2016aall/foss/2016atoolchain/foss/2016a all/Core/intel/2016a Anyone have an idea why the intel toolchain is not showing up in the all and toolchain directories? Then when using CategorizedHMNS EasyBuild fails with the installation of the foss and/or intel toolchains, because lmod cannot load the M4/1.4.17 module, as it is located in Core/devel subdirectory. Probably some misconfiguration for EB that I currently use, but I couldn't find documentation on use and how to configure then. Any pointers here are appreciated. Thanks in advance. Kind regards, Erik
Re: [easybuild] Fixing versions for standard dependencies beyond the toolchains
Hi, There are also a lot of dependencies to applications that in my opinion don't need a specific toolchain, but just need to be available. Maybe don't add these to a specific toolchain or version, but a generally avaible toolchain (dummy?). Also, now dependencies are really strict on version, while this is not always necessary. Maybe having something like '>' and/or '<' for version dependencies might help to focus on applications that really need updating. Maybe this is already discussed and decided on a long time ago or maybe this will cause other problems. Regards, Erik On Fri, Nov 24, 2017 at 10:48 AM, Åke Sandgren wrote: > It's fairly simple. > > Use whatever is already available for the selected toolchain. Don't > forget to check the git develop branch and any pending PRs when deciding > on versions. > > On 11/24/2017 10:16 AM, Joachim Hein wrote: > > Hi, > > > > Because of interoperability of software, I see an increasing need to fix > software versions beyond what is included in the actual toolchains. I am > discussing standard dependencies, like jpeg libraries, HDF5, netcdf, curl. > So, unless there is strong reasons (e.g. bugs), packages build with a > certain toolchain (e.g. foss/2017a) should use a “preferred version” for > standard dependencies. Using the latest and greatest, which is what I did > some time ago has downsides in the form of module load conflicts. > > > > The question is how would one administer this (selection of version(s), > communication between contributors, …), without driving the administrative > burden even higher. I like to put this for discussion among the regular > contributors. > > > > Best wishes > >Joachim > > > > -- > Ake Sandgren, HPC2N, Umea University, S-90187 Umea, Sweden > Internet: a...@hpc2n.umu.se Phone: +46 90 7866134 Fax: +46 90-580 14 > Mobile: +46 70 7716134 WWW: http://www.hpc2n.umu.se >
Re: [easybuild] OpenFOAM mess
Hi Maxime, Check thuis pulk request: https://github.com/easybuilders/easybuild-easyconfigs/pull/4814 I‘ve used this some time ago and for us it worked fine for both versions. Renards, Erik On Tuesday, November 7, 2017, Maxime Boissonneault < maxime.boissonnea...@calculquebec.ca> wrote: > Hi all, > > We recently got a request for installing OpenFOAM from openfoam.com > (which is different than OpenFOAM from openfoam.org). Trying to figure it > out, I noticed that all existing recipes in EasyBuild download source from > sourceforge or github repositories of openfoam.org, while many recipes > point the homepage to openfoam.com. > > Should we fix this ? > > > Does anyone have an actual recipe for OpenFOAM versions from > OpenFOAM.*COM* (which are versions below 1706). > > Also, does anyone have a suggestion on what to do with the name clash ? > > > Finally, if anyone has contacts in the OpenFOAM.com/.org developpers, > please tell them they're nuts to have done things this way... > > > > -- > - > Maxime Boissonneault > Analyste de calcul - Calcul Québec, Université Laval > Président - Comité de coordination du soutien à la recherche de Calcul > Québec > Team lead - Research Support National Team, Compute Canada > Instructeur Software Carpentry > Ph. D. en physique > >
[easybuild] EasyBuild module naming scheme in combination with lmod
Hello, Currently we are looking into switching to lmod as modules tool. Up till now we have been using our own module naming scheme when installing software with EasyBuild. This however seems to be not ideal in combination with lmod. One of the features we would like to use is easy switching between toolchains. What would you recommend as best module structure and module naming scheme in EasyBuild in combination with lmod? Thanks in advance for sharing your ideas on this. Kind regards, Erik
[easybuild] Re: OpenFOAM+
Hi, What I did so far is that I've created a new easyconfig file for OpenFOAM 1612, but based on the OpenFOAM easyblock. Also I've created a patch file for this version. However, the install failed during build phase: == 2017-07-05 10:42:06,864 build_log.py:156 ERROR EasyBuild crashed with an error (at easybuild/EasyBuild/3.3.0/lib/python2.6/site-packages/vsc_ base-2.5.8-py2.6.egg/vsc/utils/exceptions.py:124 in __init__): build failed (first 300 chars): cmd "source /hpc/shared/eb_apps/rhel6_tst/ openfoam/v1612+-foss-2016a/OpenFOAM-v1612+/etc/bashrc && /hpc/shared/eb_apps/rhel6_tst/openfoam/v1612+-foss-2016a/OpenFOAM-v1612+/Allwmake" exited with exitcode 2 and output: OMPI_CC="gcc" mpicc -DOPENFOAM_PLUS=1612 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DW (at easybuild/EasyBuild/3.3.0/lib/python2.6/site-packages/ easybuild_framework-3.3.0-py2.6.egg/easybuild/main.py:120 in build_and_install_software) == 2017-07-05 10:42:06,865 build_log.py:156 ERROR EasyBuild crashed with an error (at easybuild/EasyBuild/3.3.0/lib/python2.6/site-packages/vsc_ base-2.5.8-py2.6.egg/vsc/utils/exceptions.py:124 in __init__): Build of /hpc/home/hpcsw/EasyBuild/ASML/OpenFOAM-v1612+-foss-2016a.eb failed (err: 'build failed (first 300 chars): cmd "source /hpc/shared/eb_apps/rhel6_tst/ openfoam/v1612+-foss-2016a/OpenFOAM-v1612+/etc/bashrc && /hpc/shared/eb_apps/rhel6_tst/openfoam/v1612+-foss-2016a/OpenFOAM-v1612+/Allwmake" exited with exitcode 2 and output:\nOMPI_CC="gcc" mpicc -DOPENFOAM_PLUS=1612 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DW') (at easybuild/EasyBuild/3.3.0/lib/python2.6/site-packages/ easybuild_framework-3.3.0-py2.6.egg/easybuild/main.py:152 in build_and_install_software) Any ideas what's wrong? Any help is appreciated. Thanks in advance. Kind regards, Erik Smeets On Wed, Jul 5, 2017 at 10:55 AM, Erik Smeets wrote: > Hi, > > has anyone successfully installed OpenFOAM+ using EasyBuild and if so > could you share the easyconfig for this? > > Thanks in advance. > > Kind regards, > Erik Smeets > >
[easybuild] OpenFOAM+
Hi, has anyone successfully installed OpenFOAM+ using EasyBuild and if so could you share the easyconfig for this? Thanks in advance. Kind regards, Erik Smeets
[easybuild] OpenFOAM debug version
Hi, One of our users requested to install a version of OpenFOAM with debug enabled. From documentation I found that for this " WM_COMPILE_OPTION=Debug." should be set. Does anyone have experience installing a debug version using EasyBuild? And if so, is there documentation on how this is done available? Thanks in advance. Kind regards, Erik Smeets
RE: [easybuild] How to rebuild the foss-2016b toolchain with OpenMPI including Slurm support?
Hi Kenneth, Full path to installation of PBS. PBS is not installed with EB, but loaded as external module. Specifying the following wasn't sufficient: configopts += '--with-tm ' But using the following does work: configopts += '--with-tm=/full/path/to/install/of/pbs ' Regards, Erik > -Original Message- > From: easybuild-requ...@lists.ugent.be [mailto:easybuild- > requ...@lists.ugent.be] On Behalf Of Kenneth Hoste > Sent: Friday, October 28, 2016 8:55 AM > To: easybuild@lists.ugent.be > Subject: Re: [easybuild] How to rebuild the foss-2016b toolchain with > OpenMPI including Slurm support? > > Hi Erik, > > On 28/10/16 08:50, Erik Smeets wrote: > > Hi Ole, > > > > We've had a similar issue, but then for PBS. I created a new eb file and > added with-tm specifying full-path: > > configopts += '--with-tm=/full/path/to/pbs ' > > > > I then installed openmpi with --force --rebuild. > > > > For some reason when not specifying the full path it doesn't work for us at > the moment. I still need to look at this, as it is inconvenient having to > update > this file when we upgrade PBS. At least for now it does the trick. > > Can you clarify this? Full path to what? The easyconfig file? > And if so, on the command line, or in your EasyBuild configuration (robot- > paths)? > > > regards, > > Kenneth > > > > > Regards, > > Erik > > > > > > > >> -Original Message- > >> From: easybuild-requ...@lists.ugent.be [mailto:easybuild- > >> requ...@lists.ugent.be] On Behalf Of Kenneth Hoste > >> Sent: Wednesday, October 26, 2016 6:43 PM > >> To: easybuild@lists.ugent.be > >> Subject: Re: [easybuild] How to rebuild the foss-2016b toolchain with > >> OpenMPI including Slurm support? > >> > >> Hi Ole, > >> > >> On 26/10/16 16:03, Ole Holm Nielsen wrote: > >>> We use the foss-2016b toolchain, and we need OpenMPI to be built with > >>> Slurm resource manager support. It seems that the foss-2016b build > >>> doesn't include Slurm: > >>> > >>> # ml OpenMPI/1.10.3-GCC-5.4.0-2.26 > >>> # ompi_info | egrep -i 'slurm|pmi' > >>> MCA ess: slurm (MCA v2.0.0, API v3.0.0, Component > >>> v1.10.3) > >>> MCA plm: slurm (MCA v2.0.0, API v2.0.0, Component > >>> v1.10.3) > >>> MCA ras: slurm (MCA v2.0.0, API v2.0.0, Component > >>> v1.10.3) > >>> > >>> Our multi-node MPI jobs fail miserably, and I surmise that this is due > >>> to the lacking Slurm support. > >>> > >>> Slurm seems to require a build of OpenMPI with 1) --with-pmi and/or 2) > >>> --with-slurm. References: > >>> > >>> 1) https://www.mail- > >> archive.com/easybuild@lists.ugent.be/msg01975.html > >>> 2) https://www.open-mpi.org/faq/?category=slurm > >>> > >>> I tried making a copy of the EB file OpenMPI-1.10.3-GCC-5.4.0-2.26.eb > >>> and appending a line: > >>> > >>> configopts += '--with-slurm --with-pmi ' > >>> > >>> and rebuilding the module with eb --force. Unfortunately, the > >>> resulting module seems *not* to include my updated configopts > (looking > >>> at the file > >>> $EASYBUILD_PREFIX/ebfiles_repo/OpenMPI/OpenMPI-1.10.3-GCC- > 5.4.0- > >> 2.26.eb). > >>> Question: How do I rebuild the OpenMPI module with proper Slurm > >> support? > >> > >> Rebuilding with --force should work, so for some reason your customized > >> EasyBuild was not picked up... > >> How did you provide it to EasyBuild exactly? Was it available in the local > >> directory where you ran the 'eb' command? > >> > >> You can verify that the right easyconfig is picked up via a dry run > >> like: "eb OpenMPI-1.10.3-GCC-5.4.0-2.26.eb -Df", which will print the path > to > >> the easyconfig files used. > >> > >>> Question: Can Slurm support please be included in future versions of > >>> the OpenMPI module in the foss-201x tool chain? > >> This is a left as a site-specific customization, since including > >> --with-slurm > hard > >> would make the installation fail on any systems that do not have SLURM. > >> > >> We should have documentation on how to deal with site-specific > >> customisations well though. > >
[easybuild] ld issue?
Hi, When installing ncurses-6.0-foss-2016b.eb the build fails: /usr/bin/ld: BFD version 2.20.51.0.2-5.42.el6 20100205 internal error, aborting at reloc.c line 443 in bfd_get_reloc_size It seems it using the system ld instead of the ld from the binutils module, although this is loaded. Why is the system ld used? Most likely I'm missing something obvious, but any help is appreciated. Thanks. Erik -- The information contained in this communication and any attachments is confidential and may be privileged, and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. Unless explicitly stated otherwise in the body of this communication or the attachment thereto (if any), the information is provided on an AS-IS basis without any express or implied warranties or liabilities. To the extent you are relying on this information, you are doing so at your own risk. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. The sender nor the company/group of companies he or she represents shall be liable for the proper and complete transmission of the information contained in this communication, or for any delay in its receipt.
RE: [easybuild] How to rebuild the foss-2016b toolchain with OpenMPI including Slurm support?
Hi Ole, We've had a similar issue, but then for PBS. I created a new eb file and added with-tm specifying full-path: configopts += '--with-tm=/full/path/to/pbs ' I then installed openmpi with --force --rebuild. For some reason when not specifying the full path it doesn't work for us at the moment. I still need to look at this, as it is inconvenient having to update this file when we upgrade PBS. At least for now it does the trick. Regards, Erik > -Original Message- > From: easybuild-requ...@lists.ugent.be [mailto:easybuild- > requ...@lists.ugent.be] On Behalf Of Kenneth Hoste > Sent: Wednesday, October 26, 2016 6:43 PM > To: easybuild@lists.ugent.be > Subject: Re: [easybuild] How to rebuild the foss-2016b toolchain with > OpenMPI including Slurm support? > > Hi Ole, > > On 26/10/16 16:03, Ole Holm Nielsen wrote: > > We use the foss-2016b toolchain, and we need OpenMPI to be built with > > Slurm resource manager support. It seems that the foss-2016b build > > doesn't include Slurm: > > > > # ml OpenMPI/1.10.3-GCC-5.4.0-2.26 > > # ompi_info | egrep -i 'slurm|pmi' > > MCA ess: slurm (MCA v2.0.0, API v3.0.0, Component > > v1.10.3) > > MCA plm: slurm (MCA v2.0.0, API v2.0.0, Component > > v1.10.3) > > MCA ras: slurm (MCA v2.0.0, API v2.0.0, Component > > v1.10.3) > > > > Our multi-node MPI jobs fail miserably, and I surmise that this is due > > to the lacking Slurm support. > > > > Slurm seems to require a build of OpenMPI with 1) --with-pmi and/or 2) > > --with-slurm. References: > > > > 1) https://www.mail- > archive.com/easybuild@lists.ugent.be/msg01975.html > > 2) https://www.open-mpi.org/faq/?category=slurm > > > > I tried making a copy of the EB file OpenMPI-1.10.3-GCC-5.4.0-2.26.eb > > and appending a line: > > > > configopts += '--with-slurm --with-pmi ' > > > > and rebuilding the module with eb --force. Unfortunately, the > > resulting module seems *not* to include my updated configopts (looking > > at the file > > $EASYBUILD_PREFIX/ebfiles_repo/OpenMPI/OpenMPI-1.10.3-GCC-5.4.0- > 2.26.eb). > > > > Question: How do I rebuild the OpenMPI module with proper Slurm > support? > > Rebuilding with --force should work, so for some reason your customized > EasyBuild was not picked up... > How did you provide it to EasyBuild exactly? Was it available in the local > directory where you ran the 'eb' command? > > You can verify that the right easyconfig is picked up via a dry run > like: "eb OpenMPI-1.10.3-GCC-5.4.0-2.26.eb -Df", which will print the path to > the easyconfig files used. > > > Question: Can Slurm support please be included in future versions of > > the OpenMPI module in the foss-201x tool chain? > This is a left as a site-specific customization, since including --with-slurm > hard > would make the installation fail on any systems that do not have SLURM. > > We should have documentation on how to deal with site-specific > customisations well though. > Is anyone doing that (JSC, CSCS, TAMU?) up for writing up some > documentation for this? > The existing documentation has some examples hinting towards a possible > setup: > http://easybuild.readthedocs.io/en/latest/Configuration.html#example > > > regards, > > Kenneth -- The information contained in this communication and any attachments is confidential and may be privileged, and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. Unless explicitly stated otherwise in the body of this communication or the attachment thereto (if any), the information is provided on an AS-IS basis without any express or implied warranties or liabilities. To the extent you are relying on this information, you are doing so at your own risk. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. The sender nor the company/group of companies he or she represents shall be liable for the proper and complete transmission of the information contained in this communication, or for any delay in its receipt.
[easybuild] caffe/mxnet/tensorflow easyconfigs
Hello, Has anyone got (working) easyconfigs for caffe, mxnet and tensorflow they are willing to share? Any work in progress is also appreciated, so we could help with these. For Caffe I've already found http://www.siliconslick.com/easybuild/ebfiles_repo_cleaned/ada/Caffe/Caffe-rc3-intel-2016a-Python-2.7.11.eb and https://github.com/hpcugent/easybuild-easyconfigs/pull/3667/files. The first is not working (at least for us) and the second is foss toolchain based, while we prefer intel toolchain based. Thanks in advance. Kind regards, Erik Smeets -- The information contained in this communication and any attachments is confidential and may be privileged, and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. Unless explicitly stated otherwise in the body of this communication or the attachment thereto (if any), the information is provided on an AS-IS basis without any express or implied warranties or liabilities. To the extent you are relying on this information, you are doing so at your own risk. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. The sender nor the company/group of companies he or she represents shall be liable for the proper and complete transmission of the information contained in this communication, or for any delay in its receipt.
RE: [easybuild] Installation foss toolchains
Hi Kenneth, > -Original Message- > > It seems like you may be filtering binutils from the dependencies (via > --filter- > deps), see also https://github.com/hpcugent/easybuild- > framework/issues/1494... Thanks, I think it was caused by an old modulesenvironment binutils version (outside of EB) which was clashing with EB. This was removed and now it seems to work fine. > For foss/2016b update we are jumping to GCC 5.4, cfr. > https://github.com/hpcugent/easybuild-easyconfigs/pull/3271. > GCC 4.9.x is getting quite old (4.9.0 was released April 2014, latest > 4.9.3 is from June 2015, cfr. https://gcc.gnu.org/develop.html#timeline). Then what's going to be the difference between foss-2016b and foss-2016.06 and why keep two toolchains that are the same besides the naming scheme? Kind regards, Erik Smeets -- The information contained in this communication and any attachments is confidential and may be privileged, and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. Unless explicitly stated otherwise in the body of this communication or the attachment thereto (if any), the information is provided on an AS-IS basis without any express or implied warranties or liabilities. To the extent you are relying on this information, you are doing so at your own risk. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. The sender nor the company/group of companies he or she represents shall be liable for the proper and complete transmission of the information contained in this communication, or for any delay in its receipt.
[easybuild] Installation foss toolchains
Hi all, When installing the foss 2015b or 2016a toolchains I run into similar errors. At some point the installation fails with: get_software_root software root for binutils was not found in environment For 2015b this occurs when installing flex 2.5 39, for 2016a this occurs when installing M4 1.4.17. It seems that installation of binutils has not been done yet or failed for some reason? Does anyone recognize this and know a solution around this to install foss-2016a? By the way: is my assumption correct that in the foss versions labelled with a and b the version for GCC will keep at 4.x compared to the foss versions with -04 which have gone to GCC 5.x? Thanks in advance. Kind regards, Erik Smeets -- The information contained in this communication and any attachments is confidential and may be privileged, and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. Unless explicitly stated otherwise in the body of this communication or the attachment thereto (if any), the information is provided on an AS-IS basis without any express or implied warranties or liabilities. To the extent you are relying on this information, you are doing so at your own risk. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. The sender nor the company/group of companies he or she represents shall be liable for the proper and complete transmission of the information contained in this communication, or for any delay in its receipt.
RE: [easybuild] OpenFOAM module file
Hi Kenneth, The problem in our opinion would be that a user wouldn't return to a clean environment when unloading the modules. Furthermore, this complicates switching between different versions. What's your thought on this and how do you approach these requirements within your systems? Kind regards, Erik > -Original Message- > From: easybuild-requ...@lists.ugent.be [mailto:easybuild- > requ...@lists.ugent.be] On Behalf Of Kenneth Hoste > Sent: Tuesday, July 05, 2016 10:21 AM > To: easybuild@lists.ugent.be > Subject: Re: [easybuild] OpenFOAM module file > > Hi Erik, > > The problem is that the script provided by OpenFOAM that should be > sourced may depend on the environment in which it is sourced... > > In other words, a user may (potentially) define environment variables that > change what the script does, making it a dynamic thing that can not be > encapsulated in a module (or at least, can not be automated easily). > > You're right that without the changes to the environment being done via a > source script makes them hard to reverse in the same session, but is that a > big problem in practice? > > > regards, > > Kenneth > > On 05/07/16 09:51, Erik Smeets wrote: > > Hi, > > > > After installing OpenFOAM with EasyBuild I see that the the modulefile > created does not set all OpenFOAM environment variables, but instead the > bashrc or cshrc file from OpenFOAM itself needs to be sources. Could > someone explain why this approach is chosen instead of including the > environment variables directly in the modulefile? The main objection with > the chosen approach is that when the modulefile is now unloaded, the set > environment variables are not unset. > > > > Thanks in advance. > > Kind regards, > > Erik Smeets > > > > -- The information contained in this communication and any attachments is > confidential and may be privileged, and is for the sole use of the intended > recipient(s). Any unauthorized review, use, disclosure or distribution is > prohibited. Unless explicitly stated otherwise in the body of this > communication or the attachment thereto (if any), the information is > provided on an AS-IS basis without any express or implied warranties or > liabilities. To the extent you are relying on this information, you are doing > so > at your own risk. If you are not the intended recipient, please notify the > sender immediately by replying to this message and destroy all copies of this > message and any attachments. The sender nor the company/group of > companies he or she represents shall be liable for the proper and complete > transmission of the information contained in this communication, or for any > delay in its receipt. -- The information contained in this communication and any attachments is confidential and may be privileged, and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. Unless explicitly stated otherwise in the body of this communication or the attachment thereto (if any), the information is provided on an AS-IS basis without any express or implied warranties or liabilities. To the extent you are relying on this information, you are doing so at your own risk. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. The sender nor the company/group of companies he or she represents shall be liable for the proper and complete transmission of the information contained in this communication, or for any delay in its receipt.
[easybuild] OpenFOAM module file
Hi, After installing OpenFOAM with EasyBuild I see that the the modulefile created does not set all OpenFOAM environment variables, but instead the bashrc or cshrc file from OpenFOAM itself needs to be sources. Could someone explain why this approach is chosen instead of including the environment variables directly in the modulefile? The main objection with the chosen approach is that when the modulefile is now unloaded, the set environment variables are not unset. Thanks in advance. Kind regards, Erik Smeets -- The information contained in this communication and any attachments is confidential and may be privileged, and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. Unless explicitly stated otherwise in the body of this communication or the attachment thereto (if any), the information is provided on an AS-IS basis without any express or implied warranties or liabilities. To the extent you are relying on this information, you are doing so at your own risk. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. The sender nor the company/group of companies he or she represents shall be liable for the proper and complete transmission of the information contained in this communication, or for any delay in its receipt.
RE: [easybuild] Conflict in module dependency when installing Paraview
Hi Kenneth, > -Original Message- > > What would be the correct solution to this issue when using dependency > issues/conflicts like this in EasyBuild? > > Your conclusion is correct, but not entirely: the conflict is reported on on > libX11 that does not have a versionsuffix > (libx11/1.6.3-intel-2016.03-GCC-5.3) with one that *does* have a > (Python) versionsuffix (libx11/1.6.3-intel-2016.03-GCC-5.3-Python-2.7.10). > > So, it seems it's not the libX11 dep in Qt that is to blame. > > Since EasyBuild requires strict versioning (which includes version suffixes), > you'll need to make sure you use one or the other. Is there a way (eb option) to enforce one or the other? Or do I need to create a new eb-file for this? I mean, when installing Paraview with the robot option it automagically installs all dependencies but then it hits this conflict. Kind regards, Erik Smeets [Erik Smeets] -- The information contained in this communication and any attachments is confidential and may be privileged, and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. Unless explicitly stated otherwise in the body of this communication or the attachment thereto (if any), the information is provided on an AS-IS basis without any express or implied warranties or liabilities. To the extent you are relying on this information, you are doing so at your own risk. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. The sender nor the company/group of companies he or she represents shall be liable for the proper and complete transmission of the information contained in this communication, or for any delay in its receipt.
RE: [easybuild] Difference in toolchains goolf and foss
Hi Kenneth, > -Original Message- > >> Does that help? > We have plans to deprecate some old/inactive toolchains; the ones I have in > mind are 'goalf', 'ictce' and 'iqacml'. > We won't drop 'goolf' though, since it is still being used actively (i.e., > we're > aware of people using it and we're getting pull requests for easyconfigs using > 'goolf'). I understand the trouble in dropping an actively used toolchain. Would it be an idea to have a comment like "deprecated" behind those toolchains that aren't actively maintained when getting the list with --list-toolchains? Or split the list in two sections: official/actively maintained toolchains and unofficial/community maintained toolchains? Kind regards, Erik Smeets -- The information contained in this communication and any attachments is confidential and may be privileged, and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. Unless explicitly stated otherwise in the body of this communication or the attachment thereto (if any), the information is provided on an AS-IS basis without any express or implied warranties or liabilities. To the extent you are relying on this information, you are doing so at your own risk. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. The sender nor the company/group of companies he or she represents shall be liable for the proper and complete transmission of the information contained in this communication, or for any delay in its receipt.
RE: [easybuild] Difference in toolchains goolf and foss
Hi Kenneth, > -Original Message- > Does that help? This does certainly help. Thanks for the explanation. Did I overlook this somewhere in the documentation? I might be helpful for new users to mention the status of the toolchains to choose the right ones. Are there any plans to remove the old toolchains or do you leave them as they are? Kind regards, Erik Smeets -- The information contained in this communication and any attachments is confidential and may be privileged, and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. Unless explicitly stated otherwise in the body of this communication or the attachment thereto (if any), the information is provided on an AS-IS basis without any express or implied warranties or liabilities. To the extent you are relying on this information, you are doing so at your own risk. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. The sender nor the company/group of companies he or she represents shall be liable for the proper and complete transmission of the information contained in this communication, or for any delay in its receipt.
[easybuild] Difference in toolchains goolf and foss
Hello, Can someone provide some information that explains the differences between the goolf and foss toolchains? It seems that goolf has not been updated recently, so should we assume that this is legacy and that foss is preferred? Thanks in advance. Kind regards, Erik Smeets -- The information contained in this communication and any attachments is confidential and may be privileged, and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. Unless explicitly stated otherwise in the body of this communication or the attachment thereto (if any), the information is provided on an AS-IS basis without any express or implied warranties or liabilities. To the extent you are relying on this information, you are doing so at your own risk. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. The sender nor the company/group of companies he or she represents shall be liable for the proper and complete transmission of the information contained in this communication, or for any delay in its receipt.
[easybuild] Conflict in module dependency when installing Paraview
Hello,
Recently, we started using EasyBuild and are now facing an issue when
installing Paraview using the Intel toolchain.
== FAILED: Installation ended unsuccessfully (build directory:
/tmp/easybuild/Qt/4.8.7/intel-2016.03-GCC-5.3): build failed (first 300 chars):
libx11/1.6.3-intel-2016.03-GCC-5.3(11):ERROR:150: Module
'libx11/1.6.3-intel-2016.03-GCC-5.3' conflicts with the currently loaded
module(s) 'libx11/1.6.3-intel-2016.03-GCC-5.3-Python-2.7.10'
== Results of the build can be found in the log file
/tmp/eb-FUg2ds/easybuild-Qt-4.8.7-20160629.131758.sXrej.log
ERROR: Build of
/tmp/eb-FUg2ds/tweaked_easyconfigs/Qt-4.8.7-intel-2016.03-GCC-5.3.eb failed
(err: "build failed (first 300 chars):
libx11/1.6.3-intel-2016.03-GCC-5.3(11):ERROR:150: Module
'libx11/1.6.3-intel-2016.03-GCC-5.3' conflicts with the currently loaded
module(s) 'libx11/1.6.3-intel-2016.03-GCC-5.3-Python-2.7.10'")
It seems to me that there are two different installations are used. One
dependency comes from ParaView-4.4.0-intel-2015b.eb:('libX11', '1.6.3',
pysuff), the other from Qt-4.8.7-intel-2015b.eb:('libX11', '1.6.3',
'-Python-2.7.10'). This results in the error shown above.
What would be the correct solution to this issue when using dependency
issues/conflicts like this in EasyBuild?
Thanks in advance.
Kind regards,
Erik Smeets
-- The information contained in this communication and any attachments is
confidential and may be privileged, and is for the sole use of the intended
recipient(s). Any unauthorized review, use, disclosure or distribution is
prohibited. Unless explicitly stated otherwise in the body of this
communication or the attachment thereto (if any), the information is provided
on an AS-IS basis without any express or implied warranties or liabilities. To
the extent you are relying on this information, you are doing so at your own
risk. If you are not the intended recipient, please notify the sender
immediately by replying to this message and destroy all copies of this message
and any attachments. The sender nor the company/group of companies he or she
represents shall be liable for the proper and complete transmission of the
information contained in this communication, or for any delay in its receipt.
