[gtg258f]

Dear all,


I have a question regarding the update of the different variables or fields after a mesh deformation.


I solve a solid problem, and for a while was using the standard procedure for the deformation of the solid phases in the solid solvers offered in openFOAM (the latest I used is moveMesh from elasticNonLinSolidFoam). From my understanding, this deformation is Lagrangian, meaning that each of the mesh points is moved by the displacement U obtained at that location.


Such procedure works fine for close to solid body deformations. In my case, I have quite large compressions in some regions and not in others. As a result, a purely Lagrangian formulation leads to a deterioration of the mesh quality. I thus adopted the procedure that is used for fluid phases and am using the dynamic mesh motion capabilities (more precisely the displacement Laplacian with inverse distance diffusivity with respect to the moving boundary).


This yields a much better mesh, but .. I am not sure that my fields are transferred properly: The solution reached differs depending on my choice of mesh motion procedure.


As an example, Fig 1 (compareOldNewMotion_T50.png) shows the deformation of a cylinder subjected to a pressure load on the inner surface, with two different mesh motion procedures (moveMesh vs. dynamic mesh). Dynamic mesh definitely yields a better mesh quality, but the displacement and pressure profiles differ …


The procedure I follow for the mesh deformation is as follows:

pointVectorField pointsDispl =  cpi.interpolate(U); 
displacementSolidPatch == pointsDispl.boundaryField([solidPatchID].patchInternalField(); 
mesh.update();

where cpi is the cell to point interpolator. Taking a given time step, I looked into what happens to my fields before and after mesh.update(); Cell coordinates and volumes are updated but all other fields remain the same. While that would be correct in a purely Lagrangian deformation, it is not for an arbitrary mesh deformation. This is illustrated in Figure 2 (transferOfFieldU.png) which shows the displacement (U) profile before update (Eulerian), the profile that would be obtained when plotting U vs. the old coordinates+the displacement (Lagrangian) and the profile obtained after mesh.update().


I think I am missing something about the transfer of variables but haven't been able to find the answer in the different tutorials. Should I do an interpolation from the Lagrangian mesh to the smoother one obtained using mesh.update()? Would you have an example solver in mind that I could follow?


Thank you for any help,
Diane

[bigphil]

Originally Posted by gtg258f

I solve a solid problem, and for a while was using the standard procedure for the deformation of the solid phases in the solid solvers offered in openFOAM (the latest I used is moveMesh from elasticNonLinSolidFoam). From my understanding, this deformation is Lagrangian, meaning that each of the mesh points is moved by the displacement U obtained at that location.


Such procedure works fine for close to solid body deformations. In my case, I have quite large compressions in some regions and not in others. As a result, a purely Lagrangian formulation leads to a deterioration of the mesh quality. I thus adopted the procedure that is used for fluid phases and am using the dynamic mesh motion capabilities (more precisely the displacement Laplacian with inverse distance diffusivity with respect to the moving boundary).


This yields a much better mesh, but .. I am not sure that my fields are transferred properly: The solution reached differs depending on my choice of mesh motion procedure.

Hi Diane,

You are right that the elasticNonLinULSolidFoam solver adopts a Lagrangian approach, so it assumes that there is no mass transfer in or out of each cell. So when the mesh is moved, it is moved using the solved-for displacements meaning there is no convection (mass transfer) between the cells.

But in your case when you move the mesh using the fluid mesh motion classes then there will be a flow of mass across the cell surfaces and the momentum carried by this convection needs to be accounted for.

So essentially you need a solver using an Arbitrary Lagrangian Eulerian (ALE) approach instead of an/a updated/total Lagrangian approach. An ALE approach is where the mesh coincides with the material deformations only at the boundary and independent of each other elsewhere. ALE methods are often employed for modelling solids which undergo very large deformation e.g. extrusion and metal forming processes.

The bad news is that there is no OpenFOAM ALE for solids (although I think it is used for interface tracking in interTrackFoam).

The good news is that OpenFOAM is perfectly suited for ALE for finite volume (FV) solids as it has all the convection and mapping stuff.
Also there is considerable literature on ALE methods for solids.

If you do intend to develop an ALE FV solid solver then I can help you if you like.

Best regards,
Philip

[gtg258f]

Hi Philip,

First of all, happy new year!!
Sorry for the late reply, I went on a internet-break over the Christmas vacations!

I have been reading about ALE already, and believe that this is indeed what I will have to do as my solids deform to much for me not to loose mesh quality over time.

I would be delighted to discuss the matter with you when you have time. Especially mapping as it is something I am not familiar with and I guess that talking about it with you could make things go much faster!

Let me know when and how you would prefer to do that.

Best regards,
Diane

[Hisham]

Hi Phil and Diane

Very interesting topic ... can you please keep the discussion here!

Best regards,
Hisham

[bigphil]

Hi Hisham,

I will post here when I start getting some interesting results.

A nice description of ALE methods is given in the online Encyclopedia of Computational Mechanics - Chapter 14 - Arbitrary Lagrangian-Eulerian Methods.

Best regards,
Philip

[Hisham]

Thanks and best of luck

[ziemowitzima]

Hi,

I am working currently on a solver with a moving mesh. Actually one boundary of a domain is changing according to the solution of some other equation.
I implemented the mesh changes similar to icoSructFoam solver.
But to update my mesh I need to add following line:

 mesh.update();

which is not included in icoSructFoam...

I am confused because my mesh is not get updated without this command, but mesh in icoSructFoam is updated...


Anyway more important/confusing is that my solution, after mesh is updated, behaves somehow strange. Energy is added to the system, what is not a case if mesh is not deformed...
It happend for a advection-diffusion equation, which should just diffuse with time.
It behaves like that if mesh is not changed. But if it is changed, energy is somehow added to the system and field gets stronger and stronger with time...

I hope anyone will have any suggestions.

ZMM

[ziemowitzima]

Hi,

mesh.update();

is not a problem anymore, I found the differences between my solver and icoStructFoam.

But I still have the problem with energy being added to the system after mesh is changed.
It happens for simple diffusion equation:

fvScalarMatrix omEqn
        (
        dimDt*fvm::ddt(om)
       - fvm::laplacian(dimensionedScalar("1",dimensionSet(0, 2, 0, 0, 0),1), om)
         );        
        omEqn.solve();

if mesh does not change, or change only "a little" then it behaves as diff equation, namely field "om" diffuses out, and getting weaker.
But if mesh is changed "little more than a little" then "om" gets stronger and stronger with each time step...

Do you have any clue why it is like that ??

thanks
ZMM

[alundilong]

Originally Posted by ziemowitzima

Hi,

mesh.update();

is not a problem anymore, I found the differences between my solver and icoStructFoam.

But I still have the problem with energy being added to the system after mesh is changed.
It happens for simple diffusion equation:

fvScalarMatrix omEqn
        (
        dimDt*fvm::ddt(om)
       - fvm::laplacian(dimensionedScalar("1",dimensionSet(0, 2, 0, 0, 0),1), om)
         );        
        omEqn.solve();

if mesh does not change, or change only "a little" then it behaves as diff equation, namely field "om" diffuses out, and getting weaker.
But if mesh is changed "little more than a little" then "om" gets stronger and stronger with each time step...

Do you have any clue why it is like that ??

thanks
ZMM

Hi ziemowitzima,

I am also stick to this problem. Do you have any clue?

[alundilong]

Originally Posted by ziemowitzima

Hi,

mesh.update();

is not a problem anymore, I found the differences between my solver and icoStructFoam.

But I still have the problem with energy being added to the system after mesh is changed.
It happens for simple diffusion equation:

fvScalarMatrix omEqn
        (
        dimDt*fvm::ddt(om)
       - fvm::laplacian(dimensionedScalar("1",dimensionSet(0, 2, 0, 0, 0),1), om)
         );        
        omEqn.solve();

if mesh does not change, or change only "a little" then it behaves as diff equation, namely field "om" diffuses out, and getting weaker.
But if mesh is changed "little more than a little" then "om" gets stronger and stronger with each time step...

Do you have any clue why it is like that ??

thanks
ZMM

Have you ever tried to subtract flux caused by boundary moving?
fvScalarMatrix omEqn
(
dimDt*fvm::ddt(om)
- fvm::laplacian(dimensionedScalar("1",dimensionSet( 0, 2, 0, 0, 0),1)
- fvm::div(mesh.phi(), om), om)
);