Things are heating up in the Systems Research team (and not just because it’s summertime).
I’ve been digging into the Dasher 360 codebase, this week, to add better support for “equipment” sensors – which have multiple sensors and data feeds coming off them for a single unit – particularly with respect to tooltips. As an example, here’s a ubertooltip summarising recent data coming off a Mazak 5-axis mill in our Advanced Manufacturing Facility in Birmingham.
There are devices in the AMF that have more sensors – up to 60, in fact – but those feeds were less visually interesting (the lines were flat), so I opted for a machine with “only” 26 data feeds. It’s still a bit overwhelming, so we’ll have to see whether this style of information display proves interesting or useful to the people using the tool in Birmingham.
The main reason for digging into equipment support is to prepare the NEST model for use inside Dasher 360, which is also coming along nicely, thanks to work by BIM Facility AG. Typically equipment in the NEST building only has 3 or so sensors, so the tooltips are much more manageable. I will say the AMF data is a much better stress-test, though. :-)
It’s been a while since I’ve had time to work on Dasher, and it feels really good to be diving back into it. We’re working steadily towards our goal of having it in good enough shape to be able to share big chunks (if not all) of its source-code, hopefully by AU Vegas. I know this project has been inspiring a number of developers to do similar things – even without having access to its source – but I’m hopeful that publishing source will help even more people to head down the path of building “digital twins” using Forge.
Back in GD-land, my colleague Simon Breslav has been working hard on preparing for the Generative Design Residency that’s kicking off next week in Toronto. One of the major requirements for a number of participants has been around using environmental analyses – especially daylight – within generative workflows using Refinery. While we did something tolerable for Project Rediscover, Simon wanted to explore other options. So far he’s managed to build a version of the MaRS graph that uses the Solar Analysis for Dynamo package – which is apparently powered by the former Ecotect/Green Building Studio – as well as a version that uses Honeybee.
Honeybee was more challenging to get working – and has the advantage of delivering callibrated results, rather than “directional” once such as those generated with the Solar Analysis and our own home-rolled approach – as the package made some assumptions on the location of Dynamo etc. Simon is working with the authors to get a version posted in the coming days that should allow it to be used with Refinery, which is very cool.
I’ll publish both versions of the MaRS graph here, in due course, but in the meantime here’s a sneak peek at the results using the Solar Analysis package (which incidentally also has better performance than our own rudimentary approach);
And of course I had to try a quick animation using Capturefinery:
Speaking of Capturefinery, I’ll be talking more next week about an update I’ve made that allows it to pick up intermediate results, rather than just using the “hall of fame” of a particular study. This hopefully means the tool could be used to really show the evolution of the search algorithm (or the optimization algorithm, if you like) exploring the solution space. Should be interesting!
