How to configure one-way coupling

Hi, thanks for the clarification on one-way coupling. May I know if there are any one-way coupling examples for openfoam and calculix using precice? I am guessing in settings one has to turn off the information back to the first participant in this case openfoam. But how is this done?

Hi @Titan,

let’s get the FSI/flap_perp/OpenFOAM-CalculiX example and assume that you want to disable exchanging displacements from CalcluliX to OpenFOAM.

In any case, you can use the config-visualizer to visually validate your precice-config.xml. Here is the original configuration:

  1. In principle, we just need to remove the exchange of Displacements, therefore we remove the following node:
    <exchange data="Displacements0" mesh="Solid" from="Calculix" to="Fluid"/>
    
    We can then start the two participants as usual. This is not yet ideal, but it runs:

Furthermore, if we would like to cleanup all the involved files:

  1. We should disable the mapping of Displacements0. Currently the Fluid participant (OpenFOAM) maps the Solid mesh to Fluid-Mesh-Nodes, which is not needed anywhere else. So we remove the mapping:
    <mapping:rbf-thin-plate-splines direction="read" from="Solid" to="Fluid-Mesh-Nodes" constraint="consistent"/>
    
  2. Then, we need to “undefine” the Displacements0 data and the respective read/write operations:
    • Remove the Displacements0 data:
      <data:vector name="Displacements0"/>
      
    • Remove the Fluid-Mesh-Nodes mesh (only uses Displacement0):
      <mesh name="Fluid-Mesh-Nodes">
          <use-data name="Displacements0"/>
      </mesh>
      
    • Remove Displacements0 from the Solid mesh:
      <use-data name="Displacements0"/>
      
    • Remove the use of the Fluid-Mesh-Nodes from Fluid and Solid:
      <use-mesh name="Fluid-Mesh-Nodes" provide="yes"/>
      
    • Remove the read/write operations from the Fluid and Calculix participants:
      <read-data name="Displacements0" mesh="Fluid-Mesh-Nodes"/>
      ...
      <write-data name="Displacements0" mesh="Solid"/>
      
    Our config now looks much simpler:
  3. Apart from the precice-config.xml, you also need to remove the read/write data and the mesh definitions from your solvers/adapters.
    • In Fluid/system/preciceDict, remove the complete Interface2:
      Interface2
      {
        mesh              Fluid-Mesh-Nodes;
        patches           (flap);
        locations         faceNodes;
        
        readData
        (
          Displacements0
        );
        
        writeData
        (
        );
      };
      
    • In config.yml (CalculiX), we need to remove write-data. However, there seems to be a bug in the configuration reading right now. If you cannot wait until we solve it, you could hard-code this in the adapter source code (see issue).
  4. In case you are using implicit coupling (which does not make much sense in a one-way coupling scenario), you also need to remove any convergence measures and replace the data used for the acceleration:
    <absolute-convergence-measure limit="1e-6" data="Displacements0" mesh="Solid"/>
    
    <acceleration:IQN-ILS>
        <data name="Forces0" mesh="Solid"/>
    

Here are the respective files:

Thanks for the detailed reply @MakisH.

I used the files attached in the above message to perform one way coupling for the perpendicular flap example https://github.com/precice/tutorials/tree/master/FSI/flap_perp/OpenFOAM-CalculiX.

The simulations fails to run. The last line of fluid log is -–[precice] Setting up master communication to coupling partner/s. This case is serial, using explicit coupling instead of implicit. However, the same example for two way coupling works. The error I get is different to https://github.com/precice/calculix-adapter/issues/35#issuecomment-605350024. So, I am not sure if it’s because of CalculiX version. The issue you were referring to in above message is different I guess?

Lastly, by omitting write data in config.yml, are we still able to obtain the time history of solid displacement? (not sure if this question is valid :grimacing:)

T

The simulations fails to run. The last line of fluid log is - –[precice] Setting up master communication to coupling partner/s .

This means that the participants cannot find each other. This is often due to file residues from the previous run. Did you first run Allclean (or just remove the precice-run/ directory)?

Lastly, by omitting write data in config.yml, are we still able to obtain the time history of solid displacement?

I am not sure what you mean by “time history”. Are you refering to the export functionality of preCICE? You could still define use, and write the displacements, just don’t exchange them. Then you could also then export them.

It was a clean folder copied from wiki when I posted above query. So, there were no file residues from the previous runs. I tested again with Allclean now. Same error. Attached solid.log shows an error message. This error is because participants can’t find each other? Solid.log (2.7 KB)

I misunderstood your previous comment, here is your error:

