Comparison of currently available dealii adapters

Dear preCICE users/developers,

I used a 3D flap case to compare the performance of the available dealii adapters, namely the official “linear elasticity”, “nonlinear elasticity”, and the unofficial “matrix-free-dealii-precice” (mf) adapter. Attached you can find a schematic of the computational domain. At the inlet, a uniform constant velocity in profile in x-direction is imposed (0.5 m/s). I used the same gird resolution, basis function order, and time step size for the three simulations. The official linear and nonlinear solver yield very similar results. However, the result of the mf solver is different. I have attached the tip displacement as a function of time obtained from the three solvers. Should’nt I expect a similar solution from the mf solver as well? Can this be related to the strain-energy function variable in the mf solver?

Here is a summary of the test case physical properties:

Poisson’s ratio: 0.285
Shear modulus: 7.67e8 Pa
density: 3963 kg/m^3

kinematic viscosity: 1e-3 m^2/s
density: 1000 kg/m^3

Thank you,

precice-config_linear.xml (3.0 KB)
precice-config_mf.xml (2.7 KB) (1.9 KB)

Hi @sinaTaj ,
yes that’s most likely the case. In the MF solver, you can switch to (at least almost) the same strain-energy function than the one used in the official solver by setting set Formulation = 0 (which requires to set the caching strategy to set MF caching = tensor2, this is the only one available for this formulation). It would be interesting to see a comparison with this formulation as well. I already had the same problem and read up about the differences: IIRC, the SEF of formulation 0 splits the function into the compressible and incompressible part and formulation 1 models the SEF as a whole.

If you like, feel invited to comment your findings in this issue: Describe differences between material formulations · Issue #11 · DavidSCN/matrix-free-dealii-precice · GitHub. Details about the theoretical description of formulation 1 can also be found in this paper: and the similar nonlinear material of the official tutorial is described here The deal.II Library: The 'Quasi-Static Finite-Strain Compressible Elasticity' code gallery program (unfortunately referring there to other sources again).

1 Like

Hi @DavidSCN ,
Thank you for your response. I ran another simulation with set Formulation = 0 and set MF caching = tensor2. As you can see in the figure below, the deviation from the official solvers becomes even larger (even larger amplitudes and a lower frequency is observed in the displacement signal when set Formulation = 0). Similar behavior is also visible in your analysis in Describe differences between material formulations · Issue #11 · DavidSCN/matrix-free-dealii-precice · GitHub. Any thoughts on this?

Hm, do you use the parameter files you uploaded above? The material parameter settings are different in the zip archive you uploaded, so that the linear material settings does not fit into your description. Also note that you enabled body forces in the linearElasticity.prm.

oops, my mistake. I uploaded the wrong parameter file for the linear solver. Here is the correct one. Sorry for the confusion. (1.9 KB)

Before looking into this: the case is a simplified version of the bending flap, right? May I ask you to upload the make_grid content of your linear solver as well?

Yes, this is basically a simplified version of the bending flap. Except for the clamped boundary, all boundaries of the flap are considered as “interface”. In the attachment, you can find the make_grid content of the linear solver.
linearBeam_make_grid.txt (4.1 KB)

First of all I would like to recommend you to update the ‘official’ deal.II codes (just run a git pull) as they have changed quiet a bit: the two executables (linear and nonlinear) have been merged together and they have now a common parameter file.

Further: are you aware that the geometry of your flap case is a bit different than the default one? In particular the thickness is different. I assume you adjusted the geometry and refinement on the coarsest level for the MF codes as well?

1 Like

I will update the “official” codes. Thanks for the tip. But I suppose this would not have any effect on the performance of the solvers. Yes, indeed I changed the geometry and material properties of the flap. I have adjusted this also in the MF solver (attached). If you prefer, I can also share all the files for these simulations.

P.S Can this be related to the differences in the time integration schemes?
IS there a difference between the Newmark method in the MF solver and the nonlinear solver? (1.3 KB)

Yes this would be great, then I can reproduce it immediately.

In the attachments, you can find the three cases. The corresponding solid solvers to be compiled are
linearBeam, nonlinearBeam, and solid for the linear, nonlinear, and the MF solver, respectively. The executables should be copied to the Solid ( solid for the MF case) directory.
./Allrun -parallel will start the simulations with the fluid participant running in parallel on 32 cores (this might need modification depending on your system). (2.9 MB) (104.5 KB) (1005.4 KB)

The geometry of your fluid in case of the MF solid solver is not fitting. Given that you use a NN mapping, this leads to the shown deviation since the impact on the flap tip is rather large. If you correct this (and also use the same convergence measures in your configuration file) the results between the MF code and the official nonlinear solver should be almost the same. You could probably still observe some small deviations since the data reading (as I am sure you have already noticed) is performed a bit different in terms of the number of interface nodes and the node location.
You can use the parameter Write data specification = values_on_dofs in the MF parameter file (see matrix-free-dealii-precice/elasticity.prm at 94c8ca11a158fba77b363da6afa7e4c52e9b745e · DavidSCN/matrix-free-dealii-precice · GitHub ) in order to make the utilized interfaces for data writing the same as in case of the ‘official’ solver.

1 Like

Indeed… a typo in blockMeshdict. This is how the solution looks like after the fix. I used the same convergence measures and Write data specification = values_on_dofs. I will also make a comparison of the strain energy formulation and add it to the related issue on GitHub. Thank you @DavidSCN for the tips.


Can I know where we can edit geometry ?

Directly in the code, e.g. here:

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