coupling with code_aster deformation issues

[Luciano Garelli]

Hello Yvan and Paul,

I'm trying to solve an FSI problem with Saturne and Aster. I have read several post about how to couple them. I'm using CS version 5.0.9 (unreleased) download from the repo due to a patch was applied recently and the universal salome-meca 2017.0.2 distribution.

The first problem was the library libFSI_SATURNEExelib.so with an undefined symbol. This error was mentioned in this post https://www.code-saturne.org/forum/vie ... hp?t=1957 . I was compiling CS with gcc 7.2.0 and the solution was compile CS with gcc 4.9, the same that used to generate the universal version salome-meca.

After that I run the external cylinder problem shared by Yvan and the solution of the coupled problem works.

I have the same "dirty finalization", more over the prompt is not returned so I have to kill after CS and CA finished the runs. The same problem with the setting of the NALINF variable and also with the restart. When the simulation is restarted from a previous case in CS and error message about differences in the time appears.

The last and unresolved problem appear when the solid has to be moved by the fluid. I have changed a little bit the external cylinder problem. I set a inlet velocity in some faces (x<-0.075) and an outlet at (x>0.075). The pure CFD problem works perfectly and the karma vortex street appears. When I try to couple with CA the run blows up after several time steps due to a negative volume in CS. I try several solutions like increase the rigidity of the spring in aster comm file, reduce the time step, let only the FY force component and fix FX and FZ, etc.

I'm a bit confused about this behavior....any idea?

Best Regads,

Luciano

[Paul Brss]

Hi Luciano,

I didn't do too much with that case as I'm trying to set my own now.

Yet, I've also changed it a bit, but only on the structural parameters like the initial velocity, young modulus, etc... Your problem seems to be related to the ALE method isn't it ? Negative volumes appear when the mesh is too distorded. How big are the cylinder displacements ? My fisrt guess is to change the mesh viscosity... Yvan might have a better guess.

Regards,

Paul

[Luciano Garelli]

Hello,

The mesh viscosity is set very high near the cylinder. I want to find an equilibrium between the drag force and the spring. With a high rigidity for the spring the displacement should be small.

I will shared the case.

Regards,

Luciano

[Yvan Fournier]

Hi Luciano,

As you seem to have solved/worked around the installation parts, I'll probably move this post/thread soon to the "General Usage" section.

I'm not sure how to solve this. CDO-based mesh movement such as is now possible in v5.2 for boundary layer insertion should help, but is not plugged into the ALE part yet (and still requires a bit of work).

For now, I would suggest postprocessing output of each of the 5 or 10 time steps before the crash, to understand how/where the mesh movement is causing issues (and to see if that movement is expected or not).

Besides decreasing the time step, which you have tested, increasing the mesh viscosity usually helps, but I would try with a uniform (high) mesh viscosity first (to spread the displacement over a larger portion of the mesh).

Best regards,

Yvan

[Luciano Garelli]

Hello Yvan,

I think that it is good idea move the the post to "General Usage" section.

I don't think that the problem came from the mesh movement algorithm, I think that is a problem in the force/displacement communication between CS and CA. I get this conclusion from the following test.

The internal cylinder can move in the "X" and "Y" direction

Code: Select all

CON_LIM=AFFE_CHAR_MECA(MODELE=MO,
                       DDL_IMPO=_F(GROUP_MA='SIDES',
				 DZ=0.0,),);

And I set in CALC_IFS_DNL that only communicate the force in the "X" direction

Code: Select all

