I was trying to figure out what was wrong with my Link case (I just figured it out, it has nothing to do with this…) and my first thought was that it looked like I lost a bunch of particles due to the initial transient so then the spout was just too strong. I do have bc.po_no_par_out = 1 set. I put a Lagrangian::GeneralProperty::Sum monitor on ones over the “full-domain” region to sum the particles, the result vs time is below. I’m losing some, but not in bunches like as if no_par_out wasn’t working correctly. Do you think my particles are just too soft and some are getting squished through the wall and deleted?
You can test if the bc.po_no_par_out flag is working by setting up the simple pseudo-1D problem:
- domain is periodic in x and z directions
- pressure inflow at y-high and pressure outflow at y-low
- gravity acting in the negative y direction
- initialize the domain with a few particles and let them settle under gravity
If the particles all ‘fall out’ then the flag is not working as expected and we’ll need to investigate.
You can test the setup in general by switching the pressure outflow at y-low with a mass inflow with zero-fluid velocity. This will ‘fake’ a wall along the bottom of the domain extent the same way the flag should impose a wall.
I ran a simple test like you suggest: bench05 size008 with gravity sign flipped, so all the particles rush to the top.
I added the same monitor and bc.po_no_par_out = 1. The initial particle count and final particle count match, Np = 7776. so the flag is working as expected.
Back in the Link bed (case B1), I bumped the spring constant up from 43 kN/m to 170 kN/m (halved the collision duration). I expected to see it lose fewer particles, but it’s actually losing more particles (red line, still running). Curious.
@jmusser I am freeing up some scratch space and ran into the last sim of this case we discussed what feels like forever ago. I “removed” the left/right walls and made it periodic, here’s the inputs diff w/ the original setup:
wfullmer@login02:/nfs/scr/2/wfullmer/link/2d_B1> diff inputs ../B1/inputs
118c118
< geometry.is_periodic = 0 0 1 # Is periodic in each direction?
---
> geometry.is_periodic = 0 0 0 # Is periodic in each direction?
255,256c255,256
< box.Lo = 0.019 -1.0 -1.
< box.Hi = 0.173 3.0 1.
---
> box.Lo = 0.019 -1.0 0.
> box.Hi = 0.173 3.0 0.084
This 2-D case (in red) does not lose particles. So they are slipping out through the corners. Still not sure why increasing the spring stiffness would increase the loss rate.
I’ve determined that particles are leaving through the pressure outflow and not the corners/edges of the domain. I’m guessing it’s a bit of a compound effect with one particle being thrown against the outflow by the jet, then another particle collides with it, pushing it outside the domain.
Merge request 1515 is a proposed fix.
Background:
In MFIX-Exa, walls are represented by an embedded boundary (EB) that is converted into a levelset function to compute particle-wall interactions. The levelset geometry differs from the EB because additional walls are added to “cover up” mass and pressure inflows, preventing particles from leaving. This can also be extended to pressure outflows by setting bc.po_no_par_out = 1 in the inputs file.
The Bug:
The logic used to set the no-outflow flag was incorrect. Additionally, there was a specific bug related to “box” EB geometries where the flags to cover “flow” boundaries were not applied. This issue is particularly interesting because it was hidden by additional code designed to prevent particles from crossing domain extents. However, this code likely only prevents slower-moving particles from escaping.
@jmusser I slipped the particle count monitor into my inputs and re-ran my validation tests but still seem to be losing particles. Did this MR not make its way into develop yet?
Nope. The proposed fix is sitting in MR1522.
1 Like
sorry, I didn’t realize you were waiting for me to run it. yes! this fixes my issue seen in the Link bed. no particles lost on all three cases. thank you.