|
[Sponsors] |
February 2, 2005, 11:08 |
Hi all,
I have a question
|
#1 |
Guest
Posts: n/a
|
Hi all,
I have a question regarding moving meshes in terms of a rotationg cylinder. I found the 2D mixer example in icoTopoFoam and removed the blades. But i don't like the sliding patches in the inside because they producing strange results if I close the cylinder at top and botton with stationary solid walls. My question: is it possible to define movements in terms of rotation without the mixer class, e.g. use icoAutoFoam and define the inner wall as a rotating wall? My second question concerns the property of the default boundary condition 'empty patch'. What does it mathematically mean? Exists a more detailed description of usable boundary conditions and also of the way the system of equations are implemented and solved? Thank you. |
|
February 2, 2005, 11:17 |
- strange velocities: you are
|
#2 |
Guest
Posts: n/a
|
- strange velocities: you are making a 3D geometry (since you have walls on top and bottom) which is only one cell thick?
- moving walls: you can just enter a non-zero velocity for the walls of the mixer (see the lid-driven cavity tutorial). All velocities are in stationary coord system. - empty patch is a patch for which nothing has to be done. There are no values stored, nothing is discretised. Mattijs |
|
February 2, 2005, 11:59 |
* I extended the third direct
|
#3 |
Guest
Posts: n/a
|
* I extended the third direction to get an aspect ratio of eight. Additionally I modified the resolution
also in r- and phi-direction. Nevertheless near top and bottom the velocity distribution in radial direction is wrong, it's constant in the outer part (outside the slider) and correct (quadratically) in the inner part (low Reynolds number). With 'empty patch' top and bottom it looks good but doesn't take into account effects from solid caps which are important for higer Reynolds numbers. I also didn't got the point why the sliders are needed or what effect they have. I'm new in the field of finite volume methods, perhaps thats the reason I'm asking. * It's not simply a moving wall but rotating. Could I define velocities like v_x=sin(t) for the wall? * Regarding the empty patch: I know that nothing needs to be done, but what kind of constraint undergoes my fluid particle at such a 'wall'? |
|
February 2, 2005, 12:17 |
OK, here's some explanations:
|
#4 |
Guest
Posts: n/a
|
OK, here's some explanations:
1) Empty patch As you know, foam is a 3-d solver and 2-d cases are solved using 3-d cells and a geometry 1 cell thick. In that case, what is the natural boundary condition for the "top" and "bottom" plane? Well, it would be something like a symmetry plane or a zero gradient for all variables (there is no "action" in that direction). Howver, both choices I have given imply that value will be stored for all faces in the patch. Thus for a 2-d geometry you would end up storing all cell vaues three times: once for the cell and once for each top and bottom face. This is wasteful and unnecessary + it costs both storage and operations (as the boundary condition is always evaluated!). Why can we get away with doing a 3-d calculation on a 2-d slice? it is because the faces in the front and back plane do not really matter, i.e we do not need to solve anything on them (to be very precise, a sum of face area vectors for each cells without the front and back plane equals zero). On the other hand, foam requires you to specify a boundary condition for all external faces INCLUDING the front and back plane. An elegant solution for this problem is the empty boundary condition: it tells foam to store no values and do no operations for this patch. With this on the front and back plane, you only solve for and store one value for all cells in 2-d and there is no overhead. However, if you use it for a 3-d geometry, you will get garbage. 2) Why do you need sliders? Specifying a velocity on the wall can be done in 2 ways: - moving the actual wall + using the movingWallVelocity b.c - defining a non-zero tangential velocity on the wall. If your wall is smooth, the second one is OK: for example, you can define the rotating cylinder in this way + if you like, the actual wall velocity can be a function of time or whatever else you like. If you want to do a mixer, you will have blades etc and the velocity is not tangential to the wall in all places. Therefore, you cannot specify it in any other way apart from actually moving the wall. Now look at the mixer tutorial and create the whole mesh in one piece. Use the automatic mesh motion solver to move the impeller and leave the outside fixed. After half a rotation (at the latest), your mesh will fold onto itself and become invalid - you may like to draw this by hand :-) Once you do that, it will become clear why you need a sliding mesh. Good luck, Hrv |
|
February 2, 2005, 12:39 |
Now it becomes clearer to me,
|
#5 |
Guest
Posts: n/a
|
Now it becomes clearer to me, thank you.
So my way is the second one to define a nonzero tangential velocity. There is no tutorial with such a case, isn't it? |
|
February 2, 2005, 12:45 |
The tutorials describing this
|
#6 |
Guest
Posts: n/a
|
The tutorials describing this are:
Moving the actual wall: - without change of topology: icoFoamAutoMotion movingCone - with changing topology: icoTopoFoam: mixer2D Specifying non-zero tangential velocity: icoFoam cavity Have a careful look at what happens to the mesh in all cases. Incidentally, icoFoam cavity is also a 2-D case with the empty boundary conditions. Enjoy, Hrv |
|
February 9, 2005, 07:15 |
I'm back for asking.
Both ca
|
#7 |
Guest
Posts: n/a
|
I'm back for asking.
Both cases you pointed out are different to rotation in so far as the wall velocities are tangential but limited to one direction (x in the cavity case). For rotation it's something like uniform ( sin(x) cos(y) 0 ) I don't know how to define it. For the nonuniform case one has to give a list with velocity values at all boundary points? What's the order of that points? |
|
February 9, 2005, 08:24 |
Do a search of the board post
|
#8 |
Guest
Posts: n/a
|
Do a search of the board posts. I think the general question of specifying varying boundary conditions has been asked several times. There are even one or two example codes if I am not mistaken.
Search topic: boundary |
|
February 9, 2005, 08:40 |
The boundary conditions are n
|
#9 |
Guest
Posts: n/a
|
The boundary conditions are not varying, they are fixed. Ok only fixed in time and depending on the position in space.
So my question is if I need to define a list of values at all boundary grid points or if there is an easier way. (I didn't found an answer in either the documentation nor the message posts. And I was also not able to see similarities in the tutorial cases.) |
|
February 9, 2005, 09:01 |
You need to define velocities
|
#10 |
Guest
Posts: n/a
|
You need to define velocities at all boundary faces.
The following code included in your solver before the main calculations begin, should do the trick: /***********************************************/ label patchID = mesh.boundaryMesh().findPatchID(nameOfRotatingSurf ace); const polyPatch& cPatch = mesh.boundaryMesh()[patchID]; forAll(cPatch, faceI) { const vector& faceCoord = cPatch.faceCentres(); vector faceU(vector::zero); faceU.x() = some function of faceCoord; faceU.y() = some function of faceCoord; faceU.z() = some function of faceCoord; U.boundaryField()[patchID][faceI] = faceU; } /***********************************************/ Obviously, you need to replace "nameOfRotatingSurface" and "some function of faceCoord" with the appropriate expressions. (note this code has not been tested, and is intended as guideline only) |
|
February 9, 2005, 09:11 |
Thank you Eugene. I will try
|
#11 |
Guest
Posts: n/a
|
Thank you Eugene. I will try it that way.
|
|
February 9, 2005, 09:40 |
Better code:
/************
|
#12 |
Guest
Posts: n/a
|
Better code:
/***********************************************/ label patchID = mesh.boundaryMesh().findPatchID(nameOfRotatingSurf ace); const fvPatch& cPatch = mesh.boundaryMesh()[patchID]; const vectorField& faceCentres = cPatch.Cf(); U.boundaryField()[patchID] = some function of faceCentres; /***********************************************/ If you need to access the component fields it can be done via ".component(i)" where i=0,1,2 equiv x,y,z |
|
February 9, 2005, 10:18 |
And a completion :-)
point
|
#13 |
Guest
Posts: n/a
|
And a completion :-)
point origin(1, 1, 0.05); vector axis(0, 0, 1); U.boundaryField()[patchID] = axis ^ (faceCentres - origin); Vectors, Dude, vectors! :-) |
|
June 20, 2005, 08:47 |
Hi Hrvoje,
I want the paddl
|
#14 |
New Member
Chalothon Thumthae
Join Date: Mar 2009
Posts: 13
Rep Power: 17 |
Hi Hrvoje,
I want the paddle of 2Dmixer example of icoTopoFoam move with fluctuating function. for example, to define the paddle move with fluctuated angular speed, omega=A*sin(B*deltaT), where A and B are constant. How can I do? which file I need to edit. |
|
June 20, 2005, 14:37 |
Heya,
It depends a bit on w
|
#15 |
Senior Member
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,907
Rep Power: 33 |
Heya,
It depends a bit on what version of foam you are - the location of the file may be slightly different (apologies). Go find the directory containing icoTopoFoam - in the old version, it should be something like: OpenFOAM-1.1/applications/solvers/incompressible/icoTopoFoam In there, find the mixerMesh (or mixerFvMesh) class, which defines what the mixer vessel will be doing. An alternative location would be OpenFOAM-1.1/src/topoFvMeshes/mixerFvMesh/ Now look for the slide() or similar function - search for rpm in the .C file and you should be able to find it. In there (I am using the old code as an example), it will actually move the mesh: // Rotational speed needs to be converted from rpm movePoints ( cs_.toGlobal ( cs_.toLocal(allPoints()) + vector(0, rpm_*360.0*time().deltaT().value()/60.0, 0) *movingPointsMask() ) ); Take that function and rip it apart in any way you like (hopefully, renaming the class first). You can pull through the parameters from the dictionary in the constructor etc. Beware of the setup with double mesh motion (that's NOT an error) :-) and enjoy! Hrv
__________________
Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk |
|
April 25, 2007, 18:06 |
hello,
i would like to turn
|
#16 |
New Member
Brahim Aakti
Join Date: Mar 2009
Location: Lucerne, Switzerland
Posts: 23
Rep Power: 17 |
hello,
i would like to turn an imppeler wall in 3D (i.e moving wall) using the new code OpenFOAM-1.4 with MRF case. is it possible and and how can it be done this ! I thank you for helping me. B. |
|
September 12, 2007, 15:26 |
Dear Foamers,
I'd also like
|
#17 |
Member
Stefan Radl
Join Date: Mar 2009
Location: Graz, Austria
Posts: 82
Rep Power: 18 |
Dear Foamers,
I'd also like to have rotating parts in 3D with complex geometry, i.e., not using blockMesh and using MRF to get a steady-state solution. Just like the way the mixer2D tutorial, but with an external mesh. Has anybody tried this? How have you defined the cellZones? I'd like to use Cubit or Salome, br Stefan Radl |
|
December 14, 2010, 16:06 |
|
#18 |
Member
|
I would like to have a look at icoTopoFoam mixer 2D tutorial. How can I get it? I'm on version 1.7.1. I have a rotating square and the mesh rotates with it, so I need sliding interface as Hrv said in this thread. Bu I don't know how to combine automatic mesh motion with sliding interface.
Thanks |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Rotating objects time dependend SRF | naish | OpenFOAM Running, Solving & CFD | 0 | January 24, 2009 04:55 |
Counter rotating wall for rotating domain | melvin | CFX | 0 | February 4, 2008 05:51 |
Rotating Domain,Blades St frame or rotating? | Pankaj | CFX | 1 | May 5, 2007 08:06 |
Difference b/t rotating wall and rotating domain? | Juno Kim | CFX | 2 | February 20, 2007 21:08 |
Rotating objects in flow using MRF | Kyle | FLUENT | 1 | December 5, 2005 20:29 |