GPU/CPU remapping is available as a beta feature for handling tasks across multiple CPU and GPU resources and can lead to potential performance gains. The use of GPU/CPU remapping is particularly useful in optimizing computational tasks that are GPU-intensive, ensuring that GPUs are utilized as efficiently as possible, based on specific workload needs and system architecture.

Default remapping can be specified by adding either the -gpu_remap or -gpu_remap=1 command when launching the GPU solver from the command line as outlined in Starting the Fluent GPU Solver from the Command Line. For default remapping, all CPU partitions are merged evenly and the computational workload is distributed to all available GPUs across all machines in the network or cluster as shown in Figure 33.1: Default Remapping. This approach is aimed at maximizing the utilization of GPU resources across different hardware, enhancing overall computational efficiency.

Figure 33.1: Default Remapping

Alternatively, -gpu_remap=2 can be entered to change the default remapping behavior and assigns all CPU partitions to processes that exclusively utilize the GPUs within the same machine as shown in Figure 33.2: 2 to 1 Remapping. This approach could be beneficial in scenarios where minimizing data transfer between machines can lead to better performance due to reduced network overhead or latency.

Figure 33.2: 2 to 1 Remapping

User-defined scalar (UDS) transport equations are supported by the Fluent GPU Solver as a beta feature, with the following general limitations:

The Fluent GPU Solver supports the use of transient profiles to define boundary and cell zone conditions as a beta feature, with the following general limitations:

Cell zone condition Source Terms can be defined using transient profiles for energy and momentum with the following limitations:

The following limitations apply to setting up boundary conditions using transient profiles:

An optimized LES numerics scheme in available for the GPU solver. The optimized scheme typically allows for a reduction in the number of iterations used per time step (two iterations are often sufficient). In the case of continuity residuals not dropping for the second iteration, reducing the time step size provides better accuracy improvements over increasing the number of iterations per time step used, and eventually leads to better continuity residual behavior.

From the Viscous Model dialog box, when Large Eddy Simulation (LES) is selected, Optimized LES Numerics is available under LES Model Options.

Upon activation, the following TUI commands are enabled:

Notes:

The integral aeroacoustics model by Ffowcs Williams and Hawkings (FW-H) and its usage in Ansys Fluent are described in The Ffowcs Williams and Hawkings Model in the Fluent Theory Guide and Using the Ffowcs Williams and Hawkings Acoustics Model in the Fluent User's Guide. With Ansys Fluent 2024R1, you can use this model with the Fluent Native GPU solver.

This is done using the two step acoustics calculation workflow as follows:

This workflow is equivalent to the CPU solver, however the file format for the sound source data has the extension .asdg (instead of .asd for the CPU solver), and data from each mesh partition are exported to a separate file using a parallel output method. This is done to accelerate the output process and prevent a performance slowdown when using the fast GPU flow solver.

Because the file format is different, it is not possible to continue a CPU-written source data export in a FluentGPU session. If you load an existing FW-H setup, which was created using the Fluent CPU solver, to a Fluent GPU session, you will have to ensure that the index file does not contain lines with the .asd extension. The recommended workflow in this case is to revisit the FW-H model (using GUI or TUI) in the GPU session and click Apply in both the Acoustic Sources and Acoustic Model dialog boxes (or click through the corresponding text commands). This will re-create the index file and the model-specific solver settings. There is no need to revisit the receivers' specification.

The following limitations apply to the FW-H model in Fluent 2024R1:

