OpenFOAM-OpenFOAM FSI coupling

and here is the log files archive.

Moreover, I applied the changes that you proposed in your pull request to the adapter.

EDIT: I am now using pointDisplacement in solidFoam (which is a strict copy of “uN”) and here is the new log files. Now the error is

[precice] ESC[31mERROR: ESC[0m Data is not marked as read! 2

EDIT2: I have changed “solverType” in Solid/system/preciceDict from “incompressible” to “structure”, as suggested by the modifications in the pull request. Here are the new logs. More especially in Solid.log we can see

—[preciceAdapter] [DEBUG] Adding coupling data writers…
→ FOAM Warning :
From function void adapterInfo(std::__cxx11::string, std::__cxx11::string)
in file Utilities.C at line 50
ESC[31mError (deferred - will exit later) in the preCICE adapter: ESC[0m
Forces calculation does only support compressible or incompressible solver type.

It looks like the modification that I did based on the pull request are not enough, and that somewhere in precice’s implementation I have to include an option for “structure”.

Hey @dashqua

I think in general it looks good. Maybe you don’t even need the if-statement in the boundary. To set the loadingType to FSI on the wetsurface patch as you did should be enough.

As far as I see from your log files, you have to change the read/write directions in your Solid part.
In the solid part you want to read the Forces and write the Displacements. At the moment it seems like its the other way round.

In the preciceDict it should be like this:

interfaces
{
  Interface1
  {
    mesh              Solid-Mesh-Faces;   // Centers;
    patches           (wetsurface);
    locations         faceCenters;
    
    readData
    (
	Force
    );
    
    writeData
    (	
    );
  };
  
  Interface2
  {
    mesh              Solid-Mesh-Nodes;
    patches           (wetsurface);
    locations         faceNodes;
    
    readData
    (      
    );
    
    writeData
    (
        Displacement
    );
  };
};

Thats also why you got the error “Forces calculation does only support compressible or incompressible solver type” because the forces calculation should only be done in the Fluid part.

Hey @JSeuffert,
I applied my modification to Solid’s preciceDict but I still have the same error. I figured out it was because we are only allowing the “Force::Force” to be initialized by either a “compressible” or an “incompressible” keyword (see line 22 here). I added the possibility of a “structure” keyword and I arrived there:

/*---------------------------------------------------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  6
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
Build  : 6-47517f2ebb1b
Exec   : solidFoam -case Solid
Date   : Mar 24 2020
Time   : 18:18:28
Host   : "debian"
PID    : 31483
I/O    : uncollated
Case   : ./Solid
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

Reading dictionaries ...
Reading data from dictionaries ...
Creating mesh parameters ...
--> FOAM Serious Error : 
    From function virtual bool Foam::regIOobject::writeObject(Foam::IOstream::streamFormat, Foam::IOstream::versionNumber, Foam::IOstream::compressionType, bool) const
    in file db/regIOobject/regIOobjectWrite.C at line 55
    instance undefined for object Forces
Creating mesh coordinate fields ...
Creating mesh normal fields ...
Creating linear momentum fields ...
Creating strain measure fields ...
Creating constitutive model ...
>>energy Algorithm
>>energy Algorithm OK
Creating fields for wave speeds ...
Creating fields for gradient ...
Creating fields for reconstruction ...
Creating fields for riemann solver ...
Creating fields for the constrained procedure ...
Creating fields for angular momentum ...
Creating fields for post-processing ...
Creating variables for time ...
Printing data ...

Printing material properties ...
Constitutive model = neoHookean
Density = 1100 [1 -3 0 0 0 0 0]
Young's modulus = 17000000 [1 -1 -2 0 0 0 0]
Poisson's ratio = 0.45 [0 0 0 0 0 0 0]
Lame's first parameter lambda = 52758621 [1 -1 -2 0 0 0 0]
Lame's second parameter mu = 5862069 [1 -1 -2 0 0 0 0]
Bulk modulus kappa = 56666667 [1 -1 -2 0 0 0 0]
Linear pressure wave speed = 242.1171 [0 1 -1 0 0 0 0]
Linear shear wave speed = 73.001052 [0 1 -1 0 0 0 0]

Printing global momentums ...
Global linear momentum = (0 0 0)
Global angular momentum = (0 0 0)

Centroid of geometry = (0.425 0.2 -1.4076841e-18)
---[preciceAdapter] The preciceAdapter was loaded.
---[preciceAdapter] Reading preciceDict...
---[preciceAdapter] [DEBUG]   precice-config-file : precice-config.xml
---[preciceAdapter] [DEBUG]   participant name    : Solid
---[preciceAdapter] [DEBUG]   modules requested   : 
---[preciceAdapter] [DEBUG]   - FSI

---[preciceAdapter] [DEBUG]   interfaces : 
---[preciceAdapter] [DEBUG]   - mesh         : Solid-Mesh-Faces
---[preciceAdapter] [DEBUG]     locations    : faceCenters
---[preciceAdapter] [DEBUG]     connectivity : 0
---[preciceAdapter] [DEBUG]     patches      : 
---[preciceAdapter] [DEBUG]       - wetsurface
---[preciceAdapter] [DEBUG]     writeData    : 
---[preciceAdapter] [DEBUG]     readData     : 
---[preciceAdapter] [DEBUG]       - Force
---[preciceAdapter] [DEBUG]   - mesh         : Solid-Mesh-Nodes
---[preciceAdapter] [DEBUG]     locations    : faceNodes
---[preciceAdapter] [DEBUG]     connectivity : 0
---[preciceAdapter] [DEBUG]     patches      : 
---[preciceAdapter] [DEBUG]       - wetsurface
---[preciceAdapter] [DEBUG]     writeData    : 
---[preciceAdapter] [DEBUG]       - Displacement
---[preciceAdapter] [DEBUG]     readData     : 
---[preciceAdapter] [DEBUG]   evaluate boundaries : 1
---[preciceAdapter] [DEBUG] Configuring the FSI module...
---[preciceAdapter] [DEBUG]     user-defined solver type : structure
---[preciceAdapter] [DEBUG]     add solid forces : 0
---[preciceAdapter] [DEBUG]     pointDisplacement field name : pointDisplacement
---[preciceAdapter] [DEBUG] Known solver type: structure
---[preciceAdapter] [DEBUG] Checking the timestep type (fixed vs adjustable)...
---[preciceAdapter] [DEBUG]   Timestep type: fixed.
---[preciceAdapter] [DEBUG] Creating the preCICE solver interface...
---[preciceAdapter] [DEBUG]   Number of processes: 1
---[preciceAdapter] [DEBUG]   MPI rank: 0
---[precice] e[0m This is preCICE version 2.0.1
---[precice] e[0m Revision info: no-info [Git failed/Not a repository]
---[precice] e[0m Configuring preCICE with configuration: "precice-config.xml"
---[preciceAdapter] [DEBUG]   preCICE solver interface was created.
---[preciceAdapter] [DEBUG] Creating interfaces...
---[preciceAdapter] [DEBUG] Number of face centres: 525
---[preciceAdapter] [DEBUG] Interface created on mesh Solid-Mesh-Faces
---[preciceAdapter] [DEBUG] Adding coupling data writers...
---[preciceAdapter] [DEBUG] Adding coupling data readers...
---[preciceAdapter] [DEBUG] Added reader: Force.
---[preciceAdapter] [DEBUG] Number of face nodes: 536
---[preciceAdapter] [DEBUG] Interface created on mesh Solid-Mesh-Nodes
---[preciceAdapter] [DEBUG] Adding coupling data writers...
---[preciceAdapter] [DEBUG] Added writer: Displacement.
---[preciceAdapter] [DEBUG] Adding coupling data readers...
---[preciceAdapter] [DEBUG] Initalizing the preCICE solver interface...
---[precice] e[0m Setting up master communication to coupling partner/s
---[precice] e[0m Masters are connected
---[precice] e[0m Setting up preliminary slaves communication to coupling partner/s
---[precice] e[0m Prepare partition for mesh Solid-Mesh-Faces
---[precice] e[0m Gather mesh Solid-Mesh-Faces
---[precice] e[0m Send global mesh Solid-Mesh-Faces
---[precice] e[0m Prepare partition for mesh Solid-Mesh-Nodes
---[precice] e[0m Gather mesh Solid-Mesh-Nodes
---[precice] e[0m Send global mesh Solid-Mesh-Nodes
---[precice] e[0m Setting up slaves communication to coupling partner/s
---[precice] e[0m Slaves are connected
---[precice] e[0m it 1 of 100 | dt# 1 | t 0 of 10 | dt 0.005 | max dt 0.005 | ongoing yes | dt complete no | write-iteration-checkpoint | 
---[preciceAdapter] [DEBUG] Initializing preCICE data...
---[precice] e[0m initializeData is skipped since no data has to be initialized
---[preciceAdapter] preCICE was configured and initialized
---[preciceAdapter] [DEBUG] Reading coupling data...
---[preciceAdapter] [DEBUG] Creating a list of checkpointed fields...
---[preciceAdapter] [DEBUG] Collecting objects of type volScalarField... 
---[preciceAdapter] [DEBUG] Will be checkpointing (sqrt(((((nu*E)|((1+nu)*(1-(2*nu))))+(2*(E|(2*(1+nu)))))|rho))|stretch)
---[preciceAdapter] [DEBUG] Will be checkpointing J
---[preciceAdapter] [DEBUG] Will be checkpointing Up
---[preciceAdapter] [DEBUG] Will be checkpointing p
---[preciceAdapter] [DEBUG] Will be checkpointing energyAlgorithm
---[preciceAdapter] [DEBUG] Will be checkpointing stretch
---[preciceAdapter] [DEBUG] Will be checkpointing Us
---[preciceAdapter] [DEBUG] Collecting objects of type volVectorField... 
---[preciceAdapter] [DEBUG] Will be checkpointing rhsAm
---[preciceAdapter] [DEBUG] Will be checkpointing lm_b
---[preciceAdapter] [DEBUG] Will be checkpointing Force
---[preciceAdapter] [DEBUG] Will be checkpointing rhsLm
---[preciceAdapter] [DEBUG] Will be checkpointing Forces
---[preciceAdapter] [DEBUG] Will be checkpointing x
---[preciceAdapter] [DEBUG] Will be checkpointing lm
---[preciceAdapter] [DEBUG] Will be checkpointing t_b
---[preciceAdapter] [DEBUG] Collecting objects of type surfaceScalarField...
---[preciceAdapter] [DEBUG] Collecting objects of type surfaceVectorField...
---[preciceAdapter] [DEBUG] Will be checkpointing (S|magSf)
---[preciceAdapter] [DEBUG] Will be checkpointing lm_M
---[preciceAdapter] [DEBUG] Will be checkpointing n
---[preciceAdapter] [DEBUG] Will be checkpointing t_M
---[preciceAdapter] [DEBUG] Will be checkpointing ((0.5*(lm_M+lm_M))+((0.5*S_t)&((P_M&(S|magSf))-t_M)))
---[preciceAdapter] [DEBUG] Will be checkpointing (P_M&(S|magSf))
---[preciceAdapter] [DEBUG] Will be checkpointing ((0.5*(t_M+(P_M&(S|magSf))))+((0.5*S_lm)&(lm_M-lm_M)))
---[preciceAdapter] [DEBUG] Collecting objects of type pointScalarField...
---[preciceAdapter] [DEBUG] Collecting objects of type pointVectorField...
---[preciceAdapter] [DEBUG] Will be checkpointing lmN
---[preciceAdapter] [DEBUG] Will be checkpointing xN
---[preciceAdapter] [DEBUG] Will be checkpointing uN
---[preciceAdapter] [DEBUG] Will be checkpointing pointDisplacement
---[preciceAdapter] [DEBUG] Collecting objects of type volTensorField...
---[preciceAdapter] [DEBUG] Will be checkpointing F
---[preciceAdapter] [DEBUG] Will be checkpointing AinvLocal
---[preciceAdapter] [DEBUG] Will be checkpointing P
---[preciceAdapter] [DEBUG] Will be checkpointing Ainv
---[preciceAdapter] [DEBUG] Will be checkpointing H
---[preciceAdapter] [DEBUG] Collecting objects of type surfaceTensorField...
---[preciceAdapter] [DEBUG] Will be checkpointing S_t
---[preciceAdapter] [DEBUG] Will be checkpointing S_lm
---[preciceAdapter] [DEBUG] Will be checkpointing P_M
---[preciceAdapter] [DEBUG] Collecting objects of type pointTensorField...
---[preciceAdapter] [DEBUG] Collecting objects of type volSymmTensorField...
---[preciceAdapter] [DEBUG] Writing a checkpoint...
---[preciceAdapter] [DEBUG] Stored time value t = 0.000000
---[preciceAdapter] [DEBUG] Storing mesh points...
---[preciceAdapter] [DEBUG] Stored mesh points.
---[preciceAdapter] [DEBUG] Checkpoint for time t = 0.000000 was stored.
---[preciceAdapter] [DEBUG] Adjusting the solver's timestep...
---[preciceAdapter] [DEBUG] The solver's timestep is the same as the coupling timestep.
---[preciceAdapter] Setting the solver's endTime to infinity to prevent early exits. Only preCICE will control the simulation's endTime. Any functionObject's end() method will be triggered by the adapter. You may disable this behavior in the adapter's configuration.
---[preciceAdapter] [DEBUG] Adjusting the solver's timestep...
---[preciceAdapter] [DEBUG] The solver's timestep is the same as the coupling timestep.

Time step =1
Time increment = 0.005 s
Time = 0.005 s
correcting model
>>energy Algorithm
>>energy Algorithm OK
model corrected
updating variables
correcting model
>>energy Algorithm
>>energy Algorithm OK
model corrected
variables updated
Simulation completed = 1.110223e-16%
---[preciceAdapter] [DEBUG] Writing coupling data...


--> FOAM FATAL ERROR: 
Attempt to cast type calculated to type fixedValue

    From function To& Foam::refCast(From&) [with To = Foam::fixedValuePointPatchField<Foam::Vector<double> >; From = Foam::pointPatchField<Foam::Vector<double> >]
    in file /mnt/datasim/OpenFOAM/OpenFOAM-6/src/OpenFOAM/lnInclude/typeInfo.H at line 114.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::error::abort() at ??:?
#2  ? at Displacement.C:?
#3  preciceAdapter::Interface::writeCouplingData() at ??:?
#4  preciceAdapter::Adapter::writeCouplingData() at ??:?
#5  preciceAdapter::Adapter::execute() at ??:?
#6  Foam::functionObjects::preciceAdapterFunctionObject::execute() at ??:?
#7  Foam::functionObjectList::execute() at ??:?
#8  Foam::Time::run() const at Time.C:?
#9  ? in "/home/tdg/OpenFOAM/tdg-6/platforms/linux64GccDPInt64Opt/bin/solidFoam"
#10  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#11  ? in "/home/tdg/OpenFOAM/tdg-6/platforms/linux64GccDPInt64Opt/bin/solidFoam"
[debian:31483] *** Process received signal ***
[debian:31483] Signal: Aborted (6)
[debian:31483] Signal code:  (-6)
[debian:31483] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x37840)[0x7f8efc85b840]
[debian:31483] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x10b)[0x7f8efc85b7bb]
[debian:31483] [ 2] /lib/x86_64-linux-gnu/libc.so.6(abort+0x121)[0x7f8efc846535]
[debian:31483] [ 3] /mnt/datasim/OpenFOAM/OpenFOAM-6/platforms/linux64GccDPInt64Opt/lib/libOpenFOAM.so(_ZN4Foam5error5abortEv+0x10d)[0x7f8efd07403d]
[debian:31483] [ 4] /home/tdg/OpenFOAM/tdg-6/platforms/linux64GccDPInt64Opt/lib/libpreciceAdapterFunctionObject.so(+0x4b89c)[0x7f8efbb2a89c]
[debian:31483] [ 5] /home/tdg/OpenFOAM/tdg-6/platforms/linux64GccDPInt64Opt/lib/libpreciceAdapterFunctionObject.so(_ZN14preciceAdapter9Interface17writeCouplingDataEv+0x8d)[0x7f8efbb2ed6d]
[debian:31483] [ 6] /home/tdg/OpenFOAM/tdg-6/platforms/linux64GccDPInt64Opt/lib/libpreciceAdapterFunctionObject.so(_ZN14preciceAdapter7Adapter17writeCouplingDataEv+0xe9)[0x7f8efbb8ffd9]
[debian:31483] [ 7] /home/tdg/OpenFOAM/tdg-6/platforms/linux64GccDPInt64Opt/lib/libpreciceAdapterFunctionObject.so(_ZN14preciceAdapter7Adapter7executeEv+0x76)[0x7f8efbb9e686]
[debian:31483] [ 8] /home/tdg/OpenFOAM/tdg-6/platforms/linux64GccDPInt64Opt/lib/libpreciceAdapterFunctionObject.so(_ZN4Foam15functionObjects28preciceAdapterFunctionObject7executeEv+0xd)[0x7f8efbbccdbd]
[debian:31483] [ 9] /mnt/datasim/OpenFOAM/OpenFOAM-6/platforms/linux64GccDPInt64Opt/lib/libOpenFOAM.so(_ZN4Foam18functionObjectList7executeEv+0x46)[0x7f8efd1c5e06]
[debian:31483] [10] /mnt/datasim/OpenFOAM/OpenFOAM-6/platforms/linux64GccDPInt64Opt/lib/libOpenFOAM.so(_ZNK4Foam4Time3runEv+0xc1)[0x7f8efd1d62d1]
[debian:31483] [11] solidFoam(+0x2c9f0)[0x55c0e1f6e9f0]
[debian:31483] [12] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f8efc84809b]
[debian:31483] [13] solidFoam(+0x3422a)[0x55c0e1f7622a]
[debian:31483] *** End of error message ***

Ok yes you are right, you need to set it in the preciceDict to “compressible” or “incompressible” or (better) with the structure type you inserted.

Now you got this one:

As it states, the adapter needs a “fixedValue” type boundary condition at your interface patch. You have a “calculated” type at the moment. So in your pointDisplacement boundary condition you have to set the boundary at the wetsurface to fixedValue (be sure your uN still passes the calculated value to the pointDisplacement at the patch).

I hope thats the last bit that is missing and it starts running!

Cheers

1 Like

Hi @JSeuffert,

  1. The pointDisplacement field, called “uN” (now specified in preciceDict, so no need to recreate another field), is now read from the Solid/0/ directory and has fixedValue uniform (0 0 0)on its two boundaries including the interface.

  2. As I modified the tractionTraction boundary condition (i.e. the boundary condition applied on the traction field in a traction scenario), I also modified the tractionlinearMomentum boundary condition (i.e. the boundary condition applied on the linear momentum in a traction scenario) to include a FSI case in the following way:

else if (loadingType_ == "FSI")
  {
    const fvPatchField<vector>& Forces_ =
        patch().lookupPatchField<volVectorField, vector>("Forces");
    lm_C = lm_M_ + (S_t_ & ((Forces_) - t_M_));
  }

I am now able to run the case for a single timestep and the runtime breaks for a very surprising reason : the dimensions of magSf changes (see Solid.log for the entire log):

dim magSf: [0 1 0 0 0 0 0]
dim Sf: [0 2 0 0 0 0 0]
 
 
--> FOAM FATAL ERROR:
Different dimensions for =
     dimensions : [1 -1 -2 0 0 0 0] = [1 -2 -2 0 0 0 0]
 
 
    From function bool Foam::dimensionSet::operator=(const Foam::dimensionSet&) const
    in file dimensionSet/dimensionSet.C at line 171.
 
FOAM aborting

Note: the error occurs when arriving at the first line of the gEqns:

// Compute right hand sides
rhsLm = fvc::surfaceIntegrate(tC*magSf);

When I run solidFoam alone, there is no problem and the case runs smoothly. When I want to resort to the loadingType FSI, this error of dimensions appear.
I have reviewed my modification in openfoam-adapter. They are similar to those in the pull request and do not present flaw to me. Nevertheless the problem has to come from preCICE in my opinion.

Any thought?

Thats very weird. I don’t know how preCICE shoul change the dimensions of this field. At the interface we only write/read the values without dimensions and the magSf is not touched here.

Can you maybe check what the dimensions of mesh.magSf() is? I hope they do not change…

Maybe one of the precice guys have any idea what is the problem here?

That is what I thought too. So I have checked the dimensions of Sf and magSf in my solid solver (see the log above): at first they both have the dimension [0 2 0 0 0 0 0 0] but at the beginning of the second time step, the dimension of magSf changes to [0 1 0 0 0 0 0] and then the simulation stops (this is in the log I provided just above and I put a part of the log in my previous message).
As I said, when I do not include the preCICE library in my solid solver, everything runs smoothly.

Hey @Makis , what’s your opinion on this ?
As a recall, I modified the openfoam-adapter based on the pull request of @JSeuffert so it can read Forces and write Displacements, and I modified the solid solver so it can export the displacements (field uN) and read the forces (by the use of the tractionTraction and tractionLinearMomentum boundary conditions).

@dashqua Indeed, very strange that the dimensions change. Do you manipulate Sf or magSf in your code and if yes, how? A link would help.

Could you try the following (separately) to see if they affect the problem?

  1. Switch from implicit to explicit coupling. This would switch off checkpointing.

  2. Disable the evaluateBoundaries (we actually removed it in https://github.com/precice/openfoam-adapter/pull/110)

  3. Enable/disable the reading of data.

It definitely has nothing to do with the preCICE library, but I could imagine that we have a bug in the adapter.

Could you also try printing these dimensions in the unmodified adapter?

1 Like

Hey @Makis,
I have been able to run a simulation yestrday just by switching from an implicit to an explicit coupling ! I have not checked yet what is this checkpointing yet but this was the problem for sure.

Now the case is run and both solvers are executed in a serial-explicit fashion. However, the “flap” interface does not move for both solvers; The displacements (uN) are null for the solid solver for every time step:

/--------------------------------- C++ -----------------------------------
========= |
\ / F ield | OpenFOAM: The Open Source CFD Toolbox
\ / O peration | Website: https://openfoam.org
\ / A nd | Version: 6
\/ M anipulation |
*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class pointVectorField;
location “4.5”;
object uN;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions [0 1 0 0 0 0 0];

internalField uniform (0 0 0);

boundaryField
{
clamp
{
type fixedValue;
value uniform (0 0 0);
}
wetsurface
{
type fixedValue;
value uniform (0 0 0);
}
}

// ************************************************************************* //

and the pointDisplacement for the fluid solver is also null for every time step:

/--------------------------------- C++ -----------------------------------
========= |
\ / F ield | OpenFOAM: The Open Source CFD Toolbox
\ / O peration | Website: https://openfoam.org
\ / A nd | Version: 6
\/ M anipulation |
*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class pointVectorField;
location “4.5”;
object pointDisplacement;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions [0 1 0 0 0 0 0];

internalField uniform (0 0 0);

boundaryField
{
front
{
type empty;
}
back
{
type empty;
}
inlet
{
type fixedValue;
value uniform (0 0 0);
}
outlet
{
type fixedValue;
value uniform (0 0 0);
}
top
{
type slip;
}
bottom
{
type slip;
}
flap
{
type fixedValue;
value uniform (0 0 0);
}
cylinder
{
type fixedValue;
value uniform (0 0 0);
}
}

// ************************************************************************* //

Also, I have not uploaded the log because it is very long, feel free to ask for it if you need it. I have not touched to evaluateBoundaries yet and I have not disabled/enabled the reading of data because it looks like it is going in the right direction at the moment.

So, I thought the Reynold’s number what not adapted for the flap to start moving so I tried different inlet velocity values for the fluid. The obtained flow looks coherent with a fixed-domain simulation. That is why I think the adapter is only reading but not writing the new values at the boundaries.

EDIT: I have uploaded a gif animation of the simulation here.
This is a screenshot of paraview where the white solid colored object is the structure and the surrounding is the fluid domain. The colouring is the magnitude of U which has only a non-null horizontal component (left to right). Also, I would say Re=20. The domain is “warped” using pointDisplacement for the fluid domain and uN for the solid domain.
I thought I might have done something wrong with paraview but as I said, I checked and the values of these two fields are zero everywhere.
Also, I have different time steps for the two solvers and even if it should not be a problem during runtime with preCICE, the visualisation on paraview will be tricky.

I have been able to run a simulation yestrday just by switching from an implicit to an explicit coupling !

So, this means that something is wrong while reading a checkpoint. I assume that in the explicit coupling the dimensions of Sf and magSf don’t change, right?

I have not checked yet what is this checkpointing yet but this was the problem for sure.

Implicit coupling means that every coupling window is executed for multiple iterations, until the Fluid and the Solid part converge. In every new iteration, the two solvers are reset to the state after the previous time window (checkpoint), including their mesh and all fields. Implicit coupling is especially important in strongly-coupled problems (i.e. light structures) and you probably will not be able to go too far with explicit coupling, so we should find out what is going wrong.

However, the “flap” interface does not move for both solvers; The displacements ( uN ) are null for the solid solver for every time step:

You can export the preCICE meshes to VTK to find out if the problem is in the writing or in the reading.

Actually, could you please repeat what you are writing and what you are reading on each side? You can also use the config visualizer to create a graph of your setup, that would be useful. Are you still exchanging forces and velocities, or have you moved to something else? (the discussion has been quite long, please excuse my confusion)

So, this means that something is wrong while reading a checkpoint. I assume that in the explicit coupling the dimensions of Sf and magSf don’t change, right?

Indeed, no error is shown and the dimensions remain unchanged along the log file.

Implicit coupling is especially important in strongly-coupled problems (i.e. light structures) and you probably will not be able to go too far with explicit coupling, so we should find out what is going wrong.

I agree, but I would like to have a working case to start from.

You can export the preCICE meshes to VTK to find out if the problem is in the writing or in the reading.

I exported precice VTKs and imported the VTK groups in paraview but for now, it keeps loading and does not show anything. No matter if I want to use Glyphs or the Delaunay filter, the data does not even seem to load (the loading bar on the bottom right is showed empty - I tried with Paraview 5.4.1 linux version and windows version).

Actually, could you please repeat what you are writing and what you are reading on each side? You can also use the config visualizer to create a graph of your setup, that would be useful. Are you still exchanging forces and velocities, or have you moved to something else? (the discussion has been quite long, please excuse my confusion)

Sure no problem ! Here is the config visualizer:

digraph G {
compound=True;
layout=dot;
overlap=scale;
rankdir=LR;
splines=true;
subgraph cluster_m2n {
label=Communicators;
"m2n-Solid-Fluid" [label=sockets, shape=component];
}

subgraph cluster_cpl {
label="Coupling Schemes";
"cpl-Fluid-Solid" [label="serial-explicit", shape=component];
}

subgraph cluster_Fluid {
label=Fluid;
style=bold;
Fluid [color=black, shape=doubleoctagon];
"Fluid-Fluid-Mesh-Centers" [color=black, label="Fluid-Mesh-Centers", shape=cylinder];
"Fluid-Fluid-Mesh-Nodes" [color=black, label="Fluid-Mesh-Nodes", shape=cylinder];
"Fluid-Solid-Mesh-Nodes" [color=black, label="Solid-Mesh-Nodes\nfrom Solid", shape=cylinder, style=dashed];
"Fluid-Solid-Mesh-Faces" [color=black, label="Solid-Mesh-Faces\nfrom Solid", shape=cylinder, style=dashed];
"Fluid-Fluid-Mesh-Nodes" -> Fluid  [color=black, label=Displacement, tooltip=vector];
Fluid -> "Fluid-Fluid-Mesh-Centers"  [color=black, label=Force, tooltip=vector];
"Fluid-Fluid-Mesh-Centers" -> "Fluid-Solid-Mesh-Faces"  [label="rbf-thin-plate-splines"];
"Fluid-Solid-Mesh-Nodes" -> "Fluid-Fluid-Mesh-Nodes"  [label="rbf-thin-plate-splines"];
}

subgraph cluster_Solid {
label=Solid;
style=bold;
Solid [color=black, shape=doubleoctagon];
"Solid-Solid-Mesh-Nodes" [color=black, label="Solid-Mesh-Nodes", shape=cylinder];
"Solid-Solid-Mesh-Faces" [color=black, label="Solid-Mesh-Faces", shape=cylinder];
"Solid-Solid-Mesh-Faces" -> Solid  [color=black, label=Force, tooltip=vector];
Solid -> "Solid-Solid-Mesh-Nodes"  [color=black, label=Displacement, tooltip=vector];
}

"m2n-Solid-Fluid" -> Solid  [color=black, dir=both, lhead=cluster_Solid];
"m2n-Solid-Fluid" -> Fluid  [color=black, dir=both, lhead=cluster_Fluid];
"cpl-Fluid-Solid" -> Fluid  [color=black, lhead=cluster_Fluid, taillabel=first];
"cpl-Fluid-Solid" -> Solid  [color=black, lhead=cluster_Solid, taillabel=second];
"Fluid-Solid-Mesh-Faces" -> "Solid-Solid-Mesh-Faces"  [color=black, label=Force, tooltip=vector];
"Solid-Solid-Mesh-Nodes" -> "Fluid-Solid-Mesh-Nodes"  [color=black, label=Displacement, tooltip=vector];
}

and here is the config file :

<?xml version="1.0"?>

<precice-configuration>

    <log>
        <sink filter="%Severity% > debug and %Rank% = 0" format="---[precice] %ColorizedSeverity% %Message%" enabled="true"/>
    </log>

    <solver-interface dimensions="3">

    <data:vector name="Force"/>
    <data:vector name="Displacement"/>

    <mesh name="Fluid-Mesh-Centers">
        <use-data name="Force"/>
   </mesh>
    <mesh name="Fluid-Mesh-Nodes">
        <use-data name="Displacement"/>
    </mesh>

    <mesh name="Solid-Mesh-Nodes">
        <use-data name="Displacement"/>
    </mesh>
    <mesh name="Solid-Mesh-Faces">
        <use-data name="Force"/>
    </mesh>

    <participant name="Fluid">
        <use-mesh name="Fluid-Mesh-Centers" provide="yes"/>
        <use-mesh name="Fluid-Mesh-Nodes" provide="yes"/>
        <use-mesh name="Solid-Mesh-Nodes" from="Solid"/>
        <use-mesh name="Solid-Mesh-Faces" from="Solid"/>
        <read-data name="Displacement" mesh="Fluid-Mesh-Nodes"/>
        <write-data name="Force" mesh="Fluid-Mesh-Centers"/>
        <export:vtk directory="preCICE-output-Fluid"/>
        <mapping:rbf-thin-plate-splines direction="write" from="Fluid-Mesh-Centers" to="Solid-Mesh-Faces" constraint="conservative" z-dead="true"/>
        <mapping:rbf-thin-plate-splines direction="read" from="Solid-Mesh-Nodes" to="Fluid-Mesh-Nodes" constraint="consistent"/>
    </participant>

    <participant name="Solid">
        <use-mesh name="Solid-Mesh-Nodes" provide="yes"/>
        <use-mesh name="Solid-Mesh-Faces" provide="yes"/>
        <read-data name="Force"  mesh="Solid-Mesh-Faces"/>
        <write-data name="Displacement" mesh="Solid-Mesh-Nodes"/>
        <!--watch-point mesh="Solid-Mesh-Nodes" name="flap_tip" coordinate="0.6;0.2;0." /-->
    </participant>

    <m2n:sockets from="Fluid" to="Solid"/>

    <coupling-scheme:serial-explicit>
      <participants first="Fluid" second="Solid"/>
      <max-time value="10"/>
      <time-window-size value="0.005"/>
      <exchange data="Force" mesh="Solid-Mesh-Faces" from="Fluid" to="Solid"/>
      <exchange data="Displacement" mesh="Solid-Mesh-Nodes" from="Solid" to="Fluid" initialize="0"/>
    </coupling-scheme:serial-explicit>
    
    <!--coupling-scheme:serial-implicit>
        <time-window-size value="0.005"/>
        <max-time value="10"/>
        <participants first="Fluid" second="Solid"/>
        <exchange data="Force" mesh="Solid-Mesh-Faces" from="Fluid" to="Solid"/>
        <exchange data="Displacement" mesh="Solid-Mesh-Nodes" from="Solid" to="Fluid" initialize="0"/>

        <max-iterations value="100"/>
        <absolute-convergence-measure limit="1e-6" data="Displacement" mesh="Solid-Mesh-Nodes"/>
        <relative-convergence-measure limit="1e-4" data="Force" mesh="Solid-Mesh-Faces"/>
        <extrapolation-order value="2"/>

        <acceleration:IQN-ILS>
            <data name="Displacement" mesh="Solid-Mesh-Nodes"/>
            <preconditioner type="residual-sum"/>
            <filter type="QR1" limit="1e-6"/>
            <initial-relaxation value="0.1"/>
            <max-used-iterations value="50"/>
            <time-windows-reused value="10"/>
        </acceleration:IQN-ILS>
    </coupling-scheme:serial-implicit/-->

    </solver-interface>

</precice-configuration>

The fluid solver is pimpleFoam and its configuration is not changed from the cylinderFlap. The solid solver is an in-house solver (code is available here) that solves in a Total Lagrangian fashion. Therefore, I have access to the pointVectorField uN that s responsible for moving the nodes and that plays the role of pointDisplacement in preCICE.

I exported precice VTKs and imported the VTK groups in paraview but for now, it keeps loading and does not show anything. No matter if I want to use Glyphs or the Delaunay filter, the data does not even seem to load (the loading bar on the bottom right is showed empty - I tried with Paraview 5.4.1 linux version and windows version).

This is very strange. Have you changed anything in the way the mesh vertices are defined? Do you write data on these meshes?

Sure no problem ! Here is the config visualizer:

You can also create an image (here: precice-config.png), using

cat precice-config.xml | precice-config-visualizer | dot -Tpng > precice-config.png


This looks correct to me (it is the same as the tutorial, isn’t it?).

The solid solver is an in-house solver (code is available here) that solves in a Total Lagrangian fashion. Therefore, I have access to the pointVectorField uN that s responsible for moving the nodes and that plays the role of pointDisplacement in preCICE.

I could imagine that this solver works quite differently than “normal” Eulerian OpenFOAM solvers. @JSeuffert any experience on this?

@dashqua This is the part of the code that is responsible to storing and reloading checkpoints:

I cannot imagine how we could change the dimensions of Sf and magSf here. Any ideas? (and again, could you please check if they also change on the Fluid side?)

This is very strange. Have you changed anything in the way the mesh vertices are defined? Do you write data on these meshes?

No I have not changed such thing, that’s why I’m very surprised by the issue… However mesh motion is handled differently in the two solvers: In a Fluid timestep directory there is pointDisplacement cellDisplacement, and polyMesh/points. In a Solid timestep directory there is uN (i.e. pointDisplacement).

You can also create an image (here: precice-config.png)

Here is mine:


(oops you had already done it)

I cannot imagine how we could change the dimensions of Sf and magSf here. Any ideas? (and again, could you please check if they also change on the Fluid side?)

I reran the Fluid with the functionObject

codeExecute
#{
        const surfaceScalarField& magSf_ = mesh().magSf();
        const surfaceVectorField& Sf_ = mesh().Sf();
        Info << ">> dim magSf: " << magSf_.dimensions() << "\n";
        Info << ">> dim Sf: " << Sf_.dimensions() << "\n";
#};

and for every timestep I obtain

>> dim magSf: [0 2 0 0 0 0 0]
>> dim Sf: [0 2 0 0 0 0 0]
Courant Number mean: 7.007798467 max: 53.60082201
Time = 0.01

which is what we should expect.
I am considering having a new run of simulation from the pull request of @JSeuffert, but there should not be any difference because I reviewed all of his modifications and rewrote them in my local openfoam-adapter.

I have simplified a bit the config file :

<log>
    <sink filter="%Severity% > debug and %Rank% = 0" format="---[precice] %ColorizedSeverity% %Message%" enabled="true"/>
</log>

<solver-interface dimensions="3">

<data:vector name="Force"/>
<data:vector name="Displacement"/>

<mesh name="Fluid-Mesh-Centers">
    <use-data name="Force"/>
</mesh>
<mesh name="Fluid-Mesh-Nodes">
    <use-data name="Displacement"/>
</mesh>

<mesh name="Solid-Mesh-Nodes">
    <use-data name="Displacement"/>
</mesh>
<mesh name="Solid-Mesh-Faces">
    <use-data name="Force"/>
</mesh>

<participant name="Fluid">
    <use-mesh name="Fluid-Mesh-Centers" provide="yes"/>
    <use-mesh name="Fluid-Mesh-Nodes" provide="yes"/>
    <use-mesh name="Solid-Mesh-Nodes" from="Solid"/>
    <use-mesh name="Solid-Mesh-Faces" from="Solid"/>
    <read-data name="Displacement" mesh="Fluid-Mesh-Nodes"/>
    <write-data name="Force" mesh="Fluid-Mesh-Centers"/>
    <export:vtk directory="preCICE-output-Fluid"/>
    <mapping:nearest-neighbor direction="write" from="Fluid-Mesh-Centers" to="Solid-Mesh-Faces" constraint="conservative"/>
    <mapping:nearest-neighbor direction="read" from="Solid-Mesh-Nodes" to="Fluid-Mesh-Nodes" constraint="consistent"/>
</participant>

<participant name="Solid">
    <use-mesh name="Solid-Mesh-Nodes" provide="yes"/>
    <use-mesh name="Solid-Mesh-Faces" provide="yes"/>
    <read-data name="Force"  mesh="Solid-Mesh-Faces"/>
    <write-data name="Displacement" mesh="Solid-Mesh-Nodes"/>
    <!--watch-point mesh="Solid-Mesh-Nodes" name="flap_tip" coordinate="0.6;0.2;0." /-->
</participant>

<m2n:sockets from="Fluid" to="Solid"/>

<coupling-scheme:serial-explicit>
  <participants first="Fluid" second="Solid"/>
  <max-time value="5"/>
  <time-window-size value="0.005"/>
  <exchange data="Force" mesh="Solid-Mesh-Faces" from="Fluid" to="Solid"/>
  <exchange data="Displacement" mesh="Solid-Mesh-Nodes" from="Solid" to="Fluid" initialize="0"/>
</coupling-scheme:serial-explicit>

</solver-interface>

I think that data not being written might be related to the fact that I use 4 “meshes” and also 2 “interfaces” per solver.

Here is Solid/system/preciceDict:

FoamFile
{
version 2.0;
format ascii;
class dictionary;
location “system”;
object preciceDict;
}

preciceConfig “precice-config.xml”;

participant Solid;

modules (FSI);

interfaces
{
Interface1
{
mesh Solid-Mesh-Faces; // Centers;
patches (wetsurface);
locations faceCenters;

readData
(
    Force
);

writeData
(

);

};

Interface2
{
mesh Solid-Mesh-Nodes;
patches (wetsurface);
locations faceNodes;

readData
(

);

writeData
(
    Displacement
);

};
};

FSI
{
//rho rho [1 -3 0 0 0 0 0] 1000;
solverType structure;
namePointDisplacement uN;

and here is Fluid/system/preciceDict

FoamFile
{
version 2.0;
format ascii;
class dictionary;
location “system”;
object preciceDict;
}

preciceConfig “precice-config.xml”;

participant Fluid;

modules (FSI);

interfaces
{
Interface1
{
mesh Fluid-Mesh-Centers;
patches (flap);
locations faceCenters;

readData
(
);

writeData
(
  Force
);

};

Interface2
{
mesh Fluid-Mesh-Nodes;
patches (flap);
locations faceNodes;

readData
(
  Displacement
);

writeData
(
);

};
};

FSI
{
rho rho [1 -3 0 0 0 0 0] 1000;
}

Actually, the data is written but it looks like it is not being modified. For example, here is pointDisplacment in Fluid/0 :

FoamFile
{
version 2.0;
format ascii;
class pointVectorField;
object pointDisplacement;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions [0 1 0 0 0 0 0];

internalField uniform (0 0 0);

boundaryField
{
inlet
{
type fixedValue;
value uniform (0 0 0);
}

outlet
{
    type            fixedValue;
    value           uniform (0 0 0);
}

cylinder
{
    type            fixedValue;
    value           $internalField;
}
flap
{
    type            fixedValue;
    value           $internalField;
}

top
{
    type            slip;
}

bottom
{
    type            slip;
}
front
{
    type            empty;
}
back
{
    type            empty;
}

}

// ************************************************************************* //

and here is pointDisplacement in Fluid/2.2 (and all the other timestep directories) :

/--------------------------------- C++ -----------------------------------
========= |
\ / F ield | OpenFOAM: The Open Source CFD Toolbox
\ / O peration | Website: https://openfoam.org
\ / A nd | Version: 6
\/ M anipulation |
*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class pointVectorField;
location “2.2”;
object pointDisplacement;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions [0 1 0 0 0 0 0];

internalField uniform (0 0 0);

boundaryField
{
front
{
type empty;
}
back
{
type empty;
}
inlet
{
type fixedValue;
value uniform (0 0 0);
}
outlet
{
type fixedValue;
value uniform (0 0 0);
}
top
{
type slip;
}
bottom
{
type slip;
}
flap
{
type fixedValue;
value uniform (0 0 0);
}
cylinder
{
type fixedValue;
value uniform (0 0 0);
}
}

// ************************************************************************* //

@dashqua how is your current state? Are you observing that pointDisplacement is not overwritten or has there been any news?

Hi @Makis ,
To be honest I left this issue to focus on something else.

Actually, I reinstalled the whole preCICE machinery yesterday. I will start fresh with the newest precice (2.0.2).

Two quick things:

  1. I chose to change my test case from the cylinder flap to the flap_perp one. Indeed, as I am using two OpenFOAM solvers, I had to recreate the mesh for the solid part and I think flap_perp has an even easier domain to work with.
    However, preCICE and the OF and dealii adapters have been updated since then. It has no apparent issue with the OF-adapter but I seem to have an issue with the dealii_adapter: with both pseudo-2D and 2D cases, the cellDisplacement and pointDisplacement remain null and so the perpendicular flap does not move. Communication between the two solvers looks OK (no error message in the log). I think it is because I am using the linear_elasticity solver from dealii-adapter. I have no choice since the nonlinear_elasticity won’t compile. I attached the end of the Fluid and Solid logs, as well as the log when making the nonlinear solver.
    Solid.log (37.1 KB) nonlinear_elasticity_make.log (3.8 KB) Fluid.log (45.5 KB)
    Note: this happens whether I specify -DDIM=3 or not.

  2. I will therefore modify the perp_flap case to use my OpenFOAM solid solver instead of dealii. So far, we mentionned 2 mandatory modifications for the simulation to work:

  • To include boundary conditions in the OpenFOAM solid solver (let’s call it by its name: solidFOAM) to properly communicate with preCICE
  • To modify/improve the OpenFOAM adapter so it takes into account the Displacements vector from OpenFOAM.

Concerning the first point, I will re-check @JSeuffert’s implementation. I have already studied it, implemented it in the code and compiled it, and I have not found any problem in the code but we can still discuss about it.
Concerning the second point, I managed to create a boundary condition for a traction-based problem, where the traction is read from a distant source (see one of my post above). Here is the part of the code (to give you an idea):

else if (loadingType_ == "FSI")
{
  Info << "Applying 'FSI' Boundary Conditions" << nl;
  const volVectorField& Forces = db().lookupObject<volVectorField>("Forces");
  const fvMesh& mesh = Forces.mesh();
  // hardcoding at the moment
  forAll( mesh.boundary(), patch) // loop over patches
  {
    const word& patchName = mesh.boundary()[patch].name();
    // find the patch is wetsurface
    if ( patchName == "wetsurface" )
    {
        forAll( mesh.boundary()[patch], facei) // loop over faces
        {
          t_C[facei] = Forces.boundaryField()[patch][facei] ;
        }
    }
  }

I will let you know as soon as I have new results.

This looks like exactly this issue. It would be helpful to document your dependency versions there. But ingore my parenthesis, let’s keep this thread about coupling with your OpenFOAM solid solver.

I understand from your config (and please forgive me if I am forgetting/mixing up cases) that you are not using the adapter to couple your solidFOAM, as I don’t see any adapter output. However, you are using a Solid/system/preciceDict and are defining there that namePointDisplacement uN;.

I can only think in the following directions now:

  • There is a mix-up with the names uN and pointDisplacement, i.e. not writing to the correct field.
  • You are writing values to a copy of a field instead of a reference.

Hello @Makis,
This thread had been up for many time so it can be easily confusing for the both of us !

You are right, let us focus on the coupling. I wanted to run a tutorial case with the brand new installation before going back to my OF-OF coupling code.

The 34th post and those before are about my OF-OF coupling. Both Solid and Fluid folders have an OpenFOAM-like structure because the fluid motion is solved by pimpleFoam and the solid motion is solved by solidFoam.

On the other hand, this post and the last one are about this tutorial case, namely “flap_perp” that is available in precice’s tutorials. I want to perform correctly this simulation to be sure everything is fine before going back to my OF-OF code. It should not take long.
I successfully compiled the OF-adapter that we mentionned in this post. Then I followed the instructions on this page and successfully compiled the linear solver of the dealii-adapter. Unfortunately it is not working for the nonlinear solver. This is what I get:

$ cmake -DDEAL_II_DIR=../../dealii/build .
-- Build type: Release
-- Autopilot invoked
-- Run   $ make info  to print a detailed help message
-- Configuring done
-- Generating done
-- Build files have been written to: /home/tdg/OpenFOAM/precice/dealii-adapter/nonlinear_elasticity

and

$ make -j10
[ 50%] Building CXX object CMakeFiles/nonlinear_elasticity.dir/nonlinear_elasticity.cc.o
/home/tdg/OpenFOAM/precice/dealii-adapter/nonlinear_elasticity/nonlinear_elasticity.cc: In member function ‘void Nonlinear_Elasticity::Solid<dim, NumberType>::system_setup()’:
/home/tdg/OpenFOAM/precice/dealii-adapter/nonlinear_elasticity/nonlinear_elasticity.cc:624:34: error: missing template arguments before ‘(’ token
state_variables = std::vector({&total_displacement,
^
/home/tdg/OpenFOAM/precice/dealii-adapter/nonlinear_elasticity/nonlinear_elasticity.cc: In member function ‘void Nonlinear_Elasticity::Solid<dim, NumberType>::make_constraints(const int&)’:
/home/tdg/OpenFOAM/precice/dealii-adapter/nonlinear_elasticity/nonlinear_elasticity.cc:1359:50: error: ‘ZeroFunction’ was not declared in this scope
ZeroFunction(
^~~~~~~~~~~~
/home/tdg/OpenFOAM/precice/dealii-adapter/nonlinear_elasticity/nonlinear_elasticity.cc:1359:50: note: suggested alternative:
In file included from /home/tdg/OpenFOAM/precice/dealii-adapter/nonlinear_elasticity/nonlinear_elasticity.cc:1:
/mnt/datasim/OpenFOAM/precice/dealii/include/deal.II/base/function.h:510:9: note: ‘dealii::Functions::ZeroFunction’
class ZeroFunction : public ConstantFunction<dim, RangeNumberType>
^~~~~~~~~~~~
/home/tdg/OpenFOAM/precice/dealii-adapter/nonlinear_elasticity/nonlinear_elasticity.cc:1366:50: error: ‘ZeroFunction’ was not declared in this scope
ZeroFunction(
^~~~~~~~~~~~
/home/tdg/OpenFOAM/precice/dealii-adapter/nonlinear_elasticity/nonlinear_elasticity.cc:1366:50: note: suggested alternative:
In file included from /home/tdg/OpenFOAM/precice/dealii-adapter/nonlinear_elasticity/nonlinear_elasticity.cc:1:
/mnt/datasim/OpenFOAM/precice/dealii/include/deal.II/base/function.h:510:9: note: ‘dealii::Functions::ZeroFunction’
class ZeroFunction : public ConstantFunction<dim, RangeNumberType>
^~~~~~~~~~~~
/home/tdg/OpenFOAM/precice/dealii-adapter/nonlinear_elasticity/nonlinear_elasticity.cc:1383:13: error: ‘ZeroFunction’ was not declared in this scope
ZeroFunction(n_components),
^~~~~~~~~~~~
/home/tdg/OpenFOAM/precice/dealii-adapter/nonlinear_elasticity/nonlinear_elasticity.cc:1383:13: note: suggested alternative:
In file included from /home/tdg/OpenFOAM/precice/dealii-adapter/nonlinear_elasticity/nonlinear_elasticity.cc:1:
/mnt/datasim/OpenFOAM/precice/dealii/include/deal.II/base/function.h:510:9: note: ‘dealii::Functions::ZeroFunction’
class ZeroFunction : public ConstantFunction<dim, RangeNumberType>
^~~~~~~~~~~~
/home/tdg/OpenFOAM/precice/dealii-adapter/nonlinear_elasticity/nonlinear_elasticity.cc:1390:13: error: ‘ZeroFunction’ was not declared in this scope
ZeroFunction(n_components),
^~~~~~~~~~~~
/home/tdg/OpenFOAM/precice/dealii-adapter/nonlinear_elasticity/nonlinear_elasticity.cc:1390:13: note: suggested alternative:
In file included from /home/tdg/OpenFOAM/precice/dealii-adapter/nonlinear_elasticity/nonlinear_elasticity.cc:1:
/mnt/datasim/OpenFOAM/precice/dealii/include/deal.II/base/function.h:510:9: note: ‘dealii::Functions::ZeroFunction’
class ZeroFunction : public ConstantFunction<dim, RangeNumberType>
^~~~~~~~~~~~
make[2]: *** [CMakeFiles/nonlinear_elasticity.dir/build.make:63: CMakeFiles/nonlinear_elasticity.dir/nonlinear_elasticity.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:201: CMakeFiles/nonlinear_elasticity.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

At the present moment, I don’t understand this error.

Meanwhile I also merged the pull request of @JSeuffert so once this little issue with the OF-adapter is gone, I can rework on my code. I have one remark about this: When I first studied and integrated the change of @JSeuffert, I noticed the Make/files and several other headers (Adapter.H I do believe) were including volDisplacement.H and volDisplacementDelta.H which were not present in the last commits. I remember I had to manually add them by browsing the list of commits. It looks these two files have been removed from the list of files “to watch” when comitting. All of this to say that I had the same issue after directly merging the pull request: The two files are not there and the compiler complains.
wmake_of_OF-adapter.log (4.7 KB)

EDIT: Your last remark about the reference/copy of a field seems likely to be what is happening; Once the other things are sorted, I will take a long into this.

Just as a side remark (I haven’t followed the whole discussion, but the preCICE bot mentioned): The nonlinear solver should compile now with the current develop branch of the dealii-adapter.
In order to run successfully tutorials with the deal.II codes, your OpenFOAM adapter needs support Stress data. Depending on your OF version/adapter version, it might be necessary to merge the master branch into your version branch, have a look at git log. Everything else should work from the deal.II side.

I know that coupled problems can be quite complicated and it helps to know the history of each case, but this we can still keep track by refering to related topics with a link. Let’s please try to keep independent problems in different topics in the future. :slight_smile:

I keep this as the summary and I am excited to read any news!