Strange solid particle behavior at centerline of CYLINDRICAL flow

[rmcdermo]

This is a case I'm working that is looking at using sodium bicarbonate for fire suppression. So, this is a bit new in terms of using solid particles for suppression where we would normally use the droplet model. Nevertheless, there seems to be some behavior at the centerline that does not look right. At about 1.69 s in the simulation, you see the particles on the centerline look like they start falling due to gravity and create a backflow that leads to unstable behavior. The simulations keeps going, but something is not right.

There also seems to be problems whenever the particles get close to the centerline downstream of the burner. In this particular case, it is hard to tell if the explosions are the result of problems upstream. But other variants of this case where the upstream looks ok produce spurious issues downstream, again, whenever the particle gets close to the centerline.

I tried taking CYLINDRICAL out of play, but the OPEN bc does not act correctly for 2D calculations (this is another issue that has never really been solved).

Anyway, at this point, I'm fishing for some suggestions. I think this is a flow we should be able to count on working without too much fuss.

test.fds.txt

[mcgratta]

I'm going to write this up and we can look it over before committing. We can also try your case again to see if things improve. There is still the issue of having too many particles dragging too much gas, but that was an issue with the current formulation. We've yet to consider the effect of drag reduction for clouds of particles.

[mcgratta]

Pages from FDS_Technical_Reference_Guide.pdf

[rmcdermo]

Looks good. I'd like to try it out. I'm working on cup burner validation with mist and power. Thanks

[mcgratta]

Do you a sample case I could try before committing everything?

[rmcdermo]

Try the test case at the very top of this thread.

[mcgratta]

That case is going to fail no matter what trajectory scheme we use. Here's why. For a collection of particles, the "absorption coefficient" kappa is

kappa = C_s * sigma * beta

C_s is the shape factor (projected area divided by surface area) which for a sphere is 1/4

sigma is the surface area to volume ratio, which for a sphere is 3/r

beta is the packing ratio, which in your case is mdot''/w/rho_p = 0.02 kg/m2/s  /  0.1 m/s  /  1.2 kg/m3 = 1/6  1/m

kappa = 0.25 * 3/2e-6  * 1/6  =  62500  1/m

These particles are so tiny that they form a very optically dense cloud. Jason does a similar analysis above calculating the effective projected area of all these tiny particles. I have found that kappa needs to be on the order of 1 to get sensible results, at least with the current scheme where we just sum up the drag of all the particles and impose it on the gas.

[mcgratta]

I think this is why those who do CFD with very fine dense clouds of particles often treat it as a special kind of gas species.

[rmcdermo]

I don't really understand this. I would think that as particles become very small, they should basically become tracers. If they are evenly distributed in the flow, then they should be ok. I think that, like tracers, there should be a random walk to make the particle number density uniform. Anyway, when you push this up, I'll test.

[mcgratta]

Think of the particles as a stationary block that is blocking this vertical tunnel. Even though the particles only occupy 1/6 of the volume, they are so dense that light would not be able to penetrate more than a fraction of a millimeter (1/62500 m). But, yes, in reality we should be able to push air through this block, but we'd need a lot of pressure to do it. And in reality, the drag exerted by each particle would be reduced because they are packed close together. What we are doing is summing all the drag and just adding it to the grid cells, forming a massive source term that reverses the flow direction and then starts things oscillating wildly.

[mcgratta]

If I increase the density of the particles to 1000, and decrease the mass flux to 0.0002, then kappa is 0.75 and the particles behave as you would expect. As you increase the mass flux from there, you will eventually see spurious behavior.

[mcgratta]

I'm still digging into this. Given all I've said, I still think your test case fails too quickly. I'm printing out particle and cell values, and things go bad very fast.

[rmcdermo]

I have a solution for this case that I'm testing now---I'm creating an option for a MASSIVE_TRACER. That is, there is a one-way drag from fluid to particle, but the particle does not exert a drag force on the fluid. In these cub burner cases, the flame is pretty much laminar and all we want is for the particles to follow the flow and evaporate or decompose.

That said, once I implemented this, the case still went unstable. So, that is evidence that it is not all drag. I think the boundaries are too close to the flame, and the pressure solver can be tightened up. With these changes, things seem to be working.

[rmcdermo]

Discovered something interesting. Run this case with the code I just pushed up. With AIT set and no exclusion zone, the particles somehow decompose and create low temperatures. If AIT is not set, the case starts and runs fine. I have not yet dug into this, but might be a clue to other odd behavior. The ACCEL_X, etc., terms are all zero.

test2.fds.txt

[mcgratta]

Set HEAT_TRANSFER_COEFFICIENT=50 on the SURF line for 'KSA'. The HTC is inversely proportional to radius, and it's so large that the convective heating becomes unstable. That is, even with ambient temperature, the particles start to heat up and down spuriously. We should find a reasonable upper bound for HTC.

[drjfloyd]

That is an interesting observation. Whatever we decide on for limiting the HTC, we probably need to consider if it should also apply to droplets and possibly even blowing for very fine droplets. Given a particle temperature and an air temperature could this be treated as a semi-infinite solid in spherical coordinates (where the gas is the solid) with a constant temperature (particle temp) boundary condition?

[mcgratta]

Not sure what you mean.

[drjfloyd]

For these small particles, the particle and the gas are basically at the same velocity, so geometry is multilayer sphere where the outer layer is the air and the inner layer is the particle. Consider the particle to be fixed at its temperature. We now have a spherical coordinates conduction problem with a fixed temperature boundary condition on the inside surface of the larger sphere. The particle densities are such that there are many particle diameters between particles so we can probably treat the outer gas layer as being effectively infinite. This will have a steady state solution that would give a limit on heat transfer form the particle.

[mcgratta]

I think I've tripped over this mine several times before. If you limit HTC, the case at the very top of this thread appears to run OK. Other test cases are working too. Just from a numerical stability standpoint, it appears that for a sphere of radius r and density rho and specific heat c, HTC has to be kept below:

h < r * rho * c / (3 * dt)

or else convection can heat the sphere to a temperature higher the gas temperature in the time dt.

[drjfloyd]

That is a simpler solution than my idea.

[rmcdermo]

Yes, Kevin, I like it.

[rmcdermo]

Yes, CHECK_HT=T solves the problem too, but is probably more expensive. Limiting H is like limiting the viscosity for a given DT to avoid a VN instability.

[mcgratta]

Yes, I found that limiting the time step to really low values worked too, but impractical.

[rmcdermo]

Actually, CHECK_HT is not so bad. The reason this only showed up when I implemented AIT is that the combustion divergence is limiting the time step anyway.

[mcgratta]

I'm going to create LP%HTC_LIMIT=RADIUS*ONE_D%RHO_C_S(1)/(3*DT) which is calculated where particle mass and area are calculated. I'll test it tonight.

[mcgratta]

I implemented the upper bound on HTC. Try your various cases and make sure they work now.

[rmcdermo]

Kevin, Your modifications seem to be working well. I ran several cases over the weekend and no problems. This particular case still might have issues in that we are getting different MEC mass loadings for CYLINDRICAL and 3D calcs. But that is likely a different issue. I will close this one and open another if I pin point what is going on. Thanks for the help.