Quote:

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 use laplaceFaceDecomposition in parallel? (ii) If so, do I need to do something special to get the tet-solver to work? Thank you very much for any help or suggestions Niels |

Quote:

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, have a look at the fluxes through your wall boundaries - if all is well, they should be exactly zero. Hrv |

Quote:

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 the oscillatory motion stays the same, but the cells are smaller (on the finer grid) the relative cell displacement is increased, i.e. the boundary of the body moves multiple cell sizes within one timestep. Besides choosing a very very small timestep, is there a good solution for this?? 2) So, what are the ideal motion solver settings for this kind of problems? 3) At my place, another moving mesh method is developed using radial basis functions. This method is capable of using very large time steps without severe mesh destortion near the moving body boundary. How difficult is implementing such a new mesh motion algorithm in OpenFOAM?, or is this almost impossible? 4) I am also trying to expand the oscillatoryFixedValue boundary conditions towards a 6 DOF boundary condition which could handle arbitrary functions for 6 variables (not only oscillatory functions). Do you think this is feasible? Is it smart to start with the movingFlapFvMesh class from OpenFoam 1.2? 5) In the development sources, I am using, a top level Fluid Structure Interaction solver is present, icoFsiFoam. Is there also a tutorial available for this, just as an example how to define a problem using this solver. Unfortunately I haven't seen prof. Jasak's presentation at the 5th ICCSM, but I have read the paper and I'm impressed. Best regards, Frank |

Quote:

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 |

Quote:

Yes, you need to download metis from this site
http://people.sc.fsu.edu/~jburkardt/c_src/metis/metis.html and GKLib. GKLib was a bit more tricky to find but I have found it for example here: http://code.google.com/p/graphlabapi...0a9d384317c3bf You can checkout the whole repository if you have mercurial installed. Now it's the question of compiling these things. Set up your include paths correctly. For GKLib I had to add Code:
DMALLOCINC = -I../libmetis/ Metis compiled seamlessly in my case using script although you must add -fPIC to the gcc command. Finally go to Code:
$FOAM_SRC/parallel/decompose/metisDecomp Code:
wmake libso EDIT: ALSO! I removed the -I pointing to the dummy library. I guess that might be important. :-) |

---------------------------------------------------------------------------------

Quote:

Hello Ehsan,
the trick is exactly the one explained by Hrvoje in this thread. Create a uniform mesh, with the number of nodes you need in the three directions. Then write a small utility which: - Reads the mesh (see how this is done in all solvers or mesh manipulation utilities). - Does pointField newPoints = mesh.points(); forAll (newPoints, i) { // Your code here, calculate the point position } mesh.movePoints(newPoints); mesh.write(); using an analytical expression to relate the position of a node in a uniform grid to the new position (this is commonly done to generate grids for channel flow simulations). Regards, Alberto |