This line seems problematic when cs_glob_lagr_model->deposition = 0, which is the default setup. A workaround could be to call it only when

if (cs_glob_lagr_model->deposition == 1)

This is exactly what is done line 1197 for the deposition with elimination

CS version: Trunk version as of April 2018

Problem: In Lagrangian calculations with multiple classes , the flow rate output reported per class per boundary in the listing file is the same value as the total at the boundary.

The problem comes from bug (likely copy/paste) in 'cs_lagr_log_iteration' in 'cs_lagr_log.c', where the print statement for each class (flow_rate) on line 556 is reporting the total instead of the class value:

  for (int j = 1; j < n_stats; j++) {
    if (CS_ABS(flow_rate[z_id*n_stats + j]) > 0)
      cs_log_printf(CS_LOG_DEFAULT,
                    "    class %3d  %12.5e         %s\n",
                    j,
                    flow_rate[z_id*n_stats]/cs_glob_lagr_time_step->dtp,
                    chcond);
  }

Solution: change the print statement to:

  for (int j = 1; j < n_stats; j++) {
    if (CS_ABS(flow_rate[z_id*n_stats + j]) > 0)
      cs_log_printf(CS_LOG_DEFAULT,
                    "    class %3d  %12.5e         %s\n",
                    j,
                    flow_rate[z_id*n_stats + j]/cs_glob_lagr_time_step->dtp,
                    chcond);
  }

When using a deformable mesh and one of the boundaries conditions is free inlet/outlet there is no drop-down list to define the ALE BC. This issue arise in this post
https://www.code-saturne.org/forum/viewtopic.php?f=2&t=2521#p13729

I test it CS version 5.10 and 6.1-alpha.

Hello,

I noticed that even if I disable diffusion for the velocity, the trasnposed gradient and secondary viscosity terms are still taken into account.

Indeed, they are not multiplied by idiff in cs_convection_diffusion.c

Is that the expected behaviour ? It does not seem right to me.

Thanks

Raphael

Dear Users, Developers,

Partitioning of a small case (64 cells) fails in parallel when the number of processors is too high (works on 10 CPUS but does not on 20). I suspect the issue is related to PT-Scotch (6.0.4 used here) but I can not verify it as I do not have any other parallel partitioning tool at hand.

Code_Saturne rev. 11067

case_8x8.tar.gz

Dear users, developers,

I had some issues to initialize a case with idilat=2, here is my workaround:

• set idilat=2 inside the subroutine usipsu (cs_user_parameters.f90)
• in cs_user_initialization.f90, add use ihmpre and the following

! Apply equation of state from graphical interface
if (iihmpr.eq.1) then
  call uiphyv(iviscv, itempk, visls0, viscv0)
endif

! Apply equation of state from user subroutine
call usphyv(nvar, nscal, 0, dt)

! Put it into previous density
call field_current_to_previous(icrom)

Best,
Cédric

Hello,

I am current trying to install code-saturne 5.0 with melissa. This issue will track progress while porting the existing patch for code-saturne 4.3.1.

Suggestions are welcome. Also, if one has a test case at hand to validate the porting, feel free to post it.

Best regards,
Cedric

I have found a couple of issues with restarting a simulations that might be related (this why the single post).
The two issues are:

1. Inconsistency of the velocity field when restarting a simulation with a different turbulence model. The problem occurs when switching from LES Smagorinsky to Dynamic and vice-versa;
2. Inconsistent pressure field in the first iteration after restart.

For the 1st issue here the logs:

• Iterations 1000: write of the restart file

   field                  minimum         maximum        set mean    spatial mean
-  --------------  --------------  --------------  --------------  --------------
v  Velocity[X]           -0.66583          1.3167         0.90516          1.0001
v  Velocity[Y]           -0.66219         0.66219     -1.6971e-08      4.3483e-11
v  Velocity[Z]        -1.5525e-09      1.0827e-09      6.6371e-12      1.3426e-14
v  Pressure              -0.48921         0.54451       -0.042022       0.0017844
v  Temperature                300          448.51          309.54          300.04

• Iteration 1001: Read of checkpoint

** VARIABLES INITIALIZATION
    ------------------------

 -----------------------------------------
  Variable          Min. value  Max. value
 -----------------------------------------                   
  Velocity         -0.6213E+00  0.1385E+01
  Velocity         -0.5745E+00  0.3782E+01
  Velocity         -0.3153E+01  0.2419E+00
  Pressure         -0.4892E+00  0.5445E+00
  Temperature       0.3000E+03  0.4485E+03

