Hi, First of all, Pei and Ma
 

Hi,
First of all, Pei and Mattijs, thanks for your reaction.
Pei, the (3D) case, which I would like finally to compute, has a "bad" aspect ratio, i.e., I have about 10 cells in the vertical dimension (to keep aspect ratio of every 3D cell decent), and I have to squeeze fluids changing height by a factor of 50. This means that I cannot remove cells (moreover, I am not really fond of removing cells in VOF simulations - I am sticking to remeshing, well, with other software till now). If you can send to my e-mail address (you have it, I think) what you have till now, it will be very helpful.

Mattijs, thanks for your advice. I have tried it already (I have followed your explanation on damBreak case under threat "automatic mesh motion solver"). I have started, as it was discussed, from modifying motionProperties, but got error message complaining about wrong file format.
Then movingInkJetFvMeshCoeffs part was automatically removed from motionProperties, and further solver complains about missing movingInkJetFvMeshCoeffs.
Anyway, I am making some simple mistakes, I think.
I will try again.
Basically, what I am missing is some general HOWTO on trypical steps required to setup the moving mesh case in interFoam.

Thanks
Sergei

Pei, just a consideration: i
 

Pei, just a consideration:
if you plan to use the movingFvMesh, you may face with conservation problems.
See the
http://www.cfd-online.com/cgi-bin/Op...show.cgi?1/751
discussion.
In this case, it can be worth using the openfoam version 1.1 without performing gamma sub-cycles (that is, 1).
Michele.

sorry the link was http://ww
 

sorry the link was
http://www.cfd-online.com/cgi-bin/Op...show.cgi?1/975

Michele

HI Michele, Thanks for the li
 

HI Michele,
Thanks for the link to your test cases with moving meshes. I have missed that discussion because it was under strange thread, probably as a continuation of another discussion.
Can you give me somewhat more explanation on your case setup.
Is it actually for FOAM 1.2? According to directory structure you are refering to - it is, but I have a bunch of errors while compiling movingPinFvMesh example. Typically, it misses headers of motionSolver, tetFem, and volContinuity (and then some more errors in movingPinFvMesh comes).
It is probably simple mistakes I make, but if you have some suggestions, please.

Thanks in advance
Sergei

You need to adjust the include
 

You need to adjust the include directories in Make/options - all the files you need are still in place. Also, for the kind of mesh motion that mesh performs, you may be better off with topological changes (if you can handle the related solver issues).

Enjoy,

Hrv

Yes Hrv is right. The example
 

Yes Hrv is right. The example posted runs under version 1.2. Today I don't have the code under my hands but tomorrow I can post the Make/options file.
The simulation is the simple column rise due to a moving wall. It can be seen in the movie:
www.lem3.it/tests/movemesh.mpg

The "motionSolver" class is used, with no topological changes.
You can see how the gamma field, initially equal to 1 grows in the liquid phase due to scalar conservation law problems...

Michele.

Hrvoje and Michele, Thanks fo
 

Hrvoje and Michele,
Thanks for the reply. I have missed that, and going to try again.

Thanks

PS.Michele if you have the options file and can post it, I will appreciate.

Sergei, I just posted the opt
 

