Not all spaces in a model have windows, and not all zones might be mechanically conditioned or receive natural light. To include such zones (or sensors for daylight display) in the mapping of variables that are not applicable to them, in the example solar gains, heating energy rates and illuminance, would mean that their “0″ value for these variables artificially skews color display of other zones/sensors that do have the respective data. Note when I say “zones” in the following, it always also implies climate-based daylight sensor display.
To prevent color scale skew from happening without de-selecting the culprits, zones/sensors whose annual sum for a non-applicable report variable is zero can be suppressed by setting the suppress_null_zones (1) switch. Therefore, the color range mapping of the non-null zones is equalized / re-spaced within the (fit) bounds that actually occur.
Be aware that suppressed zones/sensors are not removed from the data stream (which would mess up the data/surface or sensor order), but only disregarded by the internal bounds generators; “null” status is computed by summing all hourly values for each zone, without any scheduling, and checking for Zero. Zones that have even very small values for a report variable are thus not disregarded, and neither are zones whose report range output in a given schedule might be temporarily zero (such as solar gains at night). A limitation of the current implementation is that the lowest occurring values thus get the same color applied to them as the null zones.