[kev4573]

Hi,

I am trying to get mesh motion to work on a hex cell grid. I had originally done the mesh with unstructured/tet cells and the motion worked great but was having problems with the results so I took the time to make a nice structured mesh. So after copying the newly converted hex mesh into the openfoam case and running, the solver fails after my moving boundary starts crossing into the mesh. I saw this same phenomena on Frank Bos' website - http://www.aero.lr.tudelft.nl/~frank/index.php?id=research/cfd/problems/2D_movin gmesh_wing - Is there anything I was supposed to change in the case dictionaries to make the mesh motion work with a hex mesh? Thanks.

[lr103476]

Hi Kevin,

Could you please be more specific about your problem.
1) What error message do you get?
2) Is your case setup correctly? You don't get dictionary related error, right?
3) Did you run checkMesh?
4) What is your Courant number? You didn't give information about your case, but maybe your timestep is too large....

Regards, Frank

[fra76]

And more, which OF version are you using?
What mesh motion algorithm (finite element or finite volume)?
I moved very big hex/tet meshes without problems...

Francesco

[lr103476]

Me too, but large rotation is still a problem for small boundary layer cells......The SBRstress fvMotionSolver seems to behave best for large displacements/rotations.

For different meshes I am still not able to rotate a wing (tip up 60 degrees combined with pitch up 45 degrees), but I got the feeling that there's still something to gain with modifying the SBRstress slightly and the diffusion coefficient...

Regards, Frank

[kev4573]

Frank,

Here's some more info about my case -
1) Getting a floating point exception error
2) As far as I know, the case is setup correctly, no dictionary errors
3) checkMesh , ok this one fails, thought I had run this, looks like I have a problem here..
4) I wasn't using adjustable time steps because the Co number seemed to either explode, or implode (approaching zero)

I think that is the crux of it, mainly having problems with time steps regardless of the motion. I went ahead and made a finer tet mesh and ran it with a fixed time step of 5e-05 and the motion works fine and it doesn't crash, but the results are obviously very wrong - getting turbulent regions propogating upstream (case is a 2D object in uniform flow field). Basically as soon as the simulation starts, I see ripples over the entire flow field start to develop and they continue to get more turbulent until I get very ugly results.

I am using the 1.4.1-dev version for this with the finite volume motion algorithm - here's the content of dynamicMeshDict (wall-4 is the moving boundary) -

dynamicFvMesh dynamicMotionSolverFvMesh;

twoDMotion yes;

solver laplaceFaceDecomposition;

diffusivity quadratic patchEnhanced;

frozenDiffusion off;

distancePatches
(
wall-4
);

I am still pretty new to openFoam and CFD in general so I really appreciate any help.

I will rerun my fine tet mesh case with an adjustable time step and report what I get.

Thanks,
Kevin

[kev4573]

After running the fine unstructured mesh again with a Courant number of 0.3, the results turn out much better, not as much ripples; I will reduce the Co further and see what happens..

Well it sounds like if I had created a valid hex mesh and used an adjustable time step all should be well - which I still want to do to capture the wake region in more detail and get a more efficient run overall.

Kevin

[msrinath80]

Kevin, just as an FYI, I would like to point out that Hrv has shown the effect of high Courant numbers in his thesis. You may want to check it out[1]. The reason I'm pointing this out is because I used to blindly assume that maintaining a Co of 0.98 was sufficient as it was below the stability criterion (unity). It turns out however that temporal accuracy (not just stability) depends quite strongly on Co. These days I never exceed a Co of 0.4. I try to keep it around 0.2 to 0.3 and things work quite well for me.

Also, I think it would be better to maintain a cell peclet number (which is kind of a Reynolds number but based on the local grid size as opposed to the characteristic length scale of the problem) of 1 to 1.5 in regions where strong gradients of velocity/pressure are expected, especially when using the linear [central differencing] scheme.


References:

[1] http://powerlab.fsb.hr/ped/kturbo/Op...jeJasakPhD.pdf