五十、UDF常见错误及报错信息

UDF错误主要分为两类：

第一类：UDF代码错误

这类错误非常常见，但是也非常容易解决，因为Build过程，控制台会提示有问题的代码行数。只要根据提示更改源代码即可。

第二类：UDF设置出错

这类错误原因非常多，基本特点就是Build能顺利通过，load也没问题。但是一计算或者初始化就有直接报错。

常见的原因：UDM未开启或数量不对；UDF中的thread、cell、face等数据结构使用不当。

正确的UDF总是千篇一律，但错误的UDF却各有各的错误。使用的多了会发现常见的错误基本就这么几个，要注意排查。

以下介绍几种常见的错误及对应的报错信息，以便大家进行UDF错误排查。

2.1 常见错误1：UDF代码存在问题

将UDF编译Build之后，先不要点击load，此时会出现如下图一堆乱码信息，我们需要从中找到有用的信息。如图出现了下图框出的部分

上图中有warning行，当出现了warning行，不必理会，UDF可以正常进行计算

.....\.....\src\original.c: warning C4819: ??????????????????

但是当出现了error行，则说明UDF代码出现了问题。下面的报错信息c(17)表明UDF的第17行代码出现了问题，可针对此行进行修改。

....\....\src\original.c (17): error C2065: ??ter??:???????????

注：

1. 有时候报错信息会很多，很多行都有问题。但是可能只修改一行代码，错误完全消失。比如忘记声明变量i，但是下面很多行都使用到了此变量，报错信息就会很多。只要声明了这个变量，错误信息都会消失。

2. 常见的代码错误：

2.2 常见错误2：环境变量配置失败

UDF代码没问题的情况下，build也没有报错信息。但是点击load，会弹出下图窗口，说明环境变量配置不成功，需要重新配置环境变量。

The UDF library you are trying to load (libudf) is not compiled forparallel use on the current platform (win64).

注：

1. 下图表示的是UDF没有编译成功。如果UDF代码有误，build后出现报错信息，没有修改UDF直接点击load，也会弹出下面的窗口。

2. 一般环境变量配置不成功的话，点击build会很快编译完成，说明没有编译成功；而环境变量配置成功，点击build，编译过程会有一段时间，说明正在进行编译。

3) 常见错误3：UDF命名出错

UDF命名是有要求的，不能出现中文字符这一点大家都知道。

同时UDF的文件名中不能出现空格，这一点很容易被大家忽视。只要文件名中包含空格或者全角符号，那点击build之后，就会出现下面的报错信息。

此时报错信息不会出现多少行代码（类似c(17)）出现问题，因此难以排查。报错信息的最后一个\后就是UDF的文件名，表示UDF 命名有问题。

2.4 常见错误4：UDM未开启或数量不够

当UDF中使用用户自定义变量UDM时，必须开启UDM，并且设置足够多的数量，否则UDF会出错。

这种情况下UDF编译build通过，load也没问题。

但是只要一点击Calculate就立马报错。这时会出现下图的报错信息，Received signal SIGSEGV

SIGSEGV：SIG是信号名的通用前缀， SEGV是segmentation violation存储器区段错误。这里就是指UDF中的UDM没有分配内存导致的错误。

只需要打开UDM，或者把UDM的数量调多就行，多了可以，但少了不行。

2.5 常见错误5：UDF数据结构错误

UDF自定义内部的数据结构有很多，我们经常用到的主要是三个：线程Thread、网格cell和面face。如果在UDF对这些数据结构错误的使用，那么UDF编译能正常通过，load也没问题，但一点计算就会报错。

比如thread1线程只进行了声明，但并没有从fluent获取。如果直接使用thread1，则编译通过，load通过，但点击计算，可能会报下图错误：Received signal SIGSEGV

这种问题，报错的信息可能有很多种。但是基本都有一个特点，那就是编译没问题、load没问题，但一点击计算又出错。

2.6 常见错误6：UDF被其他cas占用

UDF编译的过程：选择UDF后，点击build，会生成一个libudf文件夹。点击load后，fluent会直接调用libudf文件夹下的已经编译好的文件。

此时源UDF文件与fluent没有任何关系，即使删除掉源UDF文件，fluent也可以正常运行。但是不能删掉libudf文件，这个文件会一直被fluent占用。

注：libudf是编译过程生成的文件夹名称，可在点击build之前，在Library Name处更改此名。

正是由于上面的原因，又会引出一个UDF常见的问题。正常情况下，udf会被一个cas所使用，但如果两个cas想同时使用一个udf，在cas1已经使用此UDF进行计算的情况下，cas2如果仍然选择这个UDF，点击build之后，可能出现如下图的报错：

错误的原因：cas1已经生成了libudf，并且已经将这个libudf加载进fluent中了，也就是说libudf已经被cas1占用了。此时cas2想再生成libudf，应该要覆盖掉之前的libudf文件夹，但由于libudf被占用，因此无法覆盖，也就无法生成。

也就是说，这种错误和udf无关，同一个文件夹下两个完全不同的udf被两个cas调用，如果这两个cas编译udf时生成的文件夹名称相同，仍然会报上图的错误。

解决办法：解决办法很简单，两个cas的Library Name取不同的名称即可消除此错误。

2.7 常见错误7：libudf未正常更新

这种错误偶尔才会出现。

正常情况下，当UDF更改之后，需要重新对其编译，如果不编译，那还是使用原来的UDF进行计算。

但是在有些情况下，重新编译UDF可能会不成功，但是控制台不会出现进行报错信息，计算也能够正常进行。

怎么知道UDF是否正常更新呢？一方面如果计算残差和原来一模一样，没有突变，那可能就有问题。

另一方面，查看libudf文件夹下的src文件夹，里面是fluent真正加载的UDF文件，打开这个文件，看看是否和新的UDF是否相同。

什么样的信息说明build没有问题？？

首先build加载时间比较长，其次文本控制台没有任何error的信息。可能会出现很多？？？或者乱码，只要没有error就行。比如下图，尽管出现乱码，但是没有error，说明编译正常。

在windows平台下，UDF编译之后控制台信息是乱码的。可通过对电脑进行设置，使其正常显示。

打开控制面板

点进去时钟和区域--管理---更改系统区域设置

勾选Beta版，点击确定，然后重启电脑，此时fluent编译UDF就不会出现乱码了。但是UDF的一些中文注释，可能会变成乱码。