re are major changes and enhancements.
HONEYBEE
More Flexible Workflow - Many small modifications were made to support a more flexible workflow, such as the ability to separate a zone created with masses2Zones into editable HBSrfs that can be recombined. For the energy components, it is now possible to plug custom constructions directly into the components that set the zone constructions without writing them first into the library. For the daylighting components it is now possible to change all of the materials of specific surface types at once.
Support for Complex Geometry - Many small bugs for complex geometry have been fixed including the ability to import energy results correctly for curved NURBS surfaces as well as unconventional window configurations. Also, the intersectMasses component now almost always succeeds in splitting all of the surfaces of adjacent zones, no matter how complex the intersection is.
Automatic Download Issues Fixed - Many users who faced issues with not having “gendaymtx.exe” or who had trouble syncing with our github know that we faced an issue with automatic background downloads.
Air Walls - Honeybee EnergyPlus models now officially support air walls (or virtual partitions) in a basic implementation. Now, any time that you use the air wall construction or set a surface type to “air wall,” the air between adjacent zones will be automatically mixed. At present, this mixing is just a constant flow based on the surface area between zones connected by air walls multiplied by an adjustable “flow factor.” It is important to stress that this basic air mixing is not with the EnergyPlus Airflow Network, although the groundwork laid in this release will eventually allow for the implementation of the Airflow Network in future releases. As such, this present air mixing is only suitable for multi-zone conditions where there is not significant buoyancy-driven flow between zones.
Natural Ventilation - To go along with the new potential introduced by air walls, there has been a basic implementation of EnergyPlus’s natural ventilation objects in a new component called “Set EP Airflow”. The current setup allows for three possible types of natural ventilation: 1) natural ventilation through windows (with auto-calculated flow based on window area, outdoor wind speed/direction, and stack effects), 2) custom wind and stack objects that can be used to model things such as chimneys off of single zones, and 3) constant, fan-driven natural ventilation.
Additional Thermal Mass - The capability to add additional thermal mass to zones has been added. This is useful for factoring in the mass of indoor furniture or heavy interior objects such as chimneys.
New Utility Components - Abraham has added a couple of useful components to help calculate lighting loads based on bulb types and target lighting levels as well as a converter from ACH to the m3/s-m2 that the other HB components accept. Along this vein, there is also a component for adding in the resistance of Air Films to HB constructions.
Improved and Editable Ideal Air Loads System - The EnergyPlus Ideal Air System now goes through an automatic sizing period at the start of the simulation based on the extreme weeks of the weather file. Furthermore, the ability to adjust many of the parameters of the ideal air loads system have been added with a new “Set Ideal Air Loads Parameters” component. The component allows you to add in heat recovery, air side economizers and demand-controlled ventilation.
OpenStudio Export Update - The OpenStudio workflow is still largely under development but this release includes a version with a working VAV and PTHP system template for those curious with experimenting. Note that not all of the new features available for the basic “Run Energy Simulation” component are available for the OpenStudio component (such as air walls, natural ventilation, or additional thermal mass).
Microclimate/Indoor Comfort Maps - Blossoming from initial experiments with the radiant temperature map, a workflow for looking into sub-zone microclimate and indoor comfort has been initiated. All components for this are presently under the Honeybee WIP tab but, over the next month, they will be completing their development phase and moving into the rest of the tabs. If you are interested in testing when they are ready, please let Chris know. For a teaser video of the intended capabilities, see this video: (https://www.youtube.com/watch?v=fNylb42FPIc&list=UUc6HWbF4UtdKdjbZ2tvwiCQ)
LADYBUG
Monthly Bar Chart - After much demand from multiple parties, a new component to create monthly bar and line charts has been added. The component is particularly useful for plotting the outputs of the “Average Data” component like monthly EPW data or averaged monthly-per hour data. It also supports daily data and any type of Energy simulation results.
Wind Profile - To go along with the new capabilities of natural ventilation in Honeybee, Ladybug now has a fully fleshed-out Wind Profile component that allows you to visualize how wind speed changes with height in relation to your building geometry. The component is geared to understanding the conditions of prevailing wind and will be useful in the future for setting up CFD models. Credit goes to Djordje Spasic for adding in all of the new capabilities. In a similar vein, the appearance of the wind rose has also been improved thanks to suggestions from Alejandra Menchaca.
Faster Solar Adjusted Temperature - Thanks to the SolarCal method from the Center for the Built Environment at UC Berkeley (http://escholarship.org/uc/item/89m1h2dg), the solar adjusted temperature component now includes an option for a much faster calculation that produces results that are very close to those originally obtained with the genCumSky component. Instead of using the cumulative sky, the component can now accept the direct and diffuse radiation from the ImportEPW component. Over a whole year, this essentially takes a calculation that used to be a half-hour and shrinks it down to 10 seconds. Thanks again to those at UC Berkeley for keeping their work open source!
Instructions - Last but not the least, [It took me almost two years to understand this but finally] we have a text file that describes the installation step by step and is way easier to modify than a video. You can find it in the zip file. Credit goes to Chris!
We also want to welcome Anton, Patrick and Sandeep to the team. Anton has kicked off his development by working on a component to import and visualize epw ground temperature data and he will be continuing to develop components to bring in reliable precipitation data to Ladybug. With this basis, he will continue to implement Honeybee components for ground heat storage, earth tubes, rain collection and hot water systems. Patrick and Sandeep are working on integration of Honeybee to Energy Performance Calculator.
As always let us know your comments and suggestions.
Enjoy!…
mplex the models are. If we are running multi-room E+ studies, that will take far longer to calculate.
Rhino/Grasshopper = <1%
Generating Radiance .ill files = 88%
Processing .ill files into DA, etc. = ~2%
E+ = 10%
Parallelizing Grasshopper:
My first instinct is to avoid this problem by running GH on one computer only. Creating the batch files is very fast. The trick will be sending the radiance and E+ batch files to multiple computers. Perhaps a “round-robin” approach could send each iteration to another node on the network until all iterations are assigned. I have no idea how to do that but hope that it is something that can be executed within grasshopper, perhaps a custom code module. I think GH can set a directory for Radiance and E+ to save all final files to. We can set this to a local server location so all runs output to the same location. It will likely run slower than it would on the C:drive, but those losses are acceptable if we can get parallelization to work.
I’m concerned about post-processing of the Radiance/E+ runs. For starters, Honeybee calculates DA after it runs the .ill files. This doesn’t take very long, but it is a separate process that is not included in the original Radiance batch file. Any other data manipulation we intend to automatically run in GH will be left out of the batch file as well. Consolidating the results into a format that Design Explorer or Pollination can read also takes a bit of post-processing. So, it seems to me that we may want to split up the GH automation as follows:
Initiate
Parametrically generate geometry
Assign input values, material, etc.
Generate radiance/ E+ batch files for all iterations
Calculate
Calc separate runs of Radiance/E+ in parallel via network clusters. Each run will be a unique iteration.
Save all temp files to single server location on server
Post Processing
Run a GH script from a single computer. Translate .ill files or .idf files into custom metrics or graphics (DA, ASE, %shade down, net solar gain, etc.)
Collect final data in single location (excel document) to be read by Design Explorer or Pollination.
The above workflow avoids having to parallelize GH. The consequence is that we can’t parallelize any post-processing routines. This may be easier to implement in the short term, but long term we should try to parallelize everything.
Parallelizing EnergyPlus/Radiance:
I agree that the best way to enable large numbers of iterations is to set up multiple unique runs of radiance and E+ on separate computers. I don’t see the incentive to split individual runs between multiple processors because the modular nature of the iterative parametric models does this for us. Multiple unique runs will simplify the post-processing as well.
It seems that the advantages of optimizing matrix based calculations (3-5 phase methods) are most beneficial when iterations are run in series. Is it possible for multiple iterations running on different CPUs to reference the same matrices stored in a common location? Will that enable parallel computation to also benefit from reusing pre-calculated information?
Clustering computers and GPU based calculations:
Clustering unused computers seems like a natural next step for us. Our IT guru told me that we need come kind of software to make this happen, but that he didn’t know what that would be. Do you know what Penn State uses? You mentioned it is a text-only Linux based system. Can you please elaborate so I can explain to our IT department?
Accelerad is a very exciting development, especially for rpict and annual glare analysis. I’m concerned that the high quality GPU’s required might limit our ability to implement it on a large scale within our office. Does it still work well on standard GPU’s? The computer cluster method can tap into resources we already have, which is a big advantage. Our current workflow uses image-based calcs sparingly, because grid-based simulations gather the critical information much faster. The major exception is glare. Accelerad would enable luminance-based glare metrics, especially annual glare metrics, to be more feasible within fast-paced projects. All of that is a good thing.
So, both clusters and GPU-based calcs are great steps forward. Combining both methods would be amazing, especially if it is further optimized by the computational methods you are working on.
Moving forward, I think I need to explore if/how GH can send iterations across a cluster network of some kind and see what it will take to implement Accelerad. I assume some custom scripting will be necessary.…
s before here: http://spacesymmetrystructure.wordpress.com/2011/05/18/pseudo-physical-materials/)
If we want to design repetitive structures, we might want to be able to assign periodic boundary conditions to some structure to enforce translation symmetry. For instance, a long row of connected arches or vaults, which we want to be identical for ease of fabrication.
We could simulate this by adding many identical vaults in a row, and as we added more, the ones near the middle would get closer and closer to being identical. But they would never quite reach the point of being truly identical, even as we added hundreds of copies, and this would be very inefficient for large simulations:
One way around this is to take some points on one side of our structure, and lock them to some points on the other side of the structure using the new TranslationLock component:As far as the physics engine is concerned, each pair of points linked in this way is then actually just one point. It is as though the space itself has been wrapped around to join one side with the other.
Anyone who has played the game Portal will be familiar with a version of this concept (or for the older ones among you - asteroids).
Translation locks can be applied in any direction, and combined with any of the other forces. However, a few things to bear in mind:
-Be careful not to double up forces unintentionally. For instance, if you are adding a gravity load to the nodes of a catenary arch, and you want an equal load on every point, add only half the load to the locked particles, because when joined together these get combined (or equivalently you could add the full load to just one particle of the pair).
Similarly for springs - if you are smoothing a periodic tensile mesh using springs, be careful not to add the forces of the boundary springs twice.
-If you are using this for structural form-finding, remember that space we inhabit in the real world doesn't have these periodic boundary conditions (at least not on everyday scales!), so when you build it you will need to provide appropriate balancing forces at the ends.
-For forces which act on more than 2 particles, such as bending or Laplacian smoothing, you need to lock an appropriate number of particles on one side to those on the other side. Sometimes this may require adding 'ghost vertices'.
For example, here we model a periodic elastica curve:
This is achieved by applying a translation lock to the pairs shown by the red and blue arrows.
(note that the particle at the end of the blue arrow is 1 segment beyond the end of the curve)
One possible use of this tool would be the form-finding of periodic minimal surfaces (following the example of the great Surface Evolver by Ken Brakke). His site has many more great examples of these:
Generating these surfaces in a way that they remain minimal across the boundary would be very difficult without this periodic constraint.
Perhaps more interesting from a design perspective is the possibility to move beyond pure mathematical surfaces, and generate more free-form repeating units, but still preserving continuity across the boundaries, something like the work of Erwin Hauer:
…
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
…
GH, same as using sweep2 command in Rhino.
The one on the right is what I got so far (the output smooth our the kink of the original rails). Basically I am just following the methods provided by sdk sample: http://wiki.mcneel.com/developer/sdksamples/sweep2 .
The following is the function I copy and use directly from the SDK sample. By using this function, I can generate the sweep surface at right. But I want to have is the one in the middle with the kink edges. Can anyone show me how and where to modify he settings? I guess some sweep arguments need to be changed? I have try couples, such m_simplify, m_bSimpleSweep, m_bSameHeight, m_rebuild_count... but still cannot find a right combination for this function to output the sweep surface I want. Any suggestions or helps are very appreciated. Thanks for your help and time on this.
'Sweep2 function'----------------
Sub Sweep2( ByVal Rail1 As IOnCurve, _
ByVal Rail2 As IOnCurve, _
ByVal sCurves As List(Of IOnCurve), _
ByRef Sweep2_Breps As List(Of OnBrep))
'Define a new class that contains sweep2 arguments
Dim args As New MArgsRhinoSweep2
'Set the 2 rails
Dim Edge1 As New MRhinoPolyEdge
Dim Edge2 As New MRhinoPolyEdge
Edge1.Append(Rail1.DuplicateCurve())
Edge2.Append(Rail2.DuplicateCurve())
'Add rails to sweep arguments
args.m_rail_curves(0) = Edge1
args.m_rail_curves(1) = Edge2
args.m_bClosed = False
Dim section_curves As New List(Of OnCurve)
'Loop through sections to set parameters
For Each Section As IOnCurve In sCurves
Dim sCurve As OnCurve = Section.DuplicateCurve()
section_curves.Add(sCurve)
Dim t0 As Double = 0
If Not Edge1.GetClosestPoint(sCurve.PointAtStart(), t0) Then
If Not Edge1.GetClosestPoint(sCurve.PointAtEnd(), t0) Then
Dim s As Double = 0
sCurve.GetNormalizedArcLengthPoint(0.5, s)
Edge1.GetClosestPoint(sCurve.PointAt(s), t0)
End If
End If
args.m_rail_params(0).Append(t0)
Dim t1 As Double = 0
If Not Edge2.GetClosestPoint(sCurve.PointAtStart(), t1) Then
If Not Edge2.GetClosestPoint(sCurve.PointAtEnd(), t1) Then
Dim s As Double = 0
sCurve.GetNormalizedArcLengthPoint(0.5, s)
Edge2.GetClosestPoint(sCurve.PointAt(s), t1)
End If
End If
args.m_rail_params(1).Append(t1)
Next
'Set shapes
args.m_shape_curves = section_curves.ToArray
'Set the rest of parameters
args.m_simplify = 0
args.m_bSimpleSweep = False
args.m_bSameHeight = False
args.m_rebuild_count = -1 'Sample point count for rebuilding shapes
args.m_refit_tolerance = RMA.Rhino.RhUtil.RhinoApp.ActiveDoc.AbsoluteTolerance()
args.m_sweep_tolerance = RMA.Rhino.RhUtil.RhinoApp.ActiveDoc.AbsoluteTolerance()
args.m_angle_tolerance = RMA.Rhino.RhUtil.RhinoApp.ActiveDoc.AngleToleranceRadians()
Dim sBreps() As OnBrep = Nothing
If (RhUtil.RhinoSweep2(args, sBreps)) Then
For Each b As OnBrep In sBreps
Sweep2_Breps.Add(b)
Next
End If
Return
End Sub
…
into curves, and so I would like to use within Grasshopper.
I would really appreciate if anyone well versed in RhinoScript/VB.Net Syntax would be kind enough to help out.
Thank you for reading this.
' ConvertTextToGeometry.rvb -- September 2008
' If this code works, it was written by Dale Fugier.
' If not, I don't know who wrote it. ' Works with Rhino 4.0.
Option Explicit
Sub ConvertTextToGeometry
' Declare local variables
Dim obj_list, obj, saved_plane, cmd
Dim font, height, plane, style, text, bold, italic
' Select annotation objects
obj_list = Rhino.GetObjects("Select text to convert to geometry", 512, True, True)
If Not IsArray(obj_list) Then Exit Sub
' For speed, turn of screen redrawing
Call Rhino.EnableRedraw(False)
' Save the current construction plane
saved_plane = Rhino.ViewCPlane()
' Process each selected object
For Each obj In obj_list
' Weed out just the text objects
If Rhino.IsText(obj) Then
' Acquire the text parameters
font = "<single_stroke_font_name>"
height = Rhino.TextObjectHeight(obj)
plane = Rhino.TextObjectPlane(obj)
style = Rhino.TextObjectStyle(obj)
text = Rhino.TextObjectText(obj)
If (style And 1) Then
bold = "_Yes"
Else
bold = "_No"
End If
If (style And 2) Then
italic = "_Yes"
Else
italic = "_No"
End If
' Set the current construction plane
Call Rhino.ViewCPlane(, plane)
' Add a new text object (geometry)
cmd = "_-TextObject "
cmd = cmd & "_GroupOutput=_Yes "
cmd = cmd & "_FontName=" & font & " "
cmd = cmd & "_Italic=" & italic & " "
cmd = cmd & "_Bold=" & bold & " "
cmd = cmd & "_Height=" & CStr(height) & " "
cmd = cmd & "_Output=_Curves "
cmd = cmd & "_AllowOpenCurves=_Yes "
cmd = cmd & Chr(34) & text & Chr(34) & " "
cmd = cmd & "0"
Call Rhino.Command(cmd, 0)
' Delete the original object
Call Rhino.DeleteObject(obj)
End If
Next
' Restore the saved construction plane
Call Rhino.ViewCPlane(, saved_plane)
' Enable screen redrawing
Call Rhino.EnableRedraw(True)
End Sub
…
lowing error:
Has anyone encountered this error before or know what I might have done incorrectly?
The error is thrown 6 times (once for every input and output param registered?), and then Grasshopper works normally. The plugin is shown as available in the toolbox, but can't be used without throwing the above error.
Any ideas on how to fix it?
At the moment my code is the following:
using System; using System.Drawing; using Grasshopper.Kernel; using Rhino.Geometry; namespace GridShellGrasshopperPlugin { public class GridShellComponent : GH_Component { public GridShellComponent() : base("Grid Shell", "gridShell", "Applies a grid shell to a surface", "Surface", "Util"){} protected override void SolveInstance(IGH_DataAccess DA) { Surface refSurf = default(Surface); if(!DA.GetData(0, ref refSurf)) return; Point3d start = default(Point3d); if(!DA.GetData(1, ref start)) return; Point3d end = default(Point3d); if(!DA.GetData(2, ref end)) return; DA.SetData(0, null); DA.SetData(1, 33.0); DA.SetData(2, null); } protected override void RegisterOutputParams(GH_OutputParamManager pManager) { pManager.Register_LineParam("Curve On Surface", "GeoCurve", "Curve on surface between two points"); pManager.Register_DoubleParam("Line length", "length", "Length of line on surface"); pManager.Register_GenericParam("Intersection points", "points", "Points of intersection"); } protected override void RegisterInputParams(GH_InputParamManager pManager) { pManager.Register_SurfaceParam("Reference Surface", "refSurf", "Reference surface on which to form the grid shell", GH_ParamAccess.item); pManager.Register_PointParam("Start point", "startPoint", "Start point of the first line"); pManager.Register_PointParam("End point", "endPoint", "End point of the line"); } public override void CreateAttributes() { } public override Guid ComponentGuid { get { return new Guid("11111111-1111-1111-1111-111111111111"); } } protected override Bitmap Icon { get { return base.Icon; } } } }
I'm using Rhino 4.0 SR9, dated 9th March 2011, and Grasshopper 0.8.0013, dated 5th July 2011.…
r." I'm sorry to hear that, I take the interface and ease-of-use rather seriously so this sounds like a fundamental failure on my part. On the other hand, Grasshopper isn't supposed to be on a par with most other 3D programs. It is emphatically not meant for manual/direct modelling. If you would normally tackle a problem by drawing geometry by hand, Grasshopper is not (and should never be advertised as) a good alternative."What in other programs is a dialog box, is 8 or 10 components strung together in grasshopper. The wisdom for this I often hear among the grasshopper community is that this allows for parametric design."Grasshopper ships with about 1000 components (rounded to the nearest power of ten). I'm adding more all the time, either because new functionality has been exposed in the Rhino SDK or because a certain component makes a lot of sense to a lot of people. Adding pre-canned components that do the same as '8 or 10 components strung together' for the heck of it will balloon the total number of components everyone has to deal with. If you find yourself using the same 8 to 10 components together all the time, then please mention it on this forum. A lot of the currently existing components have been added because someone asked for it."[...] has a far cleaner and more intuitive interface. So does SolidWorks, Inventor, CATIA, NX, and a bunch of others."Again, GH was not designed to be an alternative to these sort of modellers. I don't like referring to GH as 'parameteric' as that term has been co-opted by relational modellers. I prefer to use 'algorithmic' instead. The idea behind parameteric seems to be that one models by hand, but every click exists within a context, and when the context changes the software figures out where to move the click to. The idea behind algorithmic is that you don't model by hand.This is not to say there is no value in the parametric approach. Obviously it is a winning strategy and many people love to use it. We have considered adding some features to GH that would make manual modelling less of a chore and we would still very much like to do so. However this is such a large chunk of work that we have to be very careful about investing the time. Before I start down this road I want to make sure that the choice I'm making is not 'lame-ass algorithmic modeller with some lame-ass parametrics tacked on' vs. 'kick-ass algorithmic modeller with no parametrics tacked on'.
Visual Programming.I'm not exactly sure I understand your grievance here, but I suspect I agree. The visual part is front and centre at the moment and it should remain there. However we need to improve upon it and at the same time give programmers more tools to achieve what they want.
Context sensitivity."There is no reason a program in 2014 should allow me to make decisions that will not work. For example, if a component input is in all cases incompatible with another component's output, I shouldn't be able to connect them."Unfortunately it's not as simple as that. Whether or not a conversion between two data types makes sense is often dependent on the actual values. If you plug a list of curves into a Line component, none of them may be convertible. Should I therefore not allow this connection to be made? What if there is a single curve that could be converted to a line? What if you want to make the connection now, but only later plan to add some convertible curves to the data? What you made the connection back when it was valid, but now it's no longer valid, wouldn't it be weird if there was a connection you couldn't make again?I've started work on GH2 and one of the first things I'm writing now is the new data-conversion logic. The goal this time around is to not just try and convert type A into type B, but include information about what sort of conversion was needed (straightforward, exotic, far-fetched. etc.) and information regarding why that type was assigned.You are right that under some conditions, we can be sure that a conversion will always fail. For example connecting a Boolean output with a Curve input. But even there my preferred solution is to tell people why that doesn't make sense rather than not allowing it in the first place.
Sliders."I think they should be optional."They are optional."The “N” should turn into the number if set."What if you assign more than one integer? I think I'd rather see a component with inputs 'N', 'P' and 'X' rather than '5', '8' and '35.7', but I concede that is a personal preference."But if I plug it into something that'll only accept a 1, a 2, or a 3, that slider should self set accordingly."Agreed.
Components."Give components a little “+” or a drawer on the bottom or something that by clicking, opens the component into something akin to a dialog box. This should give access to all of the variables in the component. I shouldn't have to r-click on each thing on a component to do all of the settings."I was thinking of just zooming in on a component would eventually provide easier ways to access settings and data."Could some of these items disappear if they are contextually inappropriate or gray out if they're unlikely?"It's almost impossible for me to know whether these things are 'unlikely' in any given situation. There are probably some cases where a suggestion along the lines of "Hey, this component is about to run 40,524 times. It seems like it would make sense to Graft the 'P' input." would be useful.
Integration."Why isn't it just live geometry?"This is an unfortunate side-effect of the way the Rhino SDK was designed. Pumping all my geometry through the Rhino document would severely impact performance and memory usage. It also complicates the matter to an almost impossible degree as any command and plugin running in Rhino now has access to 'my' geometry."Maybe add more Rhino functionality to GH. GH has no 3D offset."That's the plan moving forward. A lot of algorithms in Rhino (Make2D, FilletEdge, Shelling, BlendSrf, the list goes on) are not available as part of the public SDK. The Rhino development team is going to try and rectify this for Rhino6 and beyond. As soon as these functions become available I'll start adding them to GH (provided they make sense of course).On the whole I agree that integration needs a lot of work, and it's work that has to happen on both sides of the isle.
Documentation.Absolutely. Development for GH1 has slowed because I'm now working on GH2. We decided that GH1 is 'feature complete', basically to avoid feature creep. GH2 is a ground-up rewrite so it will take a long time until something is ready for testing. During this time, minor additions and of course bug fixes will be available for GH1, but on a much lower frequency.Documentation is woefully inadequate at present. The primer is being updated (and the new version looks great), but for GH2 we're planning a completely new help system. People have been hired to provide the content. With a bit of luck and a lot of work this will be one of the main selling points of GH2.
2D-ness."I know you'll disagree completely, but I'm sticking to this. How else could an omission like offsetsurf happen?"I don't fully disagree. A lot of geometry is either flat or happens inside surfaces. The reason there's no shelling (I'm assuming that's what you meant, there are two Offset Surface components in GH) is because (a) it's a very new feature in Rhino and doesn't work too well yet and (b) as a result of that isn't available to plugins.
Organisation.Agreed. We need to come up with better ways to organise, document, version, share and simplify GH files. GH1 UI is ok for small projects (<100 components) but can't handle more complexity.
Don't get me wrong, I appreciate the feedback, I really do, but I want to be honest and open about my own plans and where they might conflict with your wishes. Grasshopper is being used far beyond the boundaries of what we expected and it's clear that there are major shortcomings that must be addressed before too long. We didn't get it right with the first version, I don't expect we'll get it completely right with the second version but if we can improve upon the -say- five biggest drawbacks (performance, documentation, organisation, plugin management and no mac version) I'll be a happy puppy.
--
David Rutten
david@mcneel.com…
tal at food4Rhino:
http://www.food4rhino.com/project/ladybug-Honeybee?ufh
Before addressing the changes in the software itself, we would like to announce the start of two new resources that have been added to help everyone learn and share knowledge across our community.
NEW RESOURCES
GH Example File Sharing - After recognizing how important example files are for sharing knowledge and capabilities in our community, we have initiated a github-based platform for sharing Grasshopper definitions called Hydra:https://hydrashare.github.io/hydra/index.htmlWhile the database of files is a little over 50 files at the moment, it is hoped that this will become THE forum where much of collective knowledge is exchanged and shared into the future. As you can see by clicking on any of the examples, you now are able to get a high-res visual of both the Rhino scene and the GH canvas without having to download files to your machine. Furthermore the search functionality through the database enables you to quickly and easily see all that our community has contributed on certain subjects (just by searching “shade” or “wind” for example).In addition to other files that have been contributed, you can find all of the original Ladybug examples here:https://hydrashare.github.io/hydra/index.html?keywords=LBExampleFilesAnd all of the original Honeybee examples here:https://hydrashare.github.io/hydra/index.html?keywords=HBExampleFiles
LB+HB Documentation - While our historical practice of including all documentation within component descriptions may have sufficed up until this point, we have since recognized that an online database of all this documentation would be helpful. Now, you can search for key terms throughout the entire documentation of the project in our beautiful online documentation database created by Mostapha:https://www.gitbook.com/book/mostapharoudsari/ladybug-primer/detailshttps://www.gitbook.com/book/mostapharoudsari/honeybee-primer/details
And now, onto the major changes and enhancements in the software:
LADYBUG
Photovoltaics Components - Based on original code from NREL’s PVWatts (http://pvwatts.nrel.gov), Djordje Spasic and Jason Sensibaugh have built a set of 5 components that perform detailed estimate of the electricity generated by Rhino/Grasshopper surfaces when populated with Photovoltaics (PV) modules.Components allow definition of losses and shading, finding optimal tilt and orientation angles, analysing performance, energy value, consumption and emissions of the PV system.
Enhanced Solar Envelope - Boris Plotnikov has contributed a solar envelope component that is not only much faster and more stable than the previous component but also allows you to input the geometries of buildings for which you would like to ensure solar access. This enables customization of the solar envelope to specific urban contexts in a manner that the previous envelope did not. The component also features a “solar access” option that draws the envelope above which a given site receives sun from a set of sun vectors. An example file can be found here:http://hydrashare.github.io/hydra/viewer?owner=boris-p&fork=hydra&id=SolarEnvelope
Adaptive Comfort Chart - To assist with understanding the variations of the adaptive comfort model, an Adaptive Comfort Chart component has been added that functions in a similar manner to the psychrometric chart for the PMV model. In addition to granting a visualization of the adaptive standard itself, the chart is also particularly helpful for displaying the results of energy simulations in relation to the comfort polygon. The chart is based off of the UC Berkeley Center for the Built Environment’s Comfort Tool (http://comfort.cbe.berkeley.edu/) (https://github.com/CenterForTheBuiltEnvironment/comfort_tool). An example file can be found here:http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Adaptive_Comfort_Chart
Full Support for US + European Thermal Comfort Standards - Ladybug now supports the ability to model any of the variations of the Adaptive/PMV models for both the US (ASHRAE) and European (ISO) standards. This includes varying thresholds of percentage of people dissatisfied (PPD), varying thresholds for humidity ratios, the ability to use either a monthly average or daily running mean temperatures in the adaptive model, and even some functions that are not yet a part of these standards but are referenced widely in thermal comfort research. Such widely referenced functions include the ability to apply the adaptive model’s method to conditioned or mixed-mode buildings as well as the application of the adaptive model to times of the year when it is considered too cold by ASHRAE and the ISO for an adaptive standard. All of these variations on the standards can be accessed through the new “PMV Comfort Parameters” and “Adaptive Comfort Parameters” components. As a final nod to dual support for US/European standards, it is now possible to view the psychrometric chart as a Molier i,x diagram.
EPWMap - After years of struggling with the text-based indexing of the DOE’s epw file database, it is now possible to search for weather files using a map interface and search bar thanks to Mostapha’s recent web interface built with D3 and GoogleMaps (http://mostapharoudsari.github.io/epwmap/). From here on out, the Ladybug “Download EPW” component will direct you to this interface.
“RunItAll” Released as “Fly” - In preparation for future features that will assist with exploring of large multidimensional design spaces, this release of Ladybug includes a component by the name of “Fly” that is meant to run through all of the combinations of a given set of sliders. Those who follow this forum closely might recognize it as a reincarnated version of a component called “RunItAll” that appeared in some older example files. You can find an example file here: http://hydrashare.github.io/hydra/viewer?owner=mostaphaRoudsari&fork=hydra_1&id=Parametric_Daylight_Analysis
Shade Benefit Evaluator Validated + Published - After a long process of testing, the key functions within the comfort and energy shade benefit evaluator components have been validated against several similar software and energy modeling tools. A paper published to the SimAUD conference regarding this validation can be found here: https://www.dropbox.com/s/tvdj6d2giswurew/SIMAUD_Paper12.pdf?dl=0. Special recognition goes to Panagiotis Samaras, who ran many of these intensive tests for his thesis. Along with this validation, there are a few more variables that have been exposed to allow more freedom of running the shade benefit functions including the use of higher sky resolutions and multiple shade benefit test regions for a given shade.
Color Gradient Library - After realizing that several of us wanted quick access to common color gradients that we frequently plug into the Legend Parameters component, we have now added a component called “Color Gradient Library” to do just this. An image displaying all of these gradients can be found here:https://github.com/mostaphaRoudsari/ladybug/blob/master/resources/gradients.jpgAnd an example file showing how to use the library can be found here:http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Color_LibraryIf you feel that there is a common gradient that is currently missing, feel free to start a discussion on our GH group about it and we should include it soon.
Solar Time Available - The Ladybug Sunpath now includes an option to display solar time, which many have found to be more intuitive and easy to work with when designing with solar geometry. Solar time is also useful for minimizing an east vs west bias that can develop in sunlight hour studies without having to generate sun vectors at very small timesteps.
Monthly/Daily Totals for Hourly Data - The Ladybug “Average Data” component now includes the ability to total the values for months and days (as opposed to timply averaging them). This is useful particularly when you want to get monthly or daily values of total energy or visualize these totals on the monthly bar chart.
Increased IP Functionality - This release of Ladybug includes several more features that assist with converting data for an IP audience including the ability to view an IP Psychrometric or Adaptive Chart by plugging in temperature values in Farenheit as well as a number of and new converter components for the following: Wh to BTU, R-Value SI to R-Value IP, m/s to mph, Liters to Gallons. Note that Honeybee is still largely SI (requiring your Rhino model to be in meters to run energy simulations).
Mesh-to-Hatch and Future BakeIt Plans - Given that the current BakeIt_ option has only been implemented on a few components with relatively minimal use, it has been decided that future implementations of BakeIt_ will provide not just a means of recording parametric results in the Rhino scene but will also support a full pathway to vector-based programs (like Illustrator and Inkscape). As such, BakeIt_ will place text in the Rhino scene as actual editable text (not meshes) and colored meshes will be output as groups of colored hatches (so that they appear as color-filled polygons in vector-based programs). In order to give those interested in this future capability a chance to experiment at the present, a “Mesh-To-Hatch” component has been added to the Extra tab.
HONEYBEE
Fully Functional Microclimate Maps - Finally, after a long and arduous thesis followed by a couple of months of bug-fixing, Chris Mackey is pleased to announce that the ability to produce high resolution temperature maps from EnergyPlus results is complete. Together, these maps account for four key variables that produce microclimatic diversity in and around buildings - MRT variation from different surface temperatures, solar radiation shining directly on occupants, average air temperature diversity, and air temperature stratification. In addition to using these 4 variables to produce high-resolution visuals of temperature, it is also possible to produce maps of thermal comfort by using any of the three primary thermal comfort models in Ladybug (PMV, Adaptive, and Outdoor (UTCI)). Support currently exists to produce maps for both indoor and outdoor conditions and, while the temperature values and indoor comfort values currently produced are highly accurate, the outdoor wind speeds are calculated using the simplified assumptions of EnergyPlus and will be revised to enable more accurate accounting for the effects of wind on outdoor comfort in the next stable release. The whole workflow is broken down into eight components that can all be found under the 9 | Energy Energy tab. For some videos showing some time-lapse thermal renderings made from these tools see this video playlist:https://www.youtube.com/playlist?list=PLruLh1AdY-Sj3ehUTSfKa1IHPSiuJU52AFor the full 150-page documentation of the tools produced for Chris’s thesis, see this link:https://www.dropbox.com/s/k4r4rd279y4td9n/Mackey_Thesis.pdf?dl=0Finally, if you want to dive in and produce some comfort maps for yourself, you can find an example file here for indoor maps:http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Indoor_Microclimate_MapAnd an example file here for outdoor maps:http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Outdoor_Microclimate_Map
Thermal Autonomy / Thermal Comfort Percent - In addition to the new thermal mapping capabilities, this release includes the ability to use these maps to calculate a series of spatial thermal comfort metrics that are meant to mirror the metrics currently used to evaluate daylight (daylight autonomy, UDI, etc.). Specifically, these metrics are the following:Thermal Comfort Percent - The percentage of occupied time that a given point in space is thermally comfortable.Thermal Autonomy - The percentage of occupied time that a given point in space is thermally comfortable without the addition of any heating or cooling energy.Overheated Hours - The percentage of occupied time when a given point is space is too hot to be thermally comfortable.Underheated Hours - The percentage of occupied time when a given point is space is too cold to be thermally comfortable.All of these metrics can be accessed through the “Thermal Autonomy Analysis” component and you can find an example file here:http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Comfort_Autonomy
Energy Balance Visualizations - In order to help understand the flow of energy through Honeybee energy models, it is now possible to completely reconstruct the energy balance calculation of EnergyPlus from the energy simulation results. This is facilitated by the new EnergyPlus “Construct Energy Balance” component and some new features added to the monthly bar chart. See here for an example:http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Energy_Balance
More Geometry Control for Glazing - In order to make it faster to assign several different types of glazing geometries to your energy models, the “AddHBGlz” can now be used to add glazing surfaces to HBzones (not just HBsurfaces). Furthermore, the “Glazing Based on Ratio” component now contains several more inputs that enable you to customize window geometry on orthogonal surfaces, including the ability to set the horizontal distance between windows and the ability to split windows vertically into a lower view window and higher daylight window.
Earth Tube Capability - Thanks to the efforts of Anton Szilasi, it is now possible to assign earth tubes to your energy models in order to test the potential of this powerful passive strategy. See here for an example file:http://hydrashare.github.io/hydra/viewer?owner=antonszilasi&fork=hydra&id=HB_EarthTube
North Input For Annual Daylight - After the toil of having to rotate your model any time you wanted to run an annual daylight analysis, we are happy to announce that the annual daylight recipe now contains a working “North” input.
Honeybee Object Transforms - After realizing that many of us wanted to construct energy models of multi-story buildings by duplicating and moving zones, this capability is now easily facilitated with a set of three components to duplicate and transform your HBObjects. Specifically, this includes a component to move (translate) your HBObject, mirror (reflect) your HBObject, and rotate your HBObject. Using these components ensures that any properties that you have assigned to your original HBObject will be present in the transformed HBOjbect, allowing you to build large energy models very quickly. The three components can currently be found under the WIP tab.
And finally, it is with great pleasure that we welcome Boris Plotnikov to the team. As mentioned in the above release notes, Boris has added a highly advanced solar envelope component to the project.
As always let us know your comments and suggestions.
Enjoy!
Ladybug+Honeybee development team
…