CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (http://www.cfd-online.com/Forums/openfoam-solving/)
-   -   Problem with deforming mesh (http://www.cfd-online.com/Forums/openfoam-solving/108484-problem-deforming-mesh.html)

djpiro October 24, 2012 15:46

Problem with deforming mesh
 
Hello,

Sorry if this is a repeat. I have checked the forum for similar issues, but had trouble finding solutions.

I am having difficulty with large deformations near a symmetry plane. Below is a close up of the area that is giving problems.

http://www-personal.umich.edu/~djpir...ionProblem.png

On the yellow portion (body), the pointDisplacement is prescribed. The cyan portion is the symmetry plane (boundary type symmetryPlane). The end of the body is moving down, and the simulation does not get far beyond this point before crashing. As you can see, the mesh near the end of the body does not move very much compared to the body.

I've tried displacementLaplacian and displacementSBRStress motion solvers, making the solver tolerance (on cellDisplacement) 1e-15, and inverseDistance versus quadratic inverseDistance. None of the things I've tried have worked to get rid of the poor mesh quality near the end of the body.

If anyone has an idea of how to get the mesh to properly deform away from the body, I would appreciate your help. And again, sorry if this is a repeat.

Thank you,
Dominic Piro

McCarra October 25, 2012 07:22

I worked on a rotating gear some years ago and I remember that I imposed "slip" boundary condition for the pointMotion so that points can actually slip along the boundary and reduce the suffering of the mesh. I dont know with boundary would be more wise to apply it to in your case but maybe it helps gaining some more timeSteps.

You can also check "slidingInterface" cases. But I am not able to help much on that.

maija October 25, 2012 11:34

In your pointDisplacement dictionary try changing the cyan portion to "zeroGradient" (no symmetry plane declaration at all) this will allow the cyan portion of the mesh to move in tangential motion to the plane but not in and out of the board. It looks a little like your yellow portion is rotating into the page, and I doubt you want that. I think that rotation into the board is a result of the cyan portion not wanting to move at all and causing weird problems with your mesh.

displacementLaplacian with an inverseDistance diffusivity algorithm should work for your case here, at least as far as I understand it.

djpiro October 25, 2012 12:27

Thank you for your thoughts. In response:

Quote:

Originally Posted by maija (Post 388514)
In your pointDisplacement dictionary try changing the cyan portion to "zeroGradient" (no symmetry plane declaration at all) this will allow the cyan portion of the mesh to move in tangential motion to the plane but not in and out of the board.

There unfortunately seems to be no difference between the "symmetryPlane" and "zeroGradient" boundary conditions. The points still move the same amount.

Quote:

It looks a little like your yellow portion is rotating into the page, and I doubt you want that. I think that rotation into the board is a result of the cyan portion not wanting to move at all and causing weird problems with your mesh.
The body is not actually rotating into the page. The reason the mesh lines do not match at the top of the body is that there is a flat surface into and out of the page connecting the side of the body and the center line. What you are looking at is the end of a wigley hull with a flat deck.

I will continue to look into the issue, and appreciate your responses.

Dominic

maija October 25, 2012 12:35

sorry to hear my advice didn't help. if you want to post your pointDisplacement dictionary and the dynamicMeshDict files I can take a look and see if anything stands out at me. I dealt with some dynamic meshing issues not long ago...

djpiro October 26, 2012 16:52

Maija,

Right now I'm implementing radial basis functions to see if that helps. However, my 0/pointDisplacement looks like (without the header):

----------------------------------------------------------------------------------------------------------------------
dimensions [0 1 0 0 0 0 0];

internalField uniform (0 0 0);

boundaryField
{
bottom
{
type fixedValue;
value uniform (0 0 0);
}
centerPlane
{
type symmetryPlane;
}
farField
{
type fixedValue;
value uniform (0 0 0);
}
hull
{
type assignableValue;
value uniform (0 0 0);
}
inlet
{
type fixedValue;
value uniform (0 0 0);
}
top
{
type fixedValue;
value uniform (0 0 0);
}
}
----------------------------------------------------------------------------------------------------------------------

Where assignableValue is a boundary condition I've implemented to allow for FSI.

dynamicMeshDict:

----------------------------------------------------------------------------------------------------------------------
dynamicFvMesh dynamicMotionSolverFvMesh;

motionSolverLibs ("libfvMotionSolvers.so");

//solver displacementLaplacian;
solver displacementSBRStress;

diffusivity inverseDistance (hull);
----------------------------------------------------------------------------------------------------------------------

Doesn't seem like much to look at, but perhaps it can help.

JNSN November 27, 2012 12:09

HI Dominic,

do you have a solution for your problem? I am asking, because I have the same problem. I am doing sixDoF (only heave and pitch) free surface ship simulation with interDyMFoam. The first hundred timesteps look good, but then some cells near the bulbous bow at the symmetry plane are beginnig to deform and destroy the cell quality and the solution blows up. The mesh then looks like an accordion in this area.

I also tried symmetryPlane and zeroGradient as boundary condition, but with no effect.

Best regrads,
Jan

djpiro November 30, 2012 11:42

Jan,

I have not been able to fix the problem just yet. I have found that if there are high aspect ratio cells near the bow/stern, then the quality of those cells will deteriorate first. I'll be working on this problem again more soon, so as soon as I find something, I'll post.

Dominic


All times are GMT -4. The time now is 10:57.