[virginie_e]

Hello,

I have a question about faMeshDefinition in interTrackFoam.
I know you have already talked about it above in the thread but I still can't get what makeFaMesh does exactly. Does it simply set the boundary of the free surface or does it do something a little more complex?


I have another question, in faMeshDefintion, Jens Klosterman used a faPatch of type wall:

boundary
{
wall_1
{
type wall;
ownerPolyPatch freeSurface;
neighbourPolyPatch wall_1;
}

wall_2
{
type wall;
ownerPolyPatch freeSurface;
neighbourPolyPatch wall_2;
}

I would have liked to make the same, however I am using OpenFOAM-1.5-dev and I get the following error message:
Unknown faPatch type wall

Valid faPatch types are :

4
(
empty
processor
wedge
patch
)

Has the faPatch wall been deleted from the 1.5 version? If yes why and what should I set as a faPatch instead? If no, have you got an idea why I do not have it in the sources?

Thank you in advance.

Virginie

[deepsterblue]

Nope... Nothing is wrong. faMeshDefinition is used to define boundary conditions for the finite-area discretization process. Use the 'patch' type instead.

You can, of course, make your own wall patch type. Might be useful to model dynamic contact-angle problems, actually.

[asaha]

Hello,

I do not know if my question seems appropriate here.
Can I use interTrackFoam solver for damBreak case.

So far I have used interFoam solver and would like to get a grasp of interTrackFoam.

Thanks for the advises from the forum members.


a a saha.

[virginie_e]

Hello,

I have another question about interTrackFoam and this time it is about the algorithm used in freeSurface to move the mesh. (OpenFOAM-1.5-dev)
I understand that almost everything is contained in the class freeSurface and that the spine of the algorithm is the following:

interface.updateDisplacementDirections(); OK
interface.moveMeshPointsforOldFreeSurfDisplacement s(); =>move the internal mesh knowing the position of the freeSurface which has been calculated at the previous time step.

SIMPLE loop => get U,p, phi, meshPhi

interface.movePoints() => only move the free Surface with the displacement (phi-MeshPhi(rho, U))*deltaT/(Sf*(faceAreaNormals&facesDisplacementDir())

My question is in fact on the interface.moveMeshPointsforOldFreeSurfDisplacement s() function.

From what I see, the mesh is previously moved so that the freeSurface comes at its initial position (newPoints[faPatch...]-=totalDisplacement/mesh.movePoints(newPoints))
, then the motionSolver is set so that the displacement of the boundary is equal to totalDisplacement

and then we resolve a laplace or pseudo-solid equation to have the motion of all the points (including internal points) of the mesh.

So finally, my question is: why are we obliged to set the mesh previously so that teh boundary is at its initial position? Would it not be possible just to take the mesh as it is and say that the displacement on the boundary should be 0? Or another way of doing it? I suppose it is all explained in Tukovic's thesis work, but unfortunately I do not speek croatian

So a last question: has Tukovic's thesis been translated in English or not yet? Or are there any references where I could find this explanation?

Thank you very much for your time.

Virginie

[deepsterblue]

Virginie,
Have you figured this out yet? In case you haven't, (and for the benefit of others in the group) here's my explanation:

You will notice that the SIMPLE/PISO loop performs multiple iterations, i.e., an nOuterCorrections loop, where the interface position is updated iteratively based on the latest value of face-fluxes. The freeSurface class accumulates this information for each iteration and performs a single update for the time-step. That is, the interface is moved to the original position, and then the boundary conditions are passed on to the mesh-motion solver.

The reason is two-fold:
(i) The mesh-motion solver requires velocity boundary conditions (motionU), and does nothing otherwise. This is counter-intuitive, because sometimes, I would want to improve the quality of the mesh, even if no boundary motion is taking place. Nevertheless, since that's the way it was designed, I can't complain at the moment.
(ii) If interface motion was done in several steps instead on one big step, the mesh-motion swept volumes would be wrong at the freeSurface. This is the more important reason. The iterative nature of the algorithm is to ensure that fluid fluxes across the interface is close to zero, so that mass is conserved.

Hope this helps.

[virginie_e]

Yes, indeed it clarifies a lot of things... Thank you Sandeep.
I would have another question on interTrackFoam: I am trying to use it on a 3D case however there are points on my freeSurface patch that move strangely so that there are bumps or holes on my freeSurface that should not exist in real life... What is more strange is that my velocity field does not seem to present singularities at these points.

I have seen that there was a function "smooth()" in the freeSurface class that seems to minimize this kind of problem. However, I cannot get what it exactly does...

Could someone explain to me how this function works? or give me any advice on how I should proceed to limit these strange jumps of some of my freeSurface points?

Thank you in advance

Virginie

[deepsterblue]

I'm pretty sure this is a bug. I've seen it too. It looks like it's in the movePoints(deltaH) function, but I really can't be sure, and we'll need Zeljko for that. I'm currently circumventing the problem by averaging cell velocities to nodes and then performing an explicit Euler update to the free-surface. This isn't strictly volume conserving, but it works well. Let me know if you'd like the code.

[virginie_e]

Thank you for your quick answer. Yes, I would be interested by your code. I already sent you an e-mail about it. I suppose you are talking about the pointDisplacement(deltaH) function.
I would have another question about it: Have you got some paper which could explain why it is coded this way? I see that there is a kind of linear system which is resolved to calculate the point displacement from the volumes swept by all the neighbouring faces, but I cannot quite get why it has been done so...
Thank you a lot.

Virginie

[virginie_e]

Hello Foamers,

by having a look at Tukovic's thesis, I have seen that there was a paper (written in English !!!) written by Tukovic and Jasak:
Unstructured finite volume free surface tracking algorithm with automatic mesh motion
which was to be published and which seems to explain the moving of the free surface points in interTrackFoam. Do you know if I could have access to it and how?

Thank you very much in advance.

Virginie Ehrlacher

[kjmaki]

Dear All,

I would like to be able to use a solver that uses the faMesh in parallel. If I try to decompose the sloshing2D tutorial and run the interTrackFoam solver, I get the following error.

---------------------------------------------------------------------
[3] --> FOAM FATAL ERROR:
[3] Cannot find file "faceLabels" in directory "constant/faMesh"
---------------------------------------------------------------------

Has anyone been able to use faMesh in parallel?

Kevin

[jasonchen]

Hello Menon,

I'm using the surfaceTracking solver (fe31) to simulate the water wave problem. What I found is that the free surface has some wiggles and somehow have to be smoothed. The smoothing function in freeSurface class, indeed, helps smooth the surface. But it seems that the mass slightly increases compared with the case without using it. Could you please provide a deep insight into how the smoothing works? Is there a bug? Thank you.

Originally Posted by deepsterblue

I'm pretty sure this is a bug. I've seen it too. It looks like it's in the movePoints(deltaH) function, but I really can't be sure, and we'll need Zeljko for that. I'm currently circumventing the problem by averaging cell velocities to nodes and then performing an explicit Euler update to the free-surface. This isn't strictly volume conserving, but it works well. Let me know if you'd like the code.