le of weeks. But if you are patient I think we will try to solve most of the issues.
For the TOF module, I find that no matter which inputs I provide, the optimalTilt is always 45 and the optimalAzimuth is always 180. I'm providing a weather file input and a north vector.
You are the second user who reported this which means that I was wrong in my assumption of setting a very low default value for the precision_ input, it should have been higher as more user friendly for beginners. Basically the TOF component results depend on the precision_ input. The best would be to set this value to 100, let your PC run the whole night, and in the morning you would get the most precise tilt and azimuth optimal angles. However, as some of us are using weaker PCs, and as sometimes the difference between results from precision_ = 100 and say precision_ = 30 is less than a degree, you can try using the precision_ = 30 for the start.
By default the precision_ is set to only 2. I will make sure this is increased in the next release of this component. Your topic definitively contributed to that!
Another thing I noticed is that "TOF" component does not support north_ inputs not equal to 0, in terms of graphical representation of results. It would probably take me some time to fix this. But the numerical results (which is what we need) are supported.
By looking at some other similar PV applications, I haven't seen the optimal tilt/azimuth graphical representation which supports change of north angle direction, so maybe this is not too much of an issue after all. The important thing is the numerical part, which is outputs correct results.
I'm then using the optimalTilt and optimalAzimuth outputs to supply the PV_SWH_SystemSize inputs for arrayTiltAngle and arrayAzimuthAngle - obviously this isn't actually doing anything useful at the moment as the outputs from the TOF are always 45 and 180.
It will make sence now, that you increase the upper precision_ input.
With the PV_SWH_SystemSize module, I'm having issues with the spacing it is providing between the rows of PV. I know it calculates this based on the sun position on a date based on the altitude of the location the weather file provides, but I think the spacing is far too large, especially for a rooftop array where the space is more like 1-2m normally. I'm trying to specify a summer date in the format the minimalSpacingDate output provides (15 NOV 15:00) so the calculated spacing is lower, but it just throws up an error whenever I do.
minimalSpacingPeriod_ input of the "PV SWH System Size" component accepts data from Ladybug "Analysis Period" component. But again, I apologize: as this is my mistake for not mentioning this in its docstring (that's the explanation you get when you hover your mouse over this input). I will make sure this gets added to the next release of "PV SWH System Size" component as well!
I also noticed a bug with "PV SWH System Size" component - at the moment the values it calculates are not correct if north_ input is not equal to 0. This is due to the component using another Ladybug developer's code which calculates sun position angles. For some reason this code does not support changing the north angle direction. I will contact the author to see how this can be solved.
So to be clear: it's not that all Ladybug Photovoltaics component do not support north_ inputs not equal to 0. It's that "PV SWH System Size" component currently does not due to the upper issue. And "Tilt and Orientation Factor (TOF)" component does not support for its graphical representation of results. I will see if at least the first one can be fixed.
Finally, it would be really useful to be able to get the PV_SWH_SystemSize component to actually produce the array it has created as Rhino geometry, so they can be viewed when rendered; is that possible? Also, is it possible to restrict the module so that it only creates rows with dimensions such that it fits within a surface you provide?
The PV_SWHsurface output of "PV SWH System Size" component contains Grasshopper geometry of all PV rows. Are you familiar with baking in Grasshopper?
I attached below an example of how to perform a shaded PV analysis. I rotated the whole context by 40 degrees so that the issue with "PV SWH System Size" component could be overlooked. When you determine your minimalSpacingPeriod_ input, we can internalize its "PV SWH System Size" output, rotate back your context and use "40" as a value for north_ input for all components.
Let me know if something was not clear, or if I replied vaguely to some of your questions.I apology in advance if it may take me a bit longer to answer to your next question. This spring period has really toughen my free time.…
whole design intent, but this is what Inventor is good at. The way it packages bits of 'scripted' components into 'little models' that can be stored and re-assembled is central to MCAD working.
The Inventor model shown is almost 5 years old. We don't model like that any more, however it does offer a good idea of general MCAD modeling approaches.
iParts is useful in certain situations, it could've been useful in the above model, its usefulness is often in function of the quantity of variants/configurations.
So much is scripted in GH, maybe it should also be possible to script/define/constrain/assist the placement/gluing of the results?
...
Starting point: I think we are talking across purposes. AFAIK, the solving sequence of GH's scripted components is fixed. It won't do circular dependencies... without a fight. The inter-component dependencies not 'managed' like constraints solvers do for MCAD apps.
Components and assemblies are individual files in MCAD.
Placement of these within assemblies in MCAD is a product of matrix transforms and persistent constraints. There is no bi-directional link, the link is unidirectional (downflow only), because of the use of proxies.
Consequently, scripting the placement of components is irrelevant in GH, unless you decide that each component needs to be contained in its own separate file.
This also brings up the point that generating components and assemblies in MCAD is not as straightforward. In iParts and iAssemblies, each configuration needs to be generated as a "child" (the individual file needs to be created for each child) before those children can be used elsewhere.
You notice the dilemma, if you generate 100 parts, and then you realize you only need 20, you've created 80 extra parts which you have no need for, thus generating wasteful data that may cause file management issues later on.
GH remains in a transient world, and when you decide to bake geometry (if you need to at all), you can do that in one Rhino file, and save it as the state of the design at that given moment. Very convenient for design, though unacceptable for most non-digital manufacturing methods, which greatly limits Rhino's use for manufacturing unless you combine it with an MCAD app.
One of the reasons why the distributed file approach makes perfect sense in MCAD, is that in industry you deal with a finite set of objects. Generative tools are usually not a requirement. Most mechanical engineers, product engineers and machinists would never have any use for that.
The other thing that MCAD apps like Inventor have, is the 'structured' interface that offers up all that setting out information like the coordinate systems, work planes, parameters etc in a concise fashion in the 'history tree'. This will translate into user speed. GH's canvas is a bit more freeform. I suppose the info is all there and linked, so a bit of re-jigging is easy. Also, see how T-Flex can even embed sliders and other parameter input boxes into the model itself. Pretty handy/fast to understand, which also means more speed.
True. As long as you keep the browser pane/specification tree organized and easy to query.
:)
Would love to understand what you did by sketching.
I'll start by showing what was done years ago in the Inventor model, and then share with you what I did in GH, but in another post.
Let's use one of the beams as an example:
We can isolate this component for clarity.
Notice that I've highlighted the sectional sketch with dimensions, and the point of reference, which is in relation to the CL of the column which the beam bears on. The orientation and location of the beam is already set by underlying geometry.
Here's a perspective view of the same:
The extent of the beam was also driven by reference geometry, 2 planes offset from the beam's XY plane, driven by parameters from another underlying file which serves as a parameter container:
Reference axes and points are present for all other components, here are some of them:
It starts getting cluttered if you see the reference planes as well:
Is I mentioned earlier, over time we've found better ways to define and associate geometry, parameters, manage design change, improving the efficiency of parametric models. But this model is a fair representation of a basic modeling approach, and since an Inventor-GH comparison is like comparing apples and oranges anyways, this model can be used to understand the differences and similarities, for those interested.
I haven't even gotten to your latest post yet, I will eventually.…
Added by Santiago Diaz at 10:36am on February 26, 2011
he picture (4).
Previously, I had a problem with generating intersections between the two directions of the beams, but a colleague helped me by extending beams, so there was no problem with lines of intersection. But this solution has generated curl (5) at the highest vertex geometry, which I ignored in order to repair it before printing, perhaps this mean my problem with my beam spread properly. Only when the beams is 19, does not jump no problem, but I still can not distribute them properly.
(1)
(2)
(3)
(4)
(5)
I tried to show as simply as possible by removing or signing my code in GHX file.
Thank you in advance for your help
…
ting at multiple geometries in the same location. I simply sorted the list of values and used the Delete Consecutive component. This potentially rearranges the order of values but I don't think that matters in your case. I also threw in an Int component which actually seems to make a difference (try sidestepping it and you will see!).
2-I flattened the output of the mesh component before sending it to union. This ensures that the original mesh is booleaned once with all the components rather than individually with each of the 86 components.
Is this what the result should look like?
One suggestion for future postings: when referencing geometry in rhino, it often helps if you attach your rhino file as well so people don't have to guess where you are starting from.
If you have further questions, just ask ;-)
cbass…
edit 29/04/14 - Here is a new collection of more than 80 example files, organized by category:
KangarooExamples.zip
This zip is the most up to date collection of examples at the moment, and collects t
both my plotter/cutter and wide format printer. I had been running the plotter from my main work laptop - a Win10 machine via the plotters USB port. As it turns out you can't get Win XP drivers for this USB connection so I needed another solution.
I tried to use the plotters DB25 serial port connection using an old DB9 to DB25 modem cable I had in my collection = no luck the plotter wouldn't talk. A bit more research and it turns out these plotters need a 'null modem' cross over cable to operate. I found a pic of the correct wiring online and made up my own with some cable and connectors from the local electronics hobby shop.
With this hooked up and using Hyperterminal I was able to fire some codes to the plotter directly and get a response back - winning!
At this point I got my original code working with the 'net use' redirect from LPT1 to COM1.
HOWEVER - being that the plotter was now on a COM port there are a few more interesting things you can do with it - one is being able to read the paper size/cut area from the printer.
So what I needed to to was find a way to send and receive data to/from the plotter using the serial port.
A bit of research into .NET's serial port interface and using a bunch of small pieces of test code I have manged to completely re-jig this driver.
Upgrades include:
- Direct Serial Port comms using Null Modem cable (a USB to serial adaptor + null modem should also work)
- Plot area read from the plotter - a rectangle the size of the plot area is placed on a separate layer and coloured red
- Testing to see if selected plotting curves are both closed and inside of the cutting area - with errors shown and exiting if they are not right.
- After plot 'parking' of the plot head at the end of the cut items + an adjustable offset (currently requires manual resetting of origin on the plotter before for next cut)
Great thing is it is now 100% running within Rhino Python - no DOS command line calls = no flashing up of the CMD wind. Also no temp files needed on the HDD and no limit to number of curves that can be plotted - tested with 200 or so with no issues.
Overall very happy with whole project - have learnt a LOT about Python and .NET interfacing AND ended up with a very handy/useful tool.
Cheers
DK
# This code is a WIP # It plots directly to a DGI Plotter# via the serial port
import System.IO.Ports as Portsimport rhinoscriptsyntax as rsimport time
#Some setup valuescom_port = 'COM1' #change to match plotter port baud_rate = 9600 #change to match plotter settingplotter_step = .025 #mmfinsh_offset = 10 #mm
#Delete old cutting area and cut objectsif rs.IsLayer('Cutting Area'): rs.PurgeLayer('Cutting Area')if rs.IsLayer('Cutting Objects'): rs.PurgeLayer('Cut Objects')
#Setup Serial PortMyport = Ports.SerialPort(com_port)Port_Write = Ports.SerialPort.WriteMyport.BaudRate = baud_rateMyport.ReadTimeout=5000 #5 secsMyport.Close()Myport.Open()
#Setup PlotterPort_Write(Myport, 'PU;PA0,0;IN;\n')Port_Write(Myport, 'SP1;\n')Port_Write(Myport, 'PA;\n')time.sleep(2)
#Read the Paper size from PlotterPort_Write(Myport, 'OH;') #HPGL read limits codetime.sleep(2)
return1 = ''papersize = ''count = 0char_in_buffer = 0chars_in_buffer = Ports.SerialPort.BytesToRead.GetValue(Myport)
if chars_in_buffer == 0: print 'Plotter not ready' Myport.Close() exit()
while (count < chars_in_buffer): return1 = Myport.ReadChar() papersize = papersize + chr(return1) count = count + 1
papersize = papersize.split(",")rect1 = (float(papersize[2])*plotter_step)rect2 = (float(papersize[3])*plotter_step)
print 'Cutting area = ' + str(rect1) + 'x' + str(rect2)
#place cutting area curve on its own layer, make it red and lock itplane = rs.WorldXYPlane()cutting_area = rs.AddRectangle( plane, (rect1), (rect2))rs.AddLayer (name='Cutting Area', color=(255,0,0), visible=True, locked=True, parent=None)rs.ObjectLayer(cutting_area, 'Cutting Area')
#get plotting objects
allCurves = rs.GetObjects("Select curves to plot", rs.filter.curve)
#test to see if these are closed curves - exit if not
for curve in allCurves: test_closed = rs.IsCurveClosed(curve) if test_closed == 0: print "One or move of these curves are not closed" Myport.Close() exit()
#test to see if these are inside cutting area - exit if not
for curve in allCurves: test_inside = rs.PlanarClosedCurveContainment(curve, cutting_area)
if test_inside==0 or test_inside==1: print "One or more of these curves are outside of cut area" Myport.Close() exit()
#All ok - convert to points and send data to printer
rs.AddLayer (name='Cut Objects', color=(0,255,0), visible=False, locked=True, parent=None)
for curve in allCurves: Port_Write(Myport, 'PU;PA;SP1;\n') polyline = rs.ConvertCurveToPolyline(curve,angle_tolerance=5.0, tolerance=0.025, delete_input=False, min_edge_length=0, max_edge_length=0) points = rs.CurveEditPoints(polyline) rs.ObjectLayer(polyline, 'Cut Objects')
# PU to the first point x = points[0][0] y = points[0][1] Port_Write(Myport, 'PU' + str(int(x / plotter_step)) + ',' + str(int(y / plotter_step)) + ';\n') # PD to every subsequent point i = 1 while i < len(points): x = points[i][0] y = points[i][1] Port_Write(Myport, 'PD' + str(int(x / plotter_step)) + ',' + str(int(y / plotter_step)) + ';\n') i += 1
Port_Write(Myport,'PU;\n')
#find the far end of the cutbox = rs.BoundingBox(allCurves)far_end = str(box[1])far_end = far_end.split(",")far_end = far_end[0]far_end = float(far_end)/plotter_stepfar_end = (int(far_end))+ finsh_offsetfar_end = str(far_end)print (far_end)
#return plotter home and close portPort_Write(Myport, 'PU;PA' + far_end + ',0;IN;\n')Port_Write(Myport, 'SP1;\n')Port_Write(Myport, 'PA;\n')Myport.Close()time.sleep(10)…
oftware connections built from the initial seed of the project. 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.
This release is also special since today it is just about 3 years (3 years and 2 weeks) from the first release of Ladybug. As with any release, there have been a number of bug fixes and improvements but we also have some major news this time. In no specific order and to ensure that the biggest developments do not get lost in the extensive list of updates, here are the major ones:
Mostapha is re-writing Ladybug!
Ladybug for DynamoBIM is finally available.
Chris made bakeIt really useful by incorporating an export pathway to PDFs and vector-based programs.
Honeybee is now connected to THERM and the LBNL suite thanks to Chris Mackey.
Sarith has addressed a much-desired wish for Honeybee (Hi Theodore!) by adding components to model electric lighting with Radiance.
Djordje is on his way to making renewable energy deeply integrated with Ladybug by releasing components for modeling solar hot water.
There is new bug. Check the bottom of the post for Dragonfly!
Last but definitely not least (in case you’re not still convinced that this release is a major one) Miguel has started a new project that brings some of Ladybug’s features directly to Rhino. We mean Rhino Rhino - A Rhino plugin! Say hi to Icarus! #surprise
Before we forget! Ladybug and Honeybee now have official stickers. Yes! We know about T-Shirts and mugs and they will be next. For now, you can deck-out your laptops and powerhouse simulation machines with the symbology of our collaborative software ecosystem.
Now go grab a cup of tea/coffee and read the details below:
Rewriting Ladybug!
Perhaps the most far-reaching development of the last 4 months is an effort on the part of Mostapha to initiate a well structured, well documented, flexible, and extendable version of the Ladybug libraries. While such code is something that few community members will interact with directly, a well-documented library is critical for maintaining the project, adding new features, and for porting Ladybug to other software platforms.
The new Ladybug libraries are still under development across a number of new repositories and they separate a ladybug-core, which includes epw parsing and all non-geometric functions, from interface-specific geometry libraries. This allows us to easily extend Ladybug to other platforms with a different geometry library for each platform (ie. ladybug-grasshopper, ladybug-dynamo, ladybug-web, etc) all of which are developed on top of the ladybug-core.
Without getting too technical, here is an example of a useful outcome of this development. If you want to know the number of hours that relative humidity is more than 90% for a given epw, all that you have to code (in any python interface) is the following:
import ladybug as lb
_epwFile = r"C:\EnergyPlusV7-2-0\WeatherData\USA_CO_Golden-NREL.724666_TMY3.epw"
epwfile = lb.epw.EPW(_epwFile)
filteredData = epwfile.relativeHumidity.filterByConditionalStatement('x>90')
print "Number of hours with Humidity more than 90 is %d "%len(filteredData.timeStamps)
Compare that to the 500 + lines that you would have had to write previously for this operation, which were usually tied to a single interface! Now let’s see what will happen if you want to use the geometry-specific libraries. Let’s draw a sunpath in Grasshopper:
import ladybuggrasshopper.epw as epw
import ladybuggrasshopper.sunpath as sunpath
# get location data form epw file
location = epw.EPW(_epwFile).location
# initiate sunpath based on location
sp = sunpath.Sunpath.fromLocation(location, northAngle = 0, daylightSavingPeriod = None, basePoint =cenPt, scale = scale, sunScale = sunScale)
# draw sunpath geometry
sp.drawAnnualSunpath()
# assign geometries to outputs
...
Finally we ask, how would this code will look if we wanted to make a sunpath for dynamo? Well, it will be exactly the same! Just change ladybuggrasshopper in the second line to ladybugdynamo! Here is the code which is creating the sunpath below.
With this ease of scripting, we hope to involve more of our community members in our development and make it easy for others to use ladybug in their various preferred applications. By the next release, we will produce an API documentation (documentation of all the ladybug classes, methods and properties that you can script with) and begin making tutorials for those interested in getting deeper into Ladybug development.
LADYBUG
1 - Initial Release of Ladybug for Dynamo:
As is evident from the post above, we are happy to announce the first release of Ladybug for Dynamo! You can download the ladybug package from Dynamo package manager. Make sure to download version 0.0.6 which is actually 0.0.1! It took a number of trial and errors to get it up there. Once you have the file downloaded you can watch these videos to get started:
The source code can be find under ladybug-dynamo repository and (as you can already guess) it is using the new code base. It includes a very small toolkit of essential Ladybug components/nodes but it has enough to get you started. You can import weather files, draw sunpaths and run sunlighthours or radiation analyses.
There are two known issues in this release but neither of them is critical. You need to have Dynamo 0.9.1 or higher installed which you can download from here (http://dynamobuilds.com/). It is recommended that you run the scripts with ‘Manual’ run (as opposed to ‘Automatic’) since the more intense calculations can make Dynamo crash in automatic mode.
To put things in perspective, here is how we would map Ladybug for Dynamo vs Ladybug and Honeybee for Grasshopper on the classic ‘Hype graph’. The good news is that what we learned a lot from the last three years, making development of the Dynamo version easier and getting us to the plateau of productivity faster.
We should also note that the current development of the Dynamo interface is behind that of the Ladybug-Core, which means there are a number of features that are developed in the code but haven’t made their way to the nodes yet. They will be added gradually over the next month or two.
If you’re interested to get involved in the development process or have ideas for the development, follow ladybug on Facebook, Twitter and Github. We will only post major release news here. Facebook, github and twitter will be the main channels for posting the development process. There will also be a release of a new ladybug for Grasshopper soon that will use the came Ladybug-Core libraries as the Dynamo interface [Trying hard not to name it as Ladybug 2].
2 - New Project “Icarus” Provides Ladybug Capabilities Directly in Rhino
Speaking of expanded cross-platform capabilities, the talented Miguel Rus has produced a standalone Rhino Plugin off of the original Ladybug code that has been included in this release. After writing his own core C# libraries, Miguel’s plugin enables users to produce sunpath and run sunlight hours analyses in the Rhino scene without need of opening Grasshopper or engaging the (sometimes daunting) act of visual scripting.
This release includes his initial RHP plugin file. It is hoped that Miguel’s efforts will extend some of the capabilities of environmental design to individuals who are unfamiliar with visual scripting, casting the network of our community into new territory. We need your help spreading the word about Icarus since the people who will benefit the most from it have probably not read this far into the release notes. Also, as the project is in the early stages, your feedback can make a great difference. You can download the current release from this link.
Once you download the zip file. Right click and unblock it. Then extract the files under C:\Program Files\Rhinoceros 5 (64-bit)\Plug-ins\ folder. Drag and drop the RHP file into Rhino and you should be ready to go. You can either type Icarus in the command line or open it via the panels. Here is a short video that shows how to run a sunlighhours analysis study in Rhino.
3 - BakeIt Input Now Supports a Pathway to PDF +Vector Programs
As promised in the previous release, the BakeIt_ option available on Ladybug’s visual components has been enhanced to provide a full pathway to vector-based programs (like Illustrator and Inkscape) and eases the export to vector formats like PDFs.
This means that the BakeIt_ operation now places all text in the Rhino scene as actual editable text (not meshes) and any colored meshes are output as groups of colored hatches (so that they appear as color-filled polygons in vector-based programs). There is still an option to bake the colored geometries as light meshes (which requires smaller amounts of memory and computation time) but the new hatched capability should make it easier to incorporate Ladybug graphics in architectural drawings and documents like this vector psychrometric chart.
4 - Physiological Equivalent Temperature (PET) Now Available
Thanks to the efforts of Djordje Spasic, it is now possible to compute the common outdoor comfort metric ‘Physiological Equivalent Temperature’ (PET) with Ladybug. The capability has been included with this release of “Thermal Comfort Indices” component and is supported by a “Body Characteristics” component in the Extra tab. PET is particularly helpful for evaluating outdoor comfort at a high spatial resolution and so the next Honeybee release will include an option for PET with the microclimate map workflow.
5 - Solar Hot Water Components Available in WIP
Chengchu Yan and Djordje Spasic have built a set of components that perform detailed estimates of solar hot water. The components are currently undergoing final stages of testing and are available in the WIP tab of this release. You can read the full release notes for the components here.
6 - New Ladybug Graphic Standards
With the parallel efforts or so many developers, we have made an effort in this release to standardize the means by which you interact with the components. This includes warnings for missing inputs and the ability to make either icons or text appear on the components as you wish (Hi Andres!). A full list of all graphic standards can be found here. If you have any thoughts or comments on the new standards, feel free to voice them here.
7 - Wet Bulb Temperature Now Available
Thanks to Antonello Di Nunzio - the newest member of the Ladybug development team, it is now possible to calculate wet bulb temperature with Ladybug. Antonello’s component can be found under the WIP tab and takes inputs of dry bulb temperature, relative humidity, and barometric pressure.
8 - New View Analysis Types
The view analysis component now allows for several different view studies in addition to the previous ‘view to test points.’ These include, skyview (which is helpful for studies of outdoor micro-climate), as well as spherical view and ‘cone of vision’ view, which are helpful for indoor studies evaluating the overall visual connection to the outdoors.
HONEYBEE
1 - Connection to THERM and LBNL Programs
With this release, many of you will notice that a new tab has been added to Honeybee. The tab “11 | THERM” includes 7 new components that enable you to export ready-to-simulate Lawrence Berkeley National Lab (LBNL) THERM files from Rhino/Grasshopper. THERM is a 2D finite element heat flow engine that is used to evaluate the performance of wall/window construction details by simulating thermal bridging behavior. The new Honeybee tab represents the first ever CAD plugin interface for THERM, which has been in demand since the first release of LBNL THERM several years ago. The export workflow involves the drawing of window/wall construction details in Rhino and the assigning of materials and boundary conditions in Grasshopper to produce ready-to-simulate THERM files that allow you to bypass the limited drawing interface of THERM completely. Additional components in the “11 | THERM” tab allow you to import the results of THERM simulations back into Grasshopper and assist with incorporating THERM results into Honeybee EnergyPlus simulations. Finally, two components assist with a connection to LBNL WINDOW for advanced modeling of Glazing constructions. Example files illustrating many of the capabilities of the new components can be found in there links.
THERM_Export_Workflow, THERM_Comparison_of_Stud_Wall_Constructions
Analyze_THERM_Results, Thermal_Bridging_with_THERM_and_EnergyPlus
Import_Glazing_System_from_LBNL_WINDOW, Import_LBNL_WINDOW_Glazing_Assembly_for_EnergyPlus
It is recommended that those who are using these THERM components for the first time begin by exploring this example file.
Tutorial videos on how to use the components will be posted soon. A great deal of thanks is due to the LBNL team that was responsive to questions at the start of the development and special thanks goes to Payette Architects, which allowed Chris Mackey (the author of the components) a significant amount of paid time to develop them.
2 - Electrical Lighting Components with Enhanced Capabilities for Importing and Manipulating IES Files
Thanks to the efforts of Sarith Subramaniam, it is now much easier and more flexible to include electric lighting in Honeybee Radiance simulations. A series of very exciting images and videos can be found in his release post.
You can find the components under WIP tab. Sarith is looking for feedback and wishes. Please give them a try and let him know your thoughts. Several example files showing how to use the components can be found here. 1, 2, 3.
3- Expanded Dynamic Shade Capabilities
After great demand, it is now possible to assign several different types of control strategies for interior blinds and shades for EnergyPlus simulations. Control thresholds range from zone temperature, to zone cooling load, to radiation on windows, to many combinations of these variables. The new component also features the ability to run EnergyPlus simulations with electrochromic glazing. An example file showing many of the new capabilities can be found here.
Dragonfly Beta
In order to link the capabilities of Ladybug + Honeybee to a wider range of climatic data sets and analytical tools, a new insect has been initiated under the name of Dragonfly. While the Dragonfly components are not included with the download of this release, the most recent version can be downloaded here. An example file showing how to use Dragonfly to warp EPW data to account for urban heat island effect can also be found here. By the next release, the capabilities of Dragonfly should be robust enough for it to fly on its own. Additional features that will be implemented in the next few months include importing thermal satellite image data to Rhino/GH as well as the ability to warp EPW files to account for climate change projections. Anyone interested in testing out the new insect should feel free to contact Chris Mackey.
And finally, it is with great pleasure that we welcome Sarith and Antonello to the team. As mentioned in the above release notes, Sarith has added a robust implementation for electric light modeling with Honeybee and Antonello has added a component to calculate wet bulb temperature while providing stellar support to a number of people here on the GH forum.
As always let us know your comments and suggestions.
Enjoy!
Ladybug+Honeybee development team
PS: Special thanks to Chris for writing most of the release notes!…
Crystallon is an open source project for creating lattice structures using Rhino and Grasshopper3D. The goal is to generate lattice structures within Rhino’s design environment without exporting t