I’m working on a case of Fluid-Structure Interaction with Saturne-Saturne coupling using overset method, and I have 2 questions please.
I tried a coupling of 2 meshes without moving one of them, I get a continuous velocity between the 2 meshes, but the stress and the pressure are not really continuous, can you suggest a way to improce this ?
My 2nd question is about moving one of the 2 meshes inside the other one (Rotation and Translation), so should I use the mesh_periodicity subroutine or the Turbomachinery one ? How should it be done if one mesh will move (with all its elements) ?
The “Chimera” coupling is not a true Chimera method: boundary conditions are exchanged (so the velocity continuity is handled pretty well), but the incompressibility constraint is not enforced, whicn explains the pressure discontinuity.
The only solution for this would be to transform this into a true Chimera method, with stronger coupling at the pressure prediction/correction stages.
If meshes are moving, turbomachinery is a better option, because periodicity is handled at the preprocessing stage (so not updated at each time step).
Imposing a translation requires modifying the code a bit, so you would need to do that where the turbomachinery module updates the mesh (_update_mesh function in cs_turbomachinery.c). This also requires computing relative velocities between meshes, which may be more difficult (the turbomachinery modules does this using “rotation_velocity” and associated functions, for example in navstv.f90, which would need to be adapted (basically, check for all such things in cases where “iturbo.eq.2” in Fortran code), though this should be quite simple.
Adapting the ALE module to “rigid body movements” could be interesting also, but probably requires more knowledge of the code.
As a first try, I only imposed a rotation using the cs_turbomachinery.c subroutine. I have some results, but as mentionned in the Turbomachinery module usage in Doxygen, “the code/code coupling approach is not fully conservative”, so even the velocity is not continued between the 2 meshes. To solve this problem I guess I need to use the 2 subroutines cscpfb.90 and csc2cl.90, but when I put these 2 subroutines in the SRC, the results don’t change (and I don’t get an error), could you help me how do they work, where to put them, and if there is any other modifications I’ll need to do.
I don’t have this file in my repertory and I can’t download it from the doxygen, what I understood from Documentation is that it’s a solver that predict velocity and pressure, am I right ? should it have the same treatment as the 2 other ones ?
Where should I add “cs_turbomachinery-update_mesh()” ? Is it in the same file, or I should put it in other one ?
Thank you Yvan for your answer, I had a problem in my installation, so I didn’t not find the navstv.90 and the cs_turbomachinery.c where they should have been. But now I fixed it.
Can you help me with what I should modify in the update_mesh function ? it calls a lot of functions and I can’t see how it works exactly.
Actually, _update_mesh calls _update_geometry, which is simpler, and which is the part you need to modify. But in _update_mesh, you will need to remove the
if (tbm->n_rotors > 0)
test before the call to _update_geometry, or ensure n_rotors > 0 (for example using the rotor structure also for translation, in which case a rename would also be recommended for clarity).
Is there any example on how we can translate a mesh ?
Which part of _update_geometry should I modify ? the update of the coordinates ?
In the ALE module, there is the subroutine “cs_user_boundary_conditions_ale.f90” where we can impose a translation to some nodes, is it possible to do the same with the whole domain (volumetric) ?
The code-code coupling is non conservative, and as I understood, the correction of the pressure is deactivated, how ? why ?
Is there any anyway we can improve that ?
Yes, simply update the coordinates for a start. Though in places where relative rotation velocity is used (check rotation in the Fortran part of the code) you may need to also adjust for the translation relative velocity.
In ALE, to my knowledge, you can only prescribe boundary conditions. The rest is solved. It would probably be possible to prescribe movement everywhere, if you modify the code where the displacements are computed.
The code-code coupling is not conservative, because it only modifies the boundary conditions and is not a true “Chimera” (domain-decomposition family) method, as we do not solve a boundary value problem. This would require a different algorithm, and I am not sure how interpolation could be made to be conservative (though globally conservative is probably easier than locally conservative).
Globally conservative means the total exchanged quantity is not lost when interpolating between domains (it may be rescaled for this), but on a given surface subset, you may not have condervation of that quantity.
You do not need to define an additional variable in any case, just transform the flow conditions on one side to boundary conditions on the other (check src/base/csc2cl.f90 to see how this works).
Sorry for the confusion I meant by a new velocity, the velocity of translation of the mesh (domain), can you help me with the way I can impose it ?
I have a second question, for the rotation (already exisitng in the code), can I make the movement periodic in time or in space (imposing a degree of rotation) ? If yes, how can I do that ?
As I started modifying the code, there are things that I didn’t really understand, if you can help me with it please.
the function :
static inline void
_apply_vector_transfo(double matrix[3][4],
cs_real_t c[3])
{
int i, j;
double c_a[4] = {c[0], c[1], c[2], 1.}; /* homogeneous coords */
double c_b[3] = {0, 0, 0};
for (i = 0; i < 3; i++)
for (j = 0; j < 4; j++)
c_b > += matrix> [j]*c_a[j];
for (i = 0; i < 3; i++)
c > = c_b> ;
}
_It seems to me that that the 4th column in the “matrix” is for translation, no ? is the “matrix” defined elsewhere ?
what’s the difference between “matrix” and “m” used in “_apply_vector_rotation”
This function, is only used for updating the coordinates, although it can do a rotation also, so why the “_apply_vector_rotation” and “_apply_tensor_rotation” are the ones used.
If I want to use the "apply_vector_transfo", how should the other functions be modified ?
Beause in a translation there won’t be any invariant point, and in case it’s a rotation/translation it the invariant point won’t be the same.
I made a list of the other functions that should be modified, if you canfirm it, or add ones that I missed
“cs_turbomachinery_rotate_fields”
“cs_turbomachinery_rotation_matrix”
“cs_turbomachinery_add_rotor”
_the update coordinates part of "update_mesh"
_"relative_velocity"
_"update_geometry"
rotation.c → “cs_rotation_t”
I’m sorry if it’s long, but your help is much appreciated
I made a little modification to the file ‘cs_turbomachinery.c’, I deleted the call “if (tbm->n_rotors > 0)” and then imposed the transformation matrix (making it only a translation) using “cs_user_turbomachinery.c”.
I got some errors which suggested to me to add and modify the mesh periodicity.
I still get an error :
Cannot achieve to reorient the current joined face with face 1857 (selected face).
So I modified the max_sub_face and made it to 10 000, 100 000, but I still get this error.
So the problem looks to be in the mesh joining rather than in the _update_mesh of turbomachinery, isn’t it ?
Can you help me with what I should modify ?
Enclosed, you’ll find the files that I put in my SRC and the listing and error I get
The best option to understand the joining error would be to apply the same transformation (translation) as a mesh preprocessing (cs_user_mesh_modify) step, and use standard (not turbomachinery, but preprocessing) joining, so as to visualize the mesh and joining problems.