When using the Fluent GPU Solver, the exporting of solution data as EnSight DVS files has beta support. Note the following differences when exporting such files when the data was calculated by the GPU solver compared to that generated by the CPU-based solver (as described in EnSight DVS in the Fluent User's Guide):

To export solution data after a steady or transient calculation by the Fluent GPU Solver, perform one of the following:

To export solution data during a transient calculation by the Fluent GPU Solver, perform one of the following prior to running the calculation:

The Fluent GPU Solver typically utilizes both GPU and CPU resources. The ability to restart the calculation in such a way as to minimize the needed CPU resources is supported as a beta feature. To do such a restart, perform the following steps:

When using the Fluent GPU Solver, the discrete phase model (DPM) is supported as a beta feature with the following capabilities and limitations:

The following DPM model injections can be used with the GPU solver:

When the transient flow solver is used, particles will be injected at each flow timestep if the flow time is between the specified Start Time and Stop Time for the injection. Note that DPM parcels are created using the CPU-based Fluent solver, which are then uploaded to the GPU solver. Therefore, DPM parcels cannot be recomputed each time the particle solver is executed. Surface injections with the Randomize Starting Points option enabled will provide random initial positions but the starting positions will not change every time DPM parcels are injected.

When integrating the particle trajectory, physics is limited to drag and gravity/buoyancy for spherical particles. If gravity is enabled for the flow solver, gravity/buoyancy is automatically included in the calculations for the particle trajectory. If temperature is being solved in the continuous phase, then the particle temperature will also be solved. Convective heat transfer to and from the particles will be modeled using the Ranz-Marshal heat transfer coefficient. Evaporation and boiling can be modeled with the Convection/Diffusion-Controlled model for particles of type Droplet. Note that Pressure Dependent Boiling, Temperature Dependent Latent Heat, and Variable Lewis Number options are all enabled when using the GPU solver. To account for turbulent fluctuations, the Discrete Random Walk model with the Random Eddy Lifetime option is available. This model can only be enabled if turbulence modeling is enabled for the flow solver.

One-way particle-flow coupling is available in which the particle phase does not influence the continuous phase. Two-way particle-flow coupling can also be enabled by selecting the Interaction with Continuous Phase option in the Discrete Phase Model dialog box. Note that two-way coupling with mass transfer is not supported with the GPU Solver. When using two-way coupling, the Linearize Source Terms and Update DPM Sources Every Flow Iteration options are also available. Particle sub-cycling, in which particles are tracked multiple times within a single flow solver timestep, can also be used. This functionality is controlled by the DPM Iteration Interval entry in the Discrete Phase Model dialog box. For details on these settings, see Steady/Transient Treatment of Particles.

The SSD Breakup model is available when using the GPU Solver. This model can be enabled on the Discrete Phase Model panel and applies to all injections of type Inert or Droplet. Note that new child droplets are not spawned when using the GPU solver. Instead, breakup events lead to a decrease in the droplet diameter and a corresponding increase in the number-in-parcel to conserve parcel mass. The following SSD model parameters are hardcoded to the default values in Fluent:

When using the Fluent GPU solver, the particle numerical methods cannot be modified. The trapezoidal Euler method will be used to calculate the particle position, while the implicit Euler method is used for particle velocity, temperature, and mass. Additionally, the accuracy control option available with the CPU-based Fluent solver is unavailable with the GPU solver. The particle integration timestep will be calculated from the Step Length Factor set in the Discrete Phase Model dialog box.

When defining boundary conditions for the Discrete Phase Model with the GPU solver, the Escape, Trap, and Reflect boundaries can be used. For wall zones, the default boundary condition is Reflect while boundaries associated with flow inlets and outlets will be Escape by default. It is also possible to sample particles at mesh face zones similar to when solving on the CPU-based fluent solver. However, sampling on postprocessing surfaces is not supported.

When using the Fluent GPU solver, the Graphical User Interface (GUI) will be restricted to DPM features that are supported. However, the Text User Interface (TUI) will not have such restrictions. As such, it is recommended that the GUI be used when setting up the DPM model to ensure that invalid options are not enabled.

Note that when using the Fluent GPU solver, the DPM model is restricted to stationary meshes. Additionally, non-conformal interfaces are not supported. Zero-thickness walls (for example, baffles) should not be combined with the DPM model when using the Fluent GPU solver as the results will be inaccurate in the vicinity of the wall.

The Fluent Native GPU solver supports the use of user-defined functions (UDFs) written in Python as a beta feature, so that you can take advantage of the massively parallel computations. Your UDF code will largely retain the simplicity of the Python programming language, so that you can focus on the physical model. Internally, your Python code is transformed into machine code for use by the Native GPU Solver.

The following capabilities are supported:

To use Python UDFs with the Fluent Native GPU solver, perform the following steps:

A key difference from the UDFs written in C is that the Python UDF code does not need to loop over a cell or face thread, meaning macros like begin_c_loop are not used. Instead, the body of a UDF function is applied to all faces of a face zone (or all cells of a cell zone) in a massively parallel manner. This reflects the fundamental difference of their serial vs. parallel execution model.

Python UDFs are limited to a predefined set of variables as their arguments, which are listed in Table 33.1: Supported Variables. The variables have the same naming convention as those for C UDFs, but are in lowercase in keeping with the Python programming convention. More information about these variables may be found in the sections about creating and using user-defined functions in the Fluent Customization Manual.

When you hook a UDF, you apply a function to a certain face or cell zone. This is commonly done using dedicated function calls. For example, the following demonstrates how to hook up the UDF in the Python code, and applies function_pointer to all_cell_zones:

UDF.add_cell_zone_energy_source(function_pointer, UDF.all_cell_zones())

In this case, add_cell_zone_energy_source is a hookup function (for a list of supported hookup functions, see Table 33.2: Supported Hookup Functions); and all_cell_zones is a zone selection function (for a list of supported zone selection functions, see Table 33.3: Supported Zone Selection Functions).

The Python UDF predefines a Real type, which should be used for all floating point numerical values. The Real type automatically maps to 32- or 64-bit floating point numbers depending on whether Fluent is executed in single or double-precision mode, respectively, to ensure consistency. A common mistake, for example, is to use 2.0 or 2 when you should use Real(2.0).

The names of UDF functions (that is, the function pointers that you define in your Python UDF and reference in your hookup functions) must start with udf_; for example, udf_velocity_profile. The prefix udf_ is used to identify and further process the UDF functions.

A device function is a Python function whose name starts with device_. They are used to create small, reusable utilities that can be called by UDF functions. Like UDF functions, the prefix device_ is used to identify and process those functions, and it is important to follow this naming convention. For further details, see Device Functions.

def device_dot_product(a:Real3, b:Real3):
    return a[0]*b[0] + a[1]*b[1] + a[2]*b[2]

 

33.1.9.2. User-Defined Memory

You can define a certain number of user-defined memory allocations (UDMs) in Fluent and use them in a Python UDF. UDMs are intended for postprocessing uses only: a UDM is filled with certain values during the GPU computation and then visualized later in Fluent like other field variables. The function that follows hooks a UDM at index udm_index with function fn, which writes to that UDM. Here, fn is a regular UDF function (the name starts with udf_), and udm_index is the UDM’s index that starts from 0.

UDF.add_cell_zone_udm(fn, udm_index)

---

Note:

• The UDM is defined and calculated for all cell zones; there is no “per cell zone” UDM.

• You must ensure that there are a sufficient number of UDMs for indexing. Otherwise, an error message is printed and the Python UDF will fail to load. For example, if a Python UDF accesses a UDM up to index 1, at least two UDMs should be defined in Fluent (see Figure 33.4: User-Defined Memory Dialog Box).

---

Figure 33.4: User-Defined Memory Dialog Box

An example that uses UDMs is given below. It fills the 0^th UDM using a function that evaluates spatially varying values, and the 1^st UDM using a function that calculates velocity magnitude from the velocity components.

def udf_fill_udm0(c_centroid):
    x,y,z = c_centroid
    if y < 0.005:
        if x > 0.005:
            mag = 1.0
        else:
            mag = 2.0
    return Real(mag)

def udf_calc_vel_mag(c_u, c_v, c_w):
    # write velocity magnitude for postprocessing
    return math.sqrt(Real(c_u*c_u + c_v*c_v + c_w*c_w))

UDF.add_cell_zone_udm(udf_fill_udm0, 0)
UDF.add_cell_zone_udm(udf_calc_vel_mag, 1)

 

33.1.9.3. Global Reduction

You can define a global reduction, as shown in the following example:

MAXT = UDF.reduce('max', c_t, [1])

This defines a variable MAXT (a single floating-point value) that can be used elsewhere by the Python code. Here, UDF.reduce is a predefined function from the UDF module, and its arguments are:

• 'max'

  This is a string indicating the global reduction operation. The supported operations are 'min', 'max', 'avg', and 'sum'.

• c_t

  This is one of the predefined fields. For others, see Table 33.1: Supported Variables.

• [1]

  This is a list of zone IDs to which the reduction applies.

After it is defined, this variable can be used in other UDF functions. Note that if a function uses MAXT, that function must explicitly lists MAXT as one of the function parameters; you cannot use MAXT as a Python global variable.

Example

The following provides a detailed example that demonstrates the usage of global reduction. The case is a pseudo-2D channel with a square shaped obstacle in the middle. It has the following conditions:

• The inlet (the left domain boundary, indicated using blue arrows, with a face zone ID equal to 6) has a cold fluid (T = 300K) that enters the domain at a uniform velocity profile of 0.5 m/s.

• The cylinder (the hollow square in the domain with a face zone ID equal to 7) is heating up with time following a linear rule: T=300+100t [K].

• An operation protocol is imposed, such that after the temperature in the fluid cell zone (with cell zone ID equal to 1) exceeds 305 K, the inlet velocity is doubled to 1.0 m/s.

Figure 33.5: A Demonstration Case of the Reduction Functionality

The three conditions are implemented in the Python UDF that follows. The code uses three zone IDs and imposes two transient boundary conditions, one of which involves global reduction, yet it has only 10 lines of code.

MAXT = UDF.reduce('max', c_t, [1])

def udf_cylinder_temperature(flow_time):
    return min(Real(310.0), Real(300.0 + 100.0 * flow_time))

def udf_velocity_profile(f_centroid, MAXT):
    if MAXT > Real(305.0):
        return (Real(1.0), Real(0), Real(0))
    else:
        return (Real(0.5), Real(0), Real(0))

UDF.add(udf_velocity_profile, 'boundary-condition', 'momentum', 'velocity', UDF.velocity_inlet_face_zones()) 
UDF.add(udf_cylinder_temperature, 'boundary-condition', 'energy', 'temperature', UDF.wall_face_zones())

Note that the cylinder temperature increases from T = 300 to 305 in 0.05 seconds. Because the thermal boundary layer takes some time to develop, the cell next to the hot cylinder reaches T = 305 after a short delay, then the inlet velocity increases from 0.5 m/s to 1.0 m/s. The time series of the maximum inlet velocity confirms this behavior (Figure 33.6: Time Series of the Maximum Inlet Velocity).

Figure 33.6: Time Series of the Maximum Inlet Velocity

Notice that the maximum inlet velocity magnitude doubles after the maximum cell zone temperature exceeds a threshold specified in the Python UDF.

def udf_myconstant():
    return Real(0.5)

def udf_velocity_profile(f_centroid):
    return Real(0.5) + udf_myconstant() - pow(f_centroid[1]/Real(5), Real(2)), Real(0), Real(0)

# apply the velocity profile to zone 6
UDF.add_boundary_condition_velocity(udf_velocity_profile, [6])

def udf_visc(c_u_g, c_v_g, c_w_g):​
    dxx = c_u_g[0]​
    dyy = c_v_g[1]​
    dzz = c_w_g[2]​
    dxy = Real(0.5) * (c_u_g[1] + c_v_g[0])​
    dxz = Real(0.5) * (c_u_g[2] + c_w_g[0])​
    dyz = Real(0.5) * (c_v_g[2] + c_w_g[1])​
    strain_rate = math.sqrt(Real(2) * (dxx*dxx + dyy*dyy + dzz*dzz + Real(2)*(dxy*dxy + dxz*dxz + dyz*dyz)))​

    # Calculate viscosity​
    Eta0 = Real(0.1604)​
    Etainf = Real( 0.0674)​
    lam = Real(1.46e-3)​
    n0 = Real(0.5996)​
    one = Real(1)​
    two = Real(2)​
    return Etainf+(Eta0-Etainf) * pow(one + pow(lam*strain_rate, two),  (n0-one)/two)​

# add laminar viscosity UDF for all cell zones​
UDF.add_laminar_viscosity(udf_visc, UDF.all_cell_zones())​

def udf_heat_source(flow_time, c_centroid):
    x = c_centroid[0] + Real(0.02)
    y = c_centroid[1]
    radius = Real(0.003)
    mag = Real(0.0)
    omega = Real(2.0 * math.pi)

    if x*x + y*y < radius*radius:
        mag = Real(600.0) * math.sin(omega*flow_time)

    return mag

UDF.add_cell_zone_energy_source(udf_heat_source, [2])

def udf_visc(c_t):
    if c_t > Real(288.0):
        return Real(5.5e-3)
    elif c_t > Real(286.0):
        return Real(143.2135) - Real(0.49725)*c_t
    else:
        return Real(1.0)

UDF.add_laminar_viscosity(udf_visc, [1])

number_of_waves_per_yz = Real(3.0)

kx = Real(number_of_waves_per_yz*math.pi)
ky =-kx
kz = kx
ux = Real(2.0)/math.sqrt(Real(6.0))
uy = Real(0.5)*ux
uz = Real(0.5)*ux

Uin   = Real(30.0)
omega = kx * Uin

def udf_velocity_profile(flow_time, f_centroid):
    x, y, z = f_centroid[0], f_centroid[1], f_centroid[2]
    factor = math.cos(kx*x + ky*y + kz*z - omega*flow_time)
    u_prof = Uin + ux*factor
    v_prof =       uy*factor
    w_prof =       uz*factor
    return Real(u_prof), Real(v_prof), Real(w_prof)

UDF.add_boundary_condition_velocity(udf_velocity_profile, [5])

def udf_swirling_force(c_centroid):​
    x, y, z = c_centroid​
    radius = math.sqrt(x*x + y*y)​
    if radius < Real(0.001):​
        return Real(0.0), Real(0.0), Real(0.0)​
    return Real(-y/radius), Real(x/radius), Real(0.0)​

UDF.add(udf_swirling_force, 'cell-zone-source', 'momentum', 'velocity', [2])​

The recommended way to customize the Fluent GPU Solver is to use user-defined functions (UDFs) written in Python, as described in Python User-Defined Functions (UDFs). If you must use UDFs written in C, you should note that only the following DEFINE macros may potentially work with the Fluent GPU Solver, and you must verify that they are performing as intended on an individual basis.

When loading a C UDF in the Fluent GPU Solver, Fluent checks the list of functions in the UDF library and issues warnings in the console if DEFINE macros are detected that are not in the previous list.