As you can see the velocity is clearly wrong particularly in the Z direction. Whereas pressure and Temperature seems OK. However, here comes the second issue
which is quite clear for the following pictures (in this case the restart is without any change):

• Here is is in V5 where the pressure is the same with or without the restart
  
• Here is is in V6 with the restart
  

At the second iteration after the restart the pressure field return to the correct state (i.e. like the one without restart) as in the picture below. However this can be just a happy coincidence.

The release commit is 68d99b8.

Thanks for your help

Stefano

Some Lagrangian particles traverse a boundary where they were expected to bounce. I will send you the case.

Depending on the choice of surfaces on which to create wall layers, the integrity of the geometry may not be maintained. Surfaces on which wall layers have not been prescribed may be deformed by the wall layer algorithm.

Testing feature "Manage user functions within the SRC folder" crashes GUI (similar outcome for trying to view log files), with the following error printed to output:

[11:21:04] : DATA/ $ ./SaturneGUI setup.xml Traceback (most recent call last): File "/home/jcharris/Articles/OM/FINAL_RESULTS/lib/python2.7/site-packages/code_saturne/Base/MainView.py", line 886, in fileEditorOpen from code_saturne.Base.QFileEditor import QFileEditor File "/home/jcharris/Articles/OM/FINAL_RESULTS/lib/python2.7/site-packages/code_saturne/Base/QFileEditor.py", line 279, in <module> class QFileEditor(QtGui.QMainWindow): AttributeError: 'module' object has no attribute 'QMainWindow' ./SaturneGUI : ligne 7 : 7260 Abandon (core dumped) \code_saturne gui $@

I get an error if in the track converge windows the fonts type or size are changed. After in the execution of "code_saturne trackcvg" the following error appears:

\\\\\\\\\\
MainView.py", line 626, in ui_initialize
if (font.fromString(from_qvariant(f, to_text_string))):
NameError: global name 'to_text_string' is not defined
\\\\\\\\\\

The solution that I found was add to the MainView.py the following modification:
from code_saturne.Base.QtPage import getexistingdirectory ,to_text_string

If the fonts are restored to the default value the problem is also solved.
I test in the CS 6 beta.

I have been unable to build Code_Saturne with PETSc for any combination of configure petsc-related options because the relative m4 file is simply wrong, at least for a regular system-wide installation of the petsc package using a typical Linux repository. I modified some files attached here to make it work.

On my system with these modifications and the command line options:

--with-petsc=/usr
--with-petsc-lib=/usr/lib64/openmpi/lib

the compilation works correctly.

You may want to consider updating them.

cs_petsc.zip

In versión 6.1-alpha when adding a transported variable (scalar1) and then choose in the physical properties a variable/user_law diffusion coefficient value for this escalar the CS GUI close with the following error

value user_law is not in list ('constant', 'variable')

For fix this issue I change in:
/src/gui/cs_gui.c
if (cs_gui_strcmp(buff, "variable")) -> if (cs_gui_strcmp(buff, "user_law"))

and
/model/DefineUserScalarsModel.py
def setScalarDiffusivityChoice(self, scalar_name, choice):
....
self.isInList(choice, ('constant', 'variable')) -> self.isInList(choice, ('constant', 'user_law'))

This fix the problem.

It would be interesting to have the possibility to obtain notebook parameters in fortran. The following addition to cs_c_bindings.f90 could do the job. It seems to work, but might need improvements as I have to trim the variable name when calling it.

function notebook_parameter_value_by_name(var_name) result (val) &
  bind(C, name='cs_notebook_parameter_value_by_name')                        
  use, intrinsic :: iso_c_binding
  implicit none
  character(kind=c_char, len=1), dimension(*), intent(in) :: var_name        
  real(kind=c_double) :: val
end function notebook_parameter_value_by_name

