MASS_PER_VOLUME in INIT PART dramatically affect time step size

[schumakov]

Describe the bug
I have a PINE_CRIB particle that describes a space-filling mass of cylinders with given surface/volume ratio. There is a wind profile prescribed.

When I initialize particles with MASS_PER_VOLUME=1, simulation finishes in ~100 timesteps. When I initialize them with MASS_PER_VOLUME=100, it takes more than 1000 time steps. Is there any reason for that that I do not see? Looks like the CFL numbers are staying pretty low (~0.01).

To Reproduce
Steps to reproduce the behavior:

• Take the attached config.txt file, run it (single-core version of FDS)
• Change the MASS_PER_VOLUME in the last line from 1 to 100, and run it again

Expected behavior
I expect the runtimes to be similar

Desktop (please complete the following information):

• Mac OS
• CentOS

Thank you!

config.txt

[ericvmueller]

Assuming you are using a recent version of the code this sounds like it is related to #14186 / #14197. So now for particles like you have defined there is the CFL condition of:
$dt < U \cdot \left(\frac{du}{dt}\right)^{-1} $
where du/dt is due to the particle drag force. So your more dense particle mass will cause higher force and lower the step size.

@rmcdermo we had been discussing adding particle CFL to the CHID.out file and/or CFL_FILE. This seems like a good reason. I would also still be in favor of separating this drag-based condition from the particle speed CFL condition. Especially considering the condition I am implementing for surface vegetation, which uses the same drag criteria but is confusing to call a 'particle CFL' if there are no particles.

[schumakov]

@ericvmueller thank you for a quick answer. I do use the latest version of FDS.

Does this mean that creating dense burning obstructions that consist entirely of particles (e.g., modeling a wooden shed as a bunch of "pine crib" particles) is a bad idea and it makes more sense to use OBST?

[mcgratta]

OBST for sure. FDS uses an explicit temporal updating scheme for the momentum equation. Particle drag is a source term in this equation. If the term is large, you create numerical instabilities via violent fluctuations in the velocity vector. An OBST creates a flow obstruction via the solution of the Poisson equation for pressure, an elliptic PDE. Hard to explain in a simple way, but OBSTs are part of a simple "immersed boundary method" that do not cause the kinds of fluctuations you see with particles. The only way to avoid numerical fluctuations in an explicit code is to limit the time step. For particles that represent a large fraction of the free area, this time step can be quite small. With disperse particles like water droplets, it is not a problem, usually.

[schumakov]

OBST for sure. FDS uses an explicit temporal updating scheme for the momentum equation. Particle drag is a source term in this equation. If the term is large, you create numerical instabilities via violent fluctuations in the velocity vector. An OBST creates a flow obstruction via the solution of the Poisson equation for pressure, an elliptic PDE. Hard to explain in a simple way, but OBSTs are part of a simple "immersed boundary method" that do not cause the kinds of fluctuations you see with particles. The only way to avoid numerical fluctuations in an explicit code is to limit the time step. For particles that represent a large fraction of the free area, this time step can be quite small. With disperse particles like water droplets, it is not a problem, usually.

Understood, thank you. In other words, LPs trigger a presence of porous media that is modeled via a forcing term in momentum equation, while OBST change the domain geometry without affecting CFL conditions (immersed boundary method).

[obscureed]

Just as a comment, I tried your example both ways, and the run and rerun used 67 and 66 timesteps. (Actually, your context.txt had MASS_PER_VOLUME set to 100, so the rerun it set back to 1.) This was in FDS6.9.1 on WSL2 Linux. I was intrigued to see whether PARTICLE_CFL_MAX could help (although PARTICLE_CFL is F by default according to the User Guide, so maybe it's not expected to have any effect). I'll leave it alone for now.

[ericvmueller]

You'll have to use 6.10.0 to see this difference due to a recent change (I get 95 steps for the low MASS_PER_VOLUME and 1413 for the high value). It looks like the PARTICLE_CFL input is not getting checked for this drag-based criteria, so it will be used either way. Something else we should clean up/clarify for these different types of limits.