Time step in Code_Saturne 2.2 and SYRTHES 4.0

[Martin Isack]

Hello,

in the old forum we had a discussion about time steps and the time step factor. Yvan Fournier wrote in this thread:

In the next version of the Code_Saturne/SYRTHES coupling (Code_Saturne 2.1/SYRTHES4), which should be available in a few weeks, we might just have time to make this time step multiplier more automatic (so that it also works with time varying time steps).

Is there some kind of automatism implemented in Code_Saturne 2.2 and SYRTHES 4.0? Is it possible to use non-uniform time steps now?

Regards,
Martin Isack

[Yvan Fournier]

Hello,

There has been no progress regarding an automated time step multiplier (this would be quite easy for a single coupling, but could become a nightmare for multiple couplings, and is also subject to interpretation, depending on whether the multiplier has a physical (different time scales) or numerical (convergence enhancement for steady state).

Regarding non uniform time steps (for example using a time-varying time step in Code_Saturne), there is no current user keyword for this, but you may try copying src/base/cs_coupling.c to your user subroutines folder (SRC), and in the cs_coupling_discover_mpi_apps function (line 168), set sync_flag to PLE_COUPLING_TS_MIN (to use the smallest time step between Code_Saturne and SYRTHES) or PLE_COUPLING_TS_LEADER (so that Code_Saturne prescribes the time step). I am not 100% sure this is accounted for correctly in SYRTHES, but you may give it a try (and check in the "listing" file that the time step behaves as expected).

Best regards,

Yvan

[Martin Isack]

Hello,

thank you for your reply. Setting sync_flag to PLE_COUPLING_TS_LEADER works. The Code_Saturne time step gets synchronized with SYRTHES. The only problem is that it doesn’t take into account the time step factor. Would it be possible to synchronize not the time step itself, but the cs_time_step times the time_step_factor?

Regards,

Martin

[Yvan Fournier]

Hello,

As I mentioned in my previous post, this could become very complicated, at least in some cases (not in the case of PLE_COUPLING_TS_LEADER, but in the case of PLE_COUPLING_TS_MIN, with multiple couplings, or in the hypothetical case of coupling with other codes, using time step multipliers with other variables than the temperature).

In the meantime, you could force that behavior, line 309 of the same cs_coupling.c file, by multiplying the last argument to ple_coupling_mpi_set_synchronize (*ts) by the time step multiplier.

We may try to make those settings available in version 2.3, but as mentioned before, this should be reserved for advanced usage (although it does seem be useful in some cases, such as this one), and we still need to think about how to make this as safe (interpretation wise) as possible. As per advanced parameters, those options would be available in the user cs_user_coupling.c file (and probably not in the GUI, at leasr initially).

Best regards,

Yvan

[Martin Isack]

Hello,

it works if I use a constant number as multiplier. Would it be possible to use the variable (cdtvar), which is entered is in CS-Gui?

Best Regards,

Martin

[Yvan Fournier]

Hello,

Although using the same value as that of CDTVAR is very easy for you to do on a given case, using CDTVAR automatically would make the coupling difficult to extend, as I mentioned earlier: for example, if one Code_Saturne instance (using RANS) were coupled both to SYRTHES and to another Code_Saturne instance (using LES), we might want one time step multiplier for the temperature, and another for the flow, so the current way of doing things (where each code provides its time step), and an option such as PLE_COUPLING_TS_LEADER or PLE_COUPLING_TS_MIN is insufficient. To remain general, we would need one time step multiplier per coupled code.

A possibly simpler solution would be that each code provides its own (single) multiplier, and that all computations when using PLE_COUPLING_TS_MIN (where every code should choose the smallest time set of the lot) be done using this multiplier, but in this case, setting the multiplier automatically to CDTVAR is a bad idea, as per the example above, where more than one coupling may be used.

So it is not a trivial matter to have a logic which is both consistent when moving from one to several couplings, and yet automatic (in this case, having a default option to base CDTVAR on a single multiplier per code would be easier to manage than the reverse, even though it may seem similar to the user).

So we still have some thinking to do with the SYRTHES and other teams before we define anything too automatic. The required mechanisms are there (compared to the coupling with SYRTHES 3.4), but we are not in a hurry to make this too automatic, as it could be a problem in the case of complex couplings.

Hopefully, by version 2.3 (this summer), we'll at least have some improved user control over this (so that you don't need to edit non-user code), but I doubt we'll make it fully automatic (i.e. you may still need to define the multiplier in 2 different places).

