Surface coupling of fluid-fluid simulation

[dennis]

Hi everybody,

I have a relatively straight forward surface coupling case, which I am having trouble with and I hope someone can help: I am performing fluid-fluid coupling with a custom solver. Below is a simplified case setup, that illustrates my issue. I have one Fluid-1 domain and another Fluid-2 domain, which is surface coupled to the mesh of Fluid-1. My coupling variables are the volume fraction (alpha) of a liquid along with its gradient, the pressure+gradient and velocity+gradient at the interfaces. A pressure difference is set between the inlet and the outlet, I would like the liquid to simply flow through the structure shown below. I use the same boundary conditions, as I do for cases without the coupling, the only difference is that at the coupled interfaces I use a coupledVelocity and coupledPressure boundary condition.

My problem is, that after several timesteps, the simulations crashes. When looking at the pressure, I get the following profile:

Its not as continuous as I would have expected and even looks somewhat inverted (like at the coupled interface on the bottom right). Do you know if this is a problem with my precice configuration? And if so, what would I have to do to change this? I have attached my precice-config.xml below.

I appreciate any help.

All the best,

Dennis

precice-config.xml (3.9 KB)

[Makis]

@dennis

I am performing fluid-fluid coupling with a custom solver.

Could you maybe give more details about the solvers? Are they both compressible solvers?

@dennis

My coupling variables are the volume fraction (alpha) of a liquid along with its gradient, the pressure+gradient and velocity+gradient at the interfaces.

Coupling both values and gradients for both velocity and pressure is not necessarily the best setup. In our tutorials, we typically do not couple the pressure gradient:

Partitioned pipe two phase

(see also the linked study and Markus’ thesis for more examples)

Not sure if this is the reason, though. How does the flow look like until that point? Does it start fine and eventually introduce errors, or is it completely wrong since the beginning?

How do the 0/U, 0/p, and 0/alpha files look for both solvers?

[dennis]

Hello Makis,

yes, they are both compressible, porous media solvers. I have added the boundary value files below for Fluid 1. The shared boundaries are the coupledInterface in Fluid-1, that is coupled to the inlet and outlet of Fluid-2.

p_rgh_fluid1.txt (1.2 KB)

alpha_fluid1.txt (1.1 KB)

U_fluid1.txt (1.1 KB)

and here for Fluid 2

p_rgh_fluid2.txt (577 Bytes)

alpha_fluid2.txt (517 Bytes)

U_fluid2.txt (520 Bytes)

No, unfortunately its completely wrong from the beginning.

[dennis]

It might be important to add, that this only happens when i couple my solver on two interfaces. If I have only one patch (similarly to the partitioned-pipe-two-phase tutorial), then everything works as expected

[Makis]

@dennis

No, unfortunately its completely wrong from the beginning.

This is the fortunate case: we have something clear and easy to check!

I see a few issues in these files:

1. Fluid 1: Why is there only one couplingInterface? These interfaces are separated. I would define two, one for each coupled surface.

2. Fluid 2: Why are both alpha boundaries fixedValue? Aren’t you reading a gradient in one of the interfaces?

3. Fluid 2: Pressure:

   • Why are the walls defined as fixedFluxPressure? Should be zeroGradient.
   • In the examples we have, we typically define coupledPressure in the one side, and fixedValue in the other. But I think coupledPressure in both should work, as it changes type per direction of the flow. Same for velocity.

[dennis]

Thanks, Makis! I tried out your advice and changing to two coupling interfaces and using coupledPressure along with fixedValue solved some of the issues. Now the pressure function is looking the way I would expect it. I still have a problem with my alphas though - the Fluid-2 domain does not get filled (at the point I would expect it to start getting filled, the pressure - understandably - does strange things). You mentioned that the gradient should be read on one of the interfaces. Currently, Fluid-1 reads the alpha gradient and Fluid-2 writes the alpha values. I thought I could either read or write with one mesh, how would I split this up in my configuration?

[Makis]

@dennis

I thought I could either read or write with one mesh

One can read and write on the same mesh, as long as the quantities are indeed associated to the same locations (e.g., both on the face centers).

Could you upload your current alpha files?

[dennis]

Yes, of course. They are attached below, the couplingInterface1 in the Fluid-1 patch is connected to the inlet in Fluid-2 and couplingInterface2 in the Fluid-1 patch is connected to the outlet in Fluid-2

alpha_fluid1.txt (1.2 KB)

alpha_fluid2.txt (520 Bytes)

[Makis]

Why does Fluid2 not have any coupling interface?

I would make the one a zeroGradient and the other a fixedValue.

[dennis]

The coupling occurs at the inlet and outlet of Fluid-2

[Makis]

