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

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

[carlodean]

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?

[lillberg]

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

[kim]

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

[kim]

If anybody is interested above posted movie,
I will send the files by e-mail

[hjasak]

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

[kim]

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

[lr103476]

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

[zou_mo]

To Hyung min Kim,
Can you post a picture or small movie of your mesh movement? Thanks.

[groens]

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

[hjasak]

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

[groens]

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

[lillberg]

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

[hjasak]

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

[lillberg]

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

[hjasak]

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

[lillberg]

I guess you meant something like...

tetPointVectorField& motionU = const_cast<tetpointvectorfield>(mesh.fvMesh::polyM esh::objectRegistry::lookupObj ect("motionU"));

Still the same error :-|

//E

[lillberg]

Ok, got it...

tetPointVectorField& motionU = const_cast<tetpointvectorfield&>(mesh.objectRegist ry::lookupObject<tetpointvecto rfield>("motionU"));

Works!!!

Sorry to bother U

//E

[lillberg]

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