|
[Sponsors] |
December 22, 2004, 08:40 |
1) Does anyone know how "fina
|
#1 |
Guest
Posts: n/a
|
1) Does anyone know how "final" the mesh motion algorithms implementations are? Seems to me that the motion solver (fem based?) is extremely expensive, especially in parallel. The tutorial movingCone motion solver does not converge at all in parallel.
2) Further, a polyMesh of tets is decomposed into 4 tets per "polyTet", which seems a bit unnessecary; Can one avoid this? 3) What method to use to calculate patch to cell/point distances in parallel? is wallDist parallelized? /nikwik |
|
December 22, 2004, 09:09 |
3) by hyperbolic solver. Is p
|
#2 |
Guest
Posts: n/a
|
3) by hyperbolic solver. Is parallellized and cyclicized.
Has some problems with severe distortion but is very fast. Much better than octree based method for most meshes. Mattijs |
|
October 27, 2005, 08:32 |
Hi, I am a beginner in using F
|
#3 |
New Member
Carlo De Angelis
Join Date: Mar 2009
Posts: 10
Rep Power: 17 |
Hi, I am a beginner in using Foam and I'm tryng to simulate a multiphase case with interFoam with mesh motoin.
How can I move the mesh in interFoam solver using movingInkJetFvMesh solver? |
|
November 2, 2005, 08:46 |
1) I've a proplem with nodal v
|
#4 |
Member
|
1) I've a proplem with nodal velocities (at points) on a boundary in the fv-mesh that I want to use to move the mesh through motionU(). Found by trying that motionPtr->motionU().boundaryField()[patchID].size() is not equal to the number of points on the boundary where my pointVelocities reside. Hence, motionPtr->motionU().boundaryField()[patchID] == pointVelocities does not work.
How can this be done? Need some mapping or subLists or other cool stuff perhaps??? 2) Couldn't find out how pointToFace interpolation works? //Eric |
|
November 2, 2005, 23:57 |
I have solved flow over the fl
|
#5 |
New Member
Hyung min Kim
Join Date: Mar 2009
Location: Suwon-shi, Kyonggi-Do, Korea
Posts: 14
Rep Power: 17 |
I have solved flow over the flapping motion of elliptic obstacle using interFoam.
See the movie of this case under the following link. the size of the file is 2.5Mb. kuic.kyonggi.ac.kr/~pius/moveFlt2d_vor.mp2 Pius |
|
November 3, 2005, 00:00 |
If anybody is interested above
|
#6 |
New Member
Hyung min Kim
Join Date: Mar 2009
Location: Suwon-shi, Kyonggi-Do, Korea
Posts: 14
Rep Power: 17 |
If anybody is interested above posted movie,
I will send the files by e-mail |
|
November 3, 2005, 05:27 |
That would be because the moti
|
#7 |
Senior Member
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,906
Rep Power: 33 |
That would be because the motion solver is FEM and the flow solver is FVM. Since motionU is a tetFem field, the number of boundary locations is be different and mapping is required.
Enjoy, Hrv
__________________
Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk |
|
November 3, 2005, 23:17 |
To FoamUsers
It would bette
|
#8 |
New Member
Hyung min Kim
Join Date: Mar 2009
Location: Suwon-shi, Kyonggi-Do, Korea
Posts: 14
Rep Power: 17 |
To FoamUsers
It would better to post the program in this site to share with all Foam Users. This patch file is very similar to movingPinFvMesh somebody posted. I just modified the movingPinFvMesh to fit the flapping motion of obstacle. Patching procedure is 1. untar the zipped file 2. copy the movingFlapFvMesh directory into OpenFOAM-1.2/src/movingFvMesh 3. update the "files" and "options" in movingFvMesh/Make 4. compile movingFlapFvMemsh by using "wmake libso" 5. update the "options" file in the interFoam/Make 6. compile the interFoam by using "wmake" Now you can use the movingFlapFvMesh by interFoam application It is not perfect to describe the motion of obstacle because it is limited by the mesh deform. If anyboy can get any good idea to move the obstacle freely in the flow field. Please share with me. kuic.kyonggi.ac.kr/~pius/movingflapfvmesh.tgz good luck PIUS |
|
January 16, 2006, 10:08 |
What changes do I have to make
|
#9 |
Senior Member
Frank Bos
Join Date: Mar 2009
Location: The Netherlands
Posts: 340
Rep Power: 18 |
What changes do I have to make in order to use movingFlapFvMesh with the icoFoamAutoMotion solver ?
I recompiled the libraries and included the movingFlapFvMesh sources in the solver's option file, but the new motion is not used when I run icoFoamAutoMotion. Thanks, Frank
__________________
Frank Bos |
|
January 17, 2006, 03:05 |
To Hyung min Kim,
Can you pos
|
#10 |
Member
|
To Hyung min Kim,
Can you post a picture or small movie of your mesh movement? Thanks. |
|
February 7, 2006, 12:36 |
Hi all,
I have got a question
|
#11 |
New Member
Thomas Groensfelder
Join Date: Mar 2009
Posts: 6
Rep Power: 17 |
Hi all,
I have got a question concerning the "robustness" of the moving mesh algorithms. I would like to simulate the fluid flow within an annular cavity, i.e. space between the walls of two cylinders. The inner one is moving around in a orbit, but is not rotating. With the information I found in this thread, thanks to all, I changed IcoFoamAutoMotion to use the motion defined in movingFlapFvMesh. The problem is that I have to simulate a couple of complete orbits to get a quasi-stationary result. I found that during the simulation the grid is getting distorted more and more. It seems that the nodes "remember" the history of their movement through solving of the diffusion equation in every time step. I already know this behavior as I did the same simulation in CFX using their automatic mesh movement algorithms. With CFX I found a way to move all nodes within the area. Looking into the motionSolver directory I found some distortionEnergy functions. Are they used within the movement algorithms or are they just for monitoring use? I found two optional movement methods (laplace, pseudoSolid). Where are the differences? Did I miss an option which can be used for control of the movement? Another way which may lead out of my problem is to use the initial grid for the calculation of the new mesh. Any hints if this is possible to do and how? Third alternative may be to port my CFX algorithms to FOAM. The algorithm is quite simple, I just have to loop one time over every node of the area and calculate the new nodes position. I am sure that FOAM got all the capabilities for my problem, as they are also needed for the motionSolver, too. But as I am not very deep within the FOAM-code I have no idea how to do this. Or where to start. Any comments or help appreciated. Thanks in advance. Thomas |
|
February 7, 2006, 13:23 |
Use laplace with constant diff
|
#12 |
Senior Member
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,906
Rep Power: 33 |
Use laplace with constant diffusion and you will get no history effects. If the mesh gets bad next to the boundary you can try constant with patchEnhanced, which should make it better next to the boundary with minimal distortion effects.
If you are getting LOTS of history effect, it might be that you are not sufficiently converging the motion equation - try converging tighther. I have done quite a lot of these calculations - the original algorithm was written by me and then developed by my former student but I have never seen significant history effects. Any chance of some pictures? Hrv
__________________
Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk |
|
February 8, 2006, 12:51 |
Hi Hrvoje,
thanks for your an
|
#13 |
New Member
Thomas Groensfelder
Join Date: Mar 2009
Posts: 6
Rep Power: 17 |
Hi Hrvoje,
thanks for your answer. I tried to set the convergence criteria in tetFemSolution like == solvers { motionU ICCG 1e-10 0; } == with the result that the solver tells me that the residuals are in the order of magnitude of 9e-11. Motion properties look like: == movingFvMesh movingSFDFvMesh; movingSFDFvMeshCoeffs { Xamplitude .2; Xfrequency 1; Yamplitude .2; Yfrequency 1; Aamplitude 0.; Afrequency 0.; } solver laplace; twoDMotion yes; diffusion constant 1; frozenDiffusion off; == By the way: What does the frozenDiffusion-switch do? As you can see I based my solver on the movingFlapFvMesh-routine. I changed the motion-equations to x = x_amp * sin(omega * t) y = - start * y_amp * cos(omega * t) with start = (1-e^(-0.3 * t/tStep)) (and adequate time derivatives) to come from the centered initial position to the circular orbit within some time steps. Still have the problem that the grid lines start a kind of rotation or remember the path they took. Here are the desired pictures: Initial grid: and after 30 time step = 3 revolutions I know that the time steps are quite large. This is only an example grid for testing purpose. Do you have any hints? Thanks Thomas |
|
May 17, 2006, 09:24 |
Hi Folks!
How is the motion
|
#14 |
Member
|
Hi Folks!
How is the motionU field accessible when using the icoDyMFoam application with runtime selection on the motion solver? I need to add some deformations for a patch based on distance and velocity. Got that part, but can't access motionU. Regards //Eric |
|
May 17, 2006, 09:42 |
When in doubt: cheat :-)
Th
|
#15 |
Senior Member
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,906
Rep Power: 33 |
When in doubt: cheat :-)
The easiest way is from the database: // Grab motion patches tetPointVectorField& motionU = const_cast<tetpointvectorfield&> ( mesh.objectRegistry::lookupObject<tetpointvectorfi eld>("motionU") ); but if you want it from the actual motion solver and dynamic mesh you need lots of casting. I;ll have a look to see if an member function would be easier, but you will still need at least one cast to get to it, which defeats the point... Enjoy, Hrv
__________________
Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk |
|
May 17, 2006, 09:58 |
SHould have thought of that my
|
#16 |
Member
|
SHould have thought of that myself, didn't work though :-(
Had to add the <type> for the cast, i.e. tetPointVectorField& motionU = const_cast<tetpointvectorfield>(mesh.objectRegistr y::lookupObject("motionU")); but got the following error: error: no matching function for call to 'Foam::dynamicFvMesh::lookupObject(const char [8]) //E |
|
May 17, 2006, 10:24 |
Force it - the compiler is con
|
#17 |
Senior Member
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,906
Rep Power: 33 |
Force it - the compiler is confused:
dynamicFvMesh is derived from fvMesh which is derived from polyMesh which is derived form objectRegistry which has got the function you need. So, all is well (I suspect you know how to do this). Without checking, it will be something like: mesh.fvMesh.polyMesh.objectRegistry::lookupObject( ...) Hrv
__________________
Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk |
|
May 17, 2006, 15:24 |
I guess you meant something li
|
#18 |
Member
|
I guess you meant something like...
tetPointVectorField& motionU = const_cast<tetpointvectorfield>(mesh.fvMesh::polyM esh::objectRegistry::lookupObj ect("motionU")); Still the same error :-| //E |
|
May 17, 2006, 15:38 |
Ok, got it...
tetPointVecto
|
#19 |
Member
|
Ok, got it...
tetPointVectorField& motionU = const_cast<tetpointvectorfield&>(mesh.objectRegist ry::lookupObject<tetpointvecto rfield>("motionU")); Works!!! Sorry to bother U //E |
|
May 17, 2006, 17:30 |
Ooops... error in the linker p
|
#20 |
Member
|
Ooops... error in the linker part of compilation... any idea? Posted the code as well...
tetPointVectorField& motionU = const_cast<tetpointvectorfield&>(mesh.objectRegist ry::lookupObject<tetpointvecto rfield>(" motionU")); tetPolyMesh& tetMesh = const_cast<tetpolymesh&>(motionU.mesh()); label domePatchID = mesh.boundaryMesh().findPatchID("DOME"); label topPatchID = mesh.boundaryMesh().findPatchID("TOP"); scalar amplitude = 0.004; motionU.boundaryField()[topPatchID] = vector(0.0,0.0,amplitude * ::sin(runTime.value() * mathematicalConstant::pi)); const vectorField& pointVectors = tetMesh.boundary()[domePatchID].localPoints(); labelList domePatchLabels = tetMesh.boundary()[domePatchID].meshPoints(); forAll(domePatchLabels,pointI) { label patchLabel = domePatchLabels[pointI]; scalar pointRadius = ::sqrt(pow(pointVectors[pointI].x(),2)+pow(pointVectors[pointI].y(),2)); scalar normDist = (pointRadius-0.0024)/(0.00715-0.0024); scalar weight = pow((1 - pow(normDist,3)),10); motionU.boundaryField()[patchLabel] = vector(0.0,0.0,weight * amplitude * ::sin(runTime.value() * mathematicalConsta nt::pi)); } Regards //E |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Moving Reference frame - UDF - Moving mesh | modisa | FLUENT | 0 | April 18, 2008 13:31 |
Moving Mesh & Not Rotating Mesh | AB | Siemens | 1 | October 25, 2004 03:10 |
moving mesh | Jim | Siemens | 2 | August 27, 2002 07:39 |
moving mesh | zqf | Siemens | 1 | June 19, 2002 01:30 |
moving mesh | khb | Main CFD Forum | 1 | June 5, 2002 10:46 |