Trying to run `make check' fails with the following error:

cc -DHAVE_CONFIG_H -I. -I..  -I../src -DMPICH_SKIP_MPICXX -I/usr/local/include -I/usr/local/include/libxml2 -DLIBICONV_PLUG -DNDEBUG  -std=c99 -funsigned-char -Wall -Wshadow -Wpointer-arith -Wmissing-prototypes -Wuninitialized -Wunused -O2 -pipe  -DLIBICONV_PLUG -fstack-protector -fno-strict-aliasing  -MT ple_coupling_test-ple_coupling_test.o -MD -MP -MF .deps/ple_coupling_test-ple_coupling_test.Tpo -c -o ple_coupling_test-ple_coupling_test.o `test -f 'ple_coupling_test.c' || echo './'`ple_coupling_test.c
mv -f .deps/ple_coupling_test-ple_coupling_test.Tpo .deps/ple_coupling_test-ple_coupling_test.Po
/bin/sh ../libtool  --tag=CC   --mode=link cc  -std=c99 -funsigned-char -Wall -Wshadow -Wpointer-arith -Wmissing-prototypes -Wuninitialized -Wunused -O2 -pipe  -DLIBICONV_PLUG -fstack-protector -fno-strict-aliasing   -Wl,-rpath=/usr/local/lib/gcc7  -L/usr/local/lib/gcc7 -B/usr/local/bin -fstack-protector  -O -o ple_coupling_test ple_coupling_test-ple_coupling_test.o ../src/libple.la -lmpich -lopa -lmpl -lrt  -lm -lm
libtool: link: cc -std=c99 -funsigned-char -Wall -Wshadow -Wpointer-arith -Wmissing-prototypes -Wuninitialized -Wunused -O2 -pipe -DLIBICONV_PLUG -fstack-protector -fno-strict-aliasing -Wl,-rpath=/usr/local/lib/gcc7 -B/usr/local/bin -fstack-protector -O -o .libs/ple_coupling_test ple_coupling_test-ple_coupling_test.o  -L/usr/local/lib/gcc7 ../src/.libs/libple.so -lmpich -lopa -lmpl -lrt -lm -Wl,-rpath -Wl,/usr/local/lib
../src/.libs/libple.so: undefined reference to `libintl_dgettext'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[5]: *** [Makefile:423: ple_coupling_test] Error 1

The attached patch fixes the issue.
patch-libple_tests_Makefile.am.txt

Version 5.0.4 adds quotation marks around the id-prefix, if the command "code_saturne submit" is used, for example 're2017_120x041x064_LES_pr071_'20180502-1654, what prevents the simulation from being started.

