remeshing in ALE to solve large displacement/deformation

[lzhang]

Hello,

I am working on fluid-structure interaction problems with code_saturne, and I use the module ALE to deal with the deformation of fluid domain caused by the movement of the solid.

However, when the displacement is too important, I encounter in my simulation the problem of negative volume. As I read from a previous post viewtopic.php?f=2&t=2220 that no remeshing stage is implemented in code_saturne. So in your opinion, is it possible to implement a basic remeshing module in code_saturne with moderate effort, including mesh quality check, and interpolation of physical quantities? And if yes, which files could I begin with?

Or perhaps you have other suggestions to handle big displacement issue in the context of ALE in code_saturne.

Thanks in advance!

Regards,
Lei

[Yvan Fournier]

Hello,

Implementing a remeshing algorithm directly in the code would require more work, but remeshing between runs (i.e. stopping a run cleanly by limiting the number of time steps to the current or next during the computation then restarting with an interpolation) should be easier.

We do not yet have the interpolation part, but are working on it and expect to have that using Salome's MEDCoupling library within a month or so.

A purely internal solution based on Code_Saturne's PLE library would also be reasonably easy to develop if you are familiar with C programming (requiring just a few days). I could point you to the right files if necessary.

Best regards,

Yvan Fournier

[lzhang]

Hello,

Thanks a lot for your response!

Implementing a remeshing algorithm directly in the code would require more work, but remeshing between runs (i.e. stopping a run cleanly by limiting the number of time steps to the current or next during the computation then restarting with an interpolation) should be easier.

By this, do you mean that we do a restart of the simulation by using the checkpoint directory? I have already tried to restart my FSI simulation from a checkpoint, however my simulation was blocked, probably this functionality is not yet supported when doing Yacs communication. I think that only minor modifications need to be done in order to do the restart, and do you have any ideas?

We do not yet have the interpolation part, but are working on it and expect to have that using Salome's MEDCoupling library within a month or so.

Very good news!

A purely internal solution based on Code_Saturne's PLE library would also be reasonably easy to develop if you are familiar with C programming (requiring just a few days). I could point you to the right files if necessary.

Indeed, I am very motivated to begin with your proposition. Is it still necessary to remesh between runs when using PLE library? I really appreciate it if you can point me where to start.

By the way, do you have any materials that you can share on the ALE method implemented in Code_saturne, please? There are very few things on it in the literature.

Best Regards,
Lei

[Yvan Fournier]

Hello,

Using PLE still requires an interpolation. The idea is to read the first mesh, build the associated postprocessing/location mesh, then read the new mesh, and read a restart file based on the old mesh applying interpolation between old and new.

I have not tested restarts in the current ALE coupling. Do you know at which stage things seem blocked ? Each code should read its own restart file, so I expect things should work as long as the time steps match, but I do not know/have not checked how to do a restart using code_aster, and some step might be skipped in the case of restart.

In the coupling parameters.py file, you can set the coupling's verbosity, so increasing that would help determine where things block (assuming it is due to a message mismatch, which is probable).

Best regards,

Yvan

[lzhang]

Hello,

The simulation blocked with salome_meca2015 with a restart. As now I work with salome_meca2017, the simulation fails to run with an error message in FSI_SATURNE: cfd_by_yacs: ligne 6: ./cs_solver: Aucun fichier ou dossier de ce type. As my priority now is about ALE module or remeshing in Saturne, so I did not do more tests on it.

As shown in the attached file, I have a solid deformed by the fluid. As you can see the purple cell is distorted, and as the time evolves, finally we can have a negative volume of this cell.

So I imagine that the ALE module in Saturne does not check the validity of the mesh. Maybe what I need to do for my application is just to modify the subroutine for the calculation of mesh velocity, for example in the purple cell, if the velocity of the nodes in the right side of the interface is calculated large enough, there would not be a negative volume. This should be much more easier than implementing a remeshing module in the code. What do you think about it? As I have no idea how the ALE module is in Saturne, so could you please give me some indications?

Best regards,
Lei

[Yvan Fournier]

Hello,

Yes, this particular case should not need remeshing, if you can distribute the deformation over a sufficiently large region around the deformed zone, rather than over just the neighboring cells.

This is automatic using the future "CDO" based mesh deformation (already showcased by the boundary layer insertion options in development trunk), but with the current ALE module, I am not sure. I think the two main factors which may impact this are the time step and the mesh viscosity so you should experiment with those.

For the cs_solver" not found, do you have any other failure info (such as a possibly failed config.log file) ?

Best regards,

Yvan

[lzhang]

Hello,

I'm sorry for the late response!

I have tried to define a very large mesh viscosity (1e10) in the vicinity of the moving solid, and a small one (1) for regions far away from the solid. And I also have tried small time steps. For the moment, I still have no correct results.

After reading some references on mesh velocity calculation, I think that maybe I can implement a method which calculate directly node-based mesh displacement/velocity instead of cell-based mesh velocity as has been done in code_saturne. In this way, I can control directly the nodes in order to avoid mesh distortion.

For that I need to know the neighbouring nodes of a specific node, which seems not available in saturne. What I'm trying to do is to build a subroutine which can gives this geometric information. And I put the associated variable in albase.f90 in order that it can be recognized by other modules, like alemav.f90, navstv.f90 etc. However when I compile the code using "code_saturne compile --source", It seems that the definition is not taken into account, moreover the simulation fails because of some Yacs communication issues. Do you have any ideas about that, or maybe I can define the variable in other files, for example as global in order to avoid this problem, so could you explain me how to do it, please?

For the 'cs_solver' not found, I encountered again when I put 0 by error for fluid viscosity. For me, code_saturne detects some error (even without compilation errors), so it refuses to copy cs_solver in the test case directory.

Best regards,
Lei