Hi everyone,
I am getting familiar with MFIX-Exa and am currently conducting a comparative study on gas–solid fluidization. I have observed a significant disparity in the results when switching between the Gidaspow and BVK2 drag models. Despite using identical meshes and particle properties, the BVK2 model consistently predicts no fluidization, whereas fluidization is observed with the Gidaspow model.
I would appreciate any insight into the underlying physics or potential implementation considerations of these drag models that might explain this behavior.
Gidaspow: inputs.txt (7.9 KB)
BVK2: inputs.txt (7.9 KB)
P.S.: Could someone explain how meshing works in MFiX-Exa—specifically how the fluid and particle meshes interact and how load balancing is handled (n_cell, max_grid_size, mfiter_tile_size, tile_size, levelset__refinement, regrid_int, …)—in very simple terms?
@oyedejifemi I’m looking at your case now. I see a few concerning values right off the bat. You have a particle diameter of 2.5mm and the box depth is just 15 mm. I typically like to target a fluid mesh resolution of 2dp = 5 mm. This is exactly what you are using, but this gives just 3 cells in the depth of your bed. Only one full cell and two cut cells is not a good way to set up a CFD-DEM FB. Personally, I would probably shrink that
Also, I see you’ve set the domain to be 35 mm in depth (I’m not sure why you use so much dead space) and discretized it with a fluid mesh of 7. As @jmusser mentioned in the meeting last Tuesday, using a prime number for your fluid mesh is bad for the amrex solvers. you want this to be a power of 2 ideally.
Is this bed depth concrete? I mean, does it correspond to an actual experiment you are trying to match or is this just an example you’ve concocted to explore and learn MFIX-Exa? If it’s the latter I would suggest massaging this setup a little bit.
Thanks for your detailed response @wfullmer I will change the number of cells to avoid odd numbers, in general, and if possible use 2**n.
On the domain depth, unfortunately this setup is associated to an experimental setup. Nevertheless, I will make up something to extend the depth and test the two drag for sanity check. If that passes. I will try the original setup with free-slip (if available).
@oyedejifemi I think this is probably a better starting point for this problem:
inputs.txt (9.1 KB)
Notes:
- it has at least 4 cells in the depth. That’s probably an absolute minimum. You really shouldn’t be using “standard” CFD-DEM for a bed this thin. We’ve considered it previously, but I dropped it b/c it’s just too thin.
- IC generates 28,127 particles, the expected number for this case is 24750. I would play around w/ your IC a little more to get this closer
- When I first ran it, I noticed particles were getting slammed into the
po with Gidaspow drag. like what happened in this case. You can ease the initial transient by making the inflow velocity ramp up from zero in time:
bc.inflow.fluid.velocity = 0.0 0.0 1.0 0.0
bc.inflow.fluid.velocity = 2.0 0.0 1.875 0.0
- I have a couple cases running rn, I’ll confirm tomorrow and report back but it looks like the
BVK2 case is just barely fluidized. This isn’t surprising… you could probably say this is expected. I’ve always found Umf (Gidaspow) < Umf (DNS drag laws) and since you’re setting a single inlet velocity (that is supposed to be approx. 1.5x Umf found in the exp), it’s entirely possible that this is actually (just using random numbers for example) 1.6x Umf for the Gidaspow simulation and 1.2x Umf for the BVK2 simulation.
I forgot to post the results for the inputs I gave. I guess I forgot to ramp up the WenYu case b/c they are still slamming into the po. Oh well… you can see the BVK2 case is bubbling but just barely. Looks a little better at 2umf.
1 Like
