[patriem]

Hallo Foamers,

currently i am spending weeks to settle up a testcase with an harmonic oscillating plate. The mesh already exists and also my testcase with all files. Is is was set up basing on the dynamicmesh-tutorials. The configuration isn´t very complicated and easy to understand.

The problem: The mesh motion doesn´t seem to be correct, the plate isn´t moving at all, the cells around do a little oscillation but only a little bit.

It would be a great help if someone with more experience could check my setup and maybe run the movingDynamicMesh one time.

For easy understand there is a description with images in the zip file and many comments in the correspondig files (motionU, 0/U, boundary, dynamicmeshdict, ...) Again it would be a great help and one big step forward in my thesis work!

Regards,
Patrick Riemer

Setup was done in 1.4.1-dev

[patriem]

[patriem]

Finally;)

http://home.arcor.de/patrickriemer2/actuator.tar.gz

[patriem]

Thank you Mathieu,

i´m trying that right now. maybe my timestep was to high....

Another i think very important thing:
At the moment i use laplacefacedecomposition and a motonU file with oscillatingFixedValue b.c. to define mesh-motion. Version 1.4.1-dev. But i am not sure about the appropriate files:

src/finiteVolume/fields/fvPatchFields/derived/oscillatingFixedValue/
Is the internal-meshpoint motion dscribed here?

src/OpenFOAM/fields/PointPatchFields/derived/oscillatingFixedValue/OscillatingFi xedValuePointPatchField.C
Is the movement/velocity of the oscillating b. c. described here?

Having a simple cos-equation of the velocity, these files have to changed and recompiled then, right? In both cases with wmake libso in the openfoam-folder?

Thank you for answers...
Regards
Patrick

[mathieu]

If you use laplacefacedecomposition, you only need to change this file:

src/OpenFOAM/fields/PointPatchFields/derived/oscillatingFixedValue/OscillatingFi xedValuePointPatchField.C

and recompile with " wmake libso " in the src/OpenFOAM folder.


The file src/finiteVolume/fields/fvPatchFields/derived/oscillatingFixedValue/ is not "linked" to the laplacefacedecomposition motion solver (as far as I know).

Mathieu

[mathieu]

Ooops !

If one modifies the file:

src/OpenFOAM/fields/PointPatchFields/derived/oscillatingFixedValueOscillatingFix edValuePointPatchField.C

then the recompilation must be done like this:

cd ~/OpenFOAM/OpenFOAM-1.4.1-dev/src/tetDecompositionFiniteElement
./Allwmake

Sorry !

Mathieu

[obraun]

Hi everyone...

is there any detailed documentation about the moving mesh stuff out there than going through the code line by line?

I am doing some moving mesh stuff, an oscillating pitching motion at the time being, mainly using CFX and we decided spending a little time to see if this is feasible in OpenFOAM. Got along the first basic tutorials, and up to now things seem fine.

Now I have implemented a special mesh motion based on purely algebraic rules and implemented as UserFortran in CFX and it works fine. I want just to underline this rule determines the deformation of the entire mesh, not only the boundary. It is just a simple blending of a solid body rotation in the vicinity of the foil and zero displacement at the test section walls.

Where could I hook this up in OpenFOAM? I basically have a few lines of code that allow me to compute displacement per timestep based on t, and x,y,z, being it of the former step, being it initial positions, whatever.

Any advice at which tutorial example to look first is welcome, it is easy to get lost in it, or did I just not find the right documents that go with it ?

Final goal is to add the mesh motion into the oodles solver, but that's for later once I really understood how to recombine features of different apps.

BTW we aim at medium reduced frequencies, so that at the one hand the mesh motion should not too heavily impact on stability and accuracy with the time steps needed for LES, and at the other we can afford solving for all the time interval needed for the motion of the profile. This is something we clearly cannot do with a limited number of licenses of a commercial tool...

Kind Regards

Olivier

[chbenz]

Hi Olivier,

