Overview
Just as the Fluent program itself offers two session types, meshing versus solving, the Fluent connector plugin splits up into two process integration nodes Fluent-Mesher and Fluent-Solver. With the Fluent-Solver node you can parametrize and evaluate Fluent projects of two types: case type projects (.cas.h5, .cas.gz, .cas) and parametric study type projects (.flprj). When working on case files, the node is able to receive updated mesh files per input slot.
CFD models are usually representing a heavy part in a simulation workflow. That's why solving remotely with the help of HPC infrastructure is an important use case. The Fluent connector plugin goes a few crucial steps towards conveniently putting advanced remote submission power at every user's fingertips, although it has to be said, that the currently implemented bits may only cover some parts of the gaps which have to be bridged between a locally running optiSLang session and a remote HPC cluster infrastructure. What both Fluent connector nodes are offering today is an alternative work mode, whereby the node does not itself call a Fluent worker subprocess but just puts in place a Python script prescribing the work steps to be done in a subsequent Fluent worker process. We may call this second run mode the remote script preparation run mode, or short, script prepping mode. Part of this feature is that for configuration the Fluent plugin is able to pull up a version of the powerful and convenient Fluent launcher dialog.
Requirements
The Fluent-Mesher node of optiSLang 24.1.0 requires PyFluent version 0.13.1.
For the Fluent version itself there is no strict requirement.
If connected to VPN, set the environment variable REMOTING_SERVER_ADDRESS=localhost.
In consistency with the optiSLang standard, the mesh file path received by input slot (if in use) is expected to come as OPD-relative path.
Parameterization
The connector scans for input and output parameters defined in the case description tree under Parameters and Customization.
The image above shows the parameters section of the case view of an exemplary project. These definitions are taken up by the connector plugin, and after a successful scan it can generate detection listings for input and output objects as visible in the picture below.
The scan can happen quite fast due to a lightweight case reader module provided by PyFluent. Fluent projects of parametric study type (.flprj) are also inquired leveraging the case reader module. In the case of an FLPRJ file the parametrization page in optiSLang will mirror the columns of the design point table in Fluent.
Solver wizard support
The Fluent-Solver node is supported by optiSLang's new default solver wizard capability for Python-based plugins. This means that the solver can guide through multiple pages, and that the parametrization page features a useful reload button.
Settings
| Setting | Description | Possible Options |
|---|---|---|
| General options | ||
| Prepare (remote) script | Normally, this node conducts the meshing itself in a PyFluent session invoked as subprocess. In the alternative script preparation mode the node does not start Fluent, it merely puts in place (at runtime in each design directory) a ready-made Python script which can be taken up by a subsequent node in the chain. Deferring the work and adjusting a work script to be taken up by downstream nodes and processes can be a means of creating job submissions to a scheduling system in a cluster environment. | True, False |
| Configure Fluent launch command | This is an action button for invoking the Fluent Launcher dialog box. The dialog exposes many Fluent launch configuration options to users, dealing for example with CPU & GPU resource allocation per Fluent session or scheduler choices. In case the launch configuration dialog is closed with a confirm button, the Fluent connector will receive a fluent_command.txt file. Exploiting this file, it will put together a pair of raw shell scripts of types batch and bash. Building on the snippets in these files and adding further process or scripting nodes to the parametric system behind the Fluent connector node users can continue constructing a setup able to spawn remote HPC jobs. | - |
| Show GUI | Determines whether the PyFluent session will be invoked with or without graphical user interface (GUI). | True, False |
| Parallel processes | This is the setting for process_count forwarded to PyFluent when optiSLang invokes a new session by command. Fluent uses it for its MPI implementation of controlling multiple worker subprocesses. | 1, 2, ... |
| Fluent root path1 | Usually C:/Program Files/ANSYS Inc/v241/fluent or /ansys_inc/v241/fluent or using variable expansion %AWP_ROOT%/fluent | - |
| Native Fluent GPU Solver | For 3D models, Fluent offers GPU-powered solver routines. Executing parts of the CFD computation on a graphics processing unit (GPU) can greatly reduce the computation time. This option requires a Fluent Enterprise license. GPU routines are not available for 2D models. | True, False |
| Solver options | ||
| Solve via journal | You can compile a suite of commands for solving your type of
model in an extra journal script in case the default solve
commands don't work for you. The default commands implemented by
the node for case files are:
session.tui.solve.initialize.initialize_flow()
followed by iterate() or
dual_time_iterate() depending on whether the
simulation is steady-state or transient, respectively. The
default command for parametric studies is
update_selected_design_points(DP_list). | |
| Path to journal1,2 | Specify the path where the journal with the custom commands for solving the model can be found. | |
| Post-processing options | ||
| Post-process via journal | You can compile a suite of commands for postprocessing results of your simulation in an extra journal script. This scripting slot can be used to export images and videos of the simulation. | |
| Path to journal1,2 | Specify the path where the journal with the custom commands for postprocessing the simulation results can be found. | |
1Environment variable
expansion is supported in the following way: The path strings can
also contain variables which will be replaced at runtime. Only the two
placeholder formats %VARIABLENAME% and ${VARIABLENAME}
are supported. This routine is part of the Python layer of the plugin and does
not depend on the operating system. The set of available variables consists of
the usual optiSLang variables (like OSL_PROJECT_DIR,
OSL_DESIGN_DIR) merged with the currently present set of
environment variables. For example, if you have a journal
myrecipe.py placed in a folder
reference_files situated right beside the optiSLang
project file (OPF) and directory (OPD), then you can make your work folder with
reference files and the OPF containing the plugin node portable by specifying
the path in OPD-relative manner using either one of the two possible patterns:
${OSL_PROJECT_DIR}/../../reference_files/myrecipe.py
%OSL_PROJECT_DIR%/../../reference_files/myrecipe.py
2If the path starts with one or more dots, then it is interpreted as a relative path going out from the directory containing the reference file.
Additional or special slots
| Slot Name | Slot Type | Data Type | Description |
|---|---|---|---|
| IMeshFilePath | input |  | This slot for optional use can receive the path to a mesh file generated by an upstream component for this design. The slot can be used only for case files. When referencing and solving FLPRJ files, then the addition and evaluation of new design variations are all based on rows in the design point table and the slot for receiving a mesh per design is not usable. |
Please note that for paths transmitted at evaluation time by wire between actors in the optiSLang scenery the general standard is that all paths are OPD-relative.
Run Options
This node has general Run Options. The set of supported options can differ between node species.