Two norm diff = 1 at first timestep of FSI simulation

Using preCICE
,
1

Hi all,
I am having convergence issues at the first iteration of a FSI simulation. I am writing a structural solver adapter and I am trying to couple it with openFOAM.
I am performing a serial-implicit coupling with Fluid first and Solid second solver.
The convergence on displacements is set on relative convergence measure.

Looking at the convergence, at each iteration the first time step, I get:
relative two-norm diff = 1
and of course it never converges.
While I am analyzing the code on the structural side, I’d like to be sure that the structure and the sequence of operations in the adapter are correct (I basically followed dummySolver.cpp). My code looks like this:

while (interface->isCouplingOngoing()){
	if(interface->isActionRequired(actionWriteIterationCheckpoint())){
		interface->markActionFulfilled(actionWriteIterationCheckpoint());
	}

	// read forces from interface
	if (interface->isReadDataAvailable()) {
		interface->readBlockVectorData(forceID, 
                                       vertexSize,
                                       vertexIDs,
                                       adapterForces);
	}

	// Send forces to solver
	computeForces(adapterForces,coeff);

	// Solver compute motion step
	solve();

	// retrieve displacements from solver
	getConnDisplacements(adapterDisplacements);

	// send displacewments to interface
	if(interface->isWriteDataRequired(precice_dt)){
		interface->writeBlockVectorData(displID,
                                        vertexSize,
                                        vertexIDs,
                                        adapterDisplacements);
	}

	// advance
	precice_dt = interface->advance(precice_dt);

	if(interface->isActionRequired(actionReadIterationCheckpoint())){
		interface->markActionFulfilled(actionReadIterationCheckpoint());
		// tell solver that timestep didn't converge
		putForces(false);
	}else{
		// tell solver that timestep converged
		putForces(true);
	}
}

I am also writing the values (Forces and Displacements) at the interface by using export:vtk in the precice-config file at each iteration. Basically the forces keep being constant, while displacements seem to oscillate between two sets of values (nevertheless being extremely small). The fact that the two-norm diff is always 1 makes me think that one set of displacements is zero at the numerator, but I don’t see where. The mesh can be found here:

Any suggestion is much appreciated
Thank you
Claudio

2

Hi @Claudio,
the logical sequence of your time loop looks fine. You can also find a quite minimal FSI cpp example in the current develop version of our tutorials in order to compare your setup.

That’s indeed bad, the two norm diff should only be one in your first iteration. Here some ideas and common issues: Does your coupling work with an explicit coupling scheme? Have you tested your solver in a standalone mode without coupling? Do you store/reload your coupling data correctly in the checkpoints (this part is missing in your snippet)? Do you have the interface boundary accidentally constrained in your setup?

Could you provide some additional information on this?

Regards,
David

3

Hi @DavidSCN ,
thank you for your comments:

No, the coupling is set to serial implicit.

The solver itself has been already validated in stand-alone mode, but;

it has a built-in way to checkpoint and advance and I am relying on it. AFAIK it has been tested in the past mostly with explicit coupling and there might be some issue there. At the moment I don’t checkpoint in the adapter. I simply perform:

  1. read coupling data: i.e. forces
  2. send forces to the solver
  3. perform a calculation step
  4. extract interface displacements form the solver
  5. send displacements to the interface
  6. advance
  7. at convergence check: I tell the solver whether the timestep has converged (advance) or not (reload) and I am relying on this for checkpoint.

If I am not wrong my coupling data (i.e. interface displacements) are always overwritten by the solver and I don’t need to checkpoint them. I should checkpoint the state of the structural solver, but it should be built-in. Probably I need to investigate better this part of the code.
Thank you
Claudio

4

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