Because the Adaptive methodology is founded upon the notion that there are hundreds of social factors that influence comfort and that the best we can do to forecast comfort is to find variables with good correlations to these social factors (like outdoor temperature), the premise that these published Adaptive model holds regardless of cultural norms is dangerous. Notably, the founders of the adaptive model have stressed that this particular linear correlation that you cite comes from recent surveys of buildings where people have both the the ability to open windows AND a great freedom to dress down. Hypothetically, if occupants were able to open the windows in Abraham's building but the cultural norm was that everyone was expected to wear multi-layered suits or dresses (as in historic Britain), a different correlation between outdoor temperature and comfort temperature would exist. In fact, historical European comfort surveys show that people likely preferred cooler temperatures in buildings (about 1-2C cooler) than today's occupants. Accordingly, after recognizing this social premise in the Adaptive model, I have built in a few ways to adjust/alter the version in Ladybug based on the literature I have read (even though these alterations are not a part of any official ASHRAE or European standard).
Abraham, you might have to be a bit more specific about how you would like to adjust the Adaptive comfort model for me to help your particular case and this may lead to me adding in new functionality. For the time being, I can tell you that the 'Ladybug_Adaptive Comfort Parameters' component is going to be your friend and I would recommend using the Adaptive Comfort Chart to visualize how you are changing the model. You can plug these 'Adaptive Comfort Parameters' into the 'Adaptive Comfort Recipe' component to have the microclimate analysis run with these parameters. Here are a few examples of how to alter the model:
1) Mixed-mode Building - Humphreys and the European Adaptive comfort team derived two separate correlations.
One for naturally ventilated buildings:
and conditioned buildings:
The dimensionless value between 0 and 1 for _levelOfConditioning allows you to create different correlations depending on whether occupants have complete freedom of dress and window operability (0) or have slight restrictions like in a mixed mode building (0.5, for example):
2) Changing Response Time of Occupants - There has been a bit of a debate in Literature about whether it is better to use the average monthly temperature or a weekly running mean temperature. The avgMonthORRunningMean input allows you to adjust this like so:
Average Month:
Running Mean:
3) Greater Temperature Range Tolerance - While this last one is actually a part of the European and Adaptive standards, you can adjust the range of the comfort band with either the 'eightyOrNintetyComf' input or the comfortClass input like so:
Ninety Percent Comfortable
Eighty Percent Comfortable
Abraham, let me know if you would like more controls over the model or if this is enough to do what you are thinking of. This example file allows you to construct the images I have above:
http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Adaptive_Comfort_Chart&slide=0&scale=1&offset=0,0
-Chris…
ther math and logic. i can usually conceptualise what i want to do and cobble some semi working thing together but don't know which components to use and how to patch it. so i'm super happy to have someone who knows what he's doing to find this interesting.
and i'm glad you mention the fanned frets again, there is one input parameter that's still missing for the multiscale frets to be fully parametric, it's the angle of the nut or which fret should be straight. it depends a bit on personal preferences and playing posture what is more comfortable. so being able to adjust this easily would be cool. again i have no idea how the maths for that work or if you can just rotate each fret the same amount around it's middle point. The input either as fret number (for the straight fret) or as a simple slider from bridge to nut should do as input setting.
Here are the two extremes and the middle ground:
i've been thinkin today while analysing your patches and cleaning up my mess what exactly the monster should do.
Here are the input parameters needed, i think it's the complete list
scale length low E string
scale length high e string
fret angle/straight fret
string width at nut
string width at bridge
number of frets
fretboard overhang at nut (distance from string to fretboard bounds)
fretboard overhang at last fret
string gauges
string tensions
fretboard radius at nut (for compound radius fretboard radius at bridge is calculated with the stewmac formula)
fretwire crown width
fretwire crown height
action height at nut (distance between bottom of string and fretwire crown top)
action height at last fret
pickup 1 neck position
pickup 2 middle position
pickup 3 bridge position
nut width
the pickup positions should be used to draw circles for the magnet poles on each string so they are perfectly aligned and can be used for the pickup flatwork construction. ideally they would need a rotation control aligning the center line of the pickup so it's somewher between the last fret angle and bridge angle. personally i do this visually depending on the design i'm looking for, some people have huge theories on pickup positioning but personally i don't believe in it.
that should result in everything needed to quickly generate all the necessary construction curves or geometry for nut/fingerboard/frets/pickups. this is the core of what makes a guitar work, the more precise this dynamic system is the better the guitar plays and sounds.
i posted another thread trying to understand how i could use datasets form spreadsheets,databse, csv to organize the input parameters. What would make sense for the strings for example is hook into a spreadsheet with the different string sets, i attached one for the d'Addario NYXL string line which basically covers all combos that make sense.
The string tension is an interesting one, and implmenting it would sure be overkill albeit super interesting to try. it should be possible to extrapolate from the scale length of each string what the tension for a given string gauge of that string would be so that you could say 'i want a fully balanced set' or 'heavy top light bottom) and it would calculate which SKU from d'addario would best match the required tension. All the strings listed in the spreadsheet are available as single strings to buy.
i'm trying to reorganize everything which helps me understand it. i just discovered the 'hidden wires' feature which is great since once i understood what a certain block does or have finished one of my own, i can get the wires out of the way to carry on undistracted. a bit risky to hide so many wires but it makes it so much easier not to get completely lost :-)
btw, the 'fanned fret' term is trademarked, some guy tried to patent it in the 80's which is a bit silly since it has been done for centuries. there is a level of sophistication above this as well, check out http://www.truetemperament.com/ and that really is something else. it really is astounding how superior the tuning is on those wigglefrets, the problem is that it's rather awkward for string bending and also you can't easily recrown or level the frets when they are used. …
nd the challenge "Building the Invisible: Informing Digital Design with Real World Data". Information about each Workshop Cluster can be found here:
Cyber GardensUse the ForceUrban FeedsSuspended DreamsInteracting with the CityAgent ConstructionAuthored SensingPerforming SkinsResponsive Acoustic SurfacingHybrid Space Structure Typologies
The SmartGeometry 2011 Workshop will take place at CITA http://cita.karch.dk/
Applications to attend the SmartGeometry 2011 Workshop in Copenhagen will close on 31st January 2011. General Conference registration will open within 1 month.
We hope to see you there!
****************************************************
Workshop 28th-31st March
Shop Talk 1 April
Symposium 2 April
Reception 2 April
These events follow the highly successful previous SG events in Barcelona 2010, San Francisco 2009, Munich 2008, New York 2007, Cambridge/London, UK 2006 and multiple preceding events.
Click here for more info...
This year's Challenge is entitled:BUILDING THE INVISIBLEInforming Digital Design with Real World Data
THE PREMISEVast streams of data offer a rich resource for designers. By incorporating external information into our design processes the autonomy of the design is challenged. User data, energy calculations, embedded sensing, material and structural simulation, human behaviour and perception, particle flows and force fields allows design to be situated and responsive. From the simulation of megacities to the solid modelling of material systems, design has the potential to be informed by the real. Design sits not separate from is environment but inhabits an ecological system, open, dynamic and interdependent, diverse, partially self-organising, adaptive, and fragile. Across scale and within time we now have the chance to instil architecture with an immanent intelligence creating new relationships between the user, the built and its ecosphere.THE OPPORTUNITYSystems theorists suggest that data is only a raw material. It can be differentiated from information, knowledge and wisdom. Understanding is multi-levelled: understanding of relations, understanding of patterns, understanding of principles. As digital designers our challenge is in harnessing the power of computation to assist us in informing our design process. Computers help us collect, manage and analyse the environment and inform us about an abundance of data. Our challenge is to use these inputs in a meaningful way to help us make better informed design decisions.THE AIMSG 2011 explores how the incorporation of real world data challenges existing design thinking. The SG 2011 workshop aim is to create physical prototypes of design systems to be exhibited in the SG2011 exhibition.
The SmartGeometry Group is a not-for-profit educational organization dedicated to the use of computational tools in architecture and engineering. SG brings professionals, academics, and industry together to explore the next generation of digital design. SG Workshops are non-platform specific, believing it is the methodology, not the tool, that matters.
…
Added by Shane Burger at 11:23am on January 6, 2011
looked at autodesk simulation cfd 2015 and was optimistic because it had an export plugin from revit, which i use anyway for material takeoffs and etc, but found that it did not take solar radiation into account. This was a downer because I have heard that solar radiation could effect indoor airflow - convection - as much as 50 percent at a time.
Then I searched again and found that Hyperworks, a software by altair technology can be coupled with a radiation software. So I went through the trouble of obtaining an educational license of Hyperworks. However, though some email exchange I have found that the coupling is a one-way. The radiation analysis software was used, I think, for understanding the solar loading for a SOM project called church of light.
The support guy said : "Unfortunately our coupling with Hyperworks is really a one way coupling. We can accept H coefficients from their software in RadTherm, but they will not read in our wall temps. That said, it still can be a useful coupling in the sense that you can run the analysis in Hyperworks, send H coefficients to RadTherm, and run the analysis to better understand radiation and conduction. Most importantly, that analysis can be done for longer transient analysis, but will require much less compute time and resources."
Not only did I not understand what he means by the H coefficients, my wanting to get a CFD understanding coupled with solar radiation was again, unsatisfied. In the mean while I had to finish a presentation so I haven't had the time to try to get some result on the natural ventilation. I would probably need to look into how their solutions work before I can understand if their software would "do the job"
Thank you for letting me know about your work on this. I downloaded the Honeybee_Set EP Natural Ventilation component and made sure that it is allowed, but it does not show up in grasshopper.
You pointed out that "The component (and the corresponding equation) is mostly meant for cases where you have zones with windows that are NOT connected by an air wall (or a larger airflow network)." I wondered if you are suggesting it would be a code violation for zones to be connected by an air wall for fire safety reasons. It would be a violation I guess, like not putting an fiber insulation or some kind of smoke stop between Spandrel panels and the edge of a floor plate would be a code violation for a typical office building.
There is a project by kevin daly architects where you can see a section drawing with what seems like a cfd analysis (could be an illustration)
it was my initial visualization/simulation goals were for a facade design I am working on
1) an average air velocity across a zone at noon, for example, if a passive design strategy like this was used. for this I am guessing cfd is not entirely necessary. probably means that it could be used earlier in a design process, too. This would be more about user comfort.
2) at a later phase, like in detailing facade components, if airflow is indeed as expected for a zone that is connected to an air wall / chimney like feature (and to see if there is a proper mixing of air)
3) and a projection of energy savings, of course.
After seeing a video of simulation cfd I was optimistic, but like I said sim cfd does not take account of solar loading. I think I would probably go ahead start with one zone with sim cfd first, try three zones stacked on top of each other, then try hyperworks and try to factor in solar radiation.
For analyzing multiple zones on different levels, being able to add a chimney would be especially useful, I think. Having said that, I don't have a lot of experience of using honeybee except for the daylight component so it would take some time for me to understand the components.
I hope some of the information here is useful for you. after all, both sim cfd and hyperworks are commercial softwares and somewhat different than the e plus project you are working on, I guess but still trying to address a similar problem.
so.. in cased you missed it I was asking I downloaded the Honeybee_Set EP Natural Ventilation component and made sure that it is allowed and placed in the user object foler, but it does not show up in grasshopper. what could be the reason?
…
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.
…
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
…
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
…
n common tasks like updating GH definitions, viewing images on the GH canvass, and augmenting existing study-types. Most of the improvements to Honeybee have been in the making for a while and are just getting into the spotlight with this release. Notably, a number of improvements have been made to support large-scale full building energy models, including fixes to memory issues with large models, better components for splitting building masses into zones, and the ability to store HBZones in external files. Additionally, the THERM workflows have gotten a boost and these simulations can now be run directly from the Grasshopper canvass.
As always you can download the new release from Food4Rhino. Make sure to remove the older version of Ladybug and Honeybee before you do so and update your scripts. So, without further adieu, here is the list of the new capabilities added with this release:
LADYBUG
Better Method for Updating Old Grasshopper Files - As many of you have come to realize, Ladybug + Honeybee is updated on a fairly regular basis, with a stable release roughly every 6 months and a github version that never ceases to improve itself on a weekly basis. For this reason, we realize that updating old Grasshopper definitions to use recent components is a challenge for many of us. While we’ve had some methods for this in the past, there were always hiccups, particularly when it came to components that had new inputs/outputs since the previous version. Accordingly, Mostapha has added a new “Ladybug_Update File” component that will automatically update any Grasshopper Definition to be synchronized with the version of Ladybug+Honeybee that is currently in your toolbar (aka. the components in your userobjects folder). If there is a component that has new inputs/outputs since the time you built the definition, it will be automatically circled in red in your GH definition and a newer version of the component will be automatically added right next to this component:
While you still have to do some manual connecting of inputs to the newer component in this case, it should be much faster than our older methods and will hopefully help your old definitions survive long into the future!
EPWmap Now includes OneBuilding Files - Mostapha has added a number of new features to the EPWmap web interface that the “Download Ladybug” component connects to. Among the improvements are a color wheel that quickly shows you how hot, cold, and comfortable a given climate is and, perhaps more importantly, there is now support for EPW files sourced from OneBuilding. With the addition of many more weather files, you should now be able to use Ladybug with ease for more locations across the planet. We should also note that the “Open EPW and STAT” component that downloads/unzips files from a URL now supports OneBuilding URLs.
New Image Viewer Component - Mingbo Peng has graced Ladybug with a fantastic new “Image Viewer” component that takes a given image file on one’s machine and displays it on the Grasshopper canvas. It also enables one to pull color data off of the image with ease by simply clicking on the pixel of the image one is interested in. This new component is useful for a wide variety of cases, including the viewing of screenshots after they have been taken with the “Ladybug_Capture View” or “Ladybug_Render View” components. However, many of you will likely recognize it as most immediately useful in workflows involving image-based Honeybee Daylight (Radiance) simulations. This is particularly true as Migbo has built-in the capability to read many image file types, including PNG, JPEG, GIF, TIFF and the High Dynamic Range (.HDR) image files that Radiance Outputs:
The following video gives a quick overview of the Image Viewer’s capabilities:
The new component can be found under the Ladybug_Extra tab and I think I speak for us all in saying thank you Mingbo for this great component!
New Sun Shades Calculator Released Under WIP - After over a year of software development and nearly a career's worth of geometric math development, a joint effort between Abraham Yezioro and Antonello Di Nunzio has produced a new sun shade design component that can be described as nothing short of “magical.” Based on a similar principle to the current “Ladybug_Shading Designer,” the new component takes an input of sun vectors and produces shade geometries that can block the vectors. However, in comparison to the shading designer, the range of shade options that are available in this new component is truly staggering, ranging from classic overhangs, louvers and fins to pergolas and custom shade surfaces. Perhaps more importantly, the calculation methods used by this new component are faster and more reliable. It can currently can be found under the WIP section of Ladybug and it will continue to evolve in new versions of Ladybug.
Renewable Component Now Support Sandia and CEC Photovoltaics Modules - Polishing off his many contributions to the “Renewables” section of Ladybug, Djordje Spasic has added support for a couple more ways of defining Photovoltaic modules for renewables estimation. Specifically, the Ladybug WIP section now includes components to import modules defined with the California Energy Commission (CEC) and Sandia Labs.
HONEYBEE
Support for OpenStudio 2.x - A few months ago, the National Renewable Energy Lab (NREL) released a stable version of OpenStudio version 2, which included a number of improvements in stability and available features. This stable release of Honeybee is built to work with the new version of OpenStudio and, in the coming months, Honeybee will be adding a few more capabilities to its OpenStudio workflows to support v2.x’s new capabilities. Most notable among these will be support for OpenStudio measures. Measures are short scripts written in Ruby using OpenStudio’s SDK to quickly edit and change OpenStudio models. They are fundamental to visions of OpenStudio as a flexible energy modeling interface and to Honeybee’s goals of being a collaborative interface between the architectural and engineering industries. Stay tuned for the next release for many of these new capabilities!
Critical Memory Issue Fixed for Large Energy Models - A number of you wonderful members of our community have been aware of computer memory issues with large Honeybee models for some time (examples: 1, 2, 3, 4). Namely, a model that is larger than 50 zones could quickly eat up 16 GBs of memory and change Honeybee from a fast-flying insect to something more reminiscent of a snail. We are happy to say that, after a much longer time than it should have taken us, we finally identified and fixed the issue. In this version of Honeybee, such large models can now be created using less than 2% of the memory and time previously. Thanks to all of you who made us aware of this and hopefully you will now reap the rewards of your struggle.
Split Building Mass Component Getting a Makeover - Many of you veteran Ladybug users will recognize Saeran Vasathakumar as one of the original contributors of Ladybug who added components for solar fans and envelopes years ago. Now he’s back with new components to split a building mass into zones that are truly revolutionary in their speed and methodology. Saeran has divided the new capabilities into two components (one for floor-by-floor subdivision and another for core-perimeter subdivision) and they both can be found under the WIP section of this release. In this WIP version, core-perimeter thermal zones can only be generated for all convex and very simple concave geometries. Most concave geometries and geometries with holes (or courtyards) in them will fail. However it can handle even very complex convex geometries with speed and ease. You can expect the component to start accommodating concave/courtyard geometries very soon.
Load / Dump HB Objects to File - Keeping in line with the support of large, full building energy models, this release includes full support for two components that can dump and load any HBObjects to a standalone file. All information about HBzones can go into this file including custom constructions, schedules, loads, natural ventilation, shading devices, etc. You can then send the resulting .HB file to someone else and they can load up the same exact zones in another definition. This also makes it possible to have one Grasshopper file for generating the zones and running the simulation and another GH definition to import results and color zones/surfaces with those results, make energy balance graphics, etc.
Write ViewFactorInfo to File - After many of you asked for it, the _viewFactorInfo that is output from the “Honeybee_View Factor” component can now be written out to an external file using the same Load / Dump HB Objects components cited above. For those of you who have worked with the comfort map workflows, you probably already know that calculating these view factors is one of the most time consuming portions of building a microclimate map. Having to re-run this calculation each time you want to open up the Grasshopper script is a nuisance and, thanks to this new capability, you should only have to run it once and then store your results in an external .HB file.
Transform Honeybee Components Modified for Large Model Creation - Many large buildings today are made up of copies of the same rooms repeated over and over again across multiple floors, or along a street, etc. Accordingly, one can imagine that the fastest way to create a full building energy model of such buildings is to simply move and copy the same zones several times. This is what a new set of edits to the Honeybee Transform components is aimed at supporting by allowing one to build a custom set of zones, translate them several times with a Honeybee_Transform component, then solve adjacencies on all zones to make a complete energy model.
Central Plants Available on HVAC Systems - While Honeybee has historically supported the assigning of separate HVAC systems to different groups of zones, each HVAC was always an entirely new system from the ground up. So a building with separate VAV systems for each floor would be modeled with a different chiller and boiler for each floor. While this can be the case sometimes, it is more common to have only one chiller and boiler per building but separate air systems for each floor. The new ‘centralPlant_’ options on the Honeybee coolingDetails and heatingDetails enable you to create this HVAC structure by making a single boiler and chiller for any HVAC systems that have this option toggled on. Furthermore, in the case of VRF systems, you can also centralize the ventilation system, using the grouping of zones around a given HVAC to assign which zone terminals are connected to a given heat pump.
More HVAC Templates Added - As the profession continues to push the industry standard towards lower-energy HVAC systems, Honeybee intends to keep up. In this release, we have included a few more templates for modeling advanced HVAC systems including Radiant Ceilings, Radiant Heated Floors + VAV Cooling, and Two Ground Source Heat Pump (GSHP) systems. Variable Refrigerant Flow (VRF) systems have also gotten a large boost as it is now possible to model these systems with more efficient water-source loops. The next release will include the ability to model central ground source systems that use hydronics for heating cooling delivery.
Run THERM Simulations Directly from Grasshopper - Anyone who has used the THERM workflow in the past likely realized that, while Honeybee can write the THERM file, you would still have to open model in THERM yourself and hit “simulate” to get results. Now that LBNL has started a transition to becoming more open, they have graciously allowed free access for everyone to run THERM from a command line. What this means for Honeybee is that you no longer need to open THERM at all in order to get results and you can now work entirely in Rhino/Grasshopper. This also opens up the possibility of long parametric runs with THERM models since you can now automatically run simulations and collect results as you animate sliders, use galapagos, etc. A special thanks is due to the LBNL team for exposing this feature, including Setphen Selkowitz, Christian Kohler, Charlie Curcija, Eleanor Lee, and Robin Mitchell.
All Options Exposed for THERM Boundary Conditions - To finish off the full implementation of THERM in Honeybee, a final component has been added called “Honeybee_Custom Radiant Environment.” This component completes the access to all boundary condition options that THERM offers, including separate radiant and air temperatures, different view factor models, and the specification of additional heat flux (which is typically used to account for solar radiation).
Improvements to Schedule-Generating Components - Many of you who have watched the Honeybee energy modeling video tutorials have likely gotten in the habit of using CSV schedules for everything. While this is definitely one valid way to work, it is not always the most efficient since simple schedules can be specified much more cleanly to EnergyPlus/OpenStudio and the use of CSVs can also make it difficult to share your energy models (since you have to send CSV files along with the schedules themselves). This release adds two new schedule components that should take care of a lot of cases where CSV schedules were unnecessary. The new “Constant Schedule” component allow you to quickly make a schedule that is set at a single value or a set of constantly repeating 24-hour values. The second component allows you to create “Seasonal Schedules” by connecting “week schedules” from the other schedule components along with analysis periods in which these seek schedules operate. Together, these will hopefully make our schedule-generating habit a bit better as a community.
Lastly, many of you may know Mingbo Peng as the current maintainer of the Design Explorer web interface and the Colibri components under TTToolbox. Both of these tools have been revolutionary in enabling “brute force” studies of design spaces (aka. Grasshopper scripts where one runs all combinations of a set of sliders). Now, Mingbo has graced Ladybug with the aforementioned image viewer component and it is with pride that we welcome Mingbo Peng to the development team!
As always let us know your comments and suggestions.Cheers!
The Ladybug Tools Development Team
…
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…