Intel® MPI Library
Get help with building, analyzing, optimizing, and scaling high-performance computing (HPC) applications.
2219 Discussions

Bug with setvars.sh in latest version (or a subscript)

L__D__Marks
New Contributor II
9,789 Views

I downloaded and installed yesterday the latest base and HPC toolkits. I noticed today a bug in one or more of the scripts. After "source /opt/intel/oneapi/setvars.sh" (using --force does not matter), I am getting for "echo $1 ; echo $2 ; echo $9" (or similar)

advisor=latest
ccl=latest
dpl=latest

 

In other words the values that would be printed out are being exported into my environment, which is obviously not what I want!

0 Kudos
1 Solution
L__D__Marks
New Contributor II
9,027 Views

I did not respond since he clearly did not believe anything that I was reporting.

 

I looked more carefully at the setvars.sh script, and it is a classic example of a "Greedy Algorithm", Quoting from https://en.wikipedia.org/wiki/Greedy_algorithm (similar can be found elsewhere):

 

"A greedy algorithm is any algorithm that follows the problem-solving heuristic of making the locally optimal choice at each stage"

 

Greed can be good, but often also bad. As an illustration, suppose you want a total of 41 cents from a combination of 25, 10 and 4 cent coins. The Greedy approach is to reduce this as much as possible with 25 cents, so we take one leaving 16 cents more needed. Next, we reduce this as much as possible with a 10 cent coin – leaving 6. Then we can only use a single 4 cent; oops, we can only make 39 cents!

 

The different versions of the setvars.sh do not have date or release number information (bad practice!), but quoting from one:

 

# Convert a list of '\n' terminated strings into a format that can be moved
# into the positional arguments array ($@) using the eval "set -- $array_var"

 

This is classic greedy coding, converting arguments into the general $1 $2 etc variables for local convenience, ignoring the possible wider implications of this. Rather than using global variables that might be used for something else, good coding is to use local variables which are not conflicting with anything else.

 

My patch for what I consider to be poor coding is to myself save then restore the variables that the Intel code should not be using, i.e.

 

var="$@"
source /opt/intel/oneapi/setvars.sh ...
eval set -- $var

View solution in original post

0 Kudos
33 Replies
PaulF_IntelCorp
Employee
3,858 Views

@L__D__Marks  -- sorry the attached file was rejected by the forum. The changes to this file:

 

/opt/intel/oneapi/intelpython/latest/env/vars.sh

 

are very simple. Insert the following two lines of code in the locations specified:

 

echo "LINENO: ${LINENO}"
echo "$@"

 

Please add those two lines of code into the `intelpython/env/vars.sh` file, as shown below. Several lines of code above and below the insertion point are shown for reference.

At approximately line 16:

 

# code at the end of this file for more help.


echo "LINENO: ${LINENO}"
echo "$@"


# ############################################################################

# Get absolute path to this script.
# Uses `readlink` to remove links and `pwd -P` to turn into an absolute path.

 

At approximately line 201:

 

  return 255 2>/dev/null || exit 255
fi

echo "LINENO: ${LINENO}"
echo "$@"


SCRIPTPATH=$(get_script_path "${vars_script_name:-}")
ROOTPATH=$(dirname -- "${SCRIPTPATH}")

 

At approximately line 228:

 

fi
POTENTIAL_ACTIVATE_PATH="$ROOTPATH/../../$MAINENV/$PYVER/bin/activate"

echo "LINENO: ${LINENO}"
echo "$@"


# Setup conda environment env vars so the command prompt gets the correct "(env)" string
if [ "${vars_script_name}" = "${CURRENTENV}/latest/env/vars.sh" ] ; then

 

At approximately line 312:

 

    fi
fi

echo "LINENO: ${LINENO}"
echo "$@"


unset OVERWRITE_CONDA_DEFAULT_ENV
unset SCRIPTPATH

 

Then please paste the output generated by running the `setvars.sh` script.

0 Kudos
ShivaniK_Intel
Moderator
3,840 Views

Hi,


Could you please follow the above steps provided by @PaulF_IntelCorp  and provide us with the output generated by running the `setvars.sh` script?


Thanks & Regards

Shivani


0 Kudos
ShivaniK_Intel
Moderator
3,831 Views

Hi,


As we didn't hear back from you, Could you please let us know whether your issue is resolved or not? If not, Could you please follow the above steps provided by @PaulF_IntelCorp  and provide us with the output generated by running the `setvars.sh` script?


Thanks & Regards

Shivani


0 Kudos
L__D__Marks
New Contributor II
9,028 Views

I did not respond since he clearly did not believe anything that I was reporting.

 

