【服务器】配置Gurobi环境 + 提交Python命令run_gurobi
目录
Gurobi安装及配置
要测试 Gurobi WLS (Web License Service) Academic 许可证是否安装配置成功,最核心的验证点是:Gurobi 能否在运行时正确连接到 Web License 服务器并获取 Token。
1. 基础环境验证 (命令行测试)
在终端(Terminal)或命令行中运行 Gurobi 自带的交互式 Shell。
操作步骤:
在命令行输入:
gurobi.sh # Linux/macOS
# 或者
gurobi # Windows
成功标志:
如果配置成功,你应该会看到类似以下的启动信息,重点关注 WLS license 字样:
```text
Gurobi Interactive Shell (linux64), Version 10.0.x
Copyright (c) 2023, Gurobi Optimization, LLC
...
Set parameter LogFile to value "gurobi.log"
Using license file /path/to/gurobi.lic
Set parameter LicenseID to value XXXXXX <-- 你的 License ID
Set parameter WLSACCESSID to value xxxxx-xxxx-xxxx...
Set parameter WLSSECRET to value xxxxx-xxxx-xxxx...
Academic license - for non-commercial use only - expires 202X-XX-XX
gurobi>
```
*注意:如果看到 `WLSACCESSID` 和 `WLSSECRET` 参数被设置,且没有报错直接进入了 `gurobi>` 提示符,说明连接成功。*
2. Python 代码测试 (推荐)
由于 WLS 经常用于 Python 环境,写一个极简的 Python 脚本来测试是最稳妥的。这个脚本会尝试创建一个 Gurobi 环境(Environment),这一步会触发许可证验证。
运行代码:
source activate myenv3.10
python test_gurobi_wls.py
创建一个名为 test_gurobi_wls.py 的文件,写入以下代码:
import gurobipy as gp
from gurobipy import GRB
def test_wls_connection():
print("--- 开始测试 Gurobi WLS 连接 ---")
try:
# 尝试创建一个默认环境
# Gurobi 会自动读取默认路径下的 gurobi.lic 文件
# 或者读取环境变量 GRB_LICENSE_FILE 指向的文件
with gp.Env(empty=True) as env:
# 如果你是硬编码在代码里(不推荐,但有时用于测试),可以在这里 setParam
# env.setParam('WLSACCESSID', '你的ID')
# env.setParam('WLSSECRET', '你的SECRET')
# env.setParam('LICENSEID', 你的LICENSE_ID)
env.start() # 这一步真正触发联网验证
print("\n[成功] Gurobi 环境启动成功!")
print("[成功] WLS 许可证验证通过。")
# 简单创建一个极小的模型确保求解器能跑
m = gp.Model("test")
x = m.addVar(name="x")
y = m.addVar(name="y")
m.setObjective(x + y, GRB.MAXIMIZE)
m.addConstr(x + y <= 1)
m.optimize()
print(f"\n[成功] 简单模型求解完成,目标值: {m.objVal}")
except gp.GurobiError as e:
print(f"\n[失败] Gurobi 报错 (错误码 {e.errno}): {e}")
print("常见原因:")
print("1. 无法连接互联网 (WLS 必须联网)")
print("2. gurobi.lic 文件路径不对或内容错误")
print("3. WLS License 已过期或达到并发上限")
except Exception as e:
print(f"\n[失败] 系统报错: {e}")
if __name__ == "__main__":
test_wls_connection()

