FSI: OpenFOAM adapter with interFOAM

bitronteofil · March 18, 2020, 6:07pm

I tried a simple FSI example very similar to the dam-break, but with a flexible obstacle. I’m using preCICE 2.0.

Unfortunatelly an error message occur, but the log file didn’t exist.

I used the same structure of the flap behind the cylinder and the setting sems ok.

Below the error:

--> FOAM FATAL ERROR: 
Error in the preCICE adapter:
There was a problem while configuring the adapter. See the log for details.

    From function void adapterInfo(std::__cxx11::string, std::__cxx11::string)
    in file Utilities.C at line 32.

FOAM exiting

Do I have to modify something? The file pressure in a interFOAM analysis is wrote in a file called p_rgh, is it reachable by preCICE in order to exchange load with CalculiX?

DavidSCN · March 19, 2020, 10:04am

Hi @bitronteofil

which OpenFOAM version and which adapter version do you currently use?
How do you start your simulation? Do you use one of the shell scripts?
Can you generate a log file, so that we can see better, where things go wrong?

A compressible calculation should be no problem for the adapter.

bitronteofil · March 19, 2020, 11:13am

I’m using OF 1906 and CalculiX v 2.15.

The precice library is: libprecice.so.2.0.0
and I call for it in controlDict with the command:

functions
{
    preCICE_Adapter
    {
        type preciceAdapterFunctionObject;
        libs ("libpreciceAdapterFunctionObject.so");
    }
}

It is very strange, because in order to avoid mistake I used the same structure of the flap behind the cylinder, but the OF participant doesn’t start at all.

The error message is:

---[preciceAdapter] [DEBUG] Adding coupling data writers...
---[preciceAdapter] [DEBUG] Adding coupling data readers...
--> FOAM Warning : 
    From function void adapterInfo(std::__cxx11::string, std::__cxx11::string)
    in file Utilities.C at line 50
    Error (deferred - will exit later) in the preCICE adapter: 

    request for pointVectorField pointDisplacement from objectRegistry region0 failed
    available objects of type pointVectorField are
0()

Courant Number mean: 0 max: 0
Interface Courant Number mean: 0 max: 0
Time = 0.0005

PIMPLE: iteration 1
smoothSolver:  Solving for alpha.water, Initial residual = 0, Final residual = 0, No Iterations 0
Phase-1 volume fraction = 0.169587  Min(alpha.water) = 0  Max(alpha.water) = 1
MULES: Correcting alpha.water
MULES: Correcting alpha.water
Phase-1 volume fraction = 0.169587  Min(alpha.water) = 0  Max(alpha.water) = 1
DICPCG:  Solving for p_rgh, Initial residual = 1, Final residual = 0.0491804, No Iterations 7
time step continuity errors : sum local = 0.00014383, global = -9.10245e-09, cumulative = -9.10245e-09
DICPCG:  Solving for p_rgh, Initial residual = 0.0033825, Final residual = 0.000137417, No Iterations 22
time step continuity errors : sum local = 6.15787e-06, global = -1.58356e-06, cumulative = -1.59266e-06
DICPCG:  Solving for p_rgh, Initial residual = 0.0001798, Final residual = 9.41171e-08, No Iterations 88
time step continuity errors : sum local = 7.8403e-09, global = 1.80596e-10, cumulative = -1.59248e-06
smoothSolver:  Solving for epsilon, Initial residual = 0.0174728, Final residual = 2.46564e-08, No Iterations 3
smoothSolver:  Solving for k, Initial residual = 1, Final residual = 2.39041e-07, No Iterations 4
ExecutionTime = 0.46 s  ClockTime = 0 s



--> FOAM FATAL ERROR: 
Error in the preCICE adapter: 
There was a problem while configuring the adapter. See the log for details.


    From function void adapterInfo(std::__cxx11::string, std::__cxx11::string)
    in file Utilities.C at line 32.

FOAM exiting
---[preciceAdapter] [DEBUG] Adding coupling data writers...
---[preciceAdapter] [DEBUG] Adding coupling data readers...
--> FOAM Warning : 
    From function void adapterInfo(std::__cxx11::string, std::__cxx11::string)
    in file Utilities.C at line 50
    Error (deferred - will exit later) in the preCICE adapter: 

    request for pointVectorField pointDisplacement from objectRegistry region0 failed
    available objects of type pointVectorField are
0()

Courant Number mean: 0 max: 0
Interface Courant Number mean: 0 max: 0
Time = 0.0005

