OneAPI evironment modules version assumptions (4.1 vs. 3.2.10)

[CFR]

It looks like the OneAPI releases (2021.02/03) assume that one is running environment modules 4.1 or later (specifically for is-avail).  I don't know about other sites, but my systems run anything from CentOS 6.6 to 7.9 and the default is environment modules 3.2.10.  So far it's been easy enough to hack the modulefiles so they work on older, common, versions but I'm concerned that in the future newer features will start being used and make life difficult.  I'd like to request that Intel consider making sure the environment modules are compatible (or easily adaptable) to 3.2.10.

Don't get me wrong, it beats the old days of having to craft modules for Intel software from scratch, so I'd hate to see it go back to that.

[SantoshY_Intel]

Hi,

Thanks for providing your feedback.

We will forward your suggestions to the concerned team. We will get back to you soon regarding the same.

Could you please let us know if there is anything else that we could help you with?

Thanks & Regards,

Santosh

[SantoshY_Intel]

Hi,

Thank you for your patience. The issue raised by you has been fixed in the intel oneAPI 2021.4 version. So, could you please download and let us know if this resolves your issue.

Best Regards,

Santosh

[CFR]

Sadly no.  There are still 4.x-isms in the modulefiles.  One specific example is the compiler modulefile which contains 'is-avail' which looks to be from 4.1 (https://modules.readthedocs.io/en/latest/modulefile.html#mfcmd-is-avail).  I didn't not examine all the other modulefiles to see if there are more examples.

[PaulF_IntelCorp]

@CFR -- the issue was only partially fixed in the 2021.4 release. In the 2021.4 release (the October, 2021 release) two new modulefiles were added that work with Modulefiles version 3.2.10: "icc" and "icc32" -- these new modulefiles will initialize the environment for use with the "classic compilers" (aka icc and ifort). However, support for initializing the new "dpcpp," "icx" and "ifx" compilers is not supported with Modulefiles version 3.2.10 in the 2021.4 release. That fix will be part of the next release.

If you only need to use the icc or the ifort "classic compilers" with your modulefiles 3.2.10 system the new icc and icc32 modulefiles will work.

If you look inside the latest compiler installation folder, you'll see the following modulefiles:

$ ll intel/oneapi/compiler/2021.4.0/modulefiles/
total 48K
-rwxr-xr-x 1 ubuntu ubuntu 4.1K Sep 24 08:00 compiler*
-rwxr-xr-x 1 ubuntu ubuntu 4.1K Sep 24 08:00 compiler32*
-rwxr-xr-x 1 ubuntu ubuntu 3.4K Sep 24 08:00 compiler-rt*
-rwxr-xr-x 1 ubuntu ubuntu 3.2K Sep 24 08:00 compiler-rt32*
-rwxr-xr-x 1 ubuntu ubuntu 3.4K Sep 24 08:00 icc*
-rwxr-xr-x 1 ubuntu ubuntu 3.4K Sep 24 08:00 icc32*
lrwxrwxrwx 1 ubuntu ubuntu   44 Sep 24 13:22 init_opencl -> ../linux/lib/oclfpga/modulefiles/init_opencl
lrwxrwxrwx 1 ubuntu ubuntu   40 Sep 24 13:22 oclfpga -> ../linux/lib/oclfpga/modulefiles/oclfpga

 Note the addition of the "icc" and "icc32" modulefiles.

[CFR]

Fair enough.  I realize it's going to be tough to stay within 3.2.10 so doing so as much as possible is appreciated.  I just hack the remaining module files to get them to work locally.

[SantoshY_Intel]

Hi,

As Paul mentioned, your issue was partially fixed in the intel oneAPI 2021.4 release by adding two modulefiles for icc and icc32 which can be worked with the modulefiles version 3.2.10.

Support for initializing other compilers(DPCPP/ICX/IFX) is not yet supported with modulefiles version 3.2.10 in the 2021.4 release. That fix will be part of the next release.

For the time being, could you please let us know whether to keep this thread open? (or) to close this issue at our end?

Thanks & Regards,

Santosh

Thanks & Regards,

Santosh

[CFR · Accepted solution]

It was mainly a request/suggestion so I guess if you want to close it that's fine.

[SantoshY_Intel]

Hi,

We are closing this thread for now. If you need any additional information, please post a new question as this thread will no longer be monitored by Intel.

Thanks & Regards,

Santosh