Entries for October 8, 2012

Originally Posted by ngj

Hi all

I am doing mesh motion using the laplaceFaceDecomposition method available in OF-1.5-dev. It is running without any problems in serial, however, when I decompose the case, the solver stalls on the very first encounter with mesh.update().

I have made the solver myself, so I used icoDyMFoam on the "movingConeMotion" tutorial, and the same behaviour is found for a decomposed case (2 processors).

My question is twofold: (i) Is it possible to

Originally Posted by hjasak

The solver looks fine (well, at least not obviously wrong). However, your residual behaviour indicates a serious problem and my guess is that you have messed up the boundary conditions.

Note that the wall boundary needs to be specified in terms of absolute velocity, so a moving wall with no flux through it will not have fixedValue (0 0 0). If this is the problem use the movingWallVelocity b.c., which corrects the normal component based on the mesh motion.

As a test,

Originally Posted by lr103476

Hi,

The mesh motion works using the latest development code using the oscillatingFixedValue boundary condition. Now I am considering oscillating bodies (flat plates and cylinders) on different grids at low Reynolds numbers to see how the grid motion behaves.

I've got the following questions/remarks:

1) On coarse grids the meh motion performs very nicely, but on finer grids the mesh gots distorted near the body causing the flow solver to diverge. Since

Originally Posted by zhajingjing

Hi,
I use mesh motion solver for a moving boundary, and it takes a lot of time to move the whole mesh, if setting the part of mesh just near the moving boundary to move can be realized(that means just solve mesh equation in a region near the moving boundary), then I can save much time to run the case.

So how to let the mesh motion solver just solve a small region near a moving boundary? Can someone give me a hint?
Thanks!

Jingjing