Sergei,
I just posted the options file (in http://www.cfd-online.com/cgi-bin/Op...show.cgi?1/975)

Please tell me if all is OK.

Michele

Michele, Thanks for your post
 

Michele,
Thanks for your post, and sorry for my delayed respons - I have only today time to look at forum.
I have already figured out, which reference should be included (but have included to many, you "options" file helped me further).
I could run you model and reproduce changes of gamma. Further, solution is very much depending on the choice of different schemes, and number of correction steps for gamma (also, on other factors).
I have a lot of questions (for instance, one should use a "moving wall" boundary condition,I think, but how the contact angle is setup in this case, etc.), and have to try more examples.

Again thanks for your help
Sergei

Hi Michele, I had more time t
 

Hi Michele,
I had more time to look at the moving mesh case, you posted.
First of all about boundary conditions, in your setup (probably, default one) you had all "empty" patches. I have changed those for
left boundary: "moving wall" with specified velocity(don't know how to setup contact angle)
right bounday: "contact angle wall"
lower boundary: "default wall"
upper boudary: "outlet pressure"
front-back: "empty"

I am using fvSchems/divSchemes:

for velocity: Gauss, limitedLinearV (1.0)
for (both) gamma: Gauss, Gamma01 (1.0)

Further I am using adjustable time step, en 2 correctors, and recycles for gamma and pressure (with momentum predictor on)

Well results are OK. I don't know how to attach some few pictures, but you can try it yourself.

Only annoying thing is that FoamX is always overwriting motionPorperties, with a default one after saving a case.

I am going to try some different cases to see whether the solution is always OK at these settings. What happens with other fvSchemes - I don't know yet.

Sergei

Hi Sergei, have you experim
 

Hi Sergei,
have you experimented your interFoam setup on other (moving-meshes) configurations?
I admit I have some doubts on your suggestions: the scalar conservation law should be always satisfied, independently of the time marching scheme / FV discretizations. It should be also satisfied independently on the number of gamma subcycles.

Yours sincerely
Michele.

Hi Michele, I have, indeed, e
 

Hi Michele,
I have, indeed, experimented with movind meshes in 2D and 3D, well, with very primitive mesh motion. I have looked only at squeezing flow, i.e., when one wall is moving in one direction only (in this case I can look at the scalar conservation).
I am always using Gamma schemes, as mentioned above. I know from simulations with a commercial code that this type of scheme gives the best results. For instance, if we are using upwinding for velocity (in a commercial code), results are really bad.
I agree with you that scalar has to be conserved independently of the scheme, however, it does not mean that your will get sharp interface. Indeed, in your example, I have seen that scalar becomes larger than 1, which must not happen, and is really a problem (I have still to test it).
Ok, back to gamma-scheme. In my cases results were rather independent on the number of recycles (I have not used more than 4 for both scalar and pressure), and the compression factor for scalar.
Again, in my cases, scalar was conserved, and always lower than 1 (sometimes, I see 1.00002, for instance).
When flow becomes very complex, in other, commercial, software, I see typically that interface becomes fuzzy.(Mostly, it spreads over many cells). On the same problem setup (meshes, time step, etc), OpenFOAM does something totally different: scalar in heavy phase goes down (it becomes, let say 0.3), and in the light phase, it goes up. Interface, if I can still call it so, is less fuzzy, than in "other" codes (I have to point out that I am using time step adaptation, which means that Courant number is less than 0.2 in my calculations).
Further, I cannot say anything yet, whether behavior of interFoam is correct or not. I do not understand yet, how mesh motion is realized.

Specifically, the boundary conditions in the motionU file are a bit puzzling to me: mesh motion depends very much on which is exactly chosen for the walls. I have been thinking that the criterion for moving boundary is movingWall boundary, but it is not so.
If I need one moving wall and onother - steady, I have to specify "movingWall" and "slip" boundary in motionU. This means that I am doing something wrong.

Mesh motion is important to setup properly, otherwise the fields can be interpolated/mapped wrongly.
Next week I will have some more time to figure out what I am doing wrong (I hope), and try one test case with different schemas, and then, will give some feedback

Sergei

Heya, I do not understand y
 

Heya,

The mesh motion can be done in a number of different ways, depending what exactly you are doing. In the simplest case and the only connection with the flow part you need to specify where each point is moving in time, either by hand or in some other way.

If you are using my automatic mesh motion solver, the idea is this:

- the user defines the motion of the boundary and is not really inetrested in anything else

- an equation for mesh motion is solved on the points and defines the motion of all mesh points as a function of the prescribed boundary motion. The solver is written to specifically prevent mesh overlaps and deterioration of mesh quality

- in order to specify the motion, you need to set up the boundary conditions for it: this is a point-based field (I have written a FEM solver for it) and it's typically called motionU. If you want to prescribe how the boudnary moves, use fixedValue, if you want a slip, use sli and for a free boundary use zeroGradient. There are also complex boundary conditions for more clever stuff.

One more thing: if you are moving a wall, you have to make sure that on the CFD/FVM side there is no flow through it. Thus the normal component of velocity (because we are working in the global Cartesian coordinate system) needs to exactly cancel out the mesh motion flux. In simple cases you can do this by hand but it's a pain.

The nice way of doing this is to use the movingWallVelocity b.c. on the FVM velocity (!) which will do the correction for you.

Hope this is now clear,

Hrv

Hrvoje, Thanks for the quick
 

Hrvoje,
Thanks for the quick reaction. I am already that far to understand which (simple) boundary conditions work in moving mesh solver.
Indeed, the velocity components of moving wall should be the same for moving mesh and the movingWallVelocity, which I am using, boundary condition in FV part (I think this what you mean by "cancel out"). In commercial codes, we even impose a more strong condition: the time step should be chosen so that the motion per time step is only some part of the rescaled cell dimension, otherwise field interpolation is not always exactly OK (but this depends, of course, on solver).
Well, back to interFoam. I need to have a capillary effect, which means contactAngleWall, which again for FV solver for velocity is just fixedValue wall, and it is moving wall for moving mesh solver. I need two walls with capillary effect, i.e., contactAngle Walls: one moving and another - not. At the moement, with "simple" rescaling algorithm (on the basis of MovingPin example) I have got from Michele, both walls will then be moving.

My question is if I am using "slip" value in FEM part for the wall, is it also "slip" in FV, or FV part takes boundary condition from U file? May I use totally different boundary conditions for FEM and FV parts, or there is some correspondence?

Why I am asking this - it is simply wrong to use "slip" with VOF and contact angle at the wall in FV part.
Well "zeroGrad" wall works, indeed, OK, and I have not seen complains about outletPressure.

Hrvoje, thanks again for your e-mail.It helps to understand better what happens in the moving solver.
Please, if you have some suggestions how to resolve these boundary conditions in interFoam solver, I will appreciate.
This may have imact on the solver results.

Further, I will test discretisation schemes in interFoam without capillary effect for a while, i.e. theta=90, zeroGradient and fixedValue walls in FEM and FV parts.

Sergei

Heya, In commercial codes,
 

Heya,

Can you tell me which code is that? In FOAM, there's no field interpolation on mesh motion, everything is done by the moving mesh formulation.

FEM-FVM boundary conditions: Apart form the "prescribed" b.c.-s which come from the mesh (like parallel, wedge or symmetry plane), there's no connection between the two solvers. Therefore, you're free to separately specify the b.c.-s on U and motionU in any combination you wish. Just think about it as tow separate solvers operating on the identical mesh. :-)

Capillary effect: There were some people who tested this in the past and they said the pressure jump was spot on. Should be no trouble.

Hrvoje, We are using family o
 

Hrvoje,
We are using family of STAR solvers.
About time step. Well, if you would run case with, for instance, sliding meshes, and look at the (real) pressure during sliding, then you will probably see a (slight) difference depending on the time step chosen (in cases with partially overlapping boundaries - I am pretty sure). If you see difference in pressure, you will see the difference in VOF (at least, it is so in STAR)
Further, it will also have impact in conjugate heat transfer problems. For other cases I don't know.

Ok, about FOAM. Hrvoje, in your motion solver, is the fields mapped from old to new (deformed mesh) mesh? Can you say something on how the new fileds are derived.

Again about time step, now in FOAM.
Is it actually not the same as using Co< 1 for piso, and Co<0.2-0.3 for VOF interface? In this case, only, I am not sure how the solver estimates the time step for the next iteration in VOF solver, when mesh is deformed.
Further, I have been thinking, that in VOF method you always have reconstruction/interpolation of scalar at interface, but, probably, it is my mistake, and you don't have it in FOAM (?)

Thanks for the explanation on boundary conditions for FV and FE part

Sergei

Hi, STAR - I know all about
 

Hi,

STAR - I know all about it, my PhD work was sponsored by the company and I've worked there for 4 years.

Please have in mind the conceptual and implementation difference between the moving mesh, where the number and connectivity of points, faces and cells remains unchanged and topological changes, where it does not.

Field mapping

As I said, if there are no topological changes, no field mapping gets done. Instead, the integral equations we are discretising are rewritten for the arbitrary moving control volume instead of the static one. There are two effects:
1) the rate of change of the volume in the ddt term (vol and old vol)
2) the relative velocity in the convection term, equal to the difference between the absolute velocity and the mesh motion velocity - that's the mesh.phi() bit in the solver. Once you do that, the mesh motion effect is actually built into the equation itself and the "mapping" you refer to becomes a part of the solution.

