precice/fluent-adapter

preCICE-adapter for the CFD code ANSYS Fluent (currently unmaintained)

preCICE

Project Status

Project Quality

Community

preCICE stands for Precise Code Interaction Coupling Environment. Its main component is a library that can be used by simulation programs to be coupled together in a partitioned way, enabling multi-physics simulations, such as fluid-structure interaction.

If you are new to preCICE, please have a look at our documentation and at precice.org. You may also prefer to get and install a binary package for the latest release (main branch).

preCICE is an academic project, developed at the Technical University of Munich and at the University of Stuttgart. If you use preCICE, please cite us.

fluent-adapter's Issues

Add documentation on 2D lid-driven cavity with flexible bottom example

Information in #26 (comment)

Allow remeshing

Currently, preCICE does not support remeshing: coupling meshes have to stay the same from the beginning of the simulation to the end. However, in the Fluent adapter there are still some relicts of the previously supported remeshing functionality. As soon as remeshing is supported in preCICE (again), we could also try to revive these parts of the adapter.

However, as a first step we should completely ignore the remeshing functionality and first get the adapter running (#1). As soon as the adapter is running, we can try to add the remeshing functionality again.

Functions related to remeshing

• regather_write_positions
• regather_read_positions

Fluent UDF variable names should be consistent with preCICE API names

The boolean variables defined by the scheme file init-fsi.scm which are modified in the source files have names like udf/convergence, udf/iterate. These names should be more consistent with the main preCICE API to provide a better understanding of the adapter workflow.
Possible changes are:
udf/convergence --> udf/isConvergenceAchieved
udf/iterate --> udf/isImplicitIterationComplete
udf/ongoing --> udf/isCouplingOngoing
These variables are critical as they act as boolean signals between preCICE and FLUENT.

Improve Adapter Installation

Tell Fluent to use PRECICE_ROOT (Solved!)

Currently, we have to manually copy libprecice.so into libudf/lnamd64. The better approach would be to provide PRECICE_ROOT/build/last to Fluent, such that Fluent can find libprecice.so on its own.

Don't use symbolic links to src files

Symbolic links that are created during compilation of the adapter cannot be used by Fluent.

Our work-around here is to just copy-paste all src files from adapter/src into fluent-case/. However, this is not optimal. Can we somehow set an include path for Fluent, or similar?

Don't copy language bindings (Solved!)

see #1 (comment)

Provide alternative to distributing ANSYS Makefiles for compiling the adapter

Currently the adapter files include multiple ANSYS makefiles which are used to compile the adapter. These makefiles are copyrighted and cannot be distributed with the open-source adapter package. An alternative strategy to compile the adapter needs to be devised.

• Currently the most feasible idea is to provide documentation to guide the user on how to convert a FLUENT makefile for use to compile the adapter

memory leaks of fluent_21_2_0 version

When I ran the case_2D that comes with the fluent_21_2_0 version of the adapter, I found the memory leaks，as follow:
https://precice.discourse.group/t/fluent-adapter-questions-regarding-initialization/1630/7

libprecice.so needs to point to latest libstdc++.so file in the system rather than the file shipped with FLUENT

FLUENT installation ships with: ansys_inc/v195/fluent/fluent19.5.0/lnamd64/syslib/libstdc++.so.6 which is picked as the default libstdc++.so when FLUENT runs with preCICE. For many FLUENT versions this is often outdated and the requirements of libprecice.so are higher. This leads to:

Error at host: ~/ansys_inc/v195/fluent/fluent19.5.0/lnamd64/syslib/libstdc++.so.6: 
version `GLIBCXX_3.4.26' not found (required by /usr/local/lib/libprecice.so.2)

This can be resolved by ensuring that the latest libstdc++.so on the system is used

Missing license

It seems like this project is currently missing a LICENSE file. I understand that choosing a license can be complicated for an adapter that depends on a proprietary code, but it is important to settle this as long as there is still communication among all authors.

Maybe LGPLv3 or MIT would still be ok.

precice v2.3.0 incompatible with Fluent 21.2.0 due to Boost library

During debugging of a preCICE communication error (specifically a call to Boost that appends filepaths together leading to a segFault at conInfo.read()), it was found that Fluent 21.2.0 employs Boost v1.63.0. preCICE v2.3.0 needs at least Boost v1.65.1, so these are incompatible and is what causes the segFault. In practice, I had compiled preCICE on my own and was using Boost v1.73, but this doesn't change the fact that the Boost versions are incompatible.

This essentially prevents a Fluent adaptor from existing for any version of preCICE except for those compatible with Boost v1.63.0. I believe a quick look-up by developers showed that this is around preCICE v1.4.

The only real solution is to see if we can get Fluent to reference a more recent version of Boost. We know it is possible for Fluent to employ local versions of MPI (using environment variables), so maybe changing Boost versions is a similar option.

I will reach out to Fluent and to see how hard they laugh when I ask about this. I'll report back here.

Separate data writing and advancing coupling operations

Current the function fsi_write_and_advance has two core functionalities from the typical coupling time loop: (1) writing data to preCICE and (2) advancing preCICE.
For clarity it is favourable to separate these two functionalities into separate functions" write_data() and advance().

Update fluent adapter for compatibility with preCICE versions >= 2.0.0

The current version (https://github.com/precice/fluent-adapter/commits/master) of this adapter is heavily outdated and does not work with recent preCICE versions. This issue should provide an overview over the progress of this task.

API calls that have to be updated

• precicec_getReadNodesSize
• precicec_mapReadData
• precicec_getReadPositions

Possible Refactoring

• rename all_indices to vertexIDs
• Resolved in update_fluent191
• remove commented out code
• split up fsi.c? Is this allowed for ufs? Currently there is a lot of functionality in one single file.

Documentation of fsi.c

• fsi_init
• fsi_write_and_advance
• fsi_grid_motion
• fsi_plot_coords
• count_dynamic_threads
• gather_write_positions
• gather_read_positions
• read_displacements
• write_forces
• check_write_positions
• check_read_positions
• regather_read_positions #4
• regather_write_positions #4

Documentation of fsi_udf.c

• DEFINE_INIT
• DEFINE_ON_DEMAND
• DEFINE_GRID_MOTION
• All resolved in update_fluent191

Remove files

• Constants.h and SolverInterfaceC.h from repo as they are part of precice src/
• Reference here. Resolved in update_fluent191

Use markActionFulfilled

See precice/precice#631

On Implicit Coupling in Fluent Adapters

I am currently developing an adapter for fluent, and have successfully completed some flow field and flow field coupling examples and a Fluid–structure interaction example. Currently, it is possible to transfer data effectively, but I am currently facing a problem. As I am not very familiar with the implementation of CFD, I am not sure which physical field information needs to be reset to achieve implicit coupling in the flow field? I roughly understand that there are at least velocity and pressure fields, but I am not very familiar with other physical fields. For example, when opening the energy equation, do we still need to add temperature and density fields?

If possible, could you please let me know which physical quantities of the fields I should recover in the implicit iteration.

Install Fluent on Ubuntu 16.04/18.04?

Officially, only the Linux distributions CentOS and Red Hat Linux are supported. However, for development it would be convenient to be able to use Fluent on Ubuntu 16.04/18.04.

In this issue we want to answer the following questions:

• Is it possible to install Fluent 19.01 on Ubuntu 16.04?
• If yes, how? See #3 (comment)
• Is it possible to install Fluent 19.01 on Ubuntu 18.04? no
• If yes, how? no
• Is it possible to install Fluent 19.02 on Ubuntu 18.04? postponed for now, but should be working due to this post on CFD Online. ANSYS Fluent R3 19.05 works successfully on Ubuntu 18.04

In the end we should verify our installation by running a small test case. For example the lid driven cavity.

Use isTimeWindowComplete

See precice/precice#619

Use a configuration file to configure the adapter

The adapter requires some names in the precice-config.xml to agree with hard-coded names in this adapter. The user may customize these names, but this requires recompiling the adapter, so this is not user-friendly.

A common solution for other preCICE adapter is to provide a configuration file to the adapter at runtime. From the preCICE perspective we decided at some point in time to try to stick to what is a common file format in the "world" of the adapter solver to make this easy to configure for users. This usually also avoids additional dependencies for building the adapter. (compare OpenFOAM adapter using an OpenFOAM dictionary, FEniCS adapter using a json)

So the main question here is which kind of formats would feel natural for a Fluent user?

Some options that we (@mtree22, @IshaanDesai, @MakisH, @fsimonis) already discussed:

• scheme files
• xml
• yaml
• more suggestions are welcome.

Tutorial: Fluent + X

Here is a list of possible ideas:

Lid Driven Cavity with flexible bottom

One possible approach for modelling this would be a simple Bernoulli Beam for the bottom (inhouse python?) + Lid Driven Cavity computed in Fluent.

See this report, section 2.4.2 for details.

Rigid Body in Flow (or similar)

Positive side effect: We can use structure0815 and resolve issue precice/precice#79 at the same time

Automize Fluent GUI interactions as far as possible

Examples, where reducing GUI interaction for setting up the UDF would be nice

• setting up hooks
• setting user defined memory