DPM: Implicit momentum/source terms coupling

[valentin.melot]

Hey all. 

I've noticed two parameters available at "/define/models/dpm/interaction", namely "implicit-momentum-coupling" and "implicit-source-terms-coupling". I haven't found what they actually do in the documentation, but when disabled, I notice a remarkable impact in the momentum coupling between the discrete and carrier phases (I only have momentum coupling in my case). What are the expected impacts of disabling those parameters? Is this recommended? 

For context, I'm trying to replicate using RANS a DNS simulation where water vapor bubbles are scattered in a Rayleigh-Bénard (RB) type convection environment (hot bottom plate, cold top plate, liquid water carrier phase) at a very low Rayleigh number (1e5 --> laminar flow). I can't get my results to match the reference case, as it seems like the bubbles do not disturb enough the usual RB convection flow structures, which means that even with a large number of bubbles (with drag, gravity, and virtual-mass forces), the flow stays largely undisturbed, which is NOT the expected outcome. The setup is very simple as I don't use any UDFs, yet I still get the wrong results. All of this eventually led me to explore all the "hidden" DPM parameters accessible from the console, and thus the coupling parameters mentioned above. 

Thanks a lot. 

[Rob]

If they're hidden there's usually a good reason for that. If you type ? in the TUI at the menu level of interest you should get more information, assuming there's any information to share. 

How much of an effect would bubble blockage have on the real case? How reliable are the DNS results? I generally don't trust any literature results without checked as I've seen too many papers with omissions and errors that prevent a study being repeated. 

[valentin.melot]

You're damn right about that last part. Regarding the discussed parameters, the "?" command doesn't provide much explanations. But as you said, I'll just keep those parameters with their default values. 

Regarding the blockade, it isn't explicitly tested in the DNS paper. However, one of the author mentioned during a discussion that the blockade (or volumetric coupling in general) doesn't change anything due to the low bubble void fraction. When I add "Volume Displacement" in my case, the flow structure also remains unchanged by the bubbles, but the volume-averaged flow velocity gets increased (which is what happens anyway without volume displacement). It just seems like the bubbles don't move into the regions where they're supposed to go (i.e., the corners of the geometry, which is a tall cube). I've already made sure that the forces acting on a single bubble in my case do indeed match the ones specified in the paper (they do a test on a single bubble to validate their in-house model). The paper does make use of a custom drag coefficient, which I implement using an UDF (the only one I use). I made sure to return 3/4*C_D*Re, and also that the C_D I compute is not already 3/4*C_D*Re. 

I really do hope the authors haven't ommited some crucial information... Thanks for the help. 

[Rob]

How large are your bubbles relative to the cells? And relative to the wall boundary layer? Remember DPM is a point mass so bubble must be smaller than the cells for the assumptions to hold. 

[valentin.melot]

I'm using the exact same mesh as the DNS case. So I'm sure that it is appropriate for the bubble size I use and the boundary layers heights. The thing is that I ran the simulation without the bubbles, and I got the correct results. Add the bubbles: I don't get the correct results. I'm not sure why, and I've been trying to figure it out for ages. One thing I was thinking was that maybe the way Fluent handles two-way coupling is not the same as the paper whose results I'm trying to reproduce. I'm sending you a screenshot of the paper's in-house algorithm. Are you able to say if this is the same algorithm used by Fluent? I didn't find such an explicit illustration of Fluent's algorithm in the documentation, so I have trouble comparing the two... 

Thanks a lot. 

[Rob]

That looks about the same as the slides in the training materials, check the Solver chapter in Theory Guide too. Check you've not switched on the node smoothing or source term linearisation (DPM Numerics). 

Re the mesh. Without knowing how the DNS solver is coded (and I'm not reading the paper!) I can't comment, is that code cell or node based? That would mean the same mesh is treated differently. 

[valentin.melot]

I won't ask you again to read the paper, don't worry. Sorry about that, by the way... Anyway, I've noticed that when the bubbles reach the top in the paper, they are reinjected not with zero velocity, but at the local fluid's velocity (at the reinjection point). I tried implementing that inside the DEFINE_DPM_BC function I already use to handle the reinjection. Both approaches (see pic below) I used lead to SIGSEVs. The other examples for that function in the doc aren't helping. I know you can't comment on UDFs directly, but any ideas on how I could implement that? My reinjection injection inside Fluent uses randomized starting points and injects using the face normal's direction. I could set some constant value for the velocity magnitude (inside Fluent), but I feel like there should be a better option. (In the pic below, TP_UDMI(tp, x) is the xth component of the fluid velocity at the bubble's position)

[Rob]

 

Check whether reinject is actually a DPM boundary option. For injections it’s DEFINE_DPM_INIT and you’d then work with the PP_ macros to define position, mass etc. The TP_ macros are for after the particle is in the domain and it’s then a Tracked Particle. 

Nothing to be sorry about, we have rules and that's one of the very few I can't bend.