OF is very appropriate for moving meshes. A good start is the movingCone tutorial in
$FOAM_TUTORIALS/icoDyMFoam. Oscillating Boundary conditions for the motion is also available in OF.

Literature you can find on the homepage from Prof. Jasak http://www.h.jasak.dial.pipex.com/.

Regards,
Christof.

[lr103476]

Hi Oliver,

Basically, there are different ways to define the displacements of all mesh points, i.e. to define a complete motion solver (living in dynamicMesh) or to define a dynamicFvMesh based class in with you define the mesh points of either only the boundaries, or all mesh points, using the newPoints() function.

Here is an example library, derived from dynamicFvMesh, which defines the mesh points using newPoints(). It is just an oscillation of internal nodes. Here it is: .
Just put it in your own myDynamicFvMesh lib, or something like that.

Goodluck,
Frank

[lr103476]

Allright, the message board is not behaving like it should.

Take it from here:
http://www.zswk.nl/~frankbos/downloa...rnalFvMesh.tgz

[obraun]

Hi Frank,

Thanks a lot for the useful hints. The dynamicInternalFvMesh looks pretty much precisely like what I need. I still did not capture everything about how to hook it up and make it effective and we have some install issues about recompiling I have to check with our admin... but thanks to you I feel it might be faster to go than I initially thought.

Olivier

[lr103476]

Hi Olivier,

No problem. Why don't you use the existing mesh motion solvers? Is it for comparison with CFX?

You said something about blending the rotation to the outer boundaries. Take a look at the new RBF mesh motion solver in OF-1.5-dev. The new mesh points are calculated based on Radial Basis Function interpolation, including some cut-off (blending) function towards the outer domain. You may find it usefull.

Cheers, Frank

[obraun]

Hi Frank,

right, if I want to compare flow simulation results, I want to be sure that at least the mesh motion is the same. In fact, people here doing pitching hydrofoil studies before experienced lots of trouble with the high aspect ratio hex elements behind at a thin trailing edge meshed with a C-grid approach...when using the CFX built in diffusion or fluent's spring stiffness...

Starting from this on I looked into mesh motion procedures, also in context of morphing for optimization. RBF is one of them. The dev thing in OF-1.5-dev might refer to Computers and Fluids 2008 paper by ,uhhhmmm, Jakobsson and Amoignon... doing precisely what you described.

In fact my optimization objectives are the outcomes of a pitching cycle simulation using RANS.

Finally I want to validate these by a more elaborate (let's say fancy :-)) approach like DES, LES...

Well it's kind of mixing different things into a tasty dynamic mesh jam and as I was sure to be able to handle all these motions algebraically, I did not want to rely on any diffusion, spring stiffness or whatever black box scheme. Now that I have it implemented, I see it is very efficient (close to no cost at all) and conserves 100% mesh quality in the zones of interest. So why should I go for something else? In my opinion, using PDE-solvers when you can have a rigid body rotation plus a blend is kind of overkill. For sure the PDE method has the advantage of being generally available once it works fine, that's why the commercial codes got them quite quickly and that implementing user-controlled mesh motion is quite a pain in...

Have a nice weekend

Olivier

[patriem]

Hallo Foamer-Community,

i set up a testcase with a moving mesh including layeraddition/removal based on the movingconetopo tutorial. If i run a moveDynamicMesh, i soon get bad cells and faces near or on my moving boundary. It is an oscillating plate in a cavity. Could you please have a short look on what is going on there?
I think my meshmodifier and dynamicmeshdict is right so i don´t understand where my error is.

Much thanks and regards
Patrick

http://rapidshare.com/files/20031991...po.tar.gz.html

[patriem]

Hello,

for an oscillating sine motion with vel_amp_x=0.226m/s and frequency of 128Hz i used oscillatingVelocity and a pointMotionU with


type oscillatingVelocity;
omega 804.096; //=2*pi*f
amplitude (0.226 0 0);
value uniform (0 0 0);

But the oscillating amplitude seems to be much too high. what do i do wrong? The oscill....C file under fvMotionSolver/pointPatchFields/derived/oscillatingVelocity
is standard with
(p0_ + amplitude_*sin(omega_*t.value()) - p.localPoints())
/t.deltaT().value()
);

