Modification: intel-compilers-devel and intel-mpi-devel

[jcsiadal]

[Submitter’s note: the standard submission form doesn’t really fit this request. This is a significant modification to an existing component, but if this is the wrong place to submit, just let me know.]

Overview of change Expand the intel-compilers-devel and intel-mpi-devel packages to look for and create Lmod modules for Intel cluster runtime libraries.

Rationale Allows OpenHPC sysadmins to more easily configure no-cost Intel libraries, allowing clusters users execute binaries compiled with Intel developer tools without requiring the full Parallel Studio installation. Simplify Lmod setup for Intel libraries, regardless of source.

The Intel runtime libraries are available at no cost through public YUM and APT repos. They provide everything necessary for execution of binaries pre-compiled with Parallel Studio (C, Fortran, TBB, IPP, IMPI).

https://software.intel.com/en-us/articles/installing-intel-parallel-studio-xe-runtime-2019-using-yum-repository

License No license file is needed. As the OpenHPC component doesn’t include 3rd-party IP, no license change to existing components is needed.

Detail The objective is that in addition to creating Lmod modules for the full compiler and MPI installations, the RPM would also create modules for any installed runtime-only versions. This is done by changing the scan algorithm:

1. Look for runtime components.
2. If found, scan that directory for PSXE-specific compilers. a. If found, create Intel Compiler or Intel MPI Lmod modules (the current design) b. If not found, create Intel Compiler Runtime or Intel MPI Runtime Lmod modules
3. If an Lmod manifest entry already exists for a version/directory, skip module creation.
4. If a manifest entry exists for a non-existent installation, remove the entry and module.

In all cases, family names will not change. PSXE and runtime-only modules should not be concurrently active.

With regard to toolchains, I see two options:

1. Place the new modules under “/opt/ohpc/pub//intel” and treat them as any other PSXE module. If the latest is a runtime-only and a full compiler tool chain is needed, the user will need to manually select the correct module.
2. Place the runtimes module under “intel-rt” instead of “intel”, preventing the current toolchain defaults from using runtimes automatically.

I prefer option 1. Long term, the toolchains should be using the runtimes by default—most real work is about running apps and not rebuilding them.

Recommendations I recommend updating the scan to use ‘find’ instead of ‘rpm’. It’s slow, but it also adds support for remote-mounted PSXE installations (fairly common). I would exclude scanning into automounts and links.

I also recommend pulling the installation scripts out of the rpm and creating a dedicated admin binary/script. It would extract and run on installation, but instead of requiring RPM reinstallation after updating developer tools, the sysadmin would have a tool to update and clean up the modules.

---

Please keep me informed about review feedback. If the TSC approves this change, I’m willing to own the work.

Thanks,

Jeremy Siadal Open Source Technology Center Intel Corporation (503) 712-9034

[jcsiadal]

One followup on runtimes vs. compilers: would the right direction be to restrict /intel to runtimes only and move the full Parallel Studio modules to /intel-parallel-studio. This would align with the current Spack implementation. Should Spack naming be realigned with OpenHPC? Or are different naming schemes OK?

[koomie]

As an existing component, this should not be submitted as a new submission. Also, users accessing builds in ohpc that leverage parallel studio need more than runtimes, they need to be able to compile and link and installing only runtimes doesn't make a whole lot of sense in the current dev environment. Finally, we really do want to get to the point where we can use standard rpm discovery and dependency semantics but are hampered now by the current packaging of psxe. I know you are hoping to improve upon this and I think it makes sense to get this sorted out first before revamping the modules creation process.