use for active flow control in closed-loop fashion

[gewno45]

Hi,

This is a quite preliminary discussion / brainstorming.

I am wondering if this code could be used for active flow control in a closed-loop fashion. I would like to reproduce the results presented there, with the present CFD framework:

https://arxiv.org/pdf/1808.07664.pdf

For this, all what is needed is to define a closed-loop interaction, in this kind, i.e. state / action / reward:



I think defining this coupling in a transparent way is the only critical / challenging point to fix, the rest should be quite simple. There are also some implementations with sockets for communication available:

https://github.com/jerabaul29/Cylinder2 ... RLParallel

So maybe it would just be enough to have a module or similar inside saturne that gives access to the simulations through a socket interface, something similar to:

https://github.com/jerabaul29/Cylinder2 ... tServer.py

Anybody who may be interested in working on this as a 'virtual collaboration'? I can take care of the DRL part if somebody is interested in the implementation of the saturne interface part.

[Yvan Fournier]

Hello,

There is already an mechanism to control the code through sockets using the "control_file" mechanism (which can be extended with sockets, with a Python API, in bin/cs_control.py). Using "notebook variables" (which can be defined in the GUI or user functions), the controller can set and get notebook parameters.
Basically, the cs_control.py code generates a control_file containing the "connect" command (it must be run in the execution directory) and a port number (allocated automatically), and code_saturne connects to that socket, through which the same commands can be used as with a control_file, but values can also be read.

In version 6.1 and master, this has enabled using code_saturne in an FMI (https://fmi-standard.org/) environment, where the FMU is based on a C version of the controller, and communicates with the main code (server) using sockets.

So if your active control requires only a set of parameters (and not some 2D or 3D spatial field description such as is often required on couplings/co-simulation), the mechanism you will need is already there.

If this seems to work for you, do not hesitate to switch to the "usage" section of the forum if you need help using this. And if you have other "feasibility/approach type questions, we can stay on this thread for those.

Best regards,

Yvan