PIMPLE: iteration 1
smoothSolver:  Solving for alpha.water, Initial residual = 0, Final residual = 0, No Iterations 0
Phase-1 volume fraction = 0.169587  Min(alpha.water) = 0  Max(alpha.water) = 1
MULES: Correcting alpha.water
MULES: Correcting alpha.water
Phase-1 volume fraction = 0.169587  Min(alpha.water) = 0  Max(alpha.water) = 1
DICPCG:  Solving for p_rgh, Initial residual = 1, Final residual = 0.0491804, No Iterations 7
time step continuity errors : sum local = 0.00014383, global = -9.10245e-09, cumulative = -9.10245e-09
DICPCG:  Solving for p_rgh, Initial residual = 0.0033825, Final residual = 0.000137417, No Iterations 22
time step continuity errors : sum local = 6.15787e-06, global = -1.58356e-06, cumulative = -1.59266e-06
DICPCG:  Solving for p_rgh, Initial residual = 0.0001798, Final residual = 9.41171e-08, No Iterations 88
time step continuity errors : sum local = 7.8403e-09, global = 1.80596e-10, cumulative = -1.59248e-06
smoothSolver:  Solving for epsilon, Initial residual = 0.0174728, Final residual = 2.46564e-08, No Iterations 3
smoothSolver:  Solving for k, Initial residual = 1, Final residual = 2.39041e-07, No Iterations 4
ExecutionTime = 0.46 s  ClockTime = 0 s



--> FOAM FATAL ERROR: 
Error in the preCICE adapter: 
There was a problem while configuring the adapter. See the log for details.


    From function void adapterInfo(std::__cxx11::string, std::__cxx11::string)
    in file Utilities.C at line 32.

FOAM exiting

DavidSCN · March 19, 2020, 11:36am

Ok the issue is probably triggered through an inappropriate choice of your solver with your OpenFOAM version. I already ran into the same trap and opened up an an issue on github..
Does your solver support dynamic meshes? Or is there maybe an interDyM version of your solver?

bitronteofil · March 19, 2020, 1:22pm

I found some stupid errors. Now I fixed them and the couplig start well.
Now I have another trouble with something that you probably already know.
After the first iteration I experience this error message:

--> FOAM FATAL ERROR: 
updateCoeffs(const scalarField& snGradp) MUST be called before updateCoeffs() or evaluate() to set the boundary gradient.

I found some other message in which you suggest to Remove boundary evaluation for checkpointing.
Could you explain this better?

Alex

Makis · March 19, 2020, 1:30pm

@bitronteofil we removed the respective functionality and if you get the latest state of the adapter you shouldn’t be getting this error anymore.

bitronteofil · March 19, 2020, 1:50pm

my adapter were compiled at the preCICE workshop and I think it is already updated.
How could I verified for this?

DavidSCN · March 19, 2020, 2:07pm

I think we updated afterwards.
If you simply run a git pull and recompile the adapter, this error must vanish.

EDIT: Make sure you use the develop branch. I think it is not yet in the master.

Makis · March 19, 2020, 2:17pm

I just merged develop into master, now it is.

bitronteofil · March 19, 2020, 2:38pm

ok! thank you very much. I recompiled the adapter and now the simulation run fine.
But I would ask for some questions:

when I rebuild the adapter the target dir is:

/home/alex/OpenFOAM/alex-/home/alex/OpenFOAM/alex-v1906/platforms/linux64GccDPInt32Opt/libv1906/platforms/linux64GccDPInt32Opt/lib

is it the right place? It would not be better to copy it in normal openFOAM lib dir like:

/opt/OpenFOAM/OpenFOAM-v1906/platforms/linux64GccDPInt32Opt/lib/

Whrere is written about the adapter target dir? Could I modified the target dir?

Makis · March 19, 2020, 3:48pm

This is defined in the Allwmake script. By default, we use FOAM_USER_LIBBIN.

is it the right place? It would not be better to copy it in normal openFOAM lib dir like:

/opt/OpenFOAM/OpenFOAM-v1906/platforms/linux64GccDPInt32Opt/lib/

The standard OpenFOAM practice is to put everything that comes with OpenFOAM in FOAM_LIBBIN and everything that is third-party (i.e. built by the user) in FOAM_USER_LIBBIN. In many cases, as in your example, FOAM_LIBBIN is not even writable by the user (i.e. without sudo).

bitronteofil · March 19, 2020, 4:14pm

ok, I agree with you in order to take them separated.

My simple example now run well.

Thank all very much.

bitronteofil · March 23, 2020, 12:49pm

Unfortunately, the simulation diverge after time 0.5[s].
Moreover, the max Courant number is very low except that in water collision against the wall (more or less at time 0.2[s] to 0.26[s]).

div_gnuplot_2

For this reason I would like to perform some stop and restart for the coupling simulation.
In other discourse, I read that CalculiX wrote restart file only at the end of the simulation. Moreover in my tests it write only if I put:

*RESTART,WRITE,FREQUENCY=1

If I use the same save frequency like the output results (that in my case in 200) even at the end of the simulation CalculiX doesn’t write nothing.

*NODE FILE, FREQUENCY=200
U
*EL FILE, FREQUENCY=200
S
*END STEP

