MRF in Saturne?

[Yvan Fournier]

Hello,

I'll ask colleagues who are working on this functionality of the code to check this thread and provide you better info, but they are out of office until the beginning of next week (and I will be out of office next week), so I'm afraid I won't be able to provide the answer before a few days.

Best regards,

Yvan

[Pisolino]

don't worry and thank you for your help.

I'll wait for an answer, by the way now i'm having more sensed values using my configuration with k-epsilon one-scale wall. the 2-scale wall (default if you pick k-epsilon turbulent model) is used to diverge or to be unstable in my case :

stirrer (diameter 100 mm) in a tin (diameter 600 mm), fluid = air, 1470 RPM = 155.5 omega.

Now, after 100 step (steadystate) relax 0.7 you can see the result in the picture attached. They seems qualitatively correct. Now i'm rerunning until 500 step to see if the velocity values change to more converged values or not.

As a rule... during a general steady state case how can i choose the correct number of steps ? saturne by defaults says 10 but, as in this case, they aren't always enough.

[Yvan Fournier]

Hello,

We do not currently have an automated convergence test (though I believe some colleagues are working on this), but 10 iterations seems a bit short.

To check convergence, I would either place a few probes and check their values history, or add a scalar tracer (passive scalar, initialized at 0, with an inlet value of 1) to check how long it takes to fill the domain, and multyiply thant number of time steps by 2.

Also, when using rotating coordinates, I do not believe a steady state solution is possible, except maybe with a "frozen rotor" model. Otherwise, using a fixed time step with an unsteady calculation (same means of checking convergence, but this may require more time steps, and you need to choose a basic time step so that CFL values are reasonable, that is do not significantly exceed 5 to 10).

Best regards,

Yvan

[Martin FERRAND]

Hi,

here is a setting for a code-code coupling between fluid2 and fluid1:

Code: Select all

 /*-------------------------------------------------------------------------
   * Coupling with instance "fluid2".
   *
   * - coupled faces of groups "coupled_boundary2"
   * - all cells available as location support
   *-------------------------------------------------------------------------*/

  cs_sat_coupling_define("fluid2",
                         "coupled_boundary2",
                         NULL,
                         NULL,
                         "all[]",
                         verbosity);

and for the domain fluid1

Code: Select all

 /*-------------------------------------------------------------------------
   * Coupling with instance "fluid1".
   *
   * - coupled faces of groups "coupled_boundary1"
   * - all cells available as location support
   *-------------------------------------------------------------------------*/

  cs_sat_coupling_define("fluid1",
                         "coupled_boundary1",
                         NULL,
                         NULL,
                         "all[]",
                         verbosity);

Best Regards,

Martin

[Pisolino]

really thx !
your help confirmed what we were trying, once you know how to do it's quite simple to attach an MRF simulation in your job. Good job with the code.

[avallejo]

I have reviewed much of the documentation, and I just wanted to know if there was a formal example of coupled domains for v3.0 of Code_Saturne, or if the process is generally unchanged from v2.1.6? I also wanted to know if the limitation of a single rotor on a cardinal axis passing through the origin still exists?

[Yvan Fournier]

Hello,

The process you refer to is mostly unchanged (runcase_batch and runcase_coupling are replaced by runcase and coupling_parameters.py, but this is a minor detail level change).

Since 2012, there have been other additions (starting with version 3.2 of the code), in which other options are provided, which do not require code coupling (i.e. all the setup is done in a standard case)
- frozen rotor.
- single domain computation based on mesh joining.

You should find quite a few posts from last winter on this forum regarding the new "mesh joining" approach, and in 3.3, the new turbomachinery options will be available from the GUI in 4.0 (they are already available on the "trunk" main development branch, and 4.0-beta should arrive in October, for a 4.0 release early 2015).

The limitation to a single rotor still exists (the new code relative to the mesh joining approach is written so as to remove this, but there is still a part of the code which assumes a single axis, so we need to improve this before the restriction is removed).

Regards,

Yvan