abaqus子程序明明关联成功了却用不了？多半是这个问题

屏幕右下角弹出 `LINK is not found in the system`，红色字，但 `abaqus verification` 里那一排全是绿色的 PASS。这个矛盾我遇到不止一次了，上周又碰上一回，折腾到凌晨两点。

事情是这样的，那天下午在调一个 UMAT，验证工具跑完 `abaqus verify -user_std` 之后命令行回显 `PASS`，我心想终于搞定了，兴冲冲提交作业，结果求解器直接报了 `Problem during linking`。当时办公室空调坏了，三十多度的天，隔壁工位的同事在啃薯片，嘎嘣嘎嘣的，我盯着那个弹窗看了大概有十分钟，心里想的是“明明验证过了啊”。先把结论放在这里，因为这坑我踩过好几次：**Abaqus CAE 和 Abaqus Command 走的启动脚本根本就不是同一个文件**。

去 Abaqus 安装目录的 `Commands` 文件夹下面翻，找到 `abq2021.bat`（版本号按你自己的来），用记事本打开。大概率你会发现里面什么编译器相关的调用都没有，就那么几行干巴巴的路径设置。再往上找 `abaqus.bat`，打开看，它做的事情很简单，就是把命令转发给 `abq2021.bat`。问题来了，之前按网上教程在 `launcher.bat` 里加的那两行调用语句，`call vcvarsall.bat x64` 和 `call ifortvars.bat intel64`，只存在于 launcher 文件里。验证工具为什么全绿，因为它走的就是 launcher.bat 这条路，VS 和 Fortran 的环境在这条路上确实被正确加载了。但你在命令行敲 `abaqus job=xxx user=xxx int` 的时候，调用链是 `abaqus -> abaqus.bat -> abq2021.bat`，中间那个引用编译器的环节被完整绕过去了。

所以最直接的办法就是把那两行调用语句原封不动写进 `abq2021.bat` 里面，保存，关掉命令行重开，再试。注意路径里如果有空格要用双引号包住，同事就是因为这个卡了半天，他的 VS 装在 `Program Files` 下面。

PATH 里多加几条路径一般不会有副作用，少加了才会出事。建议检查一下这几个位置有没有漏：`...\IntelSWTools\compilers_and_libraries_2020.x\windows\bin\intel64`、`...\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build`、还有 Abaqus 自己的 `Commands` 目录。加完之后在 cmd 里敲 `where link` 和 `where ifort`，两个命令都必须能返回有效路径，返回“信息: 用提供的模式无法找到文件”就是没配好。另外安装路径和 Windows 用户名里千万别有中文，我以前一个同事用户名是中文的，所有配置都对但就是不行，新建了一个英文用户才解决。

验证通过之后还是报错，有个快速定位的办法。到工作目录下找与 job 同名的 `.log` 文件，编译阶段的具体报错都在里面，哪个文件哪一行出了问题会写得比较清楚。如果在命令行跑 `abaqus verify -user_std`，日志在 `verify\user_std\` 文件夹下面，叫 `user_std.log`，打开搜 `error` 关键词就能看到实际失败在哪一步。这个习惯比对着弹窗猜要省时间得多。

还有一个容易忽略的，子程序代码本身的问题。编译能过链接也能过，但求解器启动后马上崩或者算出来的结果完全不对，这种时候先检查 UMAT 的接口参数有没有写错。Abaqus 不同版本的子程序参数列表有时候会变，用旧版本的模板直接套新版本就可能对不上，哪怕只是一个参数顺序的差异，编译链接都不会报错但运行阶段会出问题。

如果你想看子程序到底有没有被调用、传进去的变量值对不对，在 VS 里调试是效率最高的方式。找到 `win86_64.env` 或 `abaqus_v6.env`，把里面 `compile_fortran`、`link_sl`、`link_exe` 三个参数前面的注释符号去掉，然后在 CAE 里提交任务，等进程列表里出现 `standard.exe` 的时候，回到 VS 菜单栏选“调试”再选“附加到进程”，找到那个 `standard.exe` 附加上去，你在代码里设的断点就能停了。第一次搞可能要花十几分钟摸清楚流程，但后面再排查逻辑错误就是几分钟的事，跟反复提交作业然后去翻 log 文件相比完全是两个效率。

免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删