Climate-based daylight (co-)visualization

SummerWinterDaylight_ZoneTransSolSeasonal zone transmitted solar and its influence on climate-based daylight simulation results; Daysim and EnergyPlus data are correlated in this cross-mapping.

As of ver. 0.2, Mr.Comfy can parse Daysim *.ill (illuminance) and *.pts (sensor points) files to spatially display climate-based daylight results alongside thermal simulation maps. See the initial release blog post for an extended discussion. The daylight component has the exact same functionalities of the thermal mapping component, minus options that would not make sense (e.g. normalization). It depends on time and mode inputs fed from the thermal component; however, sum/average/frequency/peak modes and scheduling can be overridden.

Possibly to be added in future, the daylight component currently does not output any defined metrics à la UDI, SDA, Daylight Availability etc. It instead allows to generate custom frequency checks or average computations, offering a different look at the data underlying current climate-based daylight metrics, or can even serve as a numeric overlay to enhance the reading of DIVA daylight maps.

Several steps need to be taken before daylight data can be displayed through Mr.Comfy.

First of all, reference Daysim’s *.pts and *.ill (sensor nodes / hourly results illuminance profile) files that feed into the DSparse component (1). Once files are set, parsing starts (note that because daylight data has many hourly sensor values, parsing can take a minute or more); set the daylight_mode (2) switch to any “on” mode to see daylight nodes displayed in the scene. If you do not have thermal data referenced, select “daylight only”.  When there are many sensors in a scene (e.g. 3000 nodes will yield 26,280,000 individual values for the tool to contend with), I recommend you pause processing through the daylight_mode switch to allow quick scrolling through thermal results, as otherwise you lose responsivity.

In its default shipping state and if daylight_mode uses “filtered nodes”, the script is set up to through the custom Zone_Heights and Select_Sensors components find all sensor nodes that are included in the selected thermal zone volumes. This depends on a thermal setup having been performed beforehand. An array of native GH components handles the extrusion and inclusion checking (3). Searching for sensor/zone inclusion matching is spatially positional and uses coordinates given in the *.pts file, hence thermal zone and daylight geometry need to be synchronized; put another way, you can move the thermally referenced geometry/surfaces, but cannot influence the daylight sensor node location.

If you want to instead have all sensors displayed regardless of zone selection, set daylight_mode to either “daylight on thermal (all nodes)” or “daylight only (all nodes)”.


The DSchedule and Mr.Daylight components (4) handle the actual data processing and display. Since scheduling is processing-intensive, it is only performed when the schedule actually changes; this can take up to several seconds for large data sets. In the default state, the Mr.Comfy component’s schedule_hour_start and _end inputs are slaved to the ones used for the thermal control; input your own sliders to override (since you probably don’t want illuminance averages displayed that include the night..).

Additionally set to be input independently from the thermal controls are the Mr.Daylight component’s average_sum_or_freq_mode, frequency_condition_low/highbound, min_or_max_peaks_mode, suppress_null_zones and gradient_interpolation controls (5). They function identically as documented in the thermal component docs (apart from interpolation, see below), though controls that do not apply for daylight (such as normalization) are locked and hidden.

One mode not present in thermal visualizations but possible in the daylight component is gradient_interpolation (6), which applies a natural logarithm to output sensor values and compresses them into a smaller numeric range- which allows a spatial daylight distribution to be viewed with a fine gradient even if value spread is extremely large. Use this with caution and preferably with numeric overlays, as in this mode color distance will not absolutely correspond to numerical distance.

Note that all other controls (e.g. reporting_frequency, visualization_bounds_mode) are fed to the daylight component via the thermal component (and labelled as such) to reduce on-screen clutter and simplify temporal co-display.


Visualization of results is handled through a native GH gradient and display dot component (not shown), through which you can set display colors and dot sizes. Grasshopper can occasionally choke on display pipeline updates, so be gentle on the sliders if you are viewing thousands of nodes, and let them update frequently.