I looked more carefully at the setvars.sh script, and it is a classic example of a "Greedy Algorithm", Quoting from https://en.wikipedia.org/wiki/Greedy_algorithm (similar can be found elsewhere):

 

"A greedy algorithm is any algorithm that follows the problem-solving heuristic of making the locally optimal choice at each stage"

 

Greed can be good, but often also bad. As an illustration, suppose you want a total of 41 cents from a combination of 25, 10 and 4 cent coins. The Greedy approach is to reduce this as much as possible with 25 cents, so we take one leaving 16 cents more needed. Next, we reduce this as much as possible with a 10 cent coin – leaving 6. Then we can only use a single 4 cent; oops, we can only make 39 cents!

 

The different versions of the setvars.sh do not have date or release number information (bad practice!), but quoting from one:

 

# Convert a list of '\n' terminated strings into a format that can be moved
# into the positional arguments array ($@) using the eval "set -- $array_var"

 

This is classic greedy coding, converting arguments into the general $1 $2 etc variables for local convenience, ignoring the possible wider implications of this. Rather than using global variables that might be used for something else, good coding is to use local variables which are not conflicting with anything else.

 

My patch for what I consider to be poor coding is to myself save then restore the variables that the Intel code should not be using, i.e.

 

var="$@"
source /opt/intel/oneapi/setvars.sh ...
eval set -- $var

0 Kudos
ShivaniK_Intel
Moderator
3,781 Views

Hi,


>>>I downloaded and installed yesterday the latest base and HPC toolkits


Could you please confirm the version of Intel oneAPI you have been using?


Thanks & Regards

Shivani


0 Kudos
ShivaniK_Intel
Moderator
3,749 Views

Hi,


I would like to share a few observations with you.


Method 1:


Step1:


When I source the setvars.sh script of Intel oneAPI 2022.3 and 


echo $1 ; echo $2 ; echo $9


 


I am getting nothing


Step2:


Later I am forcing the setvars.sh script of Intel onaeAPI 2022.3 and 


echo $1 ; echo $2 ; echo $9


 


I am getting nothing


Method2:


When I follow the same method1 with Intel oneAPI 2022.2 and 


echo $1 ; echo $2 ; echo $9


In Step1 I am getting nothing


But in Step2 I am getting


advisor=latest

ccl=latest

dpcpp-ct=latest


 

As we are unable to reproduce the issue with the latest version(2022.3). Could you please confirm the Intel oneAPI version you have been using?


Thanks & Regards

Shivani



0 Kudos
L__D__Marks
New Contributor II
3,740 Views
Since the setvars.sh script has no release information in it, I have no idea what version I am using. It could be any from 2020 to 2023.

I previously marked my patch as the solution. Sorry, but I have better things to do since it has taken more than two months for you to acknowledge that I might be right.
0 Kudos
ShivaniK_Intel
Moderator
3,722 Views

Hi,


>>>"Since the setvars.sh script has no release information in it, I have no idea what version I am using. It could be any from 2020 to 2023".


Could you please check any of the compiler versions in the Intel oneAPI base toolkit and HPC toolkit to know the version you have been using?


Example:


dpcpp --version


icx --version


As the issue is resolved could you please confirm whether we can close this thread?


Thanks & Regards

Shivani


0 Kudos
L__D__Marks
New Contributor II
3,716 Views

Sorry, but your suggestion is not useful. As you know, multiple compiler etc versions can exist in the same directory, all sourced by the same setvars.sh script and under the control of the configuration file. There is no connection between them.

 

The setvars.sh script should have date and version information.

 

So long as you don't mark this as something you have solved, you can close it. (I resolved it by patching around your problem.)

 

0 Kudos
ShivaniK_Intel
Moderator
3,672 Views

Hi,


There is a file that contains the current version of the installed oneAPI tools.


The file is located in:


$ONEAPI_ROOT/dev-utilities/latest/bin/version.txt


The content of that file will match the version of the setvars.sh script.


Thanks & Regards

Shivani


0 Kudos
L__D__Marks
New Contributor II
3,663 Views

It will iff just a single version has been installed. However, if multiple have and some have been uninstalled there is little reason it should match.

0 Kudos
ShivaniK_Intel
Moderator
3,615 Views

Hi,


Could you please let us know whether do you have multiple versions of Intel oneAPI?


If yes, could you please let us know how do you source the Intel oneAPI environment?


Thanks & Regards

Shivani


0 Kudos
ShivaniK_Intel
Moderator
3,593 Views

Hi,


We have not heard back from you. This thread will no longer be monitored by Intel. If you need further assistance please post a new question.


Thanks & Regards

Shivani


0 Kudos
Reply