TRAN=CALC_IFS_DNL(....
.....
GROUP_MA_IFS = ('SFLUIDE',),
NOM_CMP_IFS = ('FX' ),

So only the FX component is passed to CS. Also, in CS I fix the "Y" and "Z" components.

In the CS listing I get for all time steps

Code: Select all

Component 0 [0xebf8a8], port DEPSAT:
Reading up to 360 values of type double, time_dependency I
              (min/max time 0.000000/0.000000, iteration 53) ...[ok]
Read          360 values (min time 0.000000, iteration 53).
    2 first and last elements:
             1 :  0.0000000e+00
             2 :  0.0000000e+00
    ..........   ............
           359 :  0.0000000e+00
           360 :  0.0000000e+00

So, no displacement are received, but CS communicate forces (pressure)

Code: Select all

Component 0 [0xebf8a8], port FORSAT:
Writing 180 values of type double, time_dependency I
        (time 0.000000, iteration 53) ...[ok]
    2 first and last elements:
             1 : -0.0000000e+00
             2 :  4.5893084e+02
    ..........   ............
           179 : -1.9242977e+03
           180 :  0.0000000e+00

I share the case.

FSI_Cylinders.zip

(6.72 MiB) Downloaded 204 times

Regards,

Luciano

[Yvan Fournier]

Hello Luciano,

As there are options both in Code_Saturne to lock the displacement in certain directions (x, y, or z), I am not too sure whether this type of behavior should be setup in Code_Saturne only, code_aster only, or both. As a reminder, Code_Saturne sends forces/stresses to code_aster, and receives displacements.

It would seem more logical (and simpler) to me that this sliding behavior be set up only on the code_aster side, as it is the code which computes the displacement, and should be quite capable of handling a sliding displacement only even with a nonzero normal force component, but there might be an incorrect interaction between those two coupling options.

Could you try setting up the "sliding" behavior only on the code_aster side ? Also, I believe it is important all 3 components are exchanged between codes regardless of the options and constraints, but I think this is already the case. If some option leads to this not being the case, I would not be surprised that we have a mixup between components (this should not happen but the FSI coupling with code_aster has only been tested on a few cases, su this sort of bug would not surprise me).

Best Regards,

Yvan

[Luciano Garelli]

Hello Yvan,

It would seem more logical (and simpler) to me that this sliding behavior be set up only on the code_aster side, as it is the code which computes the displacement, and should be quite capable of handling a sliding displacement only even with a nonzero normal force component, but there might be an incorrect interaction between those two coupling options.

Yes, you are right the simple way is set the sliding at code_aster side. I try this options and several alternatives without success...the problem blows up due the very very large displacements. So, I try to debug the code in order to find where the forces are send to aster. This is done in the cs_ast_coupling.c if I'm no wrong...

Code: Select all

 if (cs_glob_n_ranks == 1) {
    assert((cs_gnum_t)n_faces == n_g_faces);
    for (cs_lnum_t i = 0; i < 3*n_faces; i++)
           g_forast[i] = forast[i];
  }

If I apply a factor of 1e-7 to forast, the problem runs without problem giving some coherent visual results. So, I think that maybe it is a scaling or projection problem, because the FVM solution from CS has to be projected to a FEM mesh for CA.

Now, the problem is how to debug the projection, because this is done in code _aster.

I attach some results...

Regars,

Luciano

[Yvan Fournier]

Hello Luciano,

Posting from my phone so I can't check the attachment now, but I was wondering whether some portions of the solid mesh could be more refined than the matching fluid mesh. This is an possible case of undetermined behavior, which would need reworking the algorithm.

Otherwise I guess we would need to check what happens on the code_aster side, but I am not familiar with that code or compiling it...

I'll take a look at your file later today or tomorrow.

Best regards,

Yvan

[Luciano Garelli]

Hello Yvan,

I have some news about the coupling. I was debugging the forces comunicated from CS to CA and I note that the values of the array forast in cs_ast_coupling.c were wrong. These values are saved in strdep.f90

Code: Select all

do ii = 1, 3
       forast(ii,indast) = asddlf(ii,-istr)*forbr(ii,ifac)
enddo

and the array asddlf should have only 0 or 1 (cs_gui_mobile_mesh.c). But when I print this array I get 1.027E9 in th "Y" component.

If I use the cs_user_fluid_structure_interaction.f90 and set asddlf(i,1) = 1 for the coupled structure the forces comunicated are the correct.

So, I think that there is a bug in the code and the asddlf is overwrited .

Regards,

Luciano

[Yvan Fournier]

Hello Luciano,

Thanks for this info. I'll check if I see any explicit overwrite in the code and keep you informed. Otherwise, I might be interested in a Valgrind run.

Did you run a debug or production build of Code_Saturne ? A debug build might catch errors earlier...

Best regards,

Yvan