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:
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.
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.
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?
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?
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).
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.
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.