coupling with code_aster deformation issues

[Paul Brss]

Hello Yvan,

Thanks for your clear answer !

I was using an isotropic description for the mesh viscosity and indeed, the ALE values were not read when I did a restart.

Using the GUI is enough as my case has no complex geometry, so I just changed the mesh viscosity description to orthotropic. Doing a restart based on this new case is now working (=the mesh viscosity of the restart file is taken into account) !

If I find the time to test your advice on lecamx.f90 and phyvar.f90, I'll let you know !

Best regards,

Paul

[Luciano Garelli]

Hello Yvan,

I test your suggestions in order to restart the mesh_viscosity field. I summarize the results.
1) If no previous ALE setting was used, after the restart the mesh_viscosity is set to 1 for both isotropic and orthotropic distributions.
Also, a warning about "restart/auxiliary: section "mesh_velocity::bc_coeffs::a/b/af/bf" not present."

2) If a previous ALE setting was used, with an orthotropic or isotropic setting, this distribution It is correctly read only if the new case is set to orthotropic (As paul mention in the previous post). But, if the new case use an isotropic distribution additional modifications has to be done in lecamx.f90 because it is use field_get_val_v(ivisma, cpro_visma_v) to get the "ivisma" vector field. In doxygen is remaked that "ivisma might be orthotropic". But, doing the following modifications (similar to iniva0.f90) the mesh viscosity is restarted for an isotropic case.

Code: Select all

double precision, dimension(:), pointer :: voidfl,  cpro_visma_s
.
.
call field_get_val_s(ivisma, cpro_visma_s)
      do iel = 1, ncel
        cpro_visma_s(iel) = vismbf(iel)
      enddo
      deallocate(vismbf)

The problem is if we want to change the mesh viscosity distribution in the new case after using a restart file, this can't be done with this solution. So, I think that the second option that you mention ( inivar) is better an allow to change the mesh viscosity distribution after a restart or keep the same using the values set in the GUI or user function.

Regards,

Luciano

[Yvan Fournier]

Hello Luciano,

Yes, we will probably even remove this from the restart as it is not even useful there, and simpler to recompute.

Best regards,

Yvan

[Luciano Garelli]

Hello Yvan,

I made some small progress in the FSI simulation. I was with a problem with the mesh movement at the interface, I get a wrong displacement, but for the moment I could solve it. I did a post in the Aster forum about that (https://code-aster.org/forum2/viewtopic.php?id=23501), but by the moment I did'n get an answer.

Now I'm facing some stability problem, I'm solving the vibration of a beam submerged in water, wherewith the densities are of the same order. After some time steps the beam displacement start to diverge, when it has to get a stable deformed position due to the fluid flow. If I introduce damping in the structure the solution get the stable position but in my problem I have to estimate the fluid added mass and damping.

My questions are about if it is used a predictor for the structural displacementes? (I couldn't find it) and If the numbers of the 'n_sub_iterations' set in the coupling_parameters file involve the exchange of data (forces/displacements) between the codes in order to get an strong coupling scheme. I was looking the aster macro calc_ifs_dnl_ops.py wich but I can't understand the coupling process.

I found some documentation in the web

http://files.salome-platform.org/Salome ... salome.pdf

http://gdr-ifs.univ-lille1.fr/colloque2 ... resEL1.ppt

Regards,

Luciano

[Paul Brss]

Hi Luciano and Yvan,

(First of all, thanks for sharing the presentation of Elisabeth Longatte, which I didn't find....)

It seems we are working on the exact same problem ! My case look like this: fsi_case.png (pseudo 3D also)

I also observed this strange displacement at the mesh interface. I also have an identical structural response of the beam which does not tend to an equilibrium position but oscillates. The oscillations are small at the beginning and grow bigger and bigger.

These oscillations are really fast. For example, the two pictures illustrates the z-vorticity field for t=0.18s and t=0.2s:
z_vorti_deform_1.png and z_vorti_deform_2.png

As you can see, the value are really high close to the beam and do not seem right. In comparison, a case with a non deformable beam:
z-vorticity.png

I tried several time step/Reynolds number/flow modelling on CS side and several beam dimensions/young modulus/etc... The problem seems to come from something else.

(For Luciano:Did you manage to use dyna_non_line correctly ?
I tried to understand dyna_non_line.py (because calc_ifs_dnl.py is based on it) by using only CA... And I still don't have a stable simulation. The deformation of the structure is not what it is expected when applying a constant load on the beam. So my guess is the coupling problem could come from this function. I don't want to pollute this forum with this specific problem, so I'll follow your topic on CA's forum.)

I don't have the answers of your questions, but definitively have the same questions ahah.

Best regards,

Paul

[Luciano Garelli]

Hello Paul,

Yes, we are trying to solve the same problem. I solved a structural problem with CA with the help of a colleague, using the dyna_non_line in order to characterize the added damping to the structure using the AMOR_ALPHA and AMOR_BETA in the material definition. I attach a fig with the results of the displacements of the beam with a constant pressure applied to one face for different damping values.

This behavior (unstable or conditional stable) is typical in partitioned coupling scheme when using similar densities (fluid/solid). The use of structural predictors and internal iterations in order to get a strong coupling could help.

Additional issues that I have detected are that when using PISO coupling in CS the fluid solver freeze, like a dead-lock and when setting NALINF>0 occurs the same. I have modified the file strdep.f90 in order to get some initial time steps without sending forces to allow the fluid initialization.

Regards,

Luciano

[Yvan Fournier]

Hello Luciano and Paul,

I seem to recall that in Fabien Huvelin's PhD that had done preliminary work for this coupling, additional time schemes were explored compared to the ones implemented so far (see www.theses.fr/2008LIL10130/document or www.theses.fr/2008LIL10130, in French).

I'm not sure about this but I'll try to check with E. Longatte, who supervised part of that work and might know what may still be missing (possibly a variant of a more stable scheme)...

Best regards,

Yvan