[MsRuby]

Dearest,

I have a problem with compiling a UDF into Fluent.
This is the warning message:

WARNING: Automatically switched to run in parallel -t1 mode. **
** Detected non-parallelized UDF usage, enabling parallel usage. **
** If you encounter any issues, please re-run with -t0 flag.

=> Question 1: How can I re-run with -t0 flag? I have searched the TUI command but still didn't find any solution.

Error: The UDF library you are trying to load (libudf) is not compiled for parallel use on the current platform (win64).\n\nThe system cannot find the file specified.
\n\nI:\14. UDF\Testing_1\libudf\win64\2ddp_host\libudf.dll

=> Question 2: I have found on the internet that someone also encountered this problem and there are some solutions. I am going to try, but is this parallel issue related to the warning message above?

Thanks,

[`e`]

What is the UDF you are running? Perhaps you could parallelise this UDF (if it's not already).

That error on loading the UDF library means that the UDF has not been properly compiled, try my compiling process for Fluent UDFs with an existing library loaded to check the the UDF is being compiled correctly and no errors are shown at compile time.

[MsRuby]

Thank u for your reply 'e'
My case is "serial", but when I compiled the UDF file, it is automatically changed to parallel. Then error appeared ... That is why I don't understand where is the problem.
My udf is just simple case DEFINE_PROPERTY with an input of porosity. It works fine with interpretation.

[`e`]

Are you running Fluent in serial or parallel mode? What is it automatically changing? Do you receive any errors if you remove the UDFs and/or simplify them (for example, set DEFINE_PROPERTY to a constant value)?

Considering that it works fine with interpreting the UDF, have you compiled any other UDFs before? Do you have a compiler such as Microsoft Visual Studio installed?

[MsRuby]

Originally Posted by `e`

Are you running Fluent in serial or parallel mode? What is it automatically changing? Do you receive any errors if you remove the UDFs and/or simplify them (for example, set DEFINE_PROPERTY to a constant value)?

Considering that it works fine with interpreting the UDF, have you compiled any other UDFs before? Do you have a compiler such as Microsoft Visual Studio installed?

=>I am running Fluent in serial mode, and when I compiled my UDF, the warning appears. Yes, the error stays even if I simplify the UDF. I have never compiled any UDF before. And yes, I have Microsoft Visual Studio installed

[`e`]

First of all, it looks like this type of warning has been found in the latest releases of Fluent, from R18.2 (for an explanation, see: How to use FLUENT only in single processing mode). I have now tried running Fluent R18.2 with a UDF in serial and get the same warning but the UDF still works fine. The warning does not appear when running Fluent R18.2 in parallel mode and the UDF still works as expected (each processor including the host prints to the console). The UDF I compiled was:

#include "udf.h"

DEFINE_ON_DEMAND(test)
{
	Message("%d: Hello\n",myid);
}

Perhaps the warning is a bug, and is only a false positive?

[obscureed]

Hi,
I have seen the same warning, with a similarly innocuous UDF, in Fluent 19.1. I think there was a change at 18.2, where even serial Fluent is run in the parallel framework, but with a single parallel process. Whatever the warning is intended to guard against, I think it can be ignored.

I expect that -t0 is an option that could be added when starting Fluent from a command prompt. Maybe it forces a truly serial-mode run. I haven't investigated, because it is easier to ignore the warning.

By the way, as general advice: if you have a UDF already compiled, you should recompile whenever you change Fluent (including any version change; parallel <--> serial; single-precision <--> double; 2D <--> 3D; operating system; etc). Often you will be prompted to recompile, or it will happen automatically, but if not you need to do it anyway. Delete the entire libudf directory if necessary. The point is that the compiled UDF for another version is not helpful.

Best regards,
Ed