Best regards,

Yvan

[Martin Isack]

Hello Yvan,

maybe you misunderstood me. I understand that it would make no sense to apply CDTVAR automatically in general at the moment.

It’s just that I always use one instance of SYRTHES and one of CS in my simulations. Furthermore I only have cases, where a time step factor makes sense (different time scales for dynamic and thermal phenomena). That’s why I thought, it would be convenient for me, if i applied this automatic usage of CDTVAR in my own cs_coupling.c.

My only problem is, that I don’t know how to use the variable CDTVAR inside of my cs_coupling.c. I would be grateful if you gave me a hint, how to do that.

Best regards,

Martin

[Yvan Fournier]

Hello,

Actually, CDTVAR is defined in a global Fortran array which is not directly accessible from the C part of the code, so there is no easy way to do this now (except hard-coding the same value in cs_coupling.c than the one you set in the GUI for the scalar).

With the new C "fields" API, mapping some Fortran keywords to C is becoming easier, so CDTVAR could be made more accessible, but still requires 2 steps:

in src/base/fldini.f90, in the loop on user variables starting line 283, after the call to fldsks, you may add a test:

Code: Select all

if if (ii .eq. iscalt) then
  name = 'cdtvar'
  call fldkid(name, key_cdtvar)
  call fldskd(ivarfl(ivar), key_cdtvar, cdtvar(ivar))
endif

(not forgetting to define a local integer variable key_cdtvar in the subroutine)

In src/base_cs_field.c, you may then add, at the end (in cs_field_define_keys_base),

Code: Select all

cs_field_define_key_double("cdtvar", 1, CS_FIELD_VARIABLE);

In src/base_cs_coupling.c, you may then add :

Code: Select all

#include "cs_field.h"

near the top (where other such includes may be found), then:

Code: Select all

double cdtvar_t = cs_field_get_key_double(cs_field_by_name("temperature"), cs_field_key_id("cdtvar"));
ple_coupling_mpi_set_synchronize(*ts * cdtvar);

where you had the previous call to ple_coupling_mpi_set_synchronize (which must be called only once per time step).

Note this is suggested (not tested) code.

Best regards,

Yvan

[Martin Isack]

Hello,

I changed the files and unfortunately got a compile error, while starting the simulation. I were able to correct a view mistakes, but it seems that even the inclusion of cs_field.h in cs_coupling.c doesn’t work properly. It raises errors like:

Code: Select all

In file included from /home/martin/Projekte/syr4/BOX/RESU_COUPLING/20120412-1155/FLUID/src_saturne/cs_coupling.c:59:
/home/martin/edfneu/saturne-2.2/arch/Linux_x86_64/include/code_saturne/cs_field.h:172: error: expected ‘;’, ‘,’ or ‘)’ before ‘CS_ARGF_SUPP_CHAINE’
/home/martin/edfneu/saturne-2.2/arch/Linux_x86_64/include/code_saturne/cs_field.h:190: error: ‘CS_PROCF’ declared as function returning a function
/home/martin/edfneu/saturne-2.2/arch/Linux_x86_64/include/code_saturne/cs_field.h:190: warning: parameter names (without types) in function declaration
/home/martin/edfneu/saturne-2.2/arch/Linux_x86_64/include/code_saturne/cs_field.h:212: error: ‘CS_PROCF’ declared as function returning a function

I think I just use a constant number in cs_coupling.c as multiplier. Nevertheless I thank you a lot for your support!

Regards,

Martin