About to enter preCICE setup in Calculix with names Calculix and config.yml 
Setting up preCICE participant Calculix, using config file: config.yml
---[precice] e[0m This is preCICE version 2.0.2
---[precice] e[0m Revision info: no-info [Git failed/Not a repository]
---[precice] e[0m Configuring preCICE with configuration: "./precice-config.xml"
Set ID Found 
Read data 'Forces0' found.
---[precice] e[31mERROR: e[0m There is no Mesh with ID:-1

This is the same error as in the issue you mentioned. Please note that the fix is not yet on the master branch, but it is on the the branch v2.16. See https://github.com/precice/calculix-adapter/pull/33 and https://github.com/precice/calculix-adapter/pull/36.

Hi @MakisH,

Thanks for the clarification.
I installed calculix adapter 2.16 to run one-way simulation for perpendicular flap.
I notice that if I include write-data: " " in config.yml, then simulation does not go past reading forces in solid.log. So, I followed this https://github.com/precice/calculix-adapter/issues/35#issuecomment-600832468 and removed read and write info from config.yml. The case runs, but then displacement is zero. The idea is to obtain displacements when forces are imposed on the flap and how different this info is when compared to two way coupling.

May I know if I am missing something?

Hello again,

This time I tried by removing write data statement from config.yml.
The flap case runs until last timestep and then fails while writing coupling data at the very end. Please see the attached log files.
Fluid.log (1.4 MB) Solid.log (1.1 MB)

@Titan it looks like the Fluid participant finalizes and exits before Solid calls the last advance(). This is strange. Could you please upload your precice-config.xml, preciceDict, and config.yml again?

Sure @MakisH.
Files are attached here
config.yml (176 Bytes) precice-config.xml (2.2 KB) preciceDict.txt (472 Bytes)

Sorry for this gentle reminder.
May I know if the above attached files are correct?

Hi,

comparing the files you provide with the files @MakisH provided for his example , I see that you are using

<coupling-scheme:serial-implicit>
    ...
</coupling-scheme:serial-implicit>

in your precice-config.xml. However, @MakisH is using serial-explicit coupling. Is there a particular reason for changing this? Did you use explicit or implicit coupling for the simulation that resulted in these log files? I would suggest to try to get the case running with serial-explicit, first.

edit I just realized that it was the other way around: Your precice-config.xml looks ok. The other files are identical to the files @MakisH is providing.

Some more details on one-way coupling and coupling schemes

Using coupling-scheme:serial-implicit if you want to do one-way coupling is a wrong configuration. If I try to run a similar case, I get an error: ERROR: In case of serial coupling, acceleration can be defined for data of second participant only!

Implicit coupling means that you iterate over the same time window and the solvers exchange boundary conditions. This happens until the coupling converges and the boundary conditions “agree” at the coupling interface.

This becomes more clear by looking at an example FSI case: \mathcal{F}(d)=f is a Fluid solver (e.g. OpenFoam) that receives a displacement (or moving geometry) d and returns forces f. \mathcal{S}(f) = d is a Solid solver (e.g. CalculiX) that receives forces f and returns displacement d. Our coupling scheme iterates until the residual of \mathcal{F}(\mathcal{S}(f))-f is small enough. For more details see Benjamin Uekermann’s thesis, section 3.1.

For one-way coupling one solver sends data and the other solver receives data; I am not sure how implicit coupling might look like in this case.

Hi Titan,

it is not easy to find out what exactly is going wrong. Since I am neither an experienced OpenFOAM nor CalculiX user, debugging the whole case is something I cannot do. As far as possible, some hopefully helpful comments from my side:

The example explained above by @MakisH is not a tutorial, but more a guideline how to turn a two-way-coupling setup into a one-way-coupling. The general approach is correct, but since it is not a tested tutorial, we cannot really promise that there are no bugs hiding in one or the other component.

What components do we have to consider?

  • I ran your precice-config.xml with the C++ solverdummy and it worked. This means on the preCICE (library) side everything looks good.
  • Additionally, there are the two adapters (OpenFOAM and CalculiX). Since one-way-coupling is a feature that is rarely used, there might be a bug in one of the two adapters.

Unfortunately, adapters are always a bit hard to debug on their own… One possibility is to run the OpenFOAM adapter + solverdummy or CalculiX adapter + solverdummy. This allows us to cancel out one side of the problem. As soon as we know whether there is a bug in one of there two adapters (or if we are extremely unlucky and both adapters are buggy), we could also open an issue in one of the adapter repositories and try to fix the bug.

However, I think this brings us pretty far away from the original topic of this thread. If you want me to provide some more details on how to debug an adapter, you can also open another topic.

As I wrote in my original post:

All the pictures are with serial-explicit coupling, however I see that I should have just skipped this point to avoid confusion.

Regarding the main issue, I also expect an issue in one of the adapters, even though this is a common step in a setup of an FSI simulation. @Titan could you maybe try turning one of the OpenFOAM-OpenFOAM or CalculiX-CalculiX tutorials into one-way coupling and report your findings here or (better) open an issue in the respective OpenFOAM adapter or CalculiX adapter repository? The results would not matter, only the finalization.

1 Like

I did not think of the OpenFOAM-OpenFOAM or CalculiX-CalculiX tutorials. This might indeed be a much easier approach than using a solverdummy on one side of the problem. :+1:

1 Like

Thanks @MakisH and @BenjaminRueth for your replies.
I assumed that one way coupling was tested on perpendicular flap case.
And also from this link https://github.com/precice/calculix-adapter/issues/35#issuecomment-608363588, i thought one way coupling works and wondered if i might be doing something wrong.
Ok. will explore same platform options for coupling as @MakisH suggested above for testing.

One-way coupling is now also supported in the main branch of the CalculiX adapter (currently v2.16), so I hope this thread is now resolved. @Titan feel free to reopen if you still have issues with this.

Sure. I will test and reopen if I encounter any issues. Thanks

Hi,

I realized that config.yml and precice-config.xml must include some displacement related info for the solution output in one-way coupling. Attached are the files that are slightly different to those posted on 17th Mar 2020
https://precice.discourse.group/t/how-to-configure-one-way-coupling/232/2?u=titan. Attached figure shows the difference in results from one-way and two-way coupling for flap tutorial.
config.yml (225 Bytes) precice-config.xml (2.5 KB)