Trying to run `make check', I get this failure:

cc -DHAVE_CONFIG_H -I/usr/ports/science/code_saturne/work/code_saturne-5.3.0/libple -I../libple/src -I/usr/ports/science/code_saturne/work/code_saturne-5.3.0 -I../src/turb -I../src/mei -I../src/gui -I../src/cdo -I../src/mesh -I../src/atmo -I../src/alge -I../src/lagr -I../src/base -I../src/pprt -I../src/rayt -I../src/elec -I../src/bft -I../src/apps -I../src/fvm -I../src/user_examples -I../src/cfbl -I../src/comb -I../src/darc -I../src/ctwr -I../src/.libs -I../src/user -I../src/cogz -I/usr/local/include -DMPICH_SKIP_MPICXX -I/usr/local/include -I/usr/local/include/libxml2 -DLIBICONV_PLUG -DNDEBUG -std=c99 -funsigned-char -Wall -Wshadow -Wpointer-arith -Wmissing-prototypes -Wuninitialized -Wunused -O2 -pipe -DLIBICONV_PLUG -fstack-protector -fno-strict-aliasing -fopenmp=libomp -O2 -c ../tests/cs_check_cdo.c
../tests/cs_check_cdo.c:1110:46: error: use of undeclared identifier 'cs_cdovb_diffusion_cost_flux_op'
    cs_cdo_diffusion_pena_dirichlet(eqp, cm, cs_cdovb_diffusion_cost_flux_op,
                                             ^
../tests/cs_check_cdo.c:1119:5: warning: implicit declaration of function 'cs_cdovb_diffusion_weak_dirichlet' is invalid in C99 [-Wimplicit-function-declaration]
    cs_cdovb_diffusion_weak_dirichlet(eqp, cm, cs_cdovb_diffusion_cost_flux_op,
    ^
../tests/cs_check_cdo.c:1119:48: error: use of undeclared identifier 'cs_cdovb_diffusion_cost_flux_op'; did you mean 'cs_cdovb_diffusion_p0_face_flux'?
    cs_cdovb_diffusion_weak_dirichlet(eqp, cm, cs_cdovb_diffusion_cost_flux_op,
                                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                               cs_cdovb_diffusion_p0_face_flux                                                                             
../src/cdo/cs_cdo_diffusion.h:504:1: note: 'cs_cdovb_diffusion_p0_face_flux' declared here
cs_cdovb_diffusion_p0_face_flux(const cs_cell_mesh_t     *cm,
^
../tests/cs_check_cdo.c:1129:5: warning: implicit declaration of function 'cs_cdovb_diffusion_wsym_dirichlet' is invalid in C99 [-Wimplicit-function-declaration]
    cs_cdovb_diffusion_wsym_dirichlet(eqp, cm, cs_cdovb_diffusion_cost_flux_op,
    ^
../tests/cs_check_cdo.c:1129:48: error: use of undeclared identifier 'cs_cdovb_diffusion_cost_flux_op'; did you mean 'cs_cdovb_diffusion_p0_face_flux'?
    cs_cdovb_diffusion_wsym_dirichlet(eqp, cm, cs_cdovb_diffusion_cost_flux_op,
                                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                               cs_cdovb_diffusion_p0_face_flux                                                                             
../src/cdo/cs_cdo_diffusion.h:504:1: note: 'cs_cdovb_diffusion_p0_face_flux' declared here
cs_cdovb_diffusion_p0_face_flux(const cs_cell_mesh_t     *cm,
^
../tests/cs_check_cdo.c:1155:46: error: use of undeclared identifier 'cs_cdovb_diffusion_cost_flux_op'
    cs_cdo_diffusion_pena_dirichlet(eqp, cm, cs_cdovb_diffusion_cost_flux_op,
                                             ^
../tests/cs_check_cdo.c:1190:46: error: use of undeclared identifier 'cs_cdovb_diffusion_wbs_flux_op'
    cs_cdo_diffusion_pena_dirichlet(eqp, cm, cs_cdovb_diffusion_wbs_flux_op,
                                             ^
../tests/cs_check_cdo.c:1199:5: warning: implicit declaration of function 'cs_cdovb_diffusion_weak_dirichlet' is invalid in C99 [-Wimplicit-function-declaration]
    cs_cdovb_diffusion_weak_dirichlet(eqp, cm, cs_cdovb_diffusion_wbs_flux_op,
    ^
../tests/cs_check_cdo.c:1199:48: error: use of undeclared identifier 'cs_cdovb_diffusion_wbs_flux_op'; did you mean 'cs_cdo_diffusion_wbs_face_flux'?
    cs_cdovb_diffusion_weak_dirichlet(eqp, cm, cs_cdovb_diffusion_wbs_flux_op,
                                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                               cs_cdo_diffusion_wbs_face_flux
../src/cdo/cs_cdo_diffusion.h:528:1: note: 'cs_cdo_diffusion_wbs_face_flux' declared here
cs_cdo_diffusion_wbs_face_flux(const cs_face_mesh_t      *fm,
^
../tests/cs_check_cdo.c:1207:5: warning: implicit declaration of function 'cs_cdovb_diffusion_wsym_dirichlet' is invalid in C99 [-Wimplicit-function-declaration]
    cs_cdovb_diffusion_wsym_dirichlet(eqp, cm, cs_cdovb_diffusion_wbs_flux_op,
    ^
../tests/cs_check_cdo.c:1207:48: error: use of undeclared identifier 'cs_cdovb_diffusion_wbs_flux_op'; did you mean 'cs_cdo_diffusion_wbs_face_flux'?
    cs_cdovb_diffusion_wsym_dirichlet(eqp, cm, cs_cdovb_diffusion_wbs_flux_op,
                                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                               cs_cdo_diffusion_wbs_face_flux
../src/cdo/cs_cdo_diffusion.h:528:1: note: 'cs_cdo_diffusion_wbs_face_flux' declared here
cs_cdo_diffusion_wbs_face_flux(const cs_face_mesh_t      *fm,
^
4 warnings and 7 errors generated.
gmake[4]: *** [Makefile:1588: cs_check_cdo] Error 1

I cannot find where it is declared; any idea?

Hello,

I would like to test the current version of CS but the GUI doesn't start. I have the following error when I try to run the GUI:

Traceback (most recent call last):
File "/home/yohann-ws2/Code_Saturne/6.0-alpha_09Jan19/code_saturne-6.0-alpha/arch/Linux_x86_64/bin/code_saturne", line 76, in
retcode = cs.execute()
File "/home/yohann-ws2/Code_Saturne/6.0-alpha_09Jan19/code_saturne-6.0-alpha/arch/Linux_x86_64/lib/python2.7/site-packages/code_saturne/cs_script.py", line 91, in execute
return self.commandscommand
File "/home/yohann-ws2/Code_Saturne/6.0-alpha_09Jan19/code_saturne-6.0-alpha/arch/Linux_x86_64/lib/python2.7/site-packages/code_saturne/cs_script.py", line 150, in gui
return cs_gui.main(options, self.package)
File "/home/yohann-ws2/Code_Saturne/6.0-alpha_09Jan19/code_saturne-6.0-alpha/arch/Linux_x86_64/lib/python2.7/site-packages/code_saturne/cs_gui.py", line 194, in main
from code_saturne.Base.MainView import MainView
File "/home/yohann-ws2/Code_Saturne/6.0-alpha_09Jan19/code_saturne-6.0-alpha/arch/Linux_x86_64/lib/python2.7/site-packages/code_saturne/Base/MainView.py", line 77, in
from code_saturne.Base.BrowserView import BrowserView
File "/home/yohann-ws2/Code_Saturne/6.0-alpha_09Jan19/code_saturne-6.0-alpha/arch/Linux_x86_64/lib/python2.7/site-packages/code_saturne/Base/BrowserView.py", line 67, in
_fromUtf8 = QString.fromUtf8
NameError: name 'QString' is not defined

How can I fix that?

Greetings,

Yohann

On a 14M cells grid with no quality problem according to the listing, in the "clipping" section Rii are < 0 on many cells (5%). Also the number of iterations required changes in one time step from ~200 to 10000 and back to ~200.
listing.txt

Depending on the geometry and the settings, the wall layer algorithm can create interpenetrating cells, resulting in meshes unsuitable for calculations.

This can happen if the velocity is zero?

When trying to use the studymanager I get the following error:

File "/home/panos/Applications/Code_Saturne/code_saturne-6.0/arch/Linux_x86_64/lib/python3.7/site-packages/code_saturne/studymanager/cs_studymanager_study.py", line 226, in __get_exe
    pkg = package()
UnboundLocalError: local variable 'package' referenced before assignment

Code_Saturne is running under Python 3.7 on my system and the code which causes this problem is the following:

def __get_exe(self, old_pkg, run_ref):
        """
        Return the name of the exe of the case, in order to mix
        Code_Saturne and NEPTUNE_CFD test cases in the same study.
        """

        # Read the runcase script from the Repository

        runcase = cs_runcase.runcase(run_ref)
        
        if runcase.cmd_name == "code_saturne":
            from cs_package import package
        elif runcase.cmd_name == "neptune_cfd":
            from nc_package import package
        pkg = package()

        return runcase.cmd_name, pkg

This part is problematic because what value does pkg take when none of the if-statements are valid? I fixed this by changing this code to the following:

def __get_exe(self, old_pkg, run_ref):
        """
        Return the name of the exe of the case, in order to mix
        Code_Saturne and NEPTUNE_CFD test cases in the same study.
        """

        # Read the runcase script from the Repository

        runcase = cs_runcase.runcase(run_ref)
        pkg = 0
        
        if runcase.cmd_name == "code_saturne":
            from cs_package import package
            pkg = package()
        elif runcase.cmd_name == "neptune_cfd":
            from nc_package import package
            pkg = package()

        return runcase.cmd_name, pkg

Hi,

I've got a mesh with a periodicity in the x direction.
I noticed in the listing that the total number (i.e. over the whole mesh) of internal faces printed after joining periodic faces seems wrong, since the boundary faces which have been joined are then counted twice.

This is not coherent with how the number of upwind faces are counted, for example.

Indeed, with the upwind scheme activated for any variable I can read in the listing that I get

m upwind faces over a total of n internal faces

where m<n !!!

Raphael

As notebook variables are now used to perform sensitivity studies, that would be useful to be able to use them in user subroutines (for instance if a structure notebook with variables in it with the same name as in the notebook of the GUI).

Dear users, developers,

Following this line of fvm_to_melissa, code_saturne works with Melissa only when data is communicated every time step. It should be possible to downsample the communication using the following modification:

-  c.writer->time_stamp = time_step;
+// Writer w has time_stamp in [0,N-1] but Melissa looks for time_stamp in [1,N]
+  c.writer->time_stamp = 1 + w->time_stamp; 

EDIT: it is actually slightly more complex to fix it, will update the post when I have a better solution

Best regards,
Cedric

The compilation of the trunk version seems broken since this commit

Currently, the listing contains the Courant and Fourier numbers for the momentum equation, and the combined Courant/Fourier criterion. It could be interesting to also have this combined Courant/Fourier criterion for transported scalars. This might be especially relevant for buoyant scalars.

In some case the Free surface BC is set in the XML file as fixed_boundary, so the boundary is not moved with the surface velocity.
I attach a case where the BC_4 is set as:
<boundary label="BC_4" name="3" nature="free_surface">TOP</boundary>
After saving any modification (time step, number of iter, etc) through the GUI the following block of code is inserted in the XML file

<wall field_id="none" label="BC_4">
<ale choice="fixed_boundary"/>
</wall>

As result the free surface doesn't move. If this block of code is removed from the XML the free surface move correctly.
The version of CS used is 5.0.9 in linux (ubuntu 17.1). Is attached the test case.

test_case.zip

Hello,

When performing a restart from a simulation without chemistry, init_at_chem is set to ival(1)

For such a case (ierror is not zero), I suspect it would be better to set it to one, so that the fields are properly initialized in atiniv?

Thanks

EDIT: adding a suggestion for the modification

if (ichemistry.gt.0.or.iaerosol.gt.0) then
  rubriq = 'atmospheric_chem'
  itysup = 0
  nbval  = 1
  call restart_read_section_int_t(rp,rubriq,itysup,nbval,ival,ierror)
  if (ierror.eq.0) then
    init_at_chem = ival(1)
    if (init_at_chem.gt.0) then
      init_at_chem = 0
    endif
  else
    init_at_chem = 1
  endif
endif

I was using the Vof algorithm in CS 5.0.9 and CS 5.3 to solve a 2D dam-break getting different results. The results were compared with the experimental and numerical results of the following paper: doi.org/10.1016/j.ijmultiphaseflow.2018.08.003 (Figs 4 and 7 of the paper)

When running with CS 5.0.9 the front of the wave hit earlier the obstacle, due to a bigger velocity. When reducing the Co number (0.5 -> 0.05) the result change significantly (see Fig_1 attached) and converge to the results of CS 5.3. The case was running with a SIMPLEC P-V coupling, because the PISO coupling diverge for this problem in CS 5.0.9. With CS 5.3 the problem run correctly for SIMPLEC and PISO coupling and the results are very close to that reported in the reference (see Fig_2 attached). About that issue I can't find the problem. I attach the dam break case.

The problem in CS 5.3 is the report of the "Mixture global mass budget", which is wrong. Debugging the code I found that the value of the array "croma" containing the density at cell centers at previous time step is not being updated and have the initial ones when using it in the vof_print_mass_budget() subroutine. Following the history of change in 5.0.9 the density at time step n-1 was updated in the section 5.bis of tridim.f90. This section was removed in 5.3 in the commits 9fb8530 and a2ddc3b, and I think that was move to varpos.f90 and then to addfld.f90. I attach a text file were is printed for a cell the density for the steps n and n-1 and the mass budget. I modify the tridim in order to update the croma array (diff file attached).

In the equation presented in the documentation the void fraction at n and n-1 are used to compute mass budget, but in the subroutine the densities at n and n-1 are used.

Fig_2.pdf
mass_budget.txt
diff_tridim.txt
CS_files.zip

Trying v5.3.3, code_saturne gui produces the following error:

  File "/usr/local/bin/code_saturne", line 76, in <module>
    retcode = cs.execute()
  File "/usr/local/lib/python2.7/site-packages/code_saturne/cs_script.py", line 91, in execute
    return self.commands[command](options)
  File "/usr/local/lib/python2.7/site-packages/code_saturne/cs_script.py", line 150, in gui
    return cs_gui.main(options, self.package)
  File "/usr/local/lib/python2.7/site-packages/code_saturne/cs_gui.py", line 196, in main
    mv = MainView(cmd_package = pkg, cmd_case = case)
  File "/usr/local/lib/python2.7/site-packages/code_saturne/Base/MainView.py", line 1346, in __init__
    self.Browser = BrowserView()
  File "/usr/local/lib/python2.7/site-packages/code_saturne/Base/BrowserView.py", line 385, in __init__
    self.model = TreeModel(from_qvariant(to_qvariant(tree), to_text_string))
  File "/usr/local/lib/python2.7/site-packages/code_saturne/Base/QtPage.py", line 144, in from_qvariant
    return convfunc(qobj.toString())
AttributeError: 'QVariant' object has no attribute 'toString'

Am I missing something?
Note: this is on FreeBSD.

When renaming scalars (species) in the GUI, the "species properties" in the Thermophysical Models/Groundwater Flow/Species Properties are not updated in the XML tree.

On a 225M cells grid with no quality problem according to the listing, the ~25 first time steps show the warning message that the calculation of wall_dist does not converge. After the message disappears and will only reappear at the beginning of the next restart.
listing.txt

Postprocessing output of boundary fields is quite limited.

The GUI should allow selecting boundary fields in a more consistent manner with volume fields. Preliminary work on this has been done in December 2018 (unifying the main GUI and NEPTUNE_CFD GUI), but the feature is not yet available.

This should be consistent with a future cs_calculator API allowing the definition of 'on the fly' computations of temporary field values, which will be used to unify time moments, probes, and other user definitions.

In order to use autovnv/study manager easily (with some python scripts) is-it possible to change the third line of the output file "cooling_towers_balance.01"
from :

line 1 # Balance for the exchange zone 01
line 2 # ====================
line 3 Time Flux air/liq Temp liq ....
To:

line 1 # Balance for the exchange zone 01
line 2 # ======================
line 3 # Time Flux air/liq Temp liq ....

Thank you for your help

Yohann

On "axysymmetric" cases (where the mesh uses a radially extruded slice, with symmetry on the sides), the wall distance approximated by a diffusion equation (in distpr) can be imprecise, with a difference up to 40% having been observed.

This issue also occurs using the CDO operators, so seems due to the the choice of equation or boundary conditions rather than linear operator.

In any case, this can induce an error on turbulence variables.

More works needs to be done on this, but replacing the approximate wall distance with a
geometrically computed wall distance for the boundary cells might at least mitigate the effects.

Attached is a small case allowing to test this.
test_pipe_axi.tar.gz

When creating an atmospheric case, the default formula for density sets it to -1 and cannot be modified, except with a manual edition of the xml. This prevents any simulation from running from the GUI.

This seems related to MEG interpretation formula colliding with the atmospheric module.

setupxml.txt

File salome/cfd_study/resources/Makefile.am refers to the following no longer existing icon files:

compiler-icon.png
editor-icon.png
file-transfer.png
viewer-icon.png

causing compilation to fail.

The initialization of turbulence does not work in case of Rij-SSG model. I tried to initialize it by three ways and none of them is working:

1. Initialization by formula:

trii   = (0.02*0.1)^2;
cmu = 0.09;
r11 = trii;
r22 = trii;
r33 = trii;
r12 = 0.;
r13 = 0.;
r23 = 0.;
k = 0.5*(r11+r22+r33);
epsilon = k^1.5*cmu/0.13;

2. Initialization by reference value.
3. Initialization by cs_user_initialization.c:

void
cs_user_initialization(void)
{

  const int location_id = CS_MESH_LOCATION_CELLS;

  const cs_lnum_t n_elts = cs_mesh_location_get_n_elts(location_id)[0];

  cs_real_3_t *vel = (cs_real_3_t *)(CS_F_(u)->val);

  // cs_real_33_t *rij = (cs_real_33_t *)(CS_F_(rij)->val);

  const cs_real_3_t  *restrict cell_cen
    = (const cs_real_3_t *restrict)cs_glob_mesh_quantities->cell_cen;


  const cs_real_3_t* xyz = (cs_real_3_t *)cs_glob_mesh->vtx_coord;

  cs_real_t * r11_val = (cs_real_t *)CS_F_(r11)->val;
  cs_real_t * r22_val = (cs_real_t *)CS_F_(r22)->val;
  cs_real_t * r33_val = (cs_real_t *)CS_F_(r33)->val;
  
  cs_real_t * r12_val = (cs_real_t *)CS_F_(r12)->val;
  cs_real_t * r23_val = (cs_real_t *)CS_F_(r23)->val;
  cs_real_t * r13_val = (cs_real_t *)CS_F_(r13)->val;

  
  cs_real_t *eps = (cs_real_t *)CS_F_(eps)->val;
  // cs_real_t *k = (cs_real_t *)CS_F_(k)->val;

  for (cs_lnum_t i = 0; i < n_elts; i++) {
    vel[i][0]=10.0;
    vel[i][1]=10.0;
    vel[i][2]=10.0;
    
    // k[i] = 0.2;
    eps[i] = 0.5;
    // rij[i][0][0] = 0.1;
    // rij[i][0][1] = 0.0;
    // rij[i][0][2] = 0.0;

    // rij[i][1][0] = 0.0;
    // rij[i][1][1] = 0.1;
    // rij[i][1][2] = 0.0;

    // rij[i][2][0] = 0.0;
    // rij[i][2][1] = 0.0;
    // rij[i][2][2] = 0.1;
    
    r11_val[i]= 0.1;
    r22_val[i]= 0.1;
    r33_val[i]= 0.1;

    r12_val[i]= 0.;
    r13_val[i]= 0.;
    r23_val[i]= 0.;
  }
}

In cases it gives error message:

cs_field.c:1075: Fatal error.

Fortran pointer of rank 1 requested for values of field "rij",
which have rank 2.


Call stack:
   1: 0x7f7924051c88 <cs_f_field_var_ptr_by_id+0x88>  (libsaturne.so.5)
   2: 0x7f7924611872 <__field_MOD_field_get_val_s+0x21> (libsaturne.so.5)
   3: 0x401657     <cs_user_f_initialization_+0x12e> (cs_solver)
   4: 0x7f79240fcc22 <inivar_+0x3f3>                  (libsaturne.so.5)
   5: 0x7f7923fe35bc <caltri_+0x131d>                 (libsaturne.so.5)
   6: 0x7f792560008f <cs_run+0x54f>                   (libcs_solver.so.5)
   7: 0x7f79255ff9f3 <main+0x113>                     (libcs_solver.so.5)
   8: 0x7f792365c830 <__libc_start_main+0xf0>         (libc.so.6)
   9: 0x4010c9     <_start+0x29>                    (cs_solver)
End of stack

P.S. Need to note if I use the same approaches but with k-epsilon model, then everything works fine.

Here a configuration which doesn't work with CS 5.3.1. There are two images attached to this mail:

• On the first image, the red face has no extrusion layer (All is Ok)
• On the second image, the red face has an extrusion layer (CS adds a strange step )

Thanks for your work,

Yohann

That would be nice to have an option - -with-catalyst=salome when Code_Saturne is configured with salome.

Currently, for Large Eddy Simulations, subgrid flux of scalars are obtained using a constant subgrid Prandtl number (default value is 1). It would be interesting to have more options as scalar fluctuations are not always similar to velocity fluctuations.

(transferred from Mantis bug tracker issue 215, opened by Mathtrack).

Hello,

With the version CS 20Dec18 be0ee1d, it is not possible to add a boundary layer. The code crash at the line " cs_mesh_boundary_layer_insert(mesh, e, 0.2, false);".

cs_user_mesh_c.txt
run_solver.txt

Hello,

To be confirmed? See my comment here 544fb30#r30970378

Best regards,
Cédric

Currently, the cell->vertices to face->cells and face->vertices connectivity conversion is done in the proprocessor. Migrating this to the solver requires modifying the preprocessor reader, but would have several advantages:

• Lower memory usage (about half) in the non-parallel preprocessor
• Migrate all postprocessing and mesh checking aspects to the solver
• prerequisite to allow adding parallel mesh readers directly in solver

This could also be done in a separate order, adding specific readers to the solver (reading into an FVM mesh for formats such as MED or CGNS, allowing interpolation operations) first.

Note: this is an update from an issue on the old (Mantis) issue tracker, which is a long-term goal.

The possibility to do a restart from a simulation performed on another mesh is very interesting. As it requires a mesh_input or a mesh_output, it would be convenient to have a checkbox in the GUI to force the creation of such a file. Currently, the files can be obtained with the tool cs_preprocess or with the routine cs_user_mesh_save.

I believe that the call of subroutine ustsnv in line 225 of file src/cfbl/cfmsfp.f90

! --- User source term
call ustsnv &
!==========
( nvar , nscal , ncepdp , ncesmp , &
iu , &
icepdc , icetsm , itypsm , &
dt , &
ckupdc , smacel , tsimp , tsexp )

is wrong because the two last arguments should be reversed as

! --- User source term
call ustsnv &
!==========
( nvar , nscal , ncepdp , ncesmp , &
iu , &
icepdc , icetsm , itypsm , &
dt , &
ckupdc , smacel , tsexp , tsimp )

Dear users, developers,

I have set some probes but the last output indicates a time of zero. Attached is the source code used. Last lines of a probe file are:

2.4999970e+04  1.6279829e-05  5.1123789e-05  5.6239926e-06  5.8274681e-07
2.4999980e+04  1.8933431e-05  5.2770401e-05  4.5013857e-06  6.1810132e-07
2.4999990e+04  2.2249430e-05  5.1205274e-05  3.6415957e-06  6.5100707e-07
0.0000000e+00  2.6026189e-05  4.6779131e-05  3.1253508e-06  6.8056081e-07

cs_user_postprocess.c.gz

Thanks,
Cedric

EDIT: the issue was not observed on 5.0 but on 02f8dec