Mesh Generation of Complex Geometry

Dear developers,
I encountered a reactor of complex geometry. Its meshing seems difficult for me. Could you give me some guidance? thank you a lot.
The mfix version is 22.4.3.
Sincerely
Tong
dangban_2023-03-20T183551.060724.zip (226.1 KB)

You cannot use zero-thickness internal STL walls. The wall thickness must be larger than the grid spacing.

Thank you! It is very helpful. The cold flow of particles can be simulated, but after adding a heat transfer model, mfix crashed. Could you help me correct it further?
dangban_2023-03-21T191134.995334.zip (391.0 KB)

Error: Solver crash!
The MFiX solver has terminated unexpectedly
Error information:
exception: float divide by zero

Please inspect your mesh. The grid resolution is still not sufficient to resolve the internal ramps.

Running 22.4.3 on Linux:

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:

#0 des_thermo_newvalues_mod_MOD_des_thermo_newvalues
  at des/des_thermo_newvalues.f:55
#1 des_time_march_MOD_des_time_step
  at des/des_time_march.f:216
#2 run_dem
  at [mfix.f:211](mfix.f:211)
#3 run_mfix
  at [mfix.f:146](mfix.f:146)
#4 main_MOD_run_mfix0
  at [main.f:79](main.f:79)

Process exit /home/cgw/mambaforge/envs/mfix-22.4.3/bin/mfixsolver -s -f /tmp/dangban_2023-03-21T191134.995334/dangban.mfx

@NJIFE - I see that you are running on WIndows. The debugging tools on Windows are not as good as the tools on Linux. On Linux, when the solver crashes, we get a full stack trace as shown above. We are working on bringing this feature to Windows (in the 23.1 release) which should make troubleshooting easier for our WIndows users.

Here’s the trouble:

! First-order method
         IF (INTG_EULER) THEN
            WHERE(PARTICLE_STATE(:MAX_PIP) == NORMAL_PARTICLE)   &
                 DES_T_s(:MAX_PIP) = DES_T_s(:MAX_PIP) +   &
                 DTSOLID*(Q_Source(:MAX_PIP)/(PMASS(:MAX_PIP)*     &
                 DES_C_ps(:MAX_PIP)))
(gdb) p intg_euler
$8 = .TRUE.
(gdb) p max_pip
$9 = 4
(gdb) p particle_state
$10 = (1, 2, 0, 0)
(gdb) p des_t_s
$11 = (783, 783, 0, 0)
(gdb) p dtsolid
$12 = 2.4791425728385559e-05
(gdb) p q_source
$13 = (-7.1522768060022806e-05, 0, 0, 0)
(gdb) p pmass
$14 = (3.1101767270538953e-05, 3.1101767270538953e-05, 3.4028234663852886e+38, 3.4028234663852886e+38)
(gdb) p des_c_ps
$15 = (0, 0, 0, 0)

So, it’s division-by-zero because of des_c_ps being in the denominator.
Also note unusually large values for pmass (3.4028234663852886e+38)

I highly appreciate your hard work@cgw@jeff.dietiker. We sincerely hope that the mesh tools and boundary condition capture tools can be improved.

In addition to the mesh quality issue Jeff points out, there’s another problem that is leading to this zero-division.

The solids specific heat model is set to Mixture, and no species are defined. This setting is invalid (it should have been disabled, I will fix that for the next release).

Set it to Constant:

1 Like

Wow, it worked. This tip is very important. Thank you!