code_saturne User's Forum

Hello,

I am using the ALE Module of Code_Saturne v.5.0.10. I took a look on the navstv.f90 file and it seems that the internal mass flux denoted "imasfl" is updated twice but this update does not seem to be taken into account by the routine predvv. Moreover a FIXME comment appears at line 1108 of the navstv.f90 file.

So my question is whether the ALE algorithm in Code_Saturne has been validated and therefore if the sequences involving the ALE part in the file navstv.f90 is correct ? Moreover does the implementation respect the so-called Geometric Conservation Law (GCL) ?

Thank you in advance.

Kind regards,

So_nuc

Hello,

Yes, there is an ALE test case (a piston) in the validation suite; and some other ALE tests. I am not too sure about the numerical subtleties here, but recommend checking the source on v6.0, as there has been further work on /use of ALE in that version.

I am not sure about any GCL in our implementation.

Regards,

Yvan

Hello Yvan,

Thank you for this feedback. Then I have tried with the v6.0.1 but I get a SIGSEGV error which I don't get by compiling with the v5.0.10. The error seems to come from the cs_user_fluid_structure_interaction.f90 file when I try to impose idfstr(ifac) = 1 in the usstr1 subroutine.

Have you already tried on your side if compiling without the GUI still works with that version ?

By the way, what is the difference between the legacy and the CDO solver within the ALE modelling ?

Thank you in advance.

Regards,

So_nuc

Hello,

The CDO variant computes the mesh velocity directly at vertices, instead of computing it at cells and redistributing to vertices. It uses the CDO discretization which is usually more robust relative to mesh quality.

Most users have better behavior/less issues with the CDO variant, with one counter-example if I remember correctly.

A colleague tells me that in fact, we probably do respect the GCL.

If you have a small test case on which I could reproduce/debug your crash on v6.0, I am interested.

Best regards,

Yvan

Hello Yvan,

Thank you for these explanations. I give you hereby the test case for debugging. The absolute path to access the mesh has to be added in DATA/cs_user_scripts.py .

Thank you in advance.

Best regards,

So_nuc

Hello,

I fixed the bug in the master and v6.0 branches, so if you pull the version from GitHub and update, things should work now.

A simpler temporary solution may be simply to copy the attached file either in your code_saturne v6.0.1 source tree (replacing src/base/strdef.f90 and reinstalling), or simply copy it into your case's SRC directory (but in this case do not forget to remove it when upgrading to a new release).

Best regards,

Yvan

Hello Yvan,

Thank you for the debugging. It works well and produce better results on that test case compared with the ALE of the version 5.0.10: the physical results were indeed impacted by some spurious loss/gain of energy.

Best regards,

So_nuc

Hello,

That's good news. Thanks for the feedback.

Best regards,

Yvan

Hello Yvan,

After testing some cases with different structure frequency with an explicit/implicit internal coupling (on the same test case which has been transmitted here), I have remarked that the displacement of the structure gets an increasing / decreasing amplitude which has to be theoretically constant in time.

I think the problem comes from the ALE itself. Have you ever remarked such numerical phenomenon on other cases ?

Thank you in advance.

Best regards,

So_nuc

Hello,

I have not worked much with ALE myself, so cannot say whether we have observed tis before or not.

I'll suggest to colleagues who worked on this to take a look.

Do you have this both with the CDO and classical variants ?

Best regards,

Yvan