Outlet condition with negative velocity

[Tsubasa]

Hello all,

I am trying to make a outlet boundary conditions where:
- velocity has a negative volumic flow rate (m3/s)
- Neumann condition for scalar transport

Otherwise, I am also considering another idea instead of the above,
- inlet condition with a negative volumic flow rate (m3/s) (This is easy to setup in GUI)
- Neumann condition for scalar transport

Is there someone who can do this with cs_user_boundary_conditions.f90?

Best regards,
Hamada

[Yvan Fournier]

Hello,

I do not have a specific example, but basically :

- You can simply use boundary conditions similar to those of an outlet for all scalars and turbulence variables.

- If a free outlet becomes an inlet dur to this, you need to define "backflow" conditions, so basically use boundary conditions similar to those of an inlet for all scalars and turbulence variables.

I am not sure we have up to date examples of this, but the adavances section of the user documentation can help, and otherwise, you can look at the code in src/base/typecl.f90 to see how defaul condtions map to individual variables.

The definition of backflow conditions is still missing from the GUI, so in most cases, you need to edit cs_user_boundary_conditions (C or Fortran) to handle this.

Best regards,

Yvan

[Tsubasa]

Hello Yvan,

For example, I tried the inlet condition with a negative velocity (handled by GUI) and set for scalar by this code:

Code: Select all

call getfbr('extraction_duct', nlelt, lstelt)
do ilelt = 1, nlelt
   ifac = lstelt(ilelt)
   itypfb(ifac) = ientre

!Neumann B.C for scalar:
call field_get_id("scalar1", f_id)
call field_get_key_id("scalar_id", keysca)
call field_get_key_int(f_id, keysca, iscal)
   icodcl(ifac,isca)=3

enddo

Is this the right direction? or Is it a stupid thing?

The error message shows

Code: Select all

SIGTERM signal (termination) received.
--> computation interrupted by environment.

Call stack:
   1: 0x7f61fec6d336 <+0x5336>                        (mca_btl_vader.so)
   2: 0x7f62007f4854 <opal_progress+0x34>             (libopen-pal.so.40)
   3: 0x7f62007fb315 <ompi_sync_wait_mt+0xb5>         (libopen-pal.so.40)
   4: 0x7f61fec28ff3 <mca_pml_ob1_recv+0x833>         (mca_pml_ob1.so)
   5: 0x7f6201528366 <ompi_coll_base_allreduce_intra_recursivedoubling+0x5d6> (libmpi.so.40)
   6: 0x7f62014e3411 <PMPI_Allreduce+0x191>           (libmpi.so.40)
   7: 0x7f620218ff03 <cs_f_parall_max_i+0x43>         (libsaturne-6.0.so)
   8: 0x7f62022683dd <typecl_+0x254>                  (libsaturne-6.0.so)
   9: 0x7f620210a8fc <condli_+0xbb0>                  (libsaturne-6.0.so)
  10: 0x7f620226778e <tridim_+0x4596>                 (libsaturne-6.0.so)
  11: 0x7f62020ed36c <caltri_+0x25ce>                 (libsaturne-6.0.so)
  12: 0x7f6203699c80 <cs_run+0x610>                   (libcs_solver-6.0.so)
  13: 0x7f6203699561 <main+0x1a1>                     (libcs_solver-6.0.so)
  14: 0x7f6201b6c0b3 <__libc_start_main+0xf3>         (libc.so.6)
  15: 0x55861bd860ee <_start+0x2e>                    (cs_solver)
End of stack

run_solver.log

(26.25 KiB) Downloaded 44 times

setup.xml

(9.94 KiB) Downloaded 42 times

Best regards,
Hamada

[Yvan Fournier]

Hello,

Actually, though you need to define backflow conditions for reverse outlets, I am not sure you need to do anything special for reverse inflows (you would need to test or read the code in typecl.f90 I think).

In any case, when you arev running on multiple MPI ranks, the base "error" file is usually not the interesting one. Check the best practice guidelines of this here : https://www.code-saturne.org/documentat ... oting.html

Best regards,

Yvan