Persistent DELH sentinel values / axial seam defect in cylindrical cut-cell mesh causing velocity spike and crash (MFiX 26.1.2, macOS and HPC Linux)

Summary

I’m running a CFD-DEM cylindrical fluidized bed and have identified a persistent geometric defect in the cut-cell mesh: an axial seam producing undefined DELH sentinel values in ~18% of U/W-momentum cut cells, consistent across mesh resolutions and tolerance settings. In an earlier run using default mesh options (no tolerance adjustments), this was associated with a localized high-velocity cut cell that displaced particles and eventually caused a DT < DT_MIN crash (see screenshots below). The attached case (with adjusted mesh tolerances) completes successfully, but the same underlying mesh defect is present in its MESH_STATS.LOG, so I’d like to understand the mechanism, since the unphysical particle behavior is actually more pronounced in the current case, despite it running to completion.

Running MFiX 26.1.2 on macOS (single-core) and HPC Linux (DMP) — same mesh defect signature on both.

Setup

Based on tutorial “3.5 Three-Dimensional Fluidized Bed”, modified to CFD-DEM: 50 mm diameter × 500 mm cylinder, 0.5/0.7 mm glass beads (ρ=2670 kg/m³), liquid water as the continuous phase, targeting Peng et al. (2022) case #1 (0.017 m/s inlet, 0.2 solids fraction, ~50% bed expansion at steady state). Tested 20×60×20 up to 26×250×26 background mesh, particle counts from ~5,900 up to ~2.4M, with and without inlet velocity.

Prior behavior at larger scale

In earlier runs at higher particle count and nonzero inlet velocity, the simulation would crash with DT < DT_MIN, preceded by hundreds of iterations of a repeating velocity-limit warning localized to a single, consistent cut cell (same cell every time, not migrating), of the form:

WARNING from utilities_mod.f:170
Velocity exceeds limit: 1.7000
Epg = 1.0000  Ug = ...  Vg = -1.7006  Wg = ...

Key points from that investigation:

  • The velocity limit was exactly 100× the imposed inlet velocity, confirming MAX_INLET_VEL_FAC clamping was in effect
  • The offending cell’s vertical velocity component was negative (opposite the inflow direction) — not a simple inlet overshoot
  • The crash reproduced at zero inlet velocity, ruling out the inlet BC as the root cause
  • Epg = 1.0 in the offending cell (no particles present) — pointing to a fluid-solver/geometry issue rather than DEM packing

Attached case: completes, but same mesh defect present

The attached case (~5,900 particles, IC_EP_S = 0.002, no inlet velocity, procedural cylinder, 26×250×26 background mesh, adjusted mesh tolerances) runs to completion (tstop = 1.0s reached, no crash — see attached .mfx/log excerpt). However, the unphysical particle displacement behavior is more pronounced in this case than in the earlier default-mesh-options run, despite the run itself not crashing. Its MESH_STATS.LOG shows the same signature defect seen previously:

  • ~18% of U-momentum and W-momentum cut cells report DELH = 9.88E+32 (the undefined placeholder value), consistent across the full range of configurations I’ve tested

  • DELH_V (radial/vertical direction) does not show this sentinel population, only DELH_U and DELH_W

  • Boundary mesh visualization (aspect-ratio colored) shows a single continuous high-aspect-ratio stripe running the full axial length of the cylinder at one circumferential position — consistent with the STL closure seam where the cylinder’s circumferential triangulation wraps back on itself

This defect appears independent of mesh resolution and tolerance settings (see below). Notably, the mesh tolerance adjustments applied to the attached case did not reduce the unphysical behavior — if anything it appears worse — suggesting these particular tolerance changes are not addressing the actual root cause and may be interacting with it in an unhelpful way.

Tried, no fix for the underlying DELH defect

  • Mesh tolerances: TOL_SMALL_CELL (0.01→0.1), TOL_SNAP (0→0.05), STL_SMALL_ANGLE (0.1→1.5°), TOL_STL_DP (0.001→0.01), TOL_STL (1e-6→1e-5), TOL_DELH (0→0.1)
  • Geometry: clean/triangle filters, primitive→procedural cylinder, circumferential resolution 30→25
  • Mesh density: 20×60×20 / 40×200×40 / 26×250×26 (finer sometimes worse — supports geometric, not resolution, root cause)
  • Seeding: switched IC_DES_NP→IC_EP_S (found IC_DES_NP was giving 100× lower solids fraction than intended), tested IC_DES_SPACING adjustments, DES_EPG_CLIP=0.42
  • Inlet ramp (0→0.017 m/s over 0.1s) — shifts crash timing only, in prior crashing cases

Not yet tried: rotating the cylinder about the y-axis (to shift the seam off the Cartesian grid’s alignment), loosening TOL_MERGE (currently default 1e-12 — could be leaving near-duplicate seam vertices unmerged), CG_SAFE_MODE=1 as a diagnostic.

