Moving mesh velocity with restarts

[Ect]

Hi all,

I am currently trying to use Elmer as the cfd-side of an explicit fluid-structure coupling scheme with Code Aster. I cannot use elmer for the structure side because I need axisymmetry, hyperelasticity and contact.

The .sif is build from the structure solution, with an imposed motion on the FSI boundary, handled by the MeshSolve solver. The cfd problem is solved in one step time from a previously saved state. The problem is that the mesh velocity is not correctly computed between restarts: it is always 0 on the FSI boundary.

Restrarts seems to be fine, the .name file does contains all variables needed:
Variables in file: curve.dat
File started at: 2009/10/20 10:39:33
199 boundary nodes for each step
0 polyline nodes for each step
1: Time step
2: Iteration step
3: Boundary condition
4: Node index
5: velocity 1
6: velocity 2
7: pressure
8: mesh update 1
9: mesh update 2
10: coordinate 1
11: coordinate 2
12: coordinate 3
13: mesh velocity 1
14: mesh velocity 2

So I started to play with MeshSolve.src and found that the mesh velocity is computed with:

MeshVelocity = ( MeshUpdate - Solver % Variable % PrevValues(:,1) ) / dt

The fact is that "Solver % Variable % PrevValues(:,1)" contains the previously computed MeshUpdate variable, as expected, but on the FSI boundary it is updated with the current Dirichlet conditions. I tried to save the PrevValues solution right at the beginning of the MeshSolve solver but no luck, it seems to be modified elsewhere.

Then I started to look at the LoadRestartFile subroutine, but does not seems that there is any Dirichlet BC related stuff in it.

Well I'm stuck for the moment because of my near-to-zero F90 level, so if anybody has an idea of what appens to the variables between LoadRestartFile and MeshSolve, his advice will surely be very appreciated

Happy elmer-ing
Ect.

[raback]

Quickly looking through the sif I found the following suspect:

In the expression "Mesh Update 2 = Variable Coordinate 2" chanching the 2nd index to 1 might make a difference. If this doesn't help let's have another go.

Some issues of beuty and efficiency:

In the simulation section set the "Steady State Max Iterations" to 1, as you don't have any real coupling (no effect though). I think it would be better to do the mesh update after the N-S rather than before.

For speed, add this to the two real solvers as the default direct solver is banded lapack

Code: Select all

Linear System Direct Method = umfpack

You can also use an include statement for the linear dependencies as in:

Code: Select all

Surface Height = Variable Coordinate 1
    Real 
      include ../global/growth_bc.dat
    End

-Peter

[Ect]

Thank you for your reply, I have just modified the .sif but the problem is still there. For the "Mesh Update 2 = Variable Coordinate 2" I just replaced it by "Mesh Update 2 = 0" for the sake of clarity.

I made three pictures of the mesh update process: the first one at t=0 shows that the MeshUpdate.1 variable is 0 everywhere

mesh-update-t0.png

(11.41 KiB) Downloaded 217 times

The second one shows the MeshUpdate.1 at t=0+dt:

mesh-update-t1.png

(23.3 KiB) Downloaded 217 times

For the third one I just diverted the MeshSolve's "Solver % Variable % PrevValues(:,1)" variable to MeshVelocity. The picture should show the MeshUpdate.1 variable at t=0, i.e. should be 0 everywhere, but on the updated mesh:

mesh-velocity-t1.png

(18.96 KiB) Downloaded 217 times

We can see that PrevValues(:,1) is 0 everywhere but on the moving boundary where it equals MeshUpdate at t=0+dt.

So, at t=0+dt, PrevValues(:,1) is equal to MeshUpdate at t=0 but with the Dirichlet BC from t=0+dt... which is not what I was expecting because the mesh velocity will be 0 on the FSI boundary.

Any idea on this?

Ect

[Ect]

Here is a picture of the resulting Mesh Velocity :

mesh-computed-velocity-t1.png

(18.59 KiB) Downloaded 217 times

wich is 0 on the FSI boundary.

[raback]

Maybe you can try the following flags of the Simulation section

Code: Select all

Initialize Dirichlet Conditions = Logical False
Restart Before Initial Conditions = Logical True

The 1st one may be what you're looking (the default is True). These take effect in the ElmerSolver.src in subroutine SetInitialConditions.

-Peter

[Ect]

It works !

mesh-computed-velocity-t1-2.png

(17.71 KiB) Downloaded 212 times

Thank you for such a fast answer !
Ect