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. The mesher node can create a mesh for a received geometry. The product of the mesher node is a mesh file per design directory. For passing the mesh file over to any downstream node who wants to use it, the mesher node offers on its right hand flyout an extra slot carrying the mesh file path. On its left hand flyout, it has a slot for receiving a geometry file path. While connecting the mesh output slot is optional, the mesher node can only work if the geometry input slot is connected. Typically, this node would be used in connection with a node for geometry parametrization and handling like the integration nodes for SpaceClaim and Discovery. The parametrization of the geometry is therefore outside the scope of the mesher node. The parameters of the meshing routine are so far not yet parametrizable by the connector node. This means that, at least for the time being, the input parametrization page will always be empty.
For its reference file, the Fluent-Mesher node can work with either a workflow template or a mesh file:
If a workflow template (.wft) is referenced, then the mesher node applies the workflow template instructions to the geometry file received on the geometry input slot to build a new mesh.
If a mesh file is referenced, it is expected that the mesh file contains extractable workflow info data to be applied to the received geometry.
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
Files for geometries, meshes, workflow templates, all have to be supported by Fluent's workflow template framework.
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.
For the node to be configured, is it required to load the Fluent program and the mesh file? The answer is no.
In consistency with the optiSLang standard, the geometry file path received by input slot is expected to come as OPD-relative path.
Base technology: the workflow template (WFT) framework
What the Fluent-Mesher node offers to optiSLang users is a connector to Fluent's workflow template technology. The setup and execution of workflow templates is an automization feature of Fluent enabling the automatic generation of a CFD-suitable mesh for design variations of a parametrized 2D or 3D geometry.
The Fluent-Mesher node can create a mesh by starting a Fluent subprocess and triggering it to rerun a workflow template.
The reference file can be a workflow template (.wft) file.
Alternatively, the reference file can be a mesh file (.msh, .msh.h5, .msh.gz) if it contains a workflow template which can be extracted and used.
By the input slot IGeometryFilePath the Fluent node expects to receive a geometry file.
If the reference file is a mesh file, then there must be an additional step of mesh file loading and WFT extraction.
In case of very large mesh files, loading on a terminal computer is not always desired.
Mesh file loading and WFT extraction are implemented to happen at evaluation time, not at configuration time.
Mesh file loading and WFT extraction happens at evaluation time at the beginning of a PyFluent-driven Fluent meshing session. It happens once per session.
Therefore it is clear that referencing a mesh file yields a setup of reduced efficiency. By referencing a WFT file, the node offers optimal efficiency.
Only by processing multi-design groups in every PyFluent-driven Fluent session, some fraction of the unnecessary drag of repeated WFT extraction can be avoided. Therefore, the setting Designs per execution under Advanced Options should always receive consideration
By choosing the option to invoke Fluent sessions with GUI, you become able to quickly verify the green check marks appearing during WFT execution. There are check marks for each step in the workflow template.
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, foe example, dealing with CPU and 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. | Default: 1 |
| Fluent root path1 | Path to the folder containing the Fluent installation.
Usually C:/Program Files/ANSYS
Inc/v241/fluent or
/ansys_inc/v241/fluent or using
variable expansion %AWP_ROOT%/fluent. | - |
| Meshing options | ||
| Mesh export format | With this set of radio buttons you can determine the compression method (and thus fily type) for the mesh files generated by the node. The choice is between h5 compression, gzip compression, and no compression. | *.msh.gz, *.msh.h5, *.msh |
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
Context: environment variable expansion allows portable configuration with relative paths definitions as a workaround for shortcomings inherent to Python-based plugins. Native built-in nodes can exhibit drop-down menus where needed in connection with file path entries and file browse buttons. The drop-down menu usually offers a choice between absolute and relative path modes. Unfortunately, GUI widgets of Python-based plugins are not yet offering equally powerful convenience options. While this is still the case, the implementation of the variable expansion routine can help creating conveniently portable optiSLang project setups.
Additional or special slots
| Slot Name | Slot Type | Data Type | Description |
|---|---|---|---|
| IGeometryFilePath | input |  | The slot expects to receive the path to this design's variation of the parametrized geometry, for example, Sensitivity/Design0099/ABC.scdoc |
| OMeshFilePath | output | | The slot offers the path to the mesh file generated by this design, for example, Sensitivity/Design0099/(input_file_name).msh. |
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.