topic Yeah, we use the hardcoded in Intel® MPI Library

mpivars.sh to build path automatically

Tiago_M_1 — Wed, 18 Feb 2015 01:27:49 GMT

Looks like on Linux the intel MPI runtime hardcodes the path of mpivars.sh, eg:
I_MPI_ROOT=/opt/intel/impi/4.1.3.049; export I_MPI_ROOT

On windows on the other hand the path is dynamically generated:
SET I_MPI_ROOT=%~dp0..\..

Is there any reason to why the path cannot also be automatically generated on Linux?
http://stackoverflow.com/questions/242538/unix-shell-script-find-out-which-directory-the-script-file-resides

We have two situations were this would help:
1 - redistributing the mpi runtime with our application, and
2 - having machines with that folder mounted into different mount points.

Hi,

Artem_R_Intel1 — Thu, 19 Feb 2015 08:16:34 GMT

Hi,
Generic solution for different shell interpreters, different usage scenarios (different current directories, using by absolute or relative paths, different ways of sourcing and so on) is too complex and may be unsafe.
I'd say mpivars.sh is designed according to the principle "keep it short and simple".

Hi Tiago,

KitturGanesh — Thu, 19 Feb 2015 17:53:49 GMT

Hi Tiago,
Good observation and I'll get back to you after finding out more on the reason for such an implementation, thanks
_Kittur

Hi Tiago,

KitturGanesh — Thu, 19 Feb 2015 19:19:33 GMT

Hi Tiago,
I think Artem's response appears to me as a very valid response. Nevertheless, let me file an issue with our developers as a feature request and they can investigate to see if there's anything that can be done further down the road. Thanks for bringing this to our attention and I'll update you accordingly if I've any further update on this.
_Kittur

Hi Kittur,

Tiago_M_1 — Thu, 19 Feb 2015 19:26:51 GMT

Hi Kittur,

Agreed, his response does makes sense. I guess that with the number of platform you support it gets complicated to support every shell variation.
Maybe it would be possible to have variations of that script that target certain mainstream shells (bash - mpivars.bash for example) which would solve the problem.

Anyway, thanks for having a look at it.

Thanks,
Tiago

Hi Tiago,

Gergana_S_Intel — Thu, 19 Feb 2015 20:07:00 GMT

Hi Tiago,

Just to clarify, we already have 2 separate scripts to cover the major shells: BASH and CSH. The mpivars.sh script is meant for BASH or compatible environments and mpivars.csh does the same for CSH. Both of those are available in the bin64/ directory.

But, as Kittur, pointed out, he'll submit a feature request to the team so it's entered into our internal system.

All the best,
~Gergana

Hi Gergana,

Tiago_M_1 — Thu, 19 Feb 2015 20:40:06 GMT

Hi Gergana,

Yeah I saw that. mpivars.sh point to "#! /bin/sh" which does not necessarily points to bash. in ubuntu it points to dash and in older redhat systems it is not unusual to come accros /bin/csh.

Why not use "#! /usr/bin/env bash" and explicitly point to bash?

Sorry being a PITA, but HEY that's how we learn things =)

Best,
Tiago

Thanks, Tiago. You've hit on

Gergana_S_Intel — Thu, 19 Feb 2015 20:53:42 GMT

Thanks, Tiago. You've hit on the Ubuntu issue which we have seen before. Part of it is usage of the Intel MPI Library: we don't see a lot of it on Ubuntu systems. As for red hat, we officially support only the last 2 releases: RHEL 6 and 7 although we certainly have customers using older versions.

Regardless, your points are well taken and well argued :) Kittur, I trust you'll get this added to the feature request you're submitting.

~Gergana

Just FYI I fixed my own bash

Tiago_M_1 — Thu, 19 Feb 2015 22:53:07 GMT

Just FYI I fixed my own bash script and now hit the same issue with mpdboot.py looks like it also has a hardcoded path.

Yeah, we use the hardcoded

Gergana_S_Intel — Thu, 19 Feb 2015 22:57:40 GMT

Yeah, we use the hardcoded path in a couple of spots.

Don't use mpdboot since the MPDs are being deprecated. I would recommend using mpiexec.hydra or mpirun directly. What version of Intel MPI do you have, by the way? Latest is Intel MPI 5.0.3 so might be good to upgrade.

~Gergana

It is one of those situations

Tiago_M_1 — Thu, 19 Feb 2015 23:14:55 GMT

It is one of those situations that I am only wrapping around someone else's code. It seems like they are still using 4.1.2.040. I will pass the info forward. Thanks!