environment variables in `.bashrc` are accessible linux CLI, but not from the `gurobi.sh` executable.

I'm using gurobi_cl in a program that runs on a multi-node compute cluster.

For context, I am running the commands below in an interactive instance on a single compute node.

I have used my program to call gurobi_cl in this compute environment before without a hitch, but all of the sudden I have having issues. The program fails to load gurobi_cl.

I can load gurobi_cl just fine from my terminal instance, but I can't load gurobi.sh from my PATH. I think that not being able to load gurobi.sh from PATH (although it is found ther might have something to do with my program not being able to call gurobi_cl.

When I call gurobi.sh, the error says GUROBI_HOME is not set, but it is (see below).
If I manually enter the lines from gurobi.sh into the command line, then I am able to load the shell.

Please help me configure my environment such that I can directly execute gurobi.sh.

(.venv) [ME@NODE_N linux64]$gurobi.sh
Environment variable GUROBI_HOME is not set. Consult the Gurobi
Quick Start Guide for information on how to set it.
/gpfs/home/ME/.local/opt/gurobi1002/linux64/bin/gurobi.sh:line17:/bin/python3.7:No such file or directory

(.venv) [ME@NODE_N linux64]$ echo $GUROBI_HOME
/gpfs/home/ME/.local/opt/gurobi1002/linux64

(.venv) [ME@NODE_N linux64]$ which gurobi.sh
/gpfs/home/ME/.local/opt/gurobi1002/linux64/bin/gurobi.sh

Here I copy-paste the contents of gurobi.sh, from the path above, directly into the terminal.


(.venv) [ME@NODE_N linux64]$ #!/bin/sh
(.venv) [ME@NODE_N linux64]$
(.venv) [ME@NODE_N linux64]$ if test -z "${GUROBI_HOME}" ; then
> echo
> echo "Environment variable GUROBI_HOME is not set. Consult the Gurobi"
> echo "Quick Start Guide for information on how to set it."
> echo
> fi
(.venv) [ME@NODE_N linux64]$
(.venv) [ME@NODE_N linux64]$ PATH=$GUROBI_HOME/bin:$PATH;export PATH
(.venv) [ME@NODE_N linux64]$ LD_LIBRARY_PATH=$GUROBI_HOME/lib:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH
(.venv) [ME@NODE_N linux64]$ PYTHONHOME=$GUROBI_HOME;export PYTHONHOME
(.venv) [ME@NODE_N linux64]$ PYTHONPATH=$GUROBI_HOME:$PYTHONPATH;export PYTHONPATH
(.venv) [ME@NODE_N linux64]$
(.venv) [ME@NODE_N linux64]$ PYTHONSTARTUP=$PYTHONHOME/lib/gurobi.py;export PYTHONSTARTUP
(.venv) [ME@NODE_N linux64]$
(.venv) [ME@NODE_N linux64]$ $PYTHONHOME/bin/python3.7 "$@"

Upon doing so, the gurobi shell loads.

Python3.7.14 (default, Sep152022,10:56:34)

[GCC 4.8.5 20150623 (Red Hat 4.8.5-44)] on linux

Type"help","copyright","credits"or"license"formoreinformation.

Set parameter WLSAccessID
Set parameter WLSSecret
Set parameter License ID to value 2406149
Set parameter LogFile to value "gurobi.log"
Academic license - for non-commercial use only - registered to ME@INSTITUTION.edu

GurobiInteractiveShell (linux64), Version 10.0.2
Copyright (c) 2023, Gurobi Optimization, LLC

Type "help()" for help

Is there any reason why I wouldn't be able to run

/gpfs/home/ME/.local/opt/gurobi1002/linux64/bin/gurobi.sh

but that by copy-pasting the contents of the source file, I'm able to load into the shell?

I realize that gurobi.sh is looking for Python3.7 in `/bin/Python3.7` and it is really located at `$GUROBI_HOME/bin/python3.7`.

I don't know why the .sh script is not reading a value for $GUROBI_HOME when it appears that it is set.

I have the following environment variables set in `.bashrc` and these are accessible form my command line instance, but not from the `gurobi.sh` executable.

GUROBI_HOME="/gpfs/home/ME/.local/opt/gurobi1002/linux64"
export PATH="${PATH}:${GUROBI_HOME}/bin"
export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${GUROBI_HOME}/lib"
export GRB_LICENSE_FILE="${GUROBI_HOME}/gurobi.lic"

Riley Clement

Gurobi Staff

September 14, 2023 00:50

Hi Matthew,

Can you see if running

source gurobi.sh

activates the shell?

- Riley

Matthew Hall

September 14, 2023 05:15
Edited

yes, it does

September 14, 2023 05:36

I see, well that is certainly one way you could run it.

I am wondering if your Python virtual environment (.venv) is causing issues here, since it will modify environment variables. The Gurobi shell is just a wrapper around a lightweight Python executable so it may not be surprising if a virtual environment is causing a problem. Can you try running gurobi.sh outside your virtual environment and see if it makes a difference?

Gwyneth Butera

September 14, 2023 14:15

Can you please add export before

GUROBI_HOME="/gpfs/home/ME/.local/opt/gurobi1002/linux64"

E.g., export GUROBI_HOME=/gpfs/home/ME/.local/opt/gurobi1002/linux64.
You need to make sure the variable is exported so it is inherited to child processes! It is not sufficient to simply execute GUROBI_HOME=/gpfs/home/ME/.local/opt/gurobi1002/linux64.

Matt Hall

September 14, 2023 16:38

Thank you! How silly of me to leave export off of that one line. That has fixed my issue.

environment variables in `.bashrc` are accessible linux CLI, but not from the `gurobi.sh` executable.

Comments

Didn't find what you were looking for?