in:Flux and Stability Classes

in:Flux models a neutral boundary layer (class D). This is the only stability class that can be legitimately modeled by CFD without using more advanced turbulence models.

In general, atmospheric stability does not make a difference to CFD dispersion in the near field (such as less than 1/2 mile) because the turbulence is primarily generated as wind flows over buildings and other obstructions, rather than natural convection plumes. It would therefore be pointless to model different stability classes if you are interested in dispersion with CFD (both toxic and combustible) on a site, because you will end up with the same answer. 

Where atmospheric stability is important is for long-range dispersion (> 1/2 mile). This is why it is normally only a consideration for toxic gases, as the concentrations of interest are a lot lower (<100ppm) and so they can reach those distances. If your project is interested in toxic gas dispersion off-site, then CFD is not the right tool for the job – these project should use gaussian dispersion models. However, it should not preclude you from using CFD for short-range dispersion.

The approach of using CFD for short-range and gaussian dispersion software for long-range is quite standard, and this overall approach will mean that you can say that your approach accounts for atmospheric stability, because you are doing so in the circumstances where it is important. 

Note that this argument is for all CFD software, not just in:Flux. While there are some CFD software that have the option of selecting other stability classes, in reality these settings bear little relationship to the physics of a stable or unstable boundary layer and does not properly model the physics. Simply, non-neutral boundary layers cannot be modeled accurately with the type of turbulence model used by most CFD software. Furthermore, there is no validation for any CFD dispersion modeling for anything other than a neutral boundary layer (Class D). 

In summary, we haven’t included stability classes in in:Flux because they cannot be modeled accurately and we do not want to provide a feature which has no validation.