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.
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.
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. addVelocity.zip (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:
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! Allwmake.zip (4.2 KB) fluidSolver.zip (6.6 KB)
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 :
caisson
{
type fixedValue;
value uniform (0.000499167 0.000249584 0);
}
I’ve tried to add another Interface in preciceDict as follows:
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.
@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.
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.)
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!
