How to transfer Pressure instead of Force in FSI?

Hi all,
I tried to enable both FSI and FF modules in preciceDict to transfer Pressure instead of Force to the solid solver by using the following format:

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

preciceConfig "../precice-config.xml";

participant Fluid;

modules (FSI FF);

interfaces
{
  Interface1
  {
    mesh              Fluid-Mesh;
    patches           (caisson);
    locations         faceCenters;
    
    readData
    (
      Displacement
    );
    
    writeData
    (
      Pressure
    );
  };
};

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

However, while running the fluid solver, an error happened:

Starting time loop

---[preciceAdapter] Loaded the OpenFOAM-preCICE adapter v1.0.0.
---[preciceAdapter] Reading preciceDict...
---[precice] e[36mWARNING: e[0m Setting the z-axis to dead on a 2-dimensional problem has no effect. Please remove the respective mapping's "z-dead" attribute.
---[precice] e[0m This is preCICE version 2.2.1
---[precice] e[0m Revision info: v2.2.1
---[precice] e[0m Configuration: Release (Debug and Trace log unavailable)
---[precice] e[0m Configuring preCICE with configuration "../precice-config.xml"
---[precice] e[0m I am participant "Fluid"
--> FOAM Warning : 
    From function void adapterInfo(std::string, std::string)
    in file Utilities.C at line 50
    e[31mError (deferred - will exit later) in the preCICE adapter: e[0m
e[31mError in the preCICE adapter: e[0m
Unknown data type - cannot add Displacement.


Courant Number mean: 0 max: 0
Interface Courant Number mean: 0 max: 0
--> FOAM Warning : 
    From function void adapterInfo(std::string, std::string)
    in file Utilities.C at line 17
[0]PETSC ERROR: ------------------------------------------------------------------------
[0]PETSC ERROR: Caught signal number 8 FPE: Floating Point Exception,probably divide by zero
[0]PETSC ERROR: Try option -start_in_debugger or -on_error_attach_debugger
[0]PETSC ERROR: or see https://www.mcs.anl.gov/petsc/documentation/faq.html#valgrind
[0]PETSC ERROR: or try http://valgrind.org on GNU/linux and Apple Mac OS X to find memory corruption errors
[0]PETSC ERROR: configure using --with-debugging=yes, recompile, link, and run 
[0]PETSC ERROR: to get more information on the crash.
[0]PETSC ERROR: User provided function() line 0 in  unknown file  
[zhou-ThinkCentre-E75:18715] [[2164,0],0] ORTE_ERROR_LOG: Data unpack would read past end of buffer in file util/show_help.c at line 501

### NOTE ### Make sure to use the correct solver for your OpenFOAM version! (pimpleFoam for OpenFOAM v1806, OpenFOAM 6, or newer, vs pimpleDyMFoam for older) You may change this in your Fluid/system/controlDict file, if needed.

It seems that FF module is not activated. Is there any method to transfer Pressure to the solid solver?precice-config.xml (1.7 KB)

Hi Stan,

assuming you still want to simulate FSI simulations, you don’t (must not) enable the FF module, enabling the FSI module is completely sufficient. The consistently mapped pressure forces, which include the viscous shear forces in addition to the pure pressure values, is called Stress data in the FSI module. Therefore, you need to choose this keyword for writing data.

Hi David,
Thank you for the suggestion! I had a try with a 2D case and found that the magnitude of Stress on the interface is equal to p. However, it is still a vector. Could you please show me where I can modify the function to only output the magnitude of Stress instead of a stress vector?

Besides, I output the readData (i.e. Stress) during the simulation and I found that the values are not as same as values in Stress files in every time step folder.
Taking the result at 7.8s as an example, the output in the terminal is shown as follows:


The pressure of all cells are in the Stress file:
Stress.txt (7.5 KB)
Since the water depth from the water surface to the bottom of the rectangular is two meters, the values in Stress file are consistent with the actual situation.

However, the output of readData is far from reality. How could this happen?

Yes it is a vector because the shear stress originating from the velocity is actually a tensor and we transfer the vector in normal direction. The pressure is IIRC scaled by the face area normal vector as well.
If you want to have a magnitude - this is not implemented, but fairly easy to do, have a look at these LOCs: https://github.com/precice/openfoam-adapter/blob/0c368d717bc5ec0fbd0aa4925c48a8164487fc3f/FSI/ForceBase.C#L184-L189

Hm I see some smaller and some larger values, which looks ok to me, hard to say if this is correct or I don’t understand this completely. May I ask you to check if you observe this inconsistency you mean here also in the very last coupling time window?

Thank you for your explanation. So the treatment for the pressure is originate from the shear stress tensor and the purpose to do so is to derive the force vector, right?

I am not familiar with c++ but I guess I just need to change the highlighted codes to:

 forAll(volScalarField::Boundary& pb(tp().boundaryField())[patchID], i)
        {
                buffer[i] = forceField.boundaryField()[patchID][i];
        }

Recompile the openfoam-adapter and then, change the readData from Stress to Force. Thus, the magnitude of Stress, namely p is obtained, right?

Of course. I checked the log and found the inconsistency existed persistently in the simulation.

Not entirely; one contribution originates from the pressure itself, one contribution originates from the shear stress.

No this won’t work since you assign now and vector to a scalar. You would need to implement a norm in order to obtain the magnitude.

Stress would be still the right keyword (although the naming of the variable is a bit confusing if you are not familiar with the code. If you really only want to have the pressure as a scalar quantity -without shear stress- maybe the simplest way would be to copy the Pressure.H and Pressure.C from the FF module into the FSI module. Afterwards, add the files in the Make/files file, change the namespace from FF to FSI and include them in the FSI.H file. Then you can recompile and use Pressure as a keyword, which gives you scalar pressure values.

Do you use any acceleration of your data or still the explicit coupling scheme?

Yes, this is what I was trying to say. What I wanted to describe is the following figure (originate from one thesis related to preCICE). There must be something wrong in my statement which leads to the misunderstanding.
微信图片_20210820091831
After doing the modification which you suggested and recompiling the openfoam-adapter, the simulation is able to run but all the pressure output is 0 and there is no Pressure file in timestep folders.


I guess I need to add Pressure in the function preciceAdapter::FSI::FluidStructureInteraction::addWriters. However, after adding this into FSI.C and recompiling the openfoam-adapter, when running the fluid part, an error occurred:

FOAM Warning:
From function void adapterInfo(std::string, std::string)
in file Utilities.C at line 50
Error (deferred - will exit later) in the preCICE adapter:

request for volScalarField compressible from objectRegistry region0 failed available objects of type volScalarField are

20
(
interfaceProperties:K
KCPorfield
alpha.water
rho
rAU
p_rgh
aPorField
nu
gh
porosityIindex
nu1
p
rho_0
nu2
bPorField
alpha.air
porosity
D50Field
useTrans
cPorField
)

The compilation log and the modified files are as follows.
RelatedFiles.zip (6.1 KB)

Ok, so again in order to make this clear: Stress data = the formula above = vector valued data, which is not equal to Pressure data = scalar data, where the \tau_{ij} is not included. If you are still looking for an implementation of the above formula; the Stressdata field includes this already.

Regarding your original question: OpenFOAM calls the pressure field and data just p, which exists as you can see. However, the constructor of the Pressure field you want to add takes the name (again, p by default) as an argument

preciceAdapter::FSI::Pressure::Pressure(
    const Foam::fvMesh& mesh,
    const std::string nameP)

whereas you pass in the solver type

        interface->addCouplingDataWriter(
            dataName,
            new Stress(mesh_, solverType_) /* TODO: Add any other arguments here */
        );

Have a look at these lines for a similar example openfoam-adapter/FSI.C at 0c368d717bc5ec0fbd0aa4925c48a8164487fc3f · precice/openfoam-adapter · GitHub

Yes, it’s clear now. Thanks for the explanation again.

I see, the Pressure in both preciceDict and precice-config.xml refers to the p rather than a new variable “Pressure”. I reckon that the “Pressure” will be written as a new variable like “Force” and “Stress” which only contains values on the interface boundary in those timestep folders at first.
Thus, apart from the modifications you mentioned before, there is no need to add Pressure in the function addWriters, right?

I’m sorry that I forget to reply to this question. Since at present, the solid part is only a simple displacement generator rather than our FEM solver, I didn’t use any acceleration and still used the explicit coupling scheme. So I still wonder why the readData output are all 0.

If so, I’ll try to modify my solid solver to verify whether the pressure is read correctly.

It is still needed for the adapter in order to enable the read and write access.

Hi David,
I’ve added nameP_ in both preciceAdapter::FSI::FluidStructureInteraction::readConfig and FSI.H. The argument Pressure has been added into addWriters and addReaders. After recompiling the openfoam-adapter, an error occurs:

After checking all the modified files, I suddenly realize that I forgot to change the type of data in precice-config.xml from vector to scalar. After changing data:vector name="Pressure" to "data:scalar name="Pressure", the OpenFOAM adapter works fine.
Thanks again for you help!
ModifiedFiles.zip (3.8 KB)

2 Likes

Alright, please mark the resolving answer as solution so that DIscourse closes this thread.

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