[ali.m.1]

Hello

I'm making a combined Euler-Euler Euler-Lagrange two phase model. I've combined reactingTwoPhaseEulerFoam and DPMFoam, which can be seen in the attached .C file.

The code runs well, and performs faster than standard DPMFoam when used on a coarse mesh with <1% particle concentration. However, when I increase the particle numbers, or increase the mesh density, the solver starts off fine, but then grinds to a halt. I can run DPMFoam alongside it, with the same mesh, same particle injection method (kinematicLookupTableInjection), same concentration of particles: but my solver almost stops injecting. It never crashes, or the memory doesn't go higher than the DPMFoam solver (by checking the terminal 'top'), it just slows down a lot. I've can run the program in a debugger (nemiver), and I've also run it using valgrind. I can attach the output from 'callgrind', in case anyone can spot something suspicious.

I've tried commenting out the lookupTable code, and that doesn't speed things up. The solver also runs ok when there are no particles, it's just after a few injections that things start to slow down.

If anyone could point me in the right direction that would be great!

Ali

Edit: It turns out the callgrind file is pretty big, so I'll leave it out. If anyone would like to see it I can email it or put it on dropbox or something.

[jfp6]

I experienced the same problem when I added a particle cloud to interFoam. I was unable to track down the problem. When I had injected a certain # of particles, the time to evolve the cloud increased dramatically (see attached plot). I spent a lot of time adjusting the mesh to see if this affected it, but was not able to see any correlation.

Please post if you find a solution.

Cheers,

jfp6

[PK1]

Same Problem here using a custom sprayFoam-derivative and using the patchInjector.

Takes about 0.35 s at an injection rate of 1M / s (stationary holdup approx 120k parcels) to bring the simulation to nearly a halt. Decreasing the injection rate does not seem to help.

EDIT 2:

My bad, I had patchInteraction set to none, which resulted in trouble when parcels hit the outlet patch without being removed. I figured this out by flipping the cloud debug switch on - which yielded a lot of tracking rescues. ParaView showed the slowdown to happen just as parcels hit the walls.

[ali.m.1]

Originally Posted by PK1

Same Problem here using a custom sprayFoam-derivative and using the patchInjector.

Takes about 0.35 s at an injection rate of 1M / s (stationary holdup approx 120k parcels) to bring the simulation to nearly a halt. Decreasing the injection rate does not seem to help.

EDIT 2:

My bad, I had patchInteraction set to none, which resulted in trouble when parcels hit the outlet patch without being removed. I figured this out by flipping the cloud debug switch on - which yielded a lot of tracking rescues. ParaView showed the slowdown to happen just as parcels hit the walls.

Hi Paul

Thanks a lot for the advice. I had my patchInteraction set to 'standardWallInteraction'. This setting seemed to work with DPMFoam, but didn't work with my solver. I changed the settings to 'localInteraction', and defined types for each patch and now the solver doesn't crash! I'll need to look into what the standardWallInteraction does.

Cheers

Ali

[ali.m.1]

Hi Joseph

How did you create that plot? I'm interested in doing the same, as my solver still isn't running as it should.

Cheers

[jfp6]

Attached is the python code for the plot. There are probably better ways to do this with pyFoam, but this worked. You may have to add you current directory to your path.

Cheers,

Joseph