Current state of generic data exchange in volume coupling of OpenFOAM adapter

Hello everyone!

Intro

I am starting to use the preCICE-adapter to couple an in-house DEM solver with OpenFOAM. I am on the current develop branch of openfoam-adapter, precice v3.2.0 and am using openfoam2412 and Fedora41. Starting point is this paper: ORBilu: Detailed Reference and the preCICE-Tutorials.

Generic data exchange in volume-coupling

From what I saw in the forums and the documentation, a generic data exchange is currently not supported:

And it was discussed that there is being done some work on it currently:

I wanted to inform myself if there is any active development done here or if there is information about the current state.

My use case

My current approach will be misusing the velocity-read of the OpenFOAM-adapter to pass the momentum-sourceterm from DEM->CFD (could also be just passing the void-fraction of each cell - I did not find out what the most convenient way is yet). Unidirectional coupling from CFD->DEM seems to work without an issue.

The issue I am currently facing appears when trying to implement bidirectional coupling. I am not sure if I can read and write to different velocity fields e.g. something like this:

modules (FF);

interfaces
{
  Interface1
  {
    mesh               FluidMesh;
    patches            ();
    cellSets           (meshBox);
    locations          volumeCenters;
    
    readData (Velocity0);
    writeData (Velocity1);
  };
};

FF
{
  nameVelocity0     U_vol;
  nameVelocity1     U;
};

Is bidirectional volume-coupling supported? I guess misusing the velocity-field for sourceterm exchange is not exactly the “preCICE” way of doing this but it’s my first naive approach. I should mention that I have zero experience with CFD and OpenFOAM but am motivated to work on this :sweat_smile:

I am willing to take a look into #279 and might be able to contribute some form of generic data-exchange to it. Any input regarding the state of issue or just something about preCICE CFD-DEM coupling is highly welcomed.

Thanks a lot!

UPDATE:
After diving a little deeper into the OpenFOAM adapter and its source code I understood the modularity and extensibility of the adapter. I created a module and defined a VolumePorosity field to exchange from my solver to OpenFOAM.

EDIT:
The current preciceDict looks something like this:

modules (MOM FF);
interfaces
{
  Interface1
  {
    mesh               FluidMesh;
    patches            ();
    faceSets           (couplingFaces);
    locations          volumeCenters;
    
    readData
    (      
    );
    
    writeData
    (
      Velocity
    );
  };

  Interface2
  {
    mesh               FluidMesh;
    patches            ();
    cellSets           (meshBox);
    locations          volumeCenters;
    
    readData
    (
      VolumePorosity
    );
    
    writeData  ();
  }
};


MOM
{
  nameVolumePorosity     VolumePorosity;
};

EDIT:
I can now exchange generic data bidirectional but am still facing an issue - I seem to receive sparse data (random 0 entries) from the OpenFOAM adapter (data is not sparse in OpenFOAM but after I receive it in my solver) and am currently trying to find out the reason for that. I would be interested in talking to someone that is actively using bidirectional communication (of generic data) with the OpenFOAM adaper about topics like performance, scalability and maybe some lessons learned :slight_smile:

1 Like

Update 2: I want to further share my progress here and the current issues I am facing. I changed the OpenFOAM adapter to accept the momentum term from my DEM simulation and am now trying to apply this term to my OpenFOAM fluid-field.

I am currently using the fvOptions file to add the momentum-term (based on Algorithms in a Robust Hybrid CFD-DEM Solver for Particle-Laden Flows | Communications in Computational Physics | Cambridge Core) to my equation, but this is where i am currently facing issues.

FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      fvOptions;
}

codedSource
{
    type            vectorCodedSource;
    selectionMode   cellSet;
    cellSet         meshBox;

    fields          (U);
    name            momentumApplication;

    codeAddSup
    #{
        const fvMesh& mesh = this->mesh();
        const labelList& cells = this->cells();

        if(mesh.foundObject<volVectorField>("MomentumSource"))
        {
            const volVectorField& momentumSource = mesh.lookupObject<volVectorField>("MomentumSource");

            vector totalMomentumSource(0, 0, 0);
            scalar totalMomentumMagnitude = 0.0;
            
            forAll(cells, i)
            {
                label celli = cells[i];
                const scalar rho = 1.2;  // Hard-coded for simplicity assuming air
                eqn.source()[celli] += momentumSource[celli] / rho;
            }
        }
        else
        {
            Info << "MomentumSource not found." << endl;
        }

        
        return;
    #};
}

My simulation becomes unstable after only a few iterations because the momentum i am applying through the coupling seems to get added cumulatively every iteration of OpenFOAM. My fluid-velocities become extremely fast and accelerate my particles therefore way to much after the first coupling interval.
Does anyone understand this topic good enough to explain it briefly to me or highlight the error in my script?

Best regards and thanks in advance!

I want to provide my final insights here to finally wrap-up this self talk - maybe this will help somebody in the future. The major issue I had was that i thought I compute the full momentum-source term on the DEM side [N/m^3] and let preCICE map those values from DEM-Grid → Fluid-Mesh. I rewrote this part to send the total sum of forces on my particles due to fluid interaction [N] and apply this in OpenFOAM.

The values I apply on OpenFOAM seem reasonable - I just have an issue mapping from a coarse grid to a finer one (DEM-Grid 21x21x21 // Fluid-Mesh 40x40x40). The image shows the received forces in the Fluid-Mesh, which has a finer resolution than the DEM-Grid. I guess this will be somehow possible to map

1 Like

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