Right, sorry. But then, the Fluid1 has an issue:

    couplingInterface1
    {
        type            fixedGradient;
        gradient        uniform 0; 
    }
    couplingInterface2
    {
        type            fixedGradient;
        gradient        uniform 0; 
    }

One of these should be fixedValue.

[dennis]

Ok, but I assume I have to make the mesh readable and writeable for this to work, correct?

[Makis]

What do you mean to “make the mesh readable and writeable”? In terms of meshes, this works already. I think it is still confusing that preCICE has both coupling interfaces (OpenFOAM patches) in the same mesh. The config file currently has:

• Fluid1-Mesh
• Fluid2-Mesh

You could make it:

• Fluid1-Upstream-Mesh
• Fluid1-Downstream-Mesh
• Fluid2-Inlet-Mesh
• Fluid2-Outlet-Mesh

The preciceDict for Fluid1 would then be something like (not tested):

interfaces
{
  Interface1
  {
    mesh              Fluid1-Upstream-Mesh;
    patches           (couplingInterface1);
    locations         faceCenters;

    readData
    (
       Pressure
       VelocityGradient
       Alpha
    );

    writeData
    (
       PressureGradient
       Velocity
       AlphaGradient
    );
  };
  Interface2
  {
    mesh              Fluid1-Downstream-Mesh;
    patches           (couplingInterface2);
    locations         faceCenters;

    readData
    (
       PressureGradient
       Velocity
       AlphaGradient
    );

    writeData
    (
       Pressure
       VelocityGradient
       Alpha
    );
  };
};

Notes:

1. Where the gradient of a field is read, the boundary condition needs to be fixedGradient. Where the value is read, the BC needs to be fixedValue.
2. It is a bit arbitrary on which participant to read values and on which gradients of each field, but typically we don’t read only values or only gradients on one patch.
3. You would need to modify your precice-config.xml as well to define the additional meshes, and add two more mappings. This is more complicated than two pipes in series, but again the case itself is also more complex.

[dennis]

Ah, the problem was that I had misunderstood how system/preciceDict works. I think the issue is fixed for me now, thank you for your help!

[dennis]

Sorry to open this up again, it seems that the issue I had with the alpha values is not resolved after all: in the beginning, the simulation looks fine, however once the alpha fraction begins to fill the domain of Fluid-2, a large pressure gradient between Fluid-1 and Fluid-2 builds up, however the fluid does not enter the Fluid-2 domain. Besides that the alpha values get values >1 in this area. I assume there is something wrong with the left coupled interface, I am unsure what it is though. Below is a screenshot of the pressure distribution right after the fluid begins to enter the FLuid-2 domain. Do you know what could be causing this?

I moved to two coupled interfaces as Makis had suggested, that exchange alpha, p_rgh and U on both interfaces.

[Makis]

I would again need the exact configuration files here:

• precice-config.xml
• 0/*
• system/preciceDict

[dennis]

Yes, they are attached:

The precice-config.xml:

precice-config.xml (8.0 KB)

The 0/* files for Fluid-1:

p_rgh_fluid1.txt (1.3 KB)

alpha_fluid1.txt (1.2 KB)

U_fluid1.txt (1.2 KB)

along with the preciceDict

preciceDict_fluid1.txt (942 Bytes)

and the 0/* values for fluid-2:

U_fluid2.txt (513 Bytes)

p_rgh_fluid2.txt (532 Bytes)

alpha_fluid2.txt (520 Bytes)

alogn with its preciceDict

preciceDict_fluid2.txt (918 Bytes)

Thanks again for your help, Makis

[Makis]

With a quick look, I think the technical setup is correct.

What happens if you exclude the PressureGradient from the coupling?

I assume these are all the variables and that you are using interFoam or a solver derived from that.

[dennis]

Excluding PressureGradient doesn’t change much.

However, I do have different variables in my solver, such as temperature and some material properties (defined as a variable, they are only used to set up the porous media domain), which I create, they are not part of any calculation though (I commented out TEqn.H for simplicity) and are therefore not coupled. Do you think this might cause problems? The variables themselves are hardcoded into the derived solver I am using and simply commenting them out isn’t so easy, therefore I haven’t tested removing them. If you think they will cause issues, I will try though.

Furthermore, I have the pressure p derived from the reduced pressure p_rgh, which I am not coupling either.

[Makis]

@dennis

Do you think this might cause problems?

No, if they are not contributing in the computations, there is no reason to couple them.

@dennis

Furthermore, I have the pressure p derived from the reduced pressure p_rgh, which I am not coupling either.

This might be an issue. Why are you defining nameP p_rgh;, if you are not using it?

I find it interesting that the problem appears when the phase changes, thinking that there might be phase-related variables that the adapter does not couple (some solver split, e.g., U into U.air and U.water).