Transfer of both velocity and displacement in the precice surface adapter

[carme-hp]

The surface adapter has four modes ("read-displacements-velocities", "read-traction", "write-displacements-velocities" and "write-traction"). However my understanding is that we don't need to transfer both the displacement and the velocity, and that it is enough to transfer the displacement only (as we do in the precice FSI examples I know).

In case of explicit coupling it does not hurt to send both quantities, but I believe that in case of implicit coupling that uses acceleration schemes, transferring both quantities can lead to nonphysical displacement-velocity relationship at the interface.

Note I was hoping that removing transfer of velocity would fix the issues observed in implicit coupling. However I have found a bug on the fiber solver (see issue #5) , so the muscle-tendon case cannot be used for testing. TODO: create a test scenario that uses two mechanic solvers only

@IshaanDesai does that make sense to you? If yes, I'll clean the code to remove it entirely (now I've just commented it in this commit ).

[IshaanDesai]

To make sure that the surface adapter does really transfer displacements and velocities at once, I looked in the code. It certainly appears to be the case:

https://github.com/maierbn/opendihu/blob/1f437dffd084394041a589f36d502ea514eab697/core/src/control/precice/surface_coupling/02_read_write.tpp#L29-L43

However I dont see this as outrightly incorrect. Transferring displacements and velocities in one direction could make sense if the other side demands this data. In FSI applications, we typically transfer displacements in one direction and forces in the other direction. In the case of the surface adapter, there is a provision to transfer traction too:

https://github.com/maierbn/opendihu/blob/1f437dffd084394041a589f36d502ea514eab697/core/src/control/precice/surface_coupling/02_read_write.tpp#L44-L56

My guess is that for the cases that were coupled, displacements and velocities being transferred in one direction and traction being transferred in the reverse direction made sense, and that is why the read and write functionality has been developed in this way.

transferring both quantities can lead to nonphysical displacement-velocity relationship at the interface.

This would only happen if one solver computes its own velocities from the displacements it gets from the other solver. But if the solver uses both displacements and velocities, and writes back tractions, then this is not a problem. What is critical is that in a two-way coupling, one should not set Dirichlet boundary conditions in both directions. Dirichlet-Dirichlet coupling does not make mathematical sense, especially for implicit coupling. One must do Dirichlet-Neumann coupling, which is the case here.

[carme-hp]

Thanks for looking into this @IshaanDesai

I see the motivation for transferring both the displacement and the velocity, but I'm still not convince of what happens when we apply acceleration schemes.

My concern is that the velocity and the displacement may be accelerated differently, and thus lead to a nonphyscal dirichlet bc. Of course it is also possible that I'm failing to understand how does the acceleration work.

Also, a muscle-tendon is in practice FSI (with the muscle being the fluid), so I don't see why to add the velocity here and not in the FSI examples.

[IshaanDesai]

I see the motivation for transferring both the displacement and the velocity, but I'm still not convince of what happens when we apply acceleration schemes.

Do you have a particular case for which you see un-physical behavior? Looking at some of the preCICE config file of the one of the cases that you are running:

https://github.com/maierbn/opendihu/blob/651278792850bae7c0f2adb2c3afac19d58f1406/examples/electrophysiology/neuromuscular/surface_coupling/muscle_quasistatictendon/precice_config.xml#L63-L72

I see that the displacement and traction are accelerated in the same scheme. Velocity does not seem to be accelerated. I am not sure if accelerating velocity would always makes sense or if there is a general intuitive understanding on which quantities to accelerate and which not. Perhaps @uekerman can say a bit more.

If you observe un-physical behavior or results which you do not expect, then we can evaluate the particular case.

Also, a muscle-tendon is in practice FSI (with the muscle being the fluid), so I don't see why to add the velocity here and not in the FSI examples.

Is the muscle really a fluid from the perspective of the equations being solved? I can imagine that the equations are not really flow equations and possibly use velocity in their computation.

[carme-hp]

Do you have a particular case for which you see un-physical behavior?

Well, my issue so far is that I haven't manage to make it converge. Without acceleration schemes, the traction is very far off. If I apply acceleration schemes, the traction looks better but then I have issues that either the displacement or the velocity do not converge. That was what started me to think that it may be wrong to transfer both magnitudes. I have tried different configurations for the acceleration scheme, meaning that I've played with which data-fields I select. However I'm not sure that only the data-field(s) that I specify are accelerated.

Is the muscle really a fluid from the perspective of the equations being solved? I can imagine that the equations are not really flow equations and possibly use velocity in their computation.

Yes, the equations are different. The muscle is modeled as an incompressible active hyperelastic material. The equation that describes the muscle mechanics in OpenDiHu is TransverselyIsotropicMooneyRivlinIncompressibleActive3D. The equations are discussed in Maier's thesis and yes, the velocity appears in the formulation of the equation. But I don't understand why this is significant, since $\textbf{v} = \dot{\textbf{u}}$ and in the incompressible NSE equations we also have the term $\frac{\delta \textbf{u}}{\delta t}$.

[uekerman]

In case of explicit coupling it does not hurt to send both quantities, but I believe that in case of implicit coupling that uses acceleration schemes, transferring both quantities can lead to nonphysical displacement-velocity relationship at the interface.

No, that's not true. All data fields use the same linear combination of previous iterations. So, displacements and velocities should always be consistent.

I see that the displacement and traction are accelerated in the same scheme. Velocity does not seem to be accelerated.

In what you are saying, it becomes clear that there is a misunderstanding.

• For parallel and multi coupling, all data that is exchanged within a coupling scheme is also accelerated (if the coupling scheme has an acceleration). For serial coupling only data that is sent from second to first participant.
• Data within the acceleration tag is used to compute the acceleration.

See also: https://precice.org/configuration-acceleration.html#coupling-data-and-primary-data

[maierbn]

OpenDiHu moves to its new home under its own Github Organization :house:. The current repo will be archived soon.

Therefore all issues in the old repo must be closed now, sorry. But you can reopen your issue in the new repo where it will get new attention. :rocket: