Coupled simulation of two Code_Saturne instances

[lb_yuan]

I am a beginner of Code_Saturne. Recently, I carried out a coupled simulation of two code_saturne instances, which is a 3D T-junction with a velocity inlet at the bottom (4m/s), a outlet on the left hand side of the top structure and another inlet on the right hand side of the top structure (1m/s). The top and bottom structures were simulated with separate unsteady solvers and coupled with each other at the middle interface. The following figures show simulation results of the coupled simulation, in which it is clearly that the continuity equation is not converged - see the sudden jump of pressure field near the interface. I tried various time step sizes and total numbers of iterations, the simulation results all reach a similar steady state as shown in the following figures. I checked the residual of the field variables and found that, for the top structure, all equations are converged, however, for the bottom structure, the normalized residual of the pressure equation remains a value around 0.99 and doesn't change with time advancing. can anybody give me some advice about this? Many thanks

[Yvan Fournier]

Hello,

Could you provide more details on your setup, as per the general forum recommendations ?

How do you couple the domains ? Are you using the direct boundary condition (explict in time) coupling ? (which is not very beginner-friendly) ?

Regards,

Yvan

[lb_yuan]

Dear Yvan,

Thanks for your prompt reply.

I created the two coupled domains sharing a conformal interface which can be seen in the following picture. The unsteady SIMPLEC algorithm is used for each domain. k-epsilon model is used accounting for turbulence. Boundary conditions are specified as per the following picture as well, the interface boundary for each domain is not specified in the GUI. The upper domain is named as 'top' with the interface named as 'inlet-interface', whilst the lower domain is named as 'bottom' with the interface named as 'outlet-interface'. I think I should employ a 'time explicit' boundary coupling by using subroutine 'cs_user_saturne_coupling' in user routine 'cs_user_coupling.c'. This subroutine is specified as follows:

For domain 'bottom':
cs_user_saturne_coupling(void)
{
int verbosity = 1;
if (true)
cs_sat_coupling_define("top",
"outlet-interface",
NULL,
NULL,
"all[]",
verbosity);

}

For domain 'top':
cs_user_saturne_coupling(void)
{
int verbosity = 1;
if (true)
cs_sat_coupling_define("bottom",
"inlet-interface",
NULL,
NULL,
"all[]",
verbosity);
}

The coupling parameters is set as this:

domains = [
{'solver': 'Code_Saturne',
'domain': 'bottom',
'script': 'runcase',
'n_procs_weight': None,
'n_procs_min': 1,
'n_procs_max': None}
,
{'solver': 'Code_Saturne',
'domain': 'top',
'script': 'runcase',
'n_procs_weight': None,
'n_procs_min': 1,
'n_procs_max': None}
]

Please can advise if there is anything wrong in the above settings? many thanks

[Yvan Fournier]

Hello,

So this is a "true" coupling case.

We do not recommend coupling for this type of case, as coupling through explicit boundary conditions is not a good match for incompressible flows.

The coupling is used in 2 cases:
- turbomachinery computations, between moving rotor and stator, using sub-iterations to improve conservativity. Even in this case, mass flow conservativity is not strictly enforced, and initial transient values are off, though the computation converges to quite good stead state results.
- RANS/LES computations, in which 2 different meshes (finer for LES, coarser for RANS) are used, on the same domain (to avoid incompressibility/conservativity issues), and volume coupling is used to exchange turbulent quantities or source terms between the 2 models. This is rarely used, though it has been done in the course of some PhD work.

A third possible case (similar to the first), which has been experimented by developers in the past was to use coupling for large deformation cases.

In other cases, it is better to use a single domain, tough it is nice to know that as a beginner you were still able to set up a coupled case.

Regards,

Yvan

[lb_yuan]

Hi Yvan,

Thanks so much for your helpful information.

We are aiming to develop a 'modularized' CFD method, in which the complex computational domain will be decomposed into separate sections and to be modeled separately with different physical models and governing equation systems. This will provide us with high flexibility in studying flow and heat transfer of different spatial and time scales in such complex geometries. The T-junction case is our first test case to see the performance of the existing coupling tools in Code_Saturne. We are keen to carry out such kind of coupled simulations for incompressible flows, though this seems to be not recommended.