When topology changes are present, the morph engine stuff that I've implemented will handle the renumbering issues between the old mesh and the new. This simply takes care of the ordering, addition and removal of the points, faces, cells etc. but does not do the global integral corrections as needed (the latter is done algorithmically).

Time step estimation

Always in the same way, from the Courant number on the face. The only difference is that on moving meshes you need to take care of the mesh motion flux, i.e. the volume swept by the face in motion during a time-step.

Enjoy,

Hrv

Hrvoje, Yes I know that you h
 

Hrvoje,
Yes I know that you have experience with star (basically, STAR is an Imperial College code).
Thanks for the information - I understand now a bit better, in general lines, the concept.
I am going to run some more test with yours mesh solver in combination with interFoam.

Sergei

Hi, Can any one here help me
 

Hi,
Can any one here help me how to define the (initialsetfield) of gamma. I want to simulate the motion of a spherical bubble and I can't define the circle in the initialfield. It is a uniform value not like the bubbleFoam case. Another question, if I have an initial shape defined with analytical equation how to implement it ?
give a help please.

Hi Michel, I had no time late
 

Hi Michel,
I had no time lately to try some different cases with moving meshes, that is why there was no reaction to your message.
Well, I have run some different cases now, but again, on a simple squeezing flow.
The discussion above on the boundary conditions was, that the velocities defined in the FEM (motion) solver, have also to be defined in FV part of the solver on corresponding boundaries (patches), which according to your last message is realized automatically.
But, for instance, if I have mesh motion with sufficiently small, initial time steps, my results are always OK (well, after motion scalar jumps slightly above 1, but then it is corrected), and does not depend on whether I have 2 through 6 correction in PISO for both pressure and scalars (again, I am using Gamma scheme for scalar always, and tried different variants for velocity - LinearV and GammaV)
When I am choosing rather "large" initial time steps, then, sometimes, I see that at some time scalar starts to grow above 1, and it is not corrected well anymore. If I let the simulation run further, it simply diverges after a while (by this I mean that things are running on screen, but I am getting NaN for the scalar value).
Have you actually tried your "bad" cases with much smaller time steps (and, which, inital time steps you are using, presuming that you have an automatic ajustment of time step in your setup).
Therefore, I am not sure what interFoam does exactly to keep Co<0.2, when dealing with moving meshes.
Again, these are my speculations, which are based on your motion class (I did not find a better example, and yours is working well for me, thanks for this). Further, I am not good in c++ at all, and, therefore, not in the position to judge, whether it is well written.

Thanks for your explanation on the implementation of the motion and boundary conditions. I am planning (when I will find some spare time) to look at yours movinBodyFvMesh case, and share my impressions with you.

Thanks again
Sergei