Questions

  1. Is the ~18% DELH_U/DELH_W sentinel population a known consequence of a cylinder’s circumferential closure seam in the cut-cell mesher?
  2. The mesh tolerance adjustments I applied to the attached case (see list above) did not reduce the unphysical particle behavior — it appears worse than in an earlier run with default tolerances. Is it possible some of these tolerance changes are counterproductive for this type of defect, or interacting with it in an unexpected way?
  3. Recommended workflow for cylindrical STL geometries at this scale (~50 mm diameter) that avoids this defect class?

Target configuration

My ultimate goal is the cylindrical geometry, with inlet velocity of 0.017 m/s, 0.2 solids volume fraction, settling to a steady-state bed expansion of roughly 50% — matching Peng et al. (2022) case #1.

Attached

  1. .mfx, ~5,900 particles, IC_EP_S=0.002, inlet velocity 0.0 m/s, procedural cylinder, 26×250×26 background mesh, adjusted mesh tolerances — completes to tstop but shows more pronounced unphysical particle displacement than the earlier default-tolerance run
  2. MESH_STATS.LOG from the above case, showing the DELH_U/DELH_W sentinel histograms
  3. Solver stdout/log excerpt showing successful completion (Simulation time reached = 1.006s)

Happy to provide a previous case as well if it would help illustrate the failure mode.

Reference

Peng, J., Sun, W., Han, H., Xie, L., and Xiao, Y. (2022). Experimental and numerical simulation study on the hydrodynamic characteristics of spherical and irregular-shaped particles in a 3D liquid-fluidized bed. Korean Journal of Chemical Engineering, 39(11), 3165–3176.

FluidizedBed-MeshOptions.zip (27.0 MB)

  1. When you see DEL_H = 9.88E+32 it means the distance to the wall (from the cell center) is less than the minimum allowed. Say TOL_DELH=0.02, if a wall distance is less than 0.02 times the uncut cell diagonal, then we set DEL_H = 9.88E+32 in that cell. This is done to avoid division by a small DEL_H value when we have a small cut cell. TOL_DELH is typically set between zero and 0.01 to 0.02. Seeing o few of this values is usually not an issue.
  2. Please attach the case that fails with non-zero inlet velocity, and higher particle count. You can try to use the least amount of particles to reproduce the issue, but make sure they vertically stack up a t least a couple of cells. There is a know limitation of unphysical behavior with DEM if there is a very shallow bed (https://netl.doe.gov/projects/files/NumericalExperimentsinMultiphaseCFDArtificialLevitationofaVeryShallowFluidizedBedinCFD-DEM_100518.pdf). Now if you have an inlet with zero velocity and also zero initial velocity, this could be a source of non-convergence. The trigger to detect high velocity is based on the inlet velocity so it is xero, this may trigger a false alarm.
  3. I would start with the default cut cell tolerances. Your stl looks fine. I would increase the number of linear equation iterations (Numerics>Linear solver) to 200 for Gas pressure and 50 for U,V,W momentum. Set the discretization scheme to FOUP for all equations (Numerics>Scheme). Use non-zero inlet velocity or at least non zero particle and/or fluid velocity.

Hi Jeff,

Thank you for the quick response and detailed guidance. I had misunderstood the sentinel as indicating a failed computation rather than a deliberate clamp. I had raised TOL_DELH to 0.1 during troubleshooting, which based on your explanation would be flagging many more cells than necessary and was likely counterproductive. I’ll revert to the default (or 0.01–0.02 as you suggest) going forward.

I’ve attached the larger-scale case as requested. This is my closest-to-tutorial configuration — minimal modifications from “3.5 Three-Dimensional Fluidized Bed.” Specifically:

  • 100 mm diameter cylinder (primitive geometry, flip_normals only, 116 facets, no additional filters)
  • All cut-cell tolerances at MFiX defaults — no adjustments
  • 20×60×20 background mesh
  • 2.38 million particles, IC_EP_S = 0.2, inlet velocity bc_v_g = 0.017 m/s (nonzero throughout, no ramp)

The MESH_STATS.LOG for this case is attached and shows substantially healthier mesh diagnostics than my 50 mm cases:

  • DELH_U sentinel: 13.0% of cut cells (360 cells)
  • DELH_V sentinel: 1.3% (54 cells)
  • DELH_W sentinel: 5.4% (123 cells)
  • Maximum cut-cell aspect ratio: 5.5 — no sentinel-value aspect ratios
  • Zero small scalar cells

By comparison, my 50 mm cases consistently showed 17–20% DELH sentinel populations in U and W regardless of tolerance adjustments. This suggests the 100 mm geometry meshes more cleanly at this background resolution — which may itself be a useful data point for diagnosing whether the 50 mm problem is fundamentally a resolution/geometry issue rather than a tolerance issue. The attached log shows the simulation ran successfully across multiple restarts before crashing with DT < DT_MIN at t ≈ 0.301 s.

BaseCase-FluidizedBed.zip (2.5 MB)