I'd be very grateful if you could answer some more questions about this:

1) For the T-junction case, will the conservativity be improved if we also use sub-iterations between time steps, and how can I specify the sub-iteration in the fractional step solver in Code_Saturne?
2) Besides the time explicit face coupling scheme, are there any implicit/semi-implicit schemes available in Code_Saturne? If not, is it possible to develop one (some kind of strong coupling) with the user routine system?
3) Does it require overlapping cells to implement a volume coupling? If we use a volume coupling method in the T-junction case, allowing a overlapping section of the two sub domains (top and bottom), will the coupling performance be improved?

Kind regards,
Bo

[Yvan Fournier]

Hello,

1) sub-iterations may help, though they won't be perfect. The cs_glob_piso->netrup value may be set for this in cs_user_parameters.c.

2) strong coupling would require quite a bit of advanced work inside user functions. We are currently working on an "internal coupling" type of strong coupling, which couples boundary faces inside a single domain, and is currently usable for scalars and advected/diffused vectors, but does not handle velocity/pressure coupling at this stage. This coupling was not done with multiple domains in mind, but its extension should be possible for conforming meshes (with quite a bit of additional work). Working the other way around (using a single domain but having different physics in different zones) would be more better aligned with the current logic of the internal coupling, and easier to handle for the user (with a single case to postprocess), but still requires significant work.

3) yes, it assumes overlapping cells. Overlap could be restricted to some parts of the mesh, but overlapping on the whole mesh better avoids issues with the incompressibility constraints, while allowing some coupling between physical models, so this is generally the approach chosen.

Best regards,

Yvan

[lb_yuan]

Hi Yvan,

Many thanks for answering my questions.

Following your information, I'll do further tests and try to understand more about the code in the upcoming several weeks. Happy new year!

Kind regards,
Bo

[lb_yuan]

Dear Yvan,

Thanks again for your answers to my queries. I thought over them and still have something unclear. Can you please provide me with some more information. Many thanks.

‘sub-iterations may help, though they won't be perfect. The cs_glob_piso->netrup value may be set for this in cs_user_parameters.c.’
- Does the above procedure mean that the PISO algorithm is activated for velocity-pressure coupling? Is it equivalent to choosing PISO and giving a value of nterup in the GUI?

‘We are currently working on an "internal coupling" type of strong coupling, which couples boundary faces inside a single domain, and is currently usable for scalars and advected/diffused vectors, but does not handle velocity/pressure coupling at this stage.’
- A single domain means a single set of governing equations corresponding to a single set of linear equations. Is this boundary face an artificial interface (not a real face) to separate different fluid zones where different physics are used? In this case, the coupling should be some kind of numerical schemes to calculate the coefficients of the linear equations near the interface using a stencil including cells from the other side. Is this understanding correct? And can you suggest if I’m going to carry out such kind of coupling, which subroutines should I use? Or is this already available in the latest release of Code_Saturne?

At last, I’m still keen to the multiple domain coupling. Can you please suggest in which subroutine I can implement some modifications to the existing coupling method? And where can I find some detailed documentation about the mechanism of the existing coupling algorithm in Code_Saturne?

Best regards,
Bo

[Yvan Fournier]

Hello,

The "PISO" algorithm is actually not a true PISO, as the updated/intermediate quantities are not the same. But yes, choosing PISO and assigning nterup in the GUI is the same (I did not remember this was available in the GUI).

An yes, the internal coupling couples values at boundary faces, for which wall law turbulence values are available, and additional terms are added. It can be used for example for conjugate heat transfer, in which we have a fluid on one side, a solid (no convection, adapted physical properties) on the other side. There are still some missing features (combination with radiative boundary conditions, postprocessing of the wall temperature in this case), but to check te code "grep" for "cs_internal_coupling" in the sources. Basically, we use the same governing equations on both sides of the interface, with additional coupling terms, and modified physical properties in some cases (i.e. zero convection, turbulent diffusivity, ... in "solid" zones.

Regards,

Yvan

[lb_yuan]

Hi Yvan,

Thanks so much for your reply

Kind regards,

Bo