Saturne 8 - User code compile errors

Questions and remarks about code_saturne usage
Forum rules
Please read the forum usage recommendations before posting.
Post Reply
Antech
Posts: 199
Joined: Wed Jun 10, 2015 10:02 am

Saturne 8 - User code compile errors

Post by Antech »

Hello. I updated Saturne from 7.0.2 to 8.x and found multiple compile errors that I don't know how to resolve correctly.

Configuration is:
==========
Hardware setup: Local server (Dell R620, 24 cores, local MPI)
OS: CentOS 7.5 KDE + vault repo
Kernel: 3.10.0-1160.66.1.el7.x86_64
System gcc: 4.8.5
MPI: OpenMPI-1.8.4 (I consider newer versions problematic)

My old Saturne 7.0.2 version worked good with this configuration. Trying to compile 8.2.0 version I found that it requires full C11 support so I installed devtoolset-7 to obtain newer gcc-7.3.1 (system gcc was not touched, there is a special shell [environment variables] created with "source /opt/rh/devtoolset-7/enable" command). Full C11 support started from gcc-4.9.
With new gcc Saturne compiles without errors, bit I face problems running my user code. It's a small library for relaxation and limitations for stability, heat exchanger model and hand-made gas combustion model.

I started with current feature version 8.2.0. First thing I encountered was user code compilation test error. Digging a bit I found that it originates from including "cs_headers.h". Error is:

Code: Select all

In file included from /Programs/Code_Saturne-8.0.4-MPI-1.8.4/install-std/include/code_saturne/cs_base_headers.h:55:0,
                 from /Programs/Code_Saturne-8.0.4-MPI-1.8.4/install-std/include/code_saturne/cs_headers.h:41,
                 from /run/media/antech/WD-Data-500/Storage/Media/Work/PK-176/Saturne/RESU/20241219-1319/src/CmnParSet.c:22:
/Programs/Code_Saturne-8.0.4-MPI-1.8.4/install-std/include/code_saturne/cs_field_pointer.h:51:41: error: ‘CS_FIELD_POINTER_r11’ undeclared (first use in this function); did you mean ‘CS_FIELD_POINTER_f1m’?
It doesn't see Reynolds stress components field pointers. It turned out that, compared with 7.0.2 version, "install/include/code_saturne/cs_field_pointer.h" file is missing lines with these pointer IDs or something. In version 7.0.2, this part looks like:

Code: Select all

typedef enum {
  ...
  CS_ENUMF_(r11),          /*!< Reynolds stress component \f$ R_{xx} \f$ */
  CS_ENUMF_(r22),          /*!< Reynolds stress component \f$ R_{yy} \f$ */
  CS_ENUMF_(r33),          /*!< Reynolds stress component \f$ R_{zz} \f$ */
  CS_ENUMF_(r12),          /*!< Reynolds stress component \f$ R_{xy} \f$ */
  CS_ENUMF_(r23),          /*!< Reynolds stress component \f$ R_{yz} \f$ */
  CS_ENUMF_(r13),          /*!< Reynolds stress component \f$ R_{xz} \f$ */
  CS_ENUMF_(rij),          /*!< Reynolds stress tensor \f$ R_{ij} \f$ */
  ...
}
While in 8.x versions it's:

Code: Select all

typedef enum {
  ...
  CS_ENUMF_(rij),          /*!< Reynolds stress tensor \f$ R_{ij} \f$ */
  ...
}
I added Rxx pointer IDs and this error disappeared, but is it correct method? Why are there no Rxx pointer IDs in newer versions? Behavior is the same for 8.0.4 and 8.2.0 versions.

Then, when I started calculation, another compile error appeared:

Code: Select all

/run/media/antech/WD-Data-500/Storage/Media/Work/PK-176/Saturne/RESU/20241219-1307/src/cs_meg_source_terms.cxx:52:13: error: ‘temperature’ does not name a type; did you mean ‘temperature_vals’?
       const temperature = temperature_vals[c_id];
             ^~~~~~~~~~~
This is specific for 8.2.0 version. With 8.0.4, there is no this error.
I compared "cs_meg_source_terms.cxx" for 8.0.4 and 8.2.0 versions and have not found differences in temperature declaration. This line is the same, although functions are some different. For conveniency, here are cs_meg_source_terms functions for different versions.

Saturne 8.0.4:

Code: Select all

cs_real_t *
cs_meg_source_terms(const char       *zone_name,
                    const cs_lnum_t   n_elts,
                    const cs_lnum_t  *elt_ids,
                    const cs_real_t   xyz[][3],
                    const char       *name,
                    const char       *source_type)
{
  cs_real_t *new_vals = NULL;

  /* User defined source term for temperature over zone DUCT
    -------------------------------------------------------- */

  if (strcmp(zone_name, "DUCT") == 0 &&
      strcmp(name, "temperature") == 0 &&
      strcmp(source_type, "thermal_source_term") == 0) {

    const cs_lnum_t vals_size = n_elts * 2;
    BFT_MALLOC(new_vals, vals_size, cs_real_t);

    const cs_real_t *temperature_vals = cs_field_by_name("temperature")->val;

    for (cs_lnum_t e_id = 0; e_id < n_elts; e_id++) {
      cs_lnum_t c_id = elt_ids[e_id];
      const temperature = temperature_vals[c_id];

      new_vals[2 * e_id + 0] = - 0 * 1.07E3 * (temperature - 118);
      new_vals[2 * e_id + 1] = 0;
    }
  }
  return new_vals;
}
Saturne 8.2.0:

Code: Select all

void
cs_meg_source_terms(const char       *zone_name,
                    const cs_lnum_t   n_elts,
                    const cs_lnum_t  *elt_ids,
                    const cs_real_t   xyz[][3],
                    const char       *name,
                    const char       *source_type,
                    cs_real_t        *retvals)
{
  /* User defined source term for temperature over zone DUCT
    -------------------------------------------------------- */

  if (strcmp(zone_name, "DUCT") == 0 &&
      strcmp(name, "temperature") == 0 &&
      strcmp(source_type, "thermal_source_term") == 0) {

    const cs_real_t *temperature_vals = cs_field_by_name("temperature")->val;

    for (cs_lnum_t e_id = 0; e_id < n_elts; e_id++) {
      cs_lnum_t c_id = elt_ids[e_id];
      const temperature = temperature_vals[c_id];

      retvals[2 * e_id + 0] = - 0 * 1.07E3 * (temperature - 118);
      retvals[2 * e_id + 1] = 0;
    }
  }
}
Is it a bug in 8.2.0 or C++ compatibility problem? I ran these experiments with gcc-7.3.1 from devtoolset-7.

Third error is connected with enthalpy pointer. I have relaxation/limiting "cs_user_parameters.c" file, among others, there are lines:

Code: Select all

field=CS_F_(h); /* Field structure */
 if (field!=NULL) /* Field present */
 {
  eqnPar=cs_field_get_equation_param(field); /* Field options structure */
  eqnPar->relaxv=entRlxCoef; /* Relaxation factor */
 };
If I try to use CS_F_(h) I have memory violation error right from the start of calculation. If enthaply-related lines are removed, calculation runs. Also, in 7.0.2 version there is no this problem. Strange thing is that if I look at "cs_field_pointers.h" I see CS_ENUMF_(h) line both in 8.0.4 and 8.2.0 versions. Why does the program doesn't want to set this pointer? It doesn't return NULL cause there is a NULL-pointer check that will not allow memory violation. CS_F_(h) return something not-null but incorrect that leads to memory violation error.
Thanks for your attention.
Yvan Fournier
Posts: 4168
Joined: Mon Feb 20, 2012 3:25 pm

Re: Saturne 8 - User code compile errors

Post by Yvan Fournier »

Hello,

The change is due to the fact that in v8.0, the RSM model's "irijco" option's behavior was modified, and not a compiler issue.

- In v7.0, with a coupled Rj model, you have a symmetric tensor field "rij", while with uncoupled model, you have separate "r11, r12, ..." fields.

- In v8.0, things are unified, and you always have a single "rij" field, with symmetric tensor (cs_real_6_t) values, representing the xx, yy, zz, xy; yz, xz components in this order. The "irijco" option still exists, so that the component coupling terms can be computed or ignored, but the RSM tensor is always stored in the same way. So in cs_fields.h, r11, r12, ... do not exist anymore.

The "new" approach means you can use the same user-defined initialization, boundary conditions, postprocessing, ... code for both coupled and uncoupled RSM models, but is also means that you need to adapt/update your user code.
If you already handled the coupled case, that is trivial and will lead to simplifying your code. If you only handled the uncoupled mode, it requires a bit more adaptation.

Best regards,

Yvan
Antech
Posts: 199
Joined: Wed Jun 10, 2015 10:02 am

Re: Saturne 8 - User code compile errors

Post by Antech »

Hello, thanks for your answer.
Actually, I don't need specific operations with turbulence field. I just need to add relaxation because it stabilizes the solution. Is it enough to set Rij relaxation factor and flux reconstruction flag not touching tensor components? I mean:

Code: Select all

field=CS_F_(rij); /* Field structure */
 if (field!=NULL) /* Field present */
 {
  eqnPar=cs_field_get_equation_param(field); /* Field options structure */
  eqnPar->relaxv=turbRlxCoef; /* Relaxation factor */
  eqnPar->ircflu=idTurbFluxRc; /* Flux reconstruction flag */
 };
If so, I remove r11 etc. relaxation lines and that's it (I tried now - no errors on compilation test).

Also, how should I avoid two other errors? First with temperature declaration in cs_meg_source_terms for version 8.2.0 ("error: ‘temperature’ does not name a type") and second with solver core dump on CS_F_(h) call.
Yvan Fournier
Posts: 4168
Joined: Mon Feb 20, 2012 3:25 pm

Re: Saturne 8 - User code compile errors

Post by Yvan Fournier »

Hello,

Regarding Rij, yes, the equation parameters are now common to all components, so you settings should work.

Also, we just released v8.3.0 this afternoon (the tarballs are not updated yet to this website, but the GitHub repo has been synced), and we now have an option to disable flux reconstruction at the boundary while maintaining it in the volume, which can be an interesting precision/robustness tradeoff to test.

I am not sure about your MEG errors. The "temperature does not name a type" error seems familiar, and could be related to the fix in commit 262b9f10f, which is available on the v8.2 branch, but post v8.2.1 release (so you need to take the branch head from GitHub). Not sure about the solver core dump on a call to CS_F_(h).
Which thermal model are you using ?

I suggest updating the 8.2 branch or testing 8.3 to see if the first MEG error is fixed (it should be), and see if/where you still have the second error.

Best regards,

Yvan
Post Reply