periodic BC and moving mesh

[mulvrova]

Hello Elmer team,

I am solving N-S and heat equation in cartesian 2D box with phase change interphase, so phase change solver and mesh update solvers are used. Periodic BC on vertical sides of the box for temperature and velocity are prescribed. However, after looking at results, temperature and velocity are periodic on non-deformed mesh. After updating mesh (new mesh position 2= coordinate 2 + mesh update 2) variables are no more periodic. I tried to add
periodic BC mesh update 2 = logical true
but then mesh update solver doesn't converge even for small displacements. Do you have any suggestions how to force periodic BC on moving mesh?

regards, Martina.

[raback]

Hi Martina

The phase change solver is not periodic, I think, and will give you sligtly different values for the displacements of the corner nodes for the free surface? Maybe these wont mix well with the periodic BCs of the MeshUpdate solver. They should, but that's the only thing I can think of.

You could test this by replacing the free surface of the mesh update with some constant value. If this works without problems then I think the problem is located. The remedy would be to study why there is a conflict of these two, or maybe easier to make the phase change solver periodic. You could perhaps do it by construction afterwards by setting both of the extremum values to their mean with a small hack in the PhaseChangeSolver code.

-Peter

[mulvrova]

Hello Peter,

thank you for your reply. I replaced the mesh update of the interface by a constant value, let's say e.g. mesh update 2 = 0.001 at the free surface. When looking at results in the file line.result, the coordinate 2 (that is in this case already updated position, i.e. initial coordinate 2 + mesh update 2) was shifted the first time step about 0.001 and then stayed constant. Despite that I was waiting the update of coordinate 2 about 0.001 each timestep, periodic temperature and velocity are maintained at the boundary. So it's the phase change solver that is not periodic as you suggested.

anyway, when phase change solver is used to update the interface position and the interface moves relatively "slowly" the BCs remain periodic or "nearly" periodic, i.e. the values at sides differ by the order of per mille.

best regards to the elmer team, Martina.

[mulvrova]

That's what is in the source code of phase change solver

No Dirichlet conditions here since
One should not really try to force the phase change at some point,
rather use feedback to tune the pull velocity

so if I understand well no BC are considered when using the phase change solver?

[raback]

Hi Martina,

You could enforce the phase change to be periodic. Write after SolveSystem something like

Code: Select all

meanu = (SurfaceMove(SurfacePerm(Trip_node))+SurfaceMove(SurfacePerm(Axis_node))) / 2.0_dp
SurfaceMove(SurfacePerm(Trip_node)) = meanu
SurfaceMove(SurfacePerm(Axis_node)) = meanu

Hereby enforcing the periodicity. Of course it would be prettier to solve a periodic system in the first place but here the equation in question results to a mass matrix and it should be close enough This way you can also check whether this really is the problem. Also adding the default dirichlet conditions should do the trick given that you specify the periodicity in the .sif. This is of course the desired way but the 1st one is maybe easier to check given that the solver includes some historical weight, and its not clear that the periodicity should work with 1D equations.

BR, Peter

[mulvrova]

Hello Peter,

thank you for your reply, I always forget the perm vector ... (I was trying meanu = 0.5_dp * (SurfaceMove(1)+SurfaceMove(Size(surfacemove)) ). However, after imposing the right mean value, phase interface deforms only very slightly (it seems like changing the boundary values prevents the deformation), moreover coordinate 2 is not really periodic.

So I tried to add

Code: Select all

  CALL DefaultDirichletBCs() 

before SolveSystem(.....,surfaceMove,....) but coordinate 2 is still not periodic.

Kind regards, Martina.