[EmadTandis]

Hi colleagues,
I was working on large deflection of 2-D beam using my own movingMeshsolver and noticed that meshPhi is not zero at some faces of fixed patches! More delving into the problem, I found that corner points( points located at boundary of fixed and traction patches) moved after solution and this process happens in patchPointInterpolate.C file ( I used volPointInterpolation class to interpolate displacement from cells to points).

I was wondering if someone faced this sort of problem and would be grateful if let me know about solution of keeping corner points fixed?

[EmadTandis]

Hi Bruno,
I was solving a FSI problem, and more precisely, writing a new algorithm in OF. Regarding volPointInterpolation I noticed that the it uses geometrical interpolation implemented in PrimitivePatchInterpolationTemplate.C. file. When I was solving Turek Benchmark problem for FSI (flexible flag behind a cylinder) and also some other FSI problems, I realized that relative flux (phi) at interface is not zero ( which must be zero because motion of the mesh must be equal to the velocity at interface patch). Therefore, since mesh motion at interface point is calculated by interpolation of velocity on facePatch, finally I concluded that (U & A -meshPhi)!=0 and all of that is because of the geometrical interpolation. Am I right?!

[Moderator note: Moved from Point interpolation in OF - given that this is something that affects FSI calculations in specific]

[bigphil]

Hi Emad,

Did you find this problem with the FSI toolkit? Or with your own implementation?

In the FSi toolkit, interpolation to points is performed using the newLeastSquaresVolPointInterpolation class which should be better at corner points than the volPointInterpolation class.

Philip

[EmadTandis]

Originally Posted by bigphil

Hi Emad,

Did you find this problem with the FSI toolkit? Or with your own implementation?

In the FSi toolkit, interpolation to points is performed using the newLeastSquaresVolPointInterpolation class which should be better at corner points than the volPointInterpolation class.

Philip

Hi Philip,
Actually I found this problem in both, icoFsiElasticNonLinULSolidFoam and my solver. For example, if one notices phi at interface boundary, non-zero phi (phi is defined as relative flux in icoFsiElasticNonULSolidFoam, as I realized) can be easily seen at this patch, which is non-physical to my eyes.
I wanted to implement newLeastSquaresVolPointInterpolation class, but I faced a couple of errors.

[bigphil]

Hi Emad,

Can you check if this issue persists in the extendBazaar FSI toolkit and/or the soldis4foam toolkit (PM me and I can give you access to solids4foam)? In particular, I suggest you look at the newMovingWallVelocityFvPatchVectorField boundary condition used for the fluid velocity at the FSI interface.

Philip

[EmadTandis]

Originally Posted by bigphil

Hi Emad,

Can you check if this issue persists in the extendBazaar FSI toolkit and/or the soldis4foam toolkit (PM me and I can give you access to solids4foam)? In particular, I suggest you look at the newMovingWallVelocityFvPatchVectorField boundary condition used for the fluid velocity at the FSI interface.

Philip

I am working with OF-ext4.0 and actually didn't use these tookits. Also, I have seen movingWallVelocityFvPatchVectorField but I don't have newMovingWallVelocityFvPatchVectorField file.
To explain more, I am working on a monolithicFsi solver by unified formulation of solid and fluid, and trying to implement interface condition implicitly. That's why these fvPatchField classes are not that useful for my solver. However, It will be great to gain some information about these tookits and newMovingWallVelocityFvPatchVectorField and have their sources.

[bigphil]

Hi Emad,

PM me your email and I can share the code.

Philip