Two different climate-based daylight mapping dot overlays on thermal data; frequency & average mapping shown with annual total zone cooling energy use
It has been a while since I had the chance to publish another version of the tool, and the feature I ended up putting in first again now somewhat surprised me, because originally I had other plans. However, experiences in the now wrapped-up spatial thermal mapping class made me want to experiment with other data co-mapping regimes before once again delving into the thermal nitty gritty. So version 0.2, as also requested by a few students, now offers basic climate-based daylight co-mapping features.
Co-mapping is really the word here, because the new component is not really designed to run on its own and without accompanying thermal input (though you can of course hide the thermal display if you want..). This is not really a coding rationale, but the idea behind the new tool is to do things differently from stand-alone daylight mapping aps, since you’re probably using Mr.Comfy to primarily look at thermal data in the first place and might want to see a quick daylight overlay when appropriate. In the 0.2 release, most of the daylight time inputs are therefore slaved to the thermal component inputs, with overrides exposed where appropriate.
As I’ve written here probably a few dozen times before, I usually use DIVA for daylight simulations and visualization, which is perfectly fine but for a few reasons made me wish for other ways of representing its (basically Daysim) simulation outputs. Firstly, it of course isn’t geared towards the simultaneous on-screen display of other (e.g. thermal) maps and thus obfuscates the Mr.Comfy metrics when you overlay them. Now that might not seem like a big issue, but design cognition works in subtle ways, hence the Mr.C daylight app uses a dithered “dot” representation style that always lets the thermal metrics shimmer through underneath. That gives quite a pleasant effect in simultaneously observing schedule-synched daylight and thermal results; also, since you can modify the dot size as you see fit, this kind of display works nicely for lower-resolution sensor node grids- it really makes sensors apparent as what they are, point-in-space readings.
Secondly, the most prominent DIVA metrics are formalized climate-based metrics flavors such as UDI, Daylight Autonomy etc. While those are well researched and used in practice, I always wanted to have a way to interactively overlay the DIVA metrics with “raw” sensor node data such as averages, custom frequency checks or even cumulative illuminance. Since the daylight tool exposes all the functionality of the thermal component, you can now easily achieve this.
Naturally, this is the first release of the daylight component, so a few fixes will follow. I guess including some scale manipulations to better get a handle on daylight data’s huge variability, and yes, speed improvements, are on the agenda. Speaking of speed.. it really is quite slow right now. That’s because daylight datasets can become very large very quickly (e.g. 20 million values is easy to achieve) and the code is not highly optimized (you have to start somewhere..). So for the time being I recommend you interrupt the processing of the daylight overlay when scrolling through the thermal representation.
For a detailed walk-through of the daylight functionality, please refer to the Climate-based daylight co-visualization User Guide page.
Lastly and on an entirely personal note, if you like this release or Mr.C in general, drop me a line. I’ve recently left my faculty position at the TU Berlin and am looking for new opportunities, so if you need a performance-minded person on your team, please do get in touch. Thanks & happy co-mapping!