Moving Mesh problem
found the pointdisplcement file
pointDisplacement
pointDisplacement
Quote:
Hello everybody
Context: I'm coupling a FEM code (Feap) and OpenFOAM to solve FSI problems by a partitionned strategy. I try to validate this coupling.
To be more precise, i'm using the solver icoDyMFoam of OpenFOAM 1.4.1. The mesh is solved with the following options :
// ---------- dynamicMeshDict ---------
dynamicFvMesh dynamicMotionSolverFvMesh;
motionSolverLibs ("libfvMotionSolvers.so");
solver velocityLaplacian;
diffusivity quadratic inverseDistance 1(movingWall);
// --------------------------------------------------
As from other post and sources [1] it seems that the quadratic inverse give the best results.
Unfortunately, when the motions become to big (for problem with a small stiffness), it seems the computation crash due to bad motion (see pictures [2]) of the mesh that become non-convex.
Is this for you due to bad mesh construction, bad options to solve the mesh motions or any other idea ?
Thank you.
[1] Automatic Mesh Motion for the Unstructured Finite Volume Method by Hrvoje Jasak and Zeljko Tukovic
[2] Pictures
velocity field: <https://perso.crans.org/kassiotis/op...velocity74.jpg>
initial mesh: <https://perso.crans.org/kassiotis/openfoam/mesh0.jpg>
deformed mesh with problem: <https://perso.crans.org/kassiotis/openfoam/mesh74.jpg>
Context: I'm coupling a FEM code (Feap) and OpenFOAM to solve FSI problems by a partitionned strategy. I try to validate this coupling.
To be more precise, i'm using the solver icoDyMFoam of OpenFOAM 1.4.1. The mesh is solved with the following options :
// ---------- dynamicMeshDict ---------
dynamicFvMesh dynamicMotionSolverFvMesh;
motionSolverLibs ("libfvMotionSolvers.so");
solver velocityLaplacian;
diffusivity quadratic inverseDistance 1(movingWall);
// --------------------------------------------------
As from other post and sources [1] it seems that the quadratic inverse give the best results.
Unfortunately, when the motions become to big (for problem with a small stiffness), it seems the computation crash due to bad motion (see pictures [2]) of the mesh that become non-convex.
Is this for you due to bad mesh construction, bad options to solve the mesh motions or any other idea ?
Thank you.
[1] Automatic Mesh Motion for the Unstructured Finite Volume Method by Hrvoje Jasak and Zeljko Tukovic
[2] Pictures
velocity field: <https://perso.crans.org/kassiotis/op...velocity74.jpg>
initial mesh: <https://perso.crans.org/kassiotis/openfoam/mesh0.jpg>
deformed mesh with problem: <https://perso.crans.org/kassiotis/openfoam/mesh74.jpg>
Total Comments 0