ERROR when reading "Velocity" in FSI

Hi all,
Since I want to consider a seepage velocity on the interface which is calculated by the solid participant, I add “Velocity” as a new variable in the FSI module following the steps of adding Pressure into the module. After recompiling the OpenFOAM adapter, I modified configuration files and set the boundary condition in U to

type      fixedValue;
value     $internalField;

However, when I ran both solvers, an error occurred:

This participant does not use Data "Velocity", but attempted to write it. 
Please extend the configuration of participant "Fluid" by defining <write-data mesh="Fluid-Mesh" name="Velocity" />.

So I changed the <read-data mesh="Fluid-Mesh" name="Velocity" /> to <write-data mesh="Fluid-Mesh" name="Velocity" /> in the configuration file. And then, even though both solvers were running, the results of U on the interface in every timestep were still

type     fixedValue;
value    uniform (0 0 0);

I’ve checked out the partitioned-pipe case. In its configuration file, there is <read-data name="Velocity" mesh="Fluid2-Mesh" /> and the tutorial case runs fine.

What could possibly go wrong?
precice-config.xml (2.1 KB)
preciceDict.txt (508 Bytes)

I think you need to change the

- <write-data name="Velocity" mesh="Fluid-Mesh"/>
+ <read-data name="Velocity" mesh="Fluid-Mesh"/>

on the Fluid side and accordingly

-    <exchange data="Velocity" mesh="Fluid-Mesh" from="Solid" to="Fluid" />
+    <exchange data="Velocity" mesh="Solid-Mesh" from="Solid" to="Fluid" />

Hi David,
Yes, at the beginning, I set the precice-config.xml exactly as you suggested, and then I got the error

Hm Which solid solver do you use? In the OpenFOAM adapter, did you add the velocity field in the addRead functions? Since you don’t need it on the ‘writing’ side: how about deleting it from the addWriter side? I think the config should be fine. You could check it again using the config-visualizer.

1 Like

The solid solver is just a simple code (compiled using -lprecice) that provides displacement and velocity to the fluid solver. (As always, I’d like to use a simple code to test whether “Velocity” could be accurately coupled in FSI module before modifying our in-house solid solver with preCICE)

Yes, I added the velocity field in the addRead functions. Both Velocity.C and Velocity.H are copied to FSI directory and Velocity.C has been included in the files in Make directory. Now I commented the ‘writing’ side and the same error occurs again. :thinking: (4.3 KB)

Could you compile the Adapter with ADAPTER_PREP_FLAGS="-DADAPTER_DEBUG_MODE" in the Allwmake file (run Allclean before) and enable a preCICE debug output by exchanging the following log tag in the configuration file:

    <sink type="stream" output="stdout"  filter= "(%Severity% > debug) or (%Severity% >= trace )" enabled="true" />

and post the generated log file here?

Yes, of course. I’ve recompiled the adapter and modified the configuration file as you suggested. The output of ‘Allwmake’(i.e. ‘ldd.log’ and ‘wmake.log’) and the log of fluid solver are uploaded.
Thanks for your help! (4.2 KB) (6.6 KB)

You have an error in FSI.C line 226, should be a reader there, not a writer…

I’m sorry that I was so careless…
After correcting this mistake, I found that the values on the interface BC in U is a uniform value instead of a nonuniform List :

    type    fixedValue;
    value  uniform (0.000499167 0.000249584 0);

I’ve tried to add another Interface in preciceDict as follows:

but I still got a uniform value.

This problem has been solved. It is due to the mapping method setting in the configuration file. After I changed the mapping method from nearest-neighbor to rbf-thin-plate-splines, the velocity values of all the cells on the coupling interface (i.e. a nonuniform List<vector>) are written correctly in ‘U’ file.

Maybe this is the numerical deficiency that nearest-neighbor method has?

@Stan thank you for documenting your steps and progress here. As the topic already mentions a few technical issues with the configuration, I would like once again to recommend to future readers to use the config visualizer: Config visualization | preCICE - The Coupling Library

Regarding your last post:

I cannot see how the preCICE mapping could affect these errors: yes, nearest-neighbor is less accurate, but this could only lead to numerical errors, not such configuration errors. Can you reproduce this behavior?

Otherwise, let’s close this thread and continue discussing in separate threads for new questions. :smiley:

Hi Makis,
Sorry for the late reply.

Yes, I cannot agree more. However, I’m pretty sure that the output of U is different between these two methods and I have reproduced this behavior as follows:
( caisson is the interface in the simulation. Please do not focus on the values on boundary caisson, I gave the same values to those cells on the interface just out of convenience. The figure on the left is the output using nearest-neighbor method and the figure on the right is the case in which rbf-thin-plate-splines method is adopted. All the other settings of these two case are exactly the same. I dont’ know what may lead to this problem.)

In addition, the config visualizer is quite convenient and useful. You can see that the mapping method is the only difference between the two case.

Since Pressure can be successfully output and the additional Velocity can be read through openfoam-adapter (once the values are read by OpenFOAM, they are used in the next timestep, right?), I’m sure that preCICE is of great help of my study. After several problems in our in-house code are solved, I’ll adopt preCICE to couple it with OpenFOAM using the same method as soon as possible.
By the way, thanks again for the generous help provided by preCICE team! :wink:

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.