Thank you for a hint

[cwang5]

Hi guys,

I'm kind of new to the programming part of OpenFOAM, and ran into a couple of problems so far.

Frank mentioned something about adding the files into a myDynamicFvMesh lib, but I am clueless as to how to proceed, is there a tutorial somewhere I can follow? I've searched the forum for "edit lib" or "add lib" and came up empty.

Thanks in advance for any helps.

John

[cwang5]

Originally Posted by cwang5

Hi guys,
Frank mentioned something about adding the files into a myDynamicFvMesh lib, but I am clueless as to how to proceed, is there a tutorial somewhere I can follow? I've searched the forum for "edit lib" or "add lib" and came up empty.

Right, so I searched a couple more post and found the solution by searching the term add src", turned out that I should've used the wmake libso command instead of wmake.

[hjasak]

Your problem is that the FEM boundary condition does not necessarily hold the value: the value is already held within the internal field. Have a look at how I did it in the FSI solver.

Enjoy,

Hrv

[obraun]

I meanwhile implemented my mesh motion similar to the fvDynInkJet example, recomputing all of the mesh node positions based on simple algebraic rules, just for an oscillating profile. So far so good, but I now just wonder what I have to specifiy as boundary condition for the oscillating profile:

Is zero velocity ok (which means velocity is automatically interpreted as relative to the moving mesh)

Or do I have to re-specifiy the same oscillation as a function again to be coherent with the motion in an absolute frame consideration?

Sorry I am not experienced enough to dig into the depths of all the basic routines to find it out mayself, and I hope one of the gurus has a quick answer to this simple question.

Regards

P.S.: And i just see the angularOscillatingVelocityPointPatchVectorField would be about what I need if i need to

Olivier

P.P.S: And that the question is related to what "U.CorrectBoundaryCondition" does, which is not so obvious to understand for someone not familiar with the deep hierarchy of the dynamicFvMesh class...

P.P.P.S: ok, the movingWallVelocity seems to solve the problem, at least the velocity values in the results are continuous at the boundary now, U representing the velocity in absolute frame, being equal to the wall motion velocity at the boundary. Is this what it should be like, I suppose...

[Daniele Trimarchi]

Hi Foamers,
I'm trying to do FSI with OF 1.6.x, and for the moment I'm trying a code-code coupling passing files.
Now, I manage to read the file for boundary-cell displacement using something 'stolen' from IcoStructFOAM: similar to what hjasak suggested in the thread
[QUOTE=hjasak;179117]When in doubt: cheat :-)

This is the (working) code:

volVectorField::GeometricBoundaryField &meshDisplacement =
const_cast<volVectorField&>(mesh.objectRegistry::l ookupObject<volVectorField>("cellMotionU")).bounda ryField();

label fluidSideI = mesh.boundaryMesh().findPatchID(sail);

vectorField &mDisp=refCast<vectorField>(meshDisplacement[fluidSideI]);

List<vector> dispVals(fluidMesh.size());

std::ifstream fin("Displ_out");

forAll(fluidMesh,i) {
fin >> u;
fin >> v;
fin >> w;

dispVals[i][0]=u;
dispVals[i][1]=v;
dispVals[i][2]=w;

vector dd = dispVals[i];;

mDisp[i]=dd;
}


This works fine, since it assignes values from the file to the referenced boundary field of the volVectorField in cellMotionU.

Now, if I want to do similar things for pointMotionU, I gets troubles, because it is a pointVectorField, and I can't find how to deal with it's boundary field.

The only things which seems to be working is:

pointField& pointMotion = const_cast<pointField&>(mesh.objectRegistry::looku pObject<pointField>("motionU"));

Which gives access to the pointField, but no way to get to the boundaryField


Any help would be more than welcome..!