Sliding and non penetration

[fgillet]

Dear all,

I'm loosing mass through my bottom boundary where I have a sliding law and a non-penetration condition in Normal tangential for the Stokes Solver:
Boundary Condition 2
Target Boundaries = 1
Flow Force BC = Logical True
Normal-Tangential Velocity = Logical True
Velocity 1 = Real 0.0
Slip Coefficient 2 = Variable Beta
Real MATC "10^tx(0)"
Slip Coefficient 3 = Variable Beta
Real MATC "10^tx(0)"
End

The reason is that I have a quite rough topography (so I can have a big angle between the normal of 2 adjacent elements) and high sliding velocities.
It results that the velocity flux through this boundary can be quite important in my mass balance equation (where it should be zero).

Do you have any idea to improve this?

- I have try to put a high Slip Coefficient in the normal direction (1) but I get zero velocity in every direction (so zero flux but zero sliding too!)

- I've been thinking to try 2nd order element, but I'm using 3D wedges elements.
Are 715 wedges supported by ElmerSolver (at least by the Stokes Solver)?
ElmerGrid -increase creates 715 wedges but they are not supported by the "GetElementSide" function to create 408 and 306 on the boundaries.


Thanks for the help

Fabien

[Juha]

Hi Fabien,

you could try constraining the normal velocity only, using "Slip Coefficient 1" (and setting the
tangential slips as usual):

Normal-Tangential Velocity=True
Normal-Tangential Velocity Rotate = Logical False

Slip Coefficient 1 = large number
...

(and no Velocity 1=0)

let me know how it works out?

Regards, Juha

[fgillet]

Hi Juha,

If I put a large number for Slip Coefficient 1 I get zero velocities (in every direction),
so that the no flux condition is respected, but I loose my sliding velocities.

What about 2nd order elements?
Would it be possible to add the definition of 715 elements in the function GetElementSide of ElmerGrid so that ElmerGrid -increase would work for wedges?

Thanks for the help.

Fabien

[Juha]

Well,

the result should not be very different from using Dirichlet condition, possible numerical troubles aside
this should be the condition (u,n)=0 (did you also add the "Normal-Tangential Velocity Rotate = Logical False"
flag?). Try reducing or increasing the "large number", does it have any effect?

Juha

[fgillet]

Hi Juha,

Yes I tried the "Normal-Tangential Velocity Rotate = Logical False"
flag. It has no effect if I use a Slip coeff in direction 1, but I get very high vertical velocities if I use the Dirichlet Condition with this flag.

If I reduce the "large number" I see an increase of the normal flux as expected.

I agree I should get the same result for a flat surface but for the Dirichlet condition I assume that the normal is the average of the normals to each element the node belongs to, so that (u,n)=0 can be true at one node but is not the same as doing the sum of (u,n) over each element; Whereas penalizing with a high slip coefficient enforce the condition for each element so that the only solution is u=0 if there is a discontinuity in the normals.

Increasing my mesh resolution reduces the outflow as expected. I think I should try to smooth also my data to avoid large angles between two elements.
We are thinking also to second order elements and to position the middle nodes in order to minimize the discontinuity of the normals between contiguous elements.

Fabien

[fgillet]

Hi,

I'm coming back to my problem.

I don't understand exactly how Dirichlet conditions are applied with the Normal-Tangential system, but I assume that a normal is computed for every BC nodes and that at each nodes the normal is the sum of the normals to the elements the nodes belong to?
It seems for me that, at least for 202 elements, if 2 neighbors elements have a different area the resulting flux through these 2 elements will be non-nul if the velocity in the middle point is perpendicular to the sum of the normals to the elements.
To ensure a 0-flux, the normal at the node should be a weighted sum of the normals to the elements (the weight being the area). So that the condition (u,n)=0 will not be enforced elmentwise but the contribution in each element should compensate each other so that the non-flux condition will be globally preserved on the BC.

I believe this should also work in 3D?


all the best,

Fabien