Gurobi 学术版本的区别
Named-User Academic、WLS Academic 和 Take Gurobi With You 是 Gurobi 提供的不同类型的学术许可和服务,主要区别如下:
-
Named-User Academic
Named-User Academic 是一种学术用途的个人许可证,适用于学生或研究人员在学术环境中使用 Gurobi。这种许可证的有效期通常为一年,并且需要通过注册 Gurobi 账号来申请 。 -
WLS (Web License Service) Academic
WLS Academic 允许用户在任意环境中运行 Gurobi 优化器,包括多台机器 / 多个容器 / 云环境(可跨设备并发使用)与 Named-User 不同的是,WLS 更适合需要灵活部署和分布式计算的场景。它也属于学术用途的免费许可证 。使用期间必须保持互联网连接,使用时可在任意网络(包括离校)
- 必须联网: WLS 必须保持互联网连接才能工作。如果你在完全隔离的内网服务器,WLS 无法使用。
- License 文件内容: 确保你的
gurobi.lic文件内容格式正确,通常包含以下几行:LICENSEID=123456 WLSACCESSID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx WLSSECRET=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx - License 文件路径: Gurobi 默认在以下位置查找文件:
- Linux:
/opt/gurobi/gurobi.lic或用户主目录/home/user/gurobi.lic - Windows:
C:\gurobi\gurobi.lic或用户主目录 - 自定义路径: 如果文件在别处,必须设置环境变量
GRB_LICENSE_FILE指向该文件的绝对路径。
- Linux:
- Take Gurobi With You (TGWY)
Take Gurobi With You 是一项特别针对毕业生的计划。通过这个计划,毕业生可以在毕业后继续免费使用 Gurobi,而无需受限于学术用途 。这项服务旨在帮助新毕业生在职业生涯开始时继续使用他们熟悉的工具 。
代码运行
方式1:直接运行(测试)
source activate myenv3.10
nohup python /home/u3012339/3_PV/Code/Test/Test/TestGurobi.py > testGurobi.log 2>&1 &
方式2:Sbatch提交
dos2unix run_gurobi.sh
sbatch run_gurobi.sh
squeue -j 3271756
sacct -j 3271756 -o JobID,JobName,Elapsed,TotalCPU,AllocCPUs,State
seff 3271756
run_gurobi.sh 内容如下:
#!/bin/bash
#SBATCH --job-name=TestGurobi # 作业名称
#SBATCH --nodes=1 # 节点数量
#SBATCH --ntasks=1 # 总任务数
#SBATCH --cpus-per-task=8 # 每个任务需要的 CPU 核心数 (Gurobi 并行计算需要多核)
#SBATCH --mem=16G # 整个作业的总内存 (建议给 Gurobi 留足内存)
#SBATCH --time=48:00:00 # 运行时间限制 (HH:MM:SS)
#SBATCH --output=TestGurobi_%j.log # 标准输出日志 (%j 会替换为 Job ID,防止覆盖)
#SBATCH --error=TestGurobi_%j.err # 错误日志
# 1. 加载环境
# 确保 conda 能够被脚本识别。如果 source activate 不起作用,请尝试下面的 eval 块
source activate myenv3.10
# 2. 设置 Gurobi 许可证路径
export GRB_LICENSE_FILE=/home/u3012339/gurobi.lic
# 2. 进入工作目录 (非常重要,确保相对路径正确)
cd /home/u3012339/3_PV/Code/Test/Test/
# 3. 打印调试信息
echo "Job ID: $SLURM_JOB_ID"
echo "Job started on $(date)"
echo "Running on node: $(hostname)"
echo "Current directory: $(pwd)"
echo "Python path: $(which python)"
# 4. 运行 Python 脚本
# python /home/u3012339/3_PV/Code/Test/Test/TestGurobi.py
python -u TestGurobi.py 2>&1
echo "Job finished on $(date)"
错误总结
错误1:内存溢出(Out of Memory, OOM)
oom_kill 是 “Out of Memory Kill” 的缩写。
1/var/spool/slurm/d/job3271732/slurm_script: line 30: 3678
2 slurmstepd: error: Detected 1 oom_kill event in StepId=32
71732.batch. Some of the step tasks have been 0OM Killed.
常见原因:
- 模型太大: 变量(Variables)或约束(Constraints)的数量极其庞大,构建模型时就撑爆了内存。
- 求解难度高: 模型虽然初始不大,但在求解过程中,搜索树节点(Nodes)过多,导致内存耗尽。
- 申请资源不足: 在提交 Slurm 任务时(SBATCH脚本中),申请的内存(
--mem或--mem-per-cpu)太小,无法满足计算需求。
#SBATCH --mem=16G
# 或者
#SBATCH --mem=32G
参考
更多推荐



所有评论(0)