Ok, now I’m trying with this strategies:

start the coupling with a dt=1[ms] till t=0.18[s]. In this case the max Courant is below 0.7.
restart the coupling with a dt=0.05[ms] till t=0.26[s] (ending phase of the water collision).

My question is:

how do I have to consider the max-time in the precice-config.xml?
At the beginning I thought it like a total time, but the coupling didn’t stop at 0.26[s] like I expected.
I beleive to understood that:

OF consider the time like a total time
while CalculiX and preCICE consider it like an additional time.

So I changed my config file in this way:

OF: endTime 0.26;
CalculiX: dt = 0.05e-3; tfin = 0.08
preCICE: max-time value=“0.08”

Is it right?

Makis · March 23, 2020, 1:14pm

Regarding max-time: In principle, we need that the solvers don’t stop before preCICE says so. Therefore, we usually set the endTime of each solver to be larger than the max-time defined in preCICE.

In the OpenFOAM adapter, this is overwritten automatically to be GREAT, i.e. infinity in OpenFOAM terms.

bitronteofil · March 23, 2020, 2:28pm

so the only that is really relevant is to syncrhonize the timestep?
There are some advice in order to restart an analysis?
The initial relaxation must be set to 1?

At the restart, every time the OF solver break at the second iteration!

Makis · March 23, 2020, 5:38pm

I think it would be better to open a new thread just for the restarting question, as it does not seem to be specific to interFoam anymore.

Then somebody more experienced with restarting could help.

bitronteofil · March 23, 2020, 9:30pm

finally I was able to use sub cycling and managing a little bit with tolerances and so on, the coupling proceed well .

Alphaoo1 · August 25, 2020, 7:43am

Can you share your case set-up, I am also working with interFoam. (OpenFOAM+CalculiX).
Will be a huge help

Thank you.

Alphaoo1 · August 26, 2020, 4:17pm

I decided to post this here because it seemed a good place to continue discussing about interFoam case and it’s issues. Please let me know if I should open a new topic instead.

System:
Kubuntu 18.04LTS
preCICE v2.1
OpenFOAM v7
CalculiX v2.15

What I have done so far
I replicated the OpenFOAM+CalculiX FSI flap tutorial.
I modified the Fluid to run for interFoam with a water column similar to dam breaking.
I checked the pure fluid case and it runs fine. (I did not modify anything else.)

Then I tried to run a coupled simulation.
The Fluid participant keeps on running but the CalculiX participant does nothing.
Solid.log (5.3 KB) Fluid.log (1.6 MB)

I have to stop both the participants manually. The Fluid case keeps on going way beyond the max time defined in precice-config.xml.

Another observation: if I stop Fluid participant before the Solid, then it proceeds by one time steps, but then obviously nothing else happens after that.
(You can see this in the Solid.log, everything after Line 46 ---[precice] e[0m Slaves are connected, comes after I kill the Fluid participant.)

Observation regarding the Fluid output, when I run the solvers separately, for every time-step, the precice adapter gives the following

---[preciceAdapter] [DEBUG] Writing coupling data...
---[preciceAdapter] [DEBUG] Advancing preCICE...
---[precice]  it 1 | dt# 1 | t 0 of 5 | dt 0.01 | max dt 0.01 | ongoing yes | dt complete no | 
---[preciceAdapter] [DEBUG] Reading coupling data...

Where as, when I run the script ./Allrun, I get some different output, (as seem in the Fluid.log).

Currently, I am trying to run a case with compressibleInterFoam, since it was suggested that precice can handle compressible multiphase solvers, but I have some error (most probably due to bad boundary condiition in the 0/T).

Question

Since I did not modify anything other than the Fluid solver in the case, why are the participants not communicating?
Is there something else that I might be missing to set up this case?

Thank you in advance for all the advice and help.

Alphaoo1 · September 2, 2020, 4:49pm

Is this true for the Openfoam7 branch of the OF adapter?

I am trying to run a case now with compressibleInterFoam, but it is as before, the Fluid part keeps on going without exchanging any data, while Solid just waits.

Topic		Replies	Views
3-phase multiphase compressible FSI coupling in preCICE + openFOAM Official adapters and tutorials openfoam	2	152	March 12, 2024
Multiphase FSI case with the OpenFOAM adapter Using preCICE openfoam , multiphase	8	1299	September 28, 2022
Coupling problem about in-house OpenFOAM solver with CalculiX by preCICE Using preCICE openfoam , adapters , fsi	3	377	August 13, 2022
MultiRegion coupling in OpenFOAM using preCICE Official adapters and tutorials openfoam	8	181	April 9, 2024
About FSI Examples and Adapter Release Official adapters and tutorials openfoam , adapters , fsi	3	38	October 28, 2024

FSI: OpenFOAM adapter with interFOAM

Related topics