Analysis Tools (LAT). Our plugin has come a long way in the last 4 years and, while the legacy version will still include some small updates and contributions, we are confident in saying that the changes will be far fewer and the plugin more stable in the following months as we switch gears into the LAT effort. I can say personally that (save for a couple of small capabilities) I have made it through my list of critical features and I will hereafter be working on making these features cross-platform, cleanly-implemented, and well-documented in the new Ladybug Analysis Tools software package. As always, you can download the new release from Food4Rhino. Make sure to remove the older version of Ladybug and Honeybee and update your scripts.
The majority of changes with this release represent “icing on the cake” after a long, multi-year effort to connect to the major open source engines and datasets. So, without further adieu, here is the list of the new capabilities added with this release:
LADYBUG
Stereographic Sky Projections - Thanks to several code contributions from Byron Mardas, all Ladybug sky visualizations now support stereographic projections! Such projections are useful for understanding the hemispherical visualizations in a 2D format and they also make it easier to overlay different sky datasets on top of one another. Check here for an example file showing the sun path overlaid with helpful/harmful parts of the sky and see here for an example file using shading masks representing strategies (like an overhang) on top of the helpful / harmful portions of the sun path.
Wind Rose Upgrades - Devang Chauhan has added several new features to the Ladybug wind rose including both visual and numerical outputs of average wind velocity and frequency for each petal of the rose. Not only does this enhance the usefulness of the rose but it also paves the way for the use of the wind rose to set up CFD simulations once Butterfly is released in the near future. The new features of the wind rose can be seen in this hydra example file.
Complete Set of Local Thermal Discomfort Models - After the last release included components to evaluate radiant asymmetry discomfort (which can be modeled using these example files: 1, 2), today’s release completes Ladybug’s suite of local discomfort models from ASHRAE and the ISO by adding components to account for discomfort from cold draft. Specifically, two draft models have been added for different types of situations. The first is an older model published by P.O. Fanger, which was developed through experiments where subjects had cold air blown on the back of their neck (the most sensitive part of the body to draft). While this is useful for understanding a worst-case scenario, it can greatly overestimate the discomfort for cases of draft at ankle level - a more common occurrence that typically results from the tendency of cold air to sink. For this situation, a second draft discomfort model has been included, which is specifically meant to forecast ankle draft discomfort. The model is currently undergoing review for integration into ASHRAE-55 and a publication outlining the derivation of this model can be found here:
Liu, S., Schiavon, S., Kabanshi, A. and Nazaroff, W. (2016), Predicted Percentage Dissatisfied with Ankle Draft. Indoor Air. Accepted Author Manuscript. doi:10.1111/ina.12364 (http://escholarship.org/uc/item/9076254n).
Special thanks is due to Shichao Liu, Toby Cheung and Stefano Schiavon for sharing the model and the results of their study with the development team. The integration of draft models completes the full integration of ASHRAE-55 and EN-15251 with Ladybug. Now, you can rest assured that, if there is a certain thermal comfort standard that you need to fulfill for a given project, you can model it with the ‘bug!
Window-Based Draft Model - With the integration of draft models, the first question that one might ask is “how should these models be applied to typical design cases?” While the (soon-to-be-released) Butterfly plugin for OpenFOAM should open up a Pandora’s box of possible situations, this release of Ladybug includes a simplified downdraft model from cold vertical surfaces, which helps model several typical cases of draft discomfort. The model has been validated across several papers:
Heiselberg, P. (1994). Draught Risk From Cold Vertical Surfaces. Building and Environment, Vol 29, No. 3, 297-301
Manz, H. and Frank, T. (2003). Analysis of Thermal Comfort near Cold Vertical Surfaces by Means of Computational Fluid Dynamics. Indoor Built Environment. 13: 233-242
It has been built into the “Ladybug_Downdraft Velocity” component and has been included in an example file illustrating discomfort from cold windows in winter. The example is intended to show when glazing ratio and window U-Values are small enough to eliminate perimeter heating - a practice that is aesthetically unpleasing, costly to maintain and wasteful in its energy use.
Operative Temperature on the Psychrometric Chart - This is a feature that should have been added a long time ago but we are finally happy to say that the Ladybug_Psychrometric Chart can draw a comfort polygon assuming that the air temperature and radiant temperature are the same value (aka. an operative temperature psychrometric chart). This operative temperature chart is the format that is needed to use the ASHRAE-55 graphical method and is generally a better representation of the range of comfort in cases where one does not intend to hold the radiant temperature constant. This operative temperature capability is now set as the default on the component but you can, of course, still bring back the older comfort polygon by simply plugging in a value for meanRadiantTemperature_.
Contour Map Visualizations - Using the same inputs as the Ladybug_Recolor Mesh component, the new Ladybug_Contour Mesh component allows you to generate contoured color graphics from the results of any analysis. Now, you to maximize the use of your high-resolution studies with contours that highlight thresholds and gradients!
Image Texture Mapping for Colored Meshes - Antonello DiNunzio has added the very useful Ladybug_Texture Maker component, which allows you to bake Ladybug colored meshes with image texture maps (as opposed to the classic method that used colored vertices). This enables the creation of transparent Ladybug meshes, making it even easier to overlay Ladybug graphics with one another and with Rhino geometry:
This component also adds the ability to render Ladybug + Honeybee meshes with other rendering programs like V-Ray and 3ds Max. So you can produce Ladybug graphics like this!
Finally, image-mapped textures are also the format required for gaming and Virtual Reality software like Unity and Augmented Reality programs like Augment. So now you can export your Ladybug meshes all of the way to the virtual world!
Rhino Sun Component - If you have ever had to set up the sun for a rendering plugin and wished that you could just take your Ladybug sun and use that, then you are in luck! Byron Mardas has contributed a component that lets you set the Rhino sun based on your EPW location data, your north direction (if different from the Y-Axis) and any time of day that you want. Not only does this make it easier to coordinate the Rhino sun with your Ladybug visualizations, but you can also use it for real time shadow previews by setting your Rhino view to “Rendered” and scrolling through a slider.
Rendered Ladybug Animations - With both the image texture mapping and the Rhino sun components released, your first thought might be “it would be great if I could use this all in a rendered animation!” Thankfully, Ladybug has added a new component to help you here. The Ladybug_Render View component works in essentially the same way as the Capture View component, allowing you to make a series of images as you animate through a slider. The major benefit here is that it works with both Rhino Render and V-Ray so that animations like this can be produced effortlessly:
Cone of Vision Added - Antonello Di Nunzio has added a component that allows you to visualize various cones of vision in order to help inform your view studies. You can fine tune parameters to include just text-readable or full peripheral vision and use the resulting view cone to constrict the results of your “Ladybug_View Analysis” studies.
Terrain WIP Components Released as the Gismo Plugin - Our friend Djordje has released a new plugin Gismo - a plugin for GIS environmental analysis. As a result the following 5 terrain components: Horizon Angles, Flow Paths, Terrain Shading Mask, Terrain Generator 2, Terrain Analysis, have been removed from Ladybug+Honeybee's WIP section and are added to Gismo.
HONEYBEE
Search, Select, and Import the Hundreds Outputs from EnergyPlus/OpenStudio - Many of the power users in our community know that EnergyPlus is capable of writing several hundred different outputs from the simulation (well beyond what the basic Honeybee result readers can import). While Honeybee has always allowed one to request these outputs by adding them to the simulationOutputs_ of the component, there has not been an official workflow for searching through all of the possible outputs or importing their specific results… until now! We have added the "Honeybee_Read Result Dictionary" component, which allows you to parse the Result Data Dictionary (or .rrd file) that EnergyPlus outputs during every run of a given model. This allows you to see all of the outputs that are available for the model and you can even search through this list to find a particular output that you are interested in. Once you find what you are looking for, simply copy the text output from the component into a panel and and plug this into simulationOutputs_. Then you can use the "Honeybee_Read EP Custom Result" component to bring your custom results into GH after rerunning the simulation. The example file of an evaporative cooling tower shows how to use the workflow to request and import in the energy removed by the tower.
OpenStudio HVAC System Sizing Results - After the full integration of HVAC in the last release, we realized that a number of people wanted to run EnergyPlus models simply to evaluate the size of the Heating/Cooling system in the model (obtained from the EnergyPlus autosize calculation that is run at the start of every simulation). Such a sizing calculation can be a great way to quantify the anticipated savings from a given strategy (like shading) on the size/cost of the building’s HVAC system. To get the results of the sizing calculation, all that one needs to do is connect the output eioFile from the OpenStudio component to the Honeybee_Read HVAC Sizing component. The outputs will indicate the peak heating/cooling loads of each zone (in Watts) as well as the size of each piece of HVAC equipment in the model. The next time that you are on a project that is about to value-engineer out an exterior shading system, use the workflow in the following example file to show that the client will probably end up paying for it with a more expensive HVAC system: Quantifying HVAC Sizing Impact of Shade.
Improved Memory Usage When Building Large Energy Models - As we take the capabilities of Honeybee to larger and larger models, many of us have begun to run up against a particular limitation of our machines: memory. After upgrading our machines to have 32 GBs of RAM, there was only one way left to alleviate the problem: restructure some of the code. Honeybee now uses an enhanced approach that ensures all the previous iterations of Honeybee objects will be removed from the memory once there is a change. In any case, the considerations of memory are definitely something that we intend to improve with the future Honeybee[+] plugin.
Workflow to Import gbXML Files - While GrizzlyBear has been around for several years, enabling us to export Honeybee zones to gbXML, we have gone for quite some time without a workflow to import gbXML files to Honeybee. The new Honeybee_gbXML to Honeybee component addresses this and establishes an easier path to import models from Revit into honeybee. You can read more about the component in this post.
Window Frame Capabilities Added to OpenStudio - After the implementation of LBNL THERM / WINDOW capabilities in the last two releases, there was one final bridge to build in the Honeybee workflow - fully connecting LBNL WINDOW to Honeybee’s OpenStudio workflow. This release of Honeybee will now write all FrameAndDivider objects exported from LBNL WINDOW glazing systems into the energy simulation, enabling you to account for the frame’s thermal bridging effects. As long as the construction is brought in with the Honeybee_Import WINDOW IDF Report component, the frames associated with the construction will be assigned to all windows that have the construction. Finally, it is worth noting that the current Honeybee will also write all glass spectral data as well as gas (or gas mixture) materials into the simulation. This means that essentially all properties of any IDF export that one makes from LBNL WINDOW can be factored into the OpenStudio energy simulation (with the only exception being BSDF materials).
OpenStudio Daylight Sensors Added - In our previous releases of Honeybee, the only means of correctly account for daylight sensors in an energy simulation was to run an annual daylight simulation and use the resulting schedules for the lighting in the energy simulation. However, this can take a lot of time and work to set up and run, particularly if the daylight control (at the end of the day) will be driven by just one sensor per room. Now, we have added another option, which uses OpenStudio/EnergyPlus’s built-in daylight controls. You can assign just a point and an illuminance target on the “Set Zone Thresholds” component and the lighting will be automatically adjusted in the course of the simulation. It should also be noted that the addition of daylight sensors has also coincided with the addition of blind/shade control based on glare. The same sensor point for daylight can be used to drive dynamic shades in the energy simulation based on glare experienced at this point. This example file shows how to set up daylight controls on the EnergyPlus model and check the lighting power results to see the effect.
Better Defaults for Natural Ventilation - After many good people wrote to me informing me that Honeybee overestimates natural ventilation airflow and I wrote back showing the way that I intended natural ventilation to be set up with the component, it dawned on me that I had selected some poor component defaults. Accordingly, this release includes a window-based natural ventilation option on the Set EP Airflow component that corrects for some of the common issues that I have seen. Insect screens are included by default and the component runs a general check to see if wind-driven cross ventilation is possible before auto-assigning it. The component will air on the side of more-conservative, lower airflow rates unless the user overrides the defaults. Finally, it’s worth noting that all of these changes have not affected the freedom of the Custom WindAndStack option on the component. The new defaults can be viewed in this example file.
CFD Results Can be Plugged into Microclimate Maps - In preparation for the (very soon) release of the Butterfly that connects to the OpenFOAM CFD platform, we just wanted to note that all of the microclimate map recipes can now take an input of a csv file with a matrix of CFD results for wind speed. For the time being, we have used these to produce very high-accuracy, high resolution maps of outdoor comfort. There will be more to follow soon!
We should also note that, in the last release I mentioned that we would be phasing out the EnergyPlus component so that all efforts are focused on the OpenStudio component. While I reiterate that all of the features of the EnergyPlus component are available in the OpenStudio component and I encourage everyone to use the OpenStudio component in order to take advantage of its HVAC capabilities, I have come to realize that many prefer to use the EnergyPlus component out of habit and have not yet gotten the time to understand why the OpenStudio component is an improvement over the EnergyPlus component. As a result, we have decided to leave the EnergyPlus component in place for the time being so that everyone has more time to understand this. The future Ladybug Analysis Tools platform will only interact with EnergyPlus through OpenStudio and so it is recommended that everyone use these two components in the Honeybee plugin will serve as an educational resource to understand our current path moving forward with OpenStudio.
Lastly, it is with great pleasure that we welcome Devang Chauhan and Byron Mardas to the developer team! As mentioned previously Devang has contributed several updates to the Ladybug Wind Rose in addition to finding and solving a multitude of bugs in other components. Byron has contributed code that has enabled the previously-mentioned stereographic sky projections along with a better method for running the Ladybug Sky Mask. Finally, Byron has contributed the Rhino Sun component, which allows you to coordinate your Rhino renders with your Ladybug data. Welcome to the Ladybug team, gentlemen!
As always let us know your comments and suggestions. Cheers!
Ladybug Analysis Tools Development Team…
doing this with the current tools or a bit of scripting since the Flickr API allows you to make requests in a REST format, but utilizing the Flickr.net API library makes it much simpler.
First and foremost, you need a Flickr API key...do you have one of those?
A great way to get to know the Flickr API is with the API Explorer. Here is a link to the page for the flickr.photos.search method explorer: http://www.flickr.com/services/api/explore/flickr.photos.search
The cool thing about this page is that it generates the REST Http call towards the bottom. So, here is what I did:
1. Grab the coordinates of the bounding box per Flickr API request:
bbox (Optional)
A comma-delimited list of 4 values defining the Bounding Box of the area that will be searched. The 4 values represent the bottom-left corner of the box and the top-right corner, minimum_longitude, minimum_latitude, maximum_longitude, maximum_latitude. Longitude has a range of -180 to 180 , latitude of -90 to 90. Defaults to -180, -90, 180, 90 if not specified. Unlike standard photo queries, geo (or bounding box) queries will only return 250 results per page. Geo queries require some sort of limiting agent in order to prevent the database from crying. This is basically like the check against "parameterless searches" for queries without a geo component. A tag, for instance, is considered a limiting agent as are user defined min_date_taken and min_date_upload parameters — If no limiting factor is passed we return only photos added in the last 12 hours (though we may extend the limit in the future).
So, I went to Google Earth, picked a city (London, UK) and dropped two pins:
This gave me two locations, which I can put into the Explorer Page next to the bbox option. Here is what I put for these two points: -0.155941,51.496768,-0.116783,51.511431
2. Check has_geo
3. In extras, type in geo
4. Make the call!
You will see a list of responses in an XML format, these responses will be from the first page. Geolocated photos are limited to 250 / page, so you will have to grab them page by page.
If you want to add more options (minimum upload date, maximum upload date, etc) you can do this as well)
The best is at the bottom, you get the full http call for this: http://api.flickr.com/services/rest/?method=flickr.photos.search&api_key=ffd44f601393a46e86aa3a5f8a013360&bbox=-0.155941%2C51.496768%2C-0.116783%2C51.511431&has_geo=&extras=geo&format=rest&api_sig=b42330e5d1523bd5fe60c2ad43acde99
Notice this call has some other api key, you should eventually replace this with your own.
You could copy and paste this into a browser and you will get the results with the latitude and longitude:
So this is really what you need to know to do this through GH. Since gHowl has an XML parser component that can access files on the web, you should be able to use the same http call into this component.
Eventually, we get a response, and we need to grab the lat and lon data. With gHowl we can map these to xyz coordinates, and generate the heatmap...this is just a linear mapping:
Attached are both the Rhino file and the Grasshopper file, as well as the image underlay.
I am working on a series of components that makes this more straightforward, but for now, this should get you started.
…
peuvent se diviser une surface avec ne importe quel motif imaginable. 3. Ici, je fournir un moyen de le faire via Lunchbox ... cela fonctionne mais il est fixe et donc nous avons besoin de jouer avec des arbres de données afin de créer le motif approprié par cas. 4. L'autre composante est un joint C # qui fait beaucoup de choses autres que de diviser ne importe quelle collection de points avec de nombreux modèles (voir le modèle ANDRE que je ai fait pour vous). 5. Vous devez décomposer une polysurface en morceaux afin de travailler sur les subdivisions. 6. Je donne une autre définition ainsi que pourrait agir comme un tutoriel sur la façon de traiter des ensembles de points via des composants de GH standards et des méthodes classiques.
Avertissez si tous ceux-ci apparaissent floue pour vous: Si oui, je pourrais écrire une définition utilisant des composants de GH classiques - mais vous perdrez les variations de motifs de division.
mieux, Peter
…
and export the geometry out to VVVV to render it LIVE! RawRRRR. In this case, a digital audio workstation Ableton Live, a leading industrial standard in contemporary music production.
the good news is that VVVV and ableton live lite is both free.
https://www.ableton.com/en/products/live-lite/
i am not trying to use ipad as a controller for grasshoppper. I wanted to work with a timeline (similar to MAYA or Ableton or any other DAW(digital audio workstation)) inside grasshopper in an intuitive way. Currently there is no way of SEQUENCING your definition the way you want to see that i know of.
no more combersome export import workflows... i dont need hyperrealistic renderings most of the time. so much time invested in googling the right way to import, export ... mesh settings...this workflow works for some, for some not ...that workflow works if ... and still you cannot render it live nor change sequence of instruction WHILE THE VIDEO is played. and I think no one wants to present rhinoceros viewport. BUT vvvv veiwport is different. it is used for VJing and many custom audio visual installation for events, done professionally. you can see an example of how sound and visuals come together from this post, using only VVVV and ableton. http://vvvv.org/documentation/meso-amstel-pulse
I propose a NEW method. make a definition, wire it to ableton, draw in some midi notes, and see it thru VVVV LIVE while you sequence the animation the WAY YOU WANT TO BE SEEN DURING YOUR PRESENTATION FROM THE BEGINNING, make a whole set of sequences in ableton, go back change some notes in ableton and the whole sequence will change RIGHT INFRONT of you. yes, you can just add some sound anywhere in the process. or take the sound waves (sqaure, saw, whateve) or take the audio and influence geometric parameters using custom patches via vvvv. I cannot even begin to tell you how sophisticated digital audio sound design technology got last ten year.. this is just one example which isn't even that advanced in todays standard in sound design ( and the famous producers would say its not about the tools at all.) http://www.youtube.com/watch?v=Iwz32bEgV8o
I just want to point out that grasshopper shares the same interface with VVVV (1998) and maxforlive, a plug in inside ableton. audio mulch is yet another one that shares this interface of plugging components to each other and allows users to create their own sound instruments. vvvv is built based on vb, i believe.
so current wish list is ...
1) grasshopper recieves a sequence of commands from ableton DONE
thanks to sebastian's OSCglue vvvv patch and this one http://vvvv.org/contribution/vvvv-and-grasshopper-demo-with-ghowl-udp
after this is done, its a matter of trimming and splitting the incoming string.
2) translate numeric oscillation from ableton to change GH values
video below shows what the controll interface of both values (numbers) and the midi notes look like.
https://vimeo.com/19743303
3) midi note in = toggle GH component (this one could be tricky)
for this... i am thinking it would be great if ...it is possible to make "midi learn" function in grasshopper where one can DROP IN A COMPONENT LIKE GALAPAGOS OR TIMER and assign the component to a signal in, in this case a midi note. there are total 128 midi notes (http://www.midimountain.com/midi/midi_note_numbers.html) and this is only for one channel. there are infinite channels in ableton. I usually use 16.
I have already figured out a way to send string into grasshopper from ableton live. but problem is, how for grasshopper to listen, not just take it in, and interpret midi and cc value changes ( usually runs from 0 to 128) and perform certain actions.
Basically what I am trying to achieve is this : some time passes then a parameter is set to change from value 0 to 50, for example. then some time passes again, then another parameter becomes "previewed", then baked. I have seen some examples of hoopsnake but I couldn't tell that you can really control the values in a clear x and y graph where x is time and y is the value. but this woud be considered a basic feature of modulation and automation in music production. NVM, its been DONE by Mr Heumann. https://vimeo.com/39730831
4) send points, lines, surfaces and meshes back out to VVVV
5) render it using VVVV and play with enormous collection of components in VVVV..its been around since 1998 for the sake of awesomeness.
this kind of a digital operation-hardware connection is usually whats done in digital music production solutions. I did look into midi controller - grasshopper work, and I know its been done, but that has obvious limitations of not being precise. and it only takes 0 o 128. I am thinking that midi can be useful for this because then I can program very precise and complex sequence with ease from music production software like ableton live.
This is an ongoing design research for a performative exhibition due in Bochum, Germany, this January. I will post definition if I get somewhere. A good place to start for me is the nesting sliders by Monique . http://www.grasshopper3d.com/forum/topics/nesting-sliders
…
n be obtained for curved NURBS surfaces as well as unconventional window configurations".
And I also noticed the following information form the optional input in the runEnergySimulation component.
"meshSettings_: Optional mesh settings for your geometry from any one of the native Grasshopper mesh setting components. These will be used to change the meshing of curved surfaces before they are run through EnergyPlus (note that meshing of curved surfaces is done since Energyplus is not able to calculate heat flow through non-planar surfaces). Default Grasshopper meshing is used if nothing is input here but you may want to decrease your calculation time by changing it to Coarse or increase your curvature definition (and calculation time) by making it finer".
1) My case is an one-story, rectangular-plan large hall (40m*70m*25m) with a curved roof. The roof surface is a part of a standard sphere and the walls and floor are all planar (the each wall has one curved edge as showed in the image).
For testing, I threw the original curved roof surface into daylight and energy simulations without making customized meshings, because I assumed that it might be automatically converted to meshs by Honeybee - Am I right? As showed in the image, how can I reduce the number of meshs in a proper way? Must two connected surfaces (i.e. wall and roof) be STRICTLY/SEAMLESSLY connected or not (considering different divisions of meshs in the respective surface)? - Is a connection tolerance allowed?
2) But, when I run the annual daylight simulation for this case, it gave me a lot of warnings "oconv: warning - zero area for polygon".- is that normal? and how to avoid this? Does the daylight simulation allow "curved NURBS surfaces"?
3) Moreover, when I run an energy simulation for this case, it costed extremely long time. It was just so long that I did not even have results out of one simulation. - I guessed it might be the problem caused by the curved roof surface (or automatic meshing?), but I don't have experience of converting a curved NURBS/spheral surface into correct meshs that can be recognized by Honeybee simulations (Daylight and Energy) in a proper way.
4) The large window on the wall was generated by the "_glzRatio". But the automatically generated wall meshs around this window are just too "fine", which might largely increase simulation time. Is there a proper way to get rid of it? (Considering that the size, shape and position of the window will have large influence on the daylight distribution in the building, it is worthy to keep the size, shape and position of the window as it should be in reality).
In sum, considering all above, could your please provide me some suggestions/tutorials/links that might be helpful for dealing with "curved NURBS surfaces" in Honeybee simulations.
Thank you all in advance!
Best,
Ding
…
ing the maps to the broader community.
At the moment, there are just a few known issues left that I have to fix for complex geometric cases but they should run smoothly for most energy models that you generate with Honeybee. Within the next month, I will be clearing up these last issues and, by the end of the month, there will be an updated youtube tutorial playlist on the comfort tools and how to use them.
In the meantime, there's an updated example file (http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Indoor_Microclimate_Map) and I wanted to get you all excited with some images and animations coming out of the design part of my thesis. I also wanted to post some documentation of all of the previous research that has made these climate maps possible and give out some much deserved thanks. To begin, this image gives you a sense of how the thermal maps are made by integrating several streams of data for EnergyPlus:
(https://drive.google.com/file/d/0Bz2PwDvkjovJaTMtWDRHMExvLUk/view?usp=sharing)
To get you excited, this youtube playlist has a whole bunch of time-lapse thermal animations that a lot of you should enjoy:
https://www.youtube.com/playlist?list=PLruLh1AdY-Sj3ehUTSfKa1IHPSiuJU52A
To give a brief summary of what you are looking at in the playlist, there are two proposed designs for completely passive co-habitation spaces in New York and Los Angeles.
These diagrams explain the Los Angeles design:
(https://drive.google.com/file/d/0Bz2PwDvkjovJM0JkM0tLZ1kxUmc/view?usp=sharing)
And this video gives you and idea of how it thermally performs:
These diagrams explain the New York design:
(https://drive.google.com/file/d/0Bz2PwDvkjovJS1BZVVZiTWF4MXM/view?usp=sharing)
And this video shows you the thermal performance:
Now to credit all of the awesome people that have made the creation of these thermal maps possible:
1) As any HB user knows, the open source engines and libraries under the hood of HB are EnergyPlus and OpenStudio and the incredible thermal richness of these maps would not have been possible without these DoE teams creating such a robust modeler so a big credit is definitely due to them.
2) Many of the initial ideas for these thermal maps come from an MIT Masters thesis that was completed a few years ago by Amanda Webb called "cMap". Even though these cMaps were only taking into account surface temperature from E+, it was the viewing of her radiant temperature maps that initially touched-off the series of events that led to my thesis so a great credit is due to her. You can find her thesis here (http://dspace.mit.edu/handle/1721.1/72870).
3) Since the thesis of A. Webb, there were two key developments that made the high resolution of the current maps believable as a good approximation of the actual thermal environment of a building. The first is a PhD thesis by Alejandra Menchaca (also conducted here at MIT) that developed a computationally fast way of estimating sub-zone air temperature stratification. The method, which works simply by weighing the heat gain in a room against the incoming airflow was validated by many CFD simulations over the course of Alejandra's thesis. You can find here final thesis document here (http://dspace.mit.edu/handle/1721.1/74907).
4) The other main development since the A. Webb thesis that made the radiant map much more accurate is a fast means of estimating the radiant temperature increase felt by an occupant sitting in the sun. This method was developed by some awesome scientists at the UC Berkeley Center for the Built Environment (CBE) Including Tyler Hoyt, who has been particularly helpful to me by supporting the CBE's Github page. The original paper on this fast means of estimating the solar temperature delta can be found here (http://escholarship.org/uc/item/89m1h2dg) although they should have an official publication in a journal soon.
5) The ASHRAE comfort models under the hood of LB+HB all are derived from the javascript of the CBE comfort tool (http://smap.cbe.berkeley.edu/comforttool). A huge chunk of credit definitely goes to this group and I encourage any other researchers who are getting deep into comfort to check the code resources on their github page (https://github.com/CenterForTheBuiltEnvironment/comfort_tool).
6) And, last but not least, a huge share of credit is due to Mostapha and all members of the LB+HB community. It is because of resources and help that Mostapha initially gave me that I learned how to code in the first place and the knowledge of a community that would use the things that I developed was, by fa,r the biggest motivation throughout this thesis and all of my LB efforts.
Thank you all and stay awesome,
-Chris…
t. So here we go!
1. Honeybee is brown and not yellow [stupid!]...
As you probably remember Honeybee logo was initially yellow because of my ignorance about Honeybees. With the help of our Honeybee expert, Michalina, now the color is corrected. I promised her to update everyone about this. Below are photos of her working on the honeybee logo and the results of her study.
If you think I'm exaggerating by calling her a honeybee expert you better watch this video:
Thank you Michalina for the great work! :). I corrected the colors. No yellow anymore. The only yellow arrows represent sun rays and not the honeybee!
2. Yellow or brown, W[here]TH Honeybee is?
I know. It has been a long time after I posted the initial video and it is not fun at all to wait for a long time. Here is the good news. If you are following the Facebook page you probably now that the Daylighting components are almost ready.
Couple of friends from Grasshopper community and RADIANCE community has been helping me with testing/debugging the components. I still think/hope to release the daylighting components at some point in January before Ladybug gets one year old.
There have been multiple changes. I finally feel that the current version of Honeybee is simple enough for non-expert users to start running initial studies and flexible enough for advanced users to run advanced studies. I will post a video soon and walk you through different components.
I think I still need more time to modify the energy simulation components so they are not going to be part of the next release. Unfortunately, there are so many ways to set up and run a wrong energy simulation and I really don’t want to add one new GIGO app to the world of simulation. We already have enough of that. Moreover I’m still not quite happy with the workflow. Please bear with me for few more months and then we can all celebrate!
I recently tested the idea of connecting Grasshopper to OpenStudio by using OpenStudio API successfully. If nothing else, I really want to release the EnergyPlus components so I can concentrate on Grasshopper > OpenStudio development which I personally think is the best approach.
3. What about wind analysis?
I have been asked multiple times that if Ladybug will have a component for wind study. The short answer is YES! I have been working with EFRI-PULSE project during the last year to develop a free and open source web-based CFD simulation platform for outdoor analysis.
We had a very good progress so far and our rockstar Stefan recently presented the results of the work at the American Physical Society’s 66th annual DFD meeting and the results looks pretty convincing in comparison to measured data. Here is an image from the presentation. All the credits go to Stefan Gracik and EFRI-PULSE project.
The project will go live at some point next year and after that I will release the Butterfly which will let you prepare the model for the CFD simulation and send it to EFRI-PULSE project. I haven’t tried to run the simulations locally yet but I’m considering that as a further development. Here is how the component and the logo looks like right now.
4. Teaching resources
It has been almost 11 months from the first public release of Ladybug. I know that I didn't do a good job in providing enough tutorials/teaching materials and I know that I won’t be able to put something comprehensive together soon.
Fortunately, ladybug has been flying in multiple schools during the last year. Several design, engineering and consultant firms are using it and it has been thought in several workshops. As I checked with multiple of you, almost everyone told me that they will be happy to share their teaching materials; hence I started the teaching resources page. Please share your materials on the page. They can be in any format and any language. Thanks in advance!
I hope you enjoyed/are enjoying/will enjoy the longest night of the year. Happy Yalda!
Cheers,
-Mostapha
…
ere's not plenty of skate spots. how to know what size skateboard to get and all teams visit for each skate/vacation. Plenty of skateparks, a swimming pool scene that's difficult to break the code to, and street spots which are whether bust or presently offer the techniques logged.
The trip began off for each week in Honolulu. The crew was Chris Haslam, Paul Machnau, Sierra Fellers, and Brent Atchley. Sierra and myself had just become from Nz and australia before departing with regards to this trip, additionally to the people other crew were within the cold Northwest.
They'd a seaside house rented out for your week within the Northern Coast directly across from Pipeline. Inside the doorstep was Cholo's compound along with new Northern Coast concrete skatepark. It had been hot and moist, and so the agenda elevated to acquire awaken early, visit the beach, and swimming at like 8 am.
And possess some coffee and breakfast, maybe begin the rock at Waimea Bay. Then proven around visit skating. We did laps inside the island trying to look at different spots even though it was hot out. Lots of occasions it had been to acquire similar to, " let us visit the beach," however we discovered some rad spots and additionally it switched into " the shore, let us skate." Scott, the TM for Dakine, had the program pretty relaxed. You need to in Hawaii, right? Hold on, how extended can plenty of dudes hang within the sea together when there are lots of places to skate?
Graveside DIY project reaches its third phase. We found this out once we visited skate it one mid-day but got humbled. An issue which inserts lower because place is gnarly as hell. We spent roughly 1 hour getting thrown around instead of got an chance to come back. I'd like no under every week simply to locate the lines, bumps, protuberances, and holes.
Together with tranny, dying boxes, corners, and coping. It is a really sick place the locals needed over and did their unique factor with, not conforming for the public skatepark hype. Customized with BBQ pits within the deck along with whole nine yards. Just hearing who did what where inside was enough that will help you seem like a pussy inside the best complete skateboards for beginners.
We've proven up at Cholo's compound one evening given that they returned for the city. Skating the bowls along with small-ramps was I an enjoyable experience--he'd lights ready you will observe a session happening 'til late. Clearly, just hospitality.
Consider HAWAII? The surfing. "Yeah, Brudda, you need to come searching. We'll demonstrate what is happening.In . Yeah right, they'll. The locals can be found in water almost all day, everyday. We are inside the skateboard trip and then we fide skateboards. A lot of us proven up in this area surfing--or may i have thought that paddling around inside the sea watching the guides rip up.
It is not like i used to be while using the surfers to 13-stair handrails and gaps, letting them know they need to skate around. Nonetheless it had been awesome dealing with seem like a fool in water like numerous inside the locals yelled out such things as "We elevated here therefore you travelled here. Beat it, haoles!" I suppose we stuck out like sore thumbs. Wouldn't it are actually Haslam surfing in jeans which have been cut obtaining a blade roughly the ankles and tied obtaining a shoestring, selecting the show Castaway with Tom Hanks.
Within the second week within the trip, we travelled to Maul Same drill: Beach house in Paia Bay, obtaining a skatepark fight constantly. There's more spots in Oahu than Maui, and then we handled enough the photos there. But Maui had more to provide than we expected. We met some locals who'd formerly been ripping the skatepark in Kihea, once you have a 30-pack together these were lower to demonstrate us the island's spots.
Handrails, more ditches, some concrete parks, and abandoned truck beds stored us busy in the last day or two within the-week vacation within the islands. It had been among individuals journeys that no-one selected over depart, particularly in your thinking for your shitty winter. Of skate journeys an individual finishes inside the amount of sewer-ridden ditch with dead rats, or perhaps amount of ghetto neighborhood school wishing the equipment does not get jacked. But every from time to time when you're getting lucky. Big because of Scott and Dakine for linking plenty of days. Let us book them tickets again for get, Brudda!
WE Began WITH SEANZO in north of manchester Shore. He elevated up skating while using the Phelper within the Colonial, and he's resided in Hawaii in the last fifteen years. We hit him up for whatever pools he might take us to without getting shut within the scene, ditches which have been around. as well as other things looked awesome to ride that folks don't skate much or learn about. Such as the abandoned small-course that proven up in this area as if a skatepark within the mid-'70s. I have not skated somewhat-course much like it. not very I have ever performed small-golf inside the with snake runs and bowls either. Precisely what an crazy place. While using the finish within the session i used to be kicked out, and before we understood it baseballs were flying at us inside the driving range. Precisely what a coincidence.
Seanzo's 12-year-old boy might be a skate rat. and hubby had some rails and street spots for individuals. The youthful along with old recently experienced it covered. Machnau's visited Hawaii on numerous skate journeys, so he understood about the majority of the spots too. A couple of demos, encircled by great water, a seaside house. BBQ's each night, awesome people, Learn how to ride a skateboard and very no schedule. Too may distractions greater than a normal skate trip this is often frequently frequently considered a tough one.
…
ger work.
Be aware, this release breaks file-forwards compatibility. You will not be able to open gh and ghx files saved with 0.8.0050 on previous versions, though of course you should be able to open old files without problems. If this is not the case, please yell loudly.
If you're having trouble loading Grasshopper, note that you must have the latest Microsoft C++ Runtimes installed on your machine. They can be downloaded from the microsoft website.
The new release can be downloaded from the usual location.
Here's a list of changes, additions and fixes since 0.8.0013:
File format forwards compatibility has been broken. You will not be able to open files saved with 0.8.0050 on earlier versions.
This release contains many breaking changes and GHA libraries compiled for older version may not work anymore.
Grasshopper Binary files (*.gh) are now saved as compressed data.
Grasshopper Binary files (*.gh) are now the default format.
Support for ancient versions of the Text Panel (still called Post-It from back then) has been removed.
Support for ancient versions of the Path Mapper (still called Path Lexer from back then) has been removed.
Placeholders for ancient versions of the Graph Mapper have been removed.
Gradient input parameters now show state tag icons (Reversed, Flatten etc.).
Geometry Cache name changes are now updated on every key press.
Geometry Cache name changes can now be cancelled with Escape.
Geometry Cache name changes can now be undone.
Mesh|Mesh intersection component now uses a different algorithm. The old behaviour is still available from the component menu.
Warning and Error balloons are now drawn as part of a Canvas Widget and will no longer show up in the Hi-Res image export.
Galapagos now accepts multiple fitness values. The true fitness will be the average of the collection.
Galapagos wires are drawn much fainter when the Galapagos object is unselected.
Medium fast redraw mode in Galapagos now immediately redraws instead of at the end of each generation.
Redesigned all Grasshopper file format icons and added larger size icons for high-dpi explorer views.
Redesigned the Most Recently Used files menu, it should now display much quicker.
Compass widget has been rewritten in an attempt to increase display performance.
Added preferences section for Compass widget.
Added preferences section for Align widget.
Added preferences section for Default Preview colours.
Added preferences section for Document Preview colours.
Added preferences section for the Most Recently Used files menu.
The Area component now accepts Breps, Meshes and Planar Closed Curves.
The Area Centroid component now accepts Breps, Meshes and Planar Closed Curves.
The Volume component now accepts Breps and Meshes.
The Volume Centroid component now accepts Breps and Meshes.
Added Merge Faces component (Surface.Util panel).
Added a Mesh Smooth component (Mesh.Util panel).
Added a Curve Seam component (Curve.Util panel).
Added Interpolate Curve With Tangents component (Curve.Spline dropdown).
Added GrasshopperFolders command to open Settings, Components and UserObject folders without loading the core plugin.
The window that reports on certain Loading Errors now has a Copy button.
Added Simplify post-process filter to parameters (in addition to Reverse, Flatten and Graft).
Parameter post processes (Reverse, Flatten, Graft & Simplify) can now also be assigned to output parameters.
Version History window now has formatting (not happy with this, I'm working on something better).
The Process Info window is gone.
Main menu has been redesigned.
Canvas toolbar has been redesigned.
Canvas context menu has been replaced by a Radial Menu.
Canvas now has a radial menu which will pop up on Middle Mouse Button clicks.
It's possible to switch between Radial and Legacy menus in the Preferences (Interface.Canvas section).
'Save As Copy' feature has been replaced by 'Save Backup' which is a GUI-less save including date+time stamp.
Added a 'Show in Folder' item to the File menu.
AutoSave settings are no longer available from the File menu, you now need to use the Preferences.
Selection shifts now also modify the view so you can use Ctrl+Left and Ctrl+Right to navigate up and downstream.
Mesh Edge display can now be toggled with Ctrl+M.
Preview modes now have shortcuts (Ctrl+1 = no preview, Ctrl+2 = wireframe, Ctrl+3 = shaded).
Solution States now have a default name.
Data Viewer window now responds to all required events.
Data Viewer window can now handle input and output parameters as well.
Canvas Navigation pane can now be dragged using the icon in the upper left corner.
The Persistent Data Editor has been redesigned.
It's now possible to select multiple items in the Persistent Data Editor list and edit their properties.
It's now possible to drag multiple items at the same time in the Persistent Data Editor list.
Item addition to the Persistent Data Editor is much improved.
The Persistent Data Editor is now non-modal.
The Canvas would remain black upon maximizing the Rhino window, this is fixed.
Sliders would cause multiple updates under certain conditions, this is fixed.
Digit Scrollers would cause multiple updates under certain conditions, this is fixed.
Pipes were inside out. This is fixed.
The curve component would not adjust invalid nurbs degrees, this is fixed.
Curves referencing Brep edges failed to load, this is fixed.
Points referencing Brep edges failed to load, this is fixed.
Referenced dlls in the VB/C# components sometimes resulted in invalid imports statements, this is fixed.
Pasting geometry in Rhino would cause a recompute of the Grasshopper solution, this is fixed.
Importing a file into the Rhino document would cause a recompute of the Grasshopper solution, this is fixed.
Galapagos would trigger superfluous solutions, this is fixed.
Mesh Solid Difference had a wrong name and description, this is fixed.
Several menu items were not greyed out despite not being usable, this is fixed.
The position and size of the Grasshopper window failed to get stored on Rhino shutdown, this is fixed.
The Persistent Data Editor would crash on parameters that did not support data proxies, this is fixed.
I'll add some additional information regarding some of the new UI features in subsequent posts.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…