[mome]

Hi everybody,

Up until now I have found a solution to every single problem I had, thanks to all the experts on the forum, my post count is evidence. By now, I have quite some experience with the DPM in fluent, and yet, I cannot figure out what is happening in my present case. There are a few threads in the forum that seemed vaguely similar, but none of them was addressed really apart from obvious hints. I decided to give it a new go.

Case:

I am modelling a 3D nozzle flow of particle laden gas using the DPM model, employing it within its limitations (volume fraction low, etc). I have no issues whatsoever with the gas phase, but for completeness: 3ddp, density based, compressible, steady, realizable k-epsilon, parallel.
The DPM-problem I am encountering occurs both for steady and unsteady tracking. In either case, injections are set up in such a way that parcels are evenly distributed at respective feed rates (mostly surface injections). Particles are solid, parcel size is adequate (although I even checked through all parcel methods). No collision models are employed. All BC on escape, except walls which reflect.

Problem:

When computing the trajectories without interaction with the continuous phase, they are fine: all particles cross and exit the domain as intended. In contrast, when computing in a coupled manner, an increasingly large proportion of the particles are reported incomplete (NOT incomplete_parallel) in each DPM-iteration, accumulating until the DPM-iteration is stuck, ending when it hits the walltime or when I kill it. Note that the "maximum number of steps" does not resolve this problem: the first trajectory integrations begin to fail after only few crossed elements downsteam of the injection plane (10-20 in extreme cases), several orders of magnitude less than expected from the max no. of steps and the step length factor. Reducing the max. no. of steps reduces the computational effort on each failing trajectory and therefore postpones the catastrophic failure, but changes nothing on the actual particle advancement. Not all trajectories fail, but a high percentage.
Sidenote: parallel concurrency is reported to be about 4% only.

Attempts:

- Checking the gas phase for the reason: No singularities, zero velocity or recirculation zones occur in the gas phase, which remains nice and smooth.
- First, I thought it is mesh-related, but after checking, the problem occurred in the same manner with different meshes and different element-types (hex and tets), also no partitioning problem.
- Changing the injection, particle time step or parcel method did not help. Switching the tracking scheme has not helped either.
- Because the uncoupled trajectories work out fine, I thought it may be a memory-issue and tried on different machines (local on 8 cores, cluster on 24 cores). I performed a check on the parallel settings of the DPM model: all three memory methods fail (hybrid, message passing, shared memory), while the available memory is not even fully used.


I am really running out of ideas. Has anyone encountered this sort of problem before? Has there been a solution reported? Are there any crucial aspects I am overlooking? I would be most grateful for any advice.

Cheers, Mo

[mome]

Okay, I've kind of given up on it. After setting everything up from scratch, I could not reproduce the problem. I am not sure but, for anybody who searches input for a similar problem, this is what I think it was.

Because all my failed trajectories would end in a similar region of my domain, I thought it may be connected to a local property. I used the DRW model, and because it statistically tries to find the next particle location based on the trubulent quantities, it may fail internally under specific circumstances, go on forever without advancing the trajectory until it hits the max. no of steps. I never had the problem with the cloud tracking model, which smoothes out the solution. I think it was some weird interaction of the DRW and my local flow properties. However, I am again using it and now it is working fine!

If anyone knows more about failures like this, let me know.

Mo