code_saturne User's Forum

Posted: **Thu Dec 19, 2024 4:44 pm**

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.

Posted: **Thu Dec 19, 2024 5:54 pm**

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

Posted: **Fri Dec 20, 2024 12:41 pm**

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.

Posted: **Fri Dec 20, 2024 8:32 pm**

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

Posted: **Thu Dec 26, 2024 4:32 pm**

Hello. Sorry, was busy with our cluster maintenance. Thanks for advice.
Here is what I discovered.
1. Temperature definition and CS_F_(h) coredump. These errors was fixed with current "9.0-alpha" development version from GitGub. So, generally, initial questions I posted are solved with current development version and removing R11 etc. relaxation from cs_user_parameters.c. Thermal model is Temperature (Celsius).
2. Another issue I found in GUI is a path problem when starting from build directory (I use source/build/install structure). When launching from KDE desktop it's OK (even with setting updated C++ env), but when ran from the build directory, Saturne cannot start calculation processes. Only empty window shows up. It's a standard problem for different versions but now I see what is a culprit. I investigated how calculation is ran in GUI and found that actual process starts from CommandMgrDialogView.__init__() function in BatchRunningDialogView.py. In existing code, process is ran as

Code: Select all

# Start process
self.proc.start(self.cmd)

It's clear that self.cmd in some cases contains incorrect command. I added debug lines so the code looks as follows:

Code: Select all

# Start process
print('DATA dir path: '+self.case['data_path'])
print('Solver path: '+self.cmd)
print('Cur dir:')
os.system('pwd')
os.system('cd '+self.case['data_path'])
self.proc.start('/Programs/Code_Saturne-8.3.0-MPI-1.8.4/install-std/bin/code_saturne run')
# self.proc.start(self.cmd)

Now there is guaranteed start from any directory, but only for fixed installation dir, it's only a test solution. Output from my lines when GUI ran from build dir:

Code: Select all

DATA dir path: /run/media/antech/WD-Data-500/Storage/Media/Work/PK-176/Saturne/DATA
Solver path: ../install-std/bin/code_saturne run
Cur dir:
/run/media/antech/WD-Data-500/Storage/Media/Work/PK-176/Saturne/DATA

And here is what we get starting GUI from KDE desktop shortcut:

Code: Select all

DATA dir path: /run/media/antech/WD-Data-500/Storage/Media/Work/PK-176/Saturne/DATA
Solver path: /Programs/Code_Saturne-8.3.0-MPI-1.8.4/install-std/bin/code_saturne run
Cur dir:
/run/media/antech/WD-Data-500/Storage/Media/Work/PK-176/Saturne/DATA

The problem is that GUI only sets correct absolute solver path (self.cmd) when started from outside of build tree. Otherwise it sets current dir to DATA that is needed to run solver but uses relative solver path that is for the dir GUI started from, not for the DATA dir. That's why it fails. Sometimes it occures even when starting from KDE launcher, I don't know why (it's an experience from different older versions). Would you, please, fix it? Back in the old days, I used to get program location from GetModuleFileName in Windows on program init and store it in global structure named "prog" so any subroutine can use it despite of current dir change.
Other small issue. When opening existing project, new window opens. So you always have to GUIs: for an empty case and for the case you opened. It will be more comfortable if software will only open new window if there is any user changes in GUI, otherwise using the same window. Or just stay with one window asking user to save changes on Open (standard way), To open another project, just press Saturne launcher again.

Posted: **Thu Jan 02, 2025 3:31 am**

Hello,

Thanks for the feedback. Note that the build system was never designed to allow running the code directly from the build tree, though I was hesitating on whether to change the include path logic (using #include "subdir/file.h" rather than #include "file.h" in sources), in part so as to have a more similar logic and possibly work towards enabling this.

In any case, this would be more for reasons of comfort (faster turnaround time) than any "production" recommendations. To speed up compilation when developing, I simply tend to "cd" either to "src" or "python" (depending on what I am working on), to avoid rebuilding/reinstalling the parts not being actively changed.

Best regards,

Yvan

code_saturne User's Forum

Saturne 8 - User code compile errors

Saturne 8 - User code compile errors

Re: Saturne 8 - User code compile errors

Re: Saturne 8 - User code compile errors

Re: Saturne 8 - User code compile errors

Re: Saturne 8 - User code compile errors

Re: Saturne 8 - User code compile errors