displacementLaplacian cannot handle rotations > 90°
Context
I'm looking to compare the clocktime, particularly the parallel scaling, between AMI, Overset, and deformable meshes when simulating cycloidal rotor motions which consists of a superposition of a local oscillating motion over a global rotating motion. The idea of using a deformable mesh is to get rid of the interfaces inherent to AMI and Overset, thus accommodating the oscillating motion through mesh deformation. AMI and Overset can produce both motions without problem. The deformable mesh can model the pitching motion without problem. However, there are to the best of my knowledge no way to solidly rotate a deforming mesh without leading to issues. I give fours examples and videos to explain that.
Functionality to add/problem to solve
My guess is that a singularity occurs in the solution of the displacementLaplacian solver when rotations are beyond 90°. The same occurs for displacementSBRStress as well. Using velocityLaplacian mitigates the issue but the mesh will, in that case, nevertheless deteriorate, only at a later time, and that even if the motion is only limited to oscillation without rotation.
Steps to reproduce
I'm adding a few example cases and linking videos where the issue is visible. The left side shows whole domain while the right side zooms into the zone of interest. The cases must be run with moveDynamicMesh.
1 pointDispRotation:
a simple rotation of the whole domain, imposed though a pointDisplacement dictionary and a uniform diffusivity, everything runs smoothly until ~90° where mesh distortion suddenly explodes. Video.
2 workingPitching:
a simple pitching motion of the two blades, works without particular issues as long as the diffusivity and boundary conditions are properly tuned. Video.
3 scalingPitchingCombinedMotion:
trying to impose the rotation in dynamicMeshDict through the solidBodyDisplacementLaplacian motion solver and the pitching in pointDisplacement. Mesh quality remains good but the patches are deformed. Scaling of patches is clearly visible, but not wanted nor requested. Video.
4 pitchingVelocityLaplacian:
This solver is able to handle rotations going well beyond 360°, though the use of a angularOscillatingVelocity boundary condition imposed in the pointMotionU file. However, the quality of the mesh deteriorates with time, and this even when no global rotation is imposed. Video comparing with the workingPitch case, diffusivity and other parameters are equal for both cases.
What is the current bug behaviour?
Local mesh deformations when the whole domain rotates beyond 90° are not possible.
What is the expected correct behaviour?
Local mesh deformations should not differ whether the whole domain rotates or not.
Environment information
- OpenFOAM version : v2006
- Operating system, hardware info, and compiler : bug can be reproduced with other architectures
Funding
Not available. However, if this issue is solved you can use my case as a mesh tutorial.