I live on my computer and I even sleep with it, so learning all this is probably within my reach but I'm a complete beginner as of now.
I'm downloading the 32 bit version of rhino 5 since the 64 bit doesn't seem to work with your downloads Jon.
I haven't grasped everything you have made yet Jon I can't even begin to understand what your IFC stuff is actually capable of, but just to be clear I'm not interested in solely being able to tell that something is colliding as there are already software that can do that beautifully. What I want to do is bypass that step altogether by never having collision-checking back and forth go on, even collisions which aren't physical collisions, but rather just violations by code. The simplest way to do this would be to simply make the geometry of the beams 2 feet wider than they are in real life, so that way you could put a light right next to the 'over-sized' beam and it would still be within the rules. But that would be extremely primitive and I'm sure there's a way to do it mathematically.
Just to clarify, I'm the fire sprinkler designer in the architectural circus. The sprinkler designer (me) doesn't really get the luxury of telling the other trades that they're colliding with my stuff and they should move. Rather, I get their drawings, find out I'm colliding with them, and move around them. So it would be of great use to me to have this be automatic - that is, to automatically space my sprinklers the neccesary distance away from all obstructions. There are different spacing rules for different obstructions - walls, beams, open web steel, unit heaters, hvac ducts depending on how wide the ducts are, lights, fans, high rack storage, basically anything that would obstruct the water spray from a sprinkler needs to be taken into account and spaced away from.
It's therefore a very attractive idea to be able to just draw a rectangle (representing the walls of a simple room) for instance, have the sprinklers automatically spaced as far apart as possible within the rectangle according to the rulebooks (to minimize the amount of sprinklers needed which minimizes the material cost of the job).
Then add obstructions inside the rectangle, such as a beam, and have the sprinklers relocate themselves or add new sprinklers to accommodate for the new obstruction.. Keep adding obstructions until you have the realistic 3d model of the room, with the sprinklers spaced accordingly, and you have an up-to-code sprinkler system.
There is one example where sprinklers actually need to be spaced really close to, rather than away from, an object.. and that is the ceiling (sprinklers must be within 12 in of ceiling typically).
If the HVAC guy decides to reroute his ducts right through my sprinklers, then I could draw 3D HVAC ducts (I usually get 2D drawings coming in) going right through the room and the sprinklers would relocate and auto-space away from the ducts, without actually having to tell the HVAC guy he is colliding with me because all that will do is require me to do a redesign anyway.
And presto, the HVAC guy loves me because I didn't complain to him at all and seemingly did all this work by moving around him when all I really did was use the computer to do it, the job gets done much faster and I don't have to worry that I'm going to lose my job in court because I made a silly human error when I was patching my system manually because some HVAC guy made me redesign 12 times in different places.
From what I have been reading from you guys, doing this is possible although (I realize) ambitious. The end result would be vastly increased productivity, less error making, cheaper design cost, etc. Using programs like Rhino, architects are getting more and more funny-shaped buildings and making it difficult for guys like me to make sprinkler systems within the rules, and I see it as an inevitability that computers will be making almost all of the typical design decisions in the future when it comes to life safety systems, I'm just trying to see if it's possible to start implementing this extra aid today.
…
Introduction to Grasshopper Videos by David Rutten.
Wondering how to get started with Grasshopper? Look no further. Spend an some time with the creator of Grasshopper, David Rutten, to learn the
owing a tutorial is easy and adapting the idea of it again - it's not a fuss - i guess my skills are at 1 - since I can not yet stand alone! However I am very determined to nail this program to the ground and be at a 9 by Easter - of course that means a lot of work and hours testing - but I am young and ambitions!
I am a revit user and I just switched over (from the dark rigid side) to rhino because of a simple math problem which has to do with variations and combinations.
I am investigating the form factor for my thesis.
Form factor= building envelope (the area of the facade+the area of the roof+the area of the footprint)/the total area of the floors.
I have started by defining a specific set of parameters such as height, number of floors, maximum total floor area so I can compare the results.
Therefore the floating number will be the facade area - which in the end, considering the height is a constant - ends up being just the length of a certain shape - circle, square, triangle ...
I have done the calculation through excel after extracting from revit but only on simple shapes as follow(the following examples are my own analyzing work):
My problem is: I need a way to get all possible shapes that meet the criteria i put in - which at the moment will be defined by square meters of a floor- that is why galapagos comes in - I need it to make all possible combinations that can be computed that meet the criteria - so then the user(myself or who ever else want to use it) can make an informed choice. I am not looking for a square - circle, sphere or anything I can manually create by just using basic geometry, I am looking for all the possible combination that equal the same area.
(plan view)
After i can solve it for one level - i will constrain that all the levels add up have specific total area - so if a level get's bigger in size another one gets smaller. Again run it through Galapagos and get all possible outcomes (like the sections below)
I am aiming to get an outcome from which you have options to pick out of -> a design process not a specific shape.
You are thinking too complex - not that it's a bad thing - but I am looking for something more simplistic than that. I need a shape - windows and panels are for later use in my process and at this early stage completely irrelevant - and that will be another percentage math problem rather than aesthetics. I just need shapes to morph based on input parameters.
I hope this was an interesting read for you and I really appreciate your patience with me.…
Analysis Tools (LAT). Our plugin has come a long way in the last 4 years and, while the legacy version will still include some small updates and contributions, we are confident in saying that the changes will be far fewer and the plugin more stable in the following months as we switch gears into the LAT effort. I can say personally that (save for a couple of small capabilities) I have made it through my list of critical features and I will hereafter be working on making these features cross-platform, cleanly-implemented, and well-documented in the new Ladybug Analysis Tools software package. As always, you can download the new release from Food4Rhino. Make sure to remove the older version of Ladybug and Honeybee and update your scripts.
The majority of changes with this release represent “icing on the cake” after a long, multi-year effort to connect to the major open source engines and datasets. So, without further adieu, here is the list of the new capabilities added with this release:
LADYBUG
Stereographic Sky Projections - Thanks to several code contributions from Byron Mardas, all Ladybug sky visualizations now support stereographic projections! Such projections are useful for understanding the hemispherical visualizations in a 2D format and they also make it easier to overlay different sky datasets on top of one another. Check here for an example file showing the sun path overlaid with helpful/harmful parts of the sky and see here for an example file using shading masks representing strategies (like an overhang) on top of the helpful / harmful portions of the sun path.
Wind Rose Upgrades - Devang Chauhan has added several new features to the Ladybug wind rose including both visual and numerical outputs of average wind velocity and frequency for each petal of the rose. Not only does this enhance the usefulness of the rose but it also paves the way for the use of the wind rose to set up CFD simulations once Butterfly is released in the near future. The new features of the wind rose can be seen in this hydra example file.
Complete Set of Local Thermal Discomfort Models - After the last release included components to evaluate radiant asymmetry discomfort (which can be modeled using these example files: 1, 2), today’s release completes Ladybug’s suite of local discomfort models from ASHRAE and the ISO by adding components to account for discomfort from cold draft. Specifically, two draft models have been added for different types of situations. The first is an older model published by P.O. Fanger, which was developed through experiments where subjects had cold air blown on the back of their neck (the most sensitive part of the body to draft). While this is useful for understanding a worst-case scenario, it can greatly overestimate the discomfort for cases of draft at ankle level - a more common occurrence that typically results from the tendency of cold air to sink. For this situation, a second draft discomfort model has been included, which is specifically meant to forecast ankle draft discomfort. The model is currently undergoing review for integration into ASHRAE-55 and a publication outlining the derivation of this model can be found here:
Liu, S., Schiavon, S., Kabanshi, A. and Nazaroff, W. (2016), Predicted Percentage Dissatisfied with Ankle Draft. Indoor Air. Accepted Author Manuscript. doi:10.1111/ina.12364 (http://escholarship.org/uc/item/9076254n).
Special thanks is due to Shichao Liu, Toby Cheung and Stefano Schiavon for sharing the model and the results of their study with the development team. The integration of draft models completes the full integration of ASHRAE-55 and EN-15251 with Ladybug. Now, you can rest assured that, if there is a certain thermal comfort standard that you need to fulfill for a given project, you can model it with the ‘bug!
Window-Based Draft Model - With the integration of draft models, the first question that one might ask is “how should these models be applied to typical design cases?” While the (soon-to-be-released) Butterfly plugin for OpenFOAM should open up a Pandora’s box of possible situations, this release of Ladybug includes a simplified downdraft model from cold vertical surfaces, which helps model several typical cases of draft discomfort. The model has been validated across several papers:
Heiselberg, P. (1994). Draught Risk From Cold Vertical Surfaces. Building and Environment, Vol 29, No. 3, 297-301
Manz, H. and Frank, T. (2003). Analysis of Thermal Comfort near Cold Vertical Surfaces by Means of Computational Fluid Dynamics. Indoor Built Environment. 13: 233-242
It has been built into the “Ladybug_Downdraft Velocity” component and has been included in an example file illustrating discomfort from cold windows in winter. The example is intended to show when glazing ratio and window U-Values are small enough to eliminate perimeter heating - a practice that is aesthetically unpleasing, costly to maintain and wasteful in its energy use.
Operative Temperature on the Psychrometric Chart - This is a feature that should have been added a long time ago but we are finally happy to say that the Ladybug_Psychrometric Chart can draw a comfort polygon assuming that the air temperature and radiant temperature are the same value (aka. an operative temperature psychrometric chart). This operative temperature chart is the format that is needed to use the ASHRAE-55 graphical method and is generally a better representation of the range of comfort in cases where one does not intend to hold the radiant temperature constant. This operative temperature capability is now set as the default on the component but you can, of course, still bring back the older comfort polygon by simply plugging in a value for meanRadiantTemperature_.
Contour Map Visualizations - Using the same inputs as the Ladybug_Recolor Mesh component, the new Ladybug_Contour Mesh component allows you to generate contoured color graphics from the results of any analysis. Now, you to maximize the use of your high-resolution studies with contours that highlight thresholds and gradients!
Image Texture Mapping for Colored Meshes - Antonello DiNunzio has added the very useful Ladybug_Texture Maker component, which allows you to bake Ladybug colored meshes with image texture maps (as opposed to the classic method that used colored vertices). This enables the creation of transparent Ladybug meshes, making it even easier to overlay Ladybug graphics with one another and with Rhino geometry:
This component also adds the ability to render Ladybug + Honeybee meshes with other rendering programs like V-Ray and 3ds Max. So you can produce Ladybug graphics like this!
Finally, image-mapped textures are also the format required for gaming and Virtual Reality software like Unity and Augmented Reality programs like Augment. So now you can export your Ladybug meshes all of the way to the virtual world!
Rhino Sun Component - If you have ever had to set up the sun for a rendering plugin and wished that you could just take your Ladybug sun and use that, then you are in luck! Byron Mardas has contributed a component that lets you set the Rhino sun based on your EPW location data, your north direction (if different from the Y-Axis) and any time of day that you want. Not only does this make it easier to coordinate the Rhino sun with your Ladybug visualizations, but you can also use it for real time shadow previews by setting your Rhino view to “Rendered” and scrolling through a slider.
Rendered Ladybug Animations - With both the image texture mapping and the Rhino sun components released, your first thought might be “it would be great if I could use this all in a rendered animation!” Thankfully, Ladybug has added a new component to help you here. The Ladybug_Render View component works in essentially the same way as the Capture View component, allowing you to make a series of images as you animate through a slider. The major benefit here is that it works with both Rhino Render and V-Ray so that animations like this can be produced effortlessly:
Cone of Vision Added - Antonello Di Nunzio has added a component that allows you to visualize various cones of vision in order to help inform your view studies. You can fine tune parameters to include just text-readable or full peripheral vision and use the resulting view cone to constrict the results of your “Ladybug_View Analysis” studies.
Terrain WIP Components Released as the Gismo Plugin - Our friend Djordje has released a new plugin Gismo - a plugin for GIS environmental analysis. As a result the following 5 terrain components: Horizon Angles, Flow Paths, Terrain Shading Mask, Terrain Generator 2, Terrain Analysis, have been removed from Ladybug+Honeybee's WIP section and are added to Gismo.
HONEYBEE
Search, Select, and Import the Hundreds Outputs from EnergyPlus/OpenStudio - Many of the power users in our community know that EnergyPlus is capable of writing several hundred different outputs from the simulation (well beyond what the basic Honeybee result readers can import). While Honeybee has always allowed one to request these outputs by adding them to the simulationOutputs_ of the component, there has not been an official workflow for searching through all of the possible outputs or importing their specific results… until now! We have added the "Honeybee_Read Result Dictionary" component, which allows you to parse the Result Data Dictionary (or .rrd file) that EnergyPlus outputs during every run of a given model. This allows you to see all of the outputs that are available for the model and you can even search through this list to find a particular output that you are interested in. Once you find what you are looking for, simply copy the text output from the component into a panel and and plug this into simulationOutputs_. Then you can use the "Honeybee_Read EP Custom Result" component to bring your custom results into GH after rerunning the simulation. The example file of an evaporative cooling tower shows how to use the workflow to request and import in the energy removed by the tower.
OpenStudio HVAC System Sizing Results - After the full integration of HVAC in the last release, we realized that a number of people wanted to run EnergyPlus models simply to evaluate the size of the Heating/Cooling system in the model (obtained from the EnergyPlus autosize calculation that is run at the start of every simulation). Such a sizing calculation can be a great way to quantify the anticipated savings from a given strategy (like shading) on the size/cost of the building’s HVAC system. To get the results of the sizing calculation, all that one needs to do is connect the output eioFile from the OpenStudio component to the Honeybee_Read HVAC Sizing component. The outputs will indicate the peak heating/cooling loads of each zone (in Watts) as well as the size of each piece of HVAC equipment in the model. The next time that you are on a project that is about to value-engineer out an exterior shading system, use the workflow in the following example file to show that the client will probably end up paying for it with a more expensive HVAC system: Quantifying HVAC Sizing Impact of Shade.
Improved Memory Usage When Building Large Energy Models - As we take the capabilities of Honeybee to larger and larger models, many of us have begun to run up against a particular limitation of our machines: memory. After upgrading our machines to have 32 GBs of RAM, there was only one way left to alleviate the problem: restructure some of the code. Honeybee now uses an enhanced approach that ensures all the previous iterations of Honeybee objects will be removed from the memory once there is a change. In any case, the considerations of memory are definitely something that we intend to improve with the future Honeybee[+] plugin.
Workflow to Import gbXML Files - While GrizzlyBear has been around for several years, enabling us to export Honeybee zones to gbXML, we have gone for quite some time without a workflow to import gbXML files to Honeybee. The new Honeybee_gbXML to Honeybee component addresses this and establishes an easier path to import models from Revit into honeybee. You can read more about the component in this post.
Window Frame Capabilities Added to OpenStudio - After the implementation of LBNL THERM / WINDOW capabilities in the last two releases, there was one final bridge to build in the Honeybee workflow - fully connecting LBNL WINDOW to Honeybee’s OpenStudio workflow. This release of Honeybee will now write all FrameAndDivider objects exported from LBNL WINDOW glazing systems into the energy simulation, enabling you to account for the frame’s thermal bridging effects. As long as the construction is brought in with the Honeybee_Import WINDOW IDF Report component, the frames associated with the construction will be assigned to all windows that have the construction. Finally, it is worth noting that the current Honeybee will also write all glass spectral data as well as gas (or gas mixture) materials into the simulation. This means that essentially all properties of any IDF export that one makes from LBNL WINDOW can be factored into the OpenStudio energy simulation (with the only exception being BSDF materials).
OpenStudio Daylight Sensors Added - In our previous releases of Honeybee, the only means of correctly account for daylight sensors in an energy simulation was to run an annual daylight simulation and use the resulting schedules for the lighting in the energy simulation. However, this can take a lot of time and work to set up and run, particularly if the daylight control (at the end of the day) will be driven by just one sensor per room. Now, we have added another option, which uses OpenStudio/EnergyPlus’s built-in daylight controls. You can assign just a point and an illuminance target on the “Set Zone Thresholds” component and the lighting will be automatically adjusted in the course of the simulation. It should also be noted that the addition of daylight sensors has also coincided with the addition of blind/shade control based on glare. The same sensor point for daylight can be used to drive dynamic shades in the energy simulation based on glare experienced at this point. This example file shows how to set up daylight controls on the EnergyPlus model and check the lighting power results to see the effect.
Better Defaults for Natural Ventilation - After many good people wrote to me informing me that Honeybee overestimates natural ventilation airflow and I wrote back showing the way that I intended natural ventilation to be set up with the component, it dawned on me that I had selected some poor component defaults. Accordingly, this release includes a window-based natural ventilation option on the Set EP Airflow component that corrects for some of the common issues that I have seen. Insect screens are included by default and the component runs a general check to see if wind-driven cross ventilation is possible before auto-assigning it. The component will air on the side of more-conservative, lower airflow rates unless the user overrides the defaults. Finally, it’s worth noting that all of these changes have not affected the freedom of the Custom WindAndStack option on the component. The new defaults can be viewed in this example file.
CFD Results Can be Plugged into Microclimate Maps - In preparation for the (very soon) release of the Butterfly that connects to the OpenFOAM CFD platform, we just wanted to note that all of the microclimate map recipes can now take an input of a csv file with a matrix of CFD results for wind speed. For the time being, we have used these to produce very high-accuracy, high resolution maps of outdoor comfort. There will be more to follow soon!
We should also note that, in the last release I mentioned that we would be phasing out the EnergyPlus component so that all efforts are focused on the OpenStudio component. While I reiterate that all of the features of the EnergyPlus component are available in the OpenStudio component and I encourage everyone to use the OpenStudio component in order to take advantage of its HVAC capabilities, I have come to realize that many prefer to use the EnergyPlus component out of habit and have not yet gotten the time to understand why the OpenStudio component is an improvement over the EnergyPlus component. As a result, we have decided to leave the EnergyPlus component in place for the time being so that everyone has more time to understand this. The future Ladybug Analysis Tools platform will only interact with EnergyPlus through OpenStudio and so it is recommended that everyone use these two components in the Honeybee plugin will serve as an educational resource to understand our current path moving forward with OpenStudio.
Lastly, it is with great pleasure that we welcome Devang Chauhan and Byron Mardas to the developer team! As mentioned previously Devang has contributed several updates to the Ladybug Wind Rose in addition to finding and solving a multitude of bugs in other components. Byron has contributed code that has enabled the previously-mentioned stereographic sky projections along with a better method for running the Ladybug Sky Mask. Finally, Byron has contributed the Rhino Sun component, which allows you to coordinate your Rhino renders with your Ladybug data. Welcome to the Ladybug team, gentlemen!
As always let us know your comments and suggestions. Cheers!
Ladybug Analysis Tools Development Team…
ou will see a list of potential matches, sorted from most relevant to least relevant:
Some components and objects support initialisation codes, which means you can assign certain values directly from the popup box. You can do this by adding an equals symbol after the name and then the value you wish to assign. For example, the [Curve Offset] component allows you to specify the offset distance via the popup box by typing =5 after the offset command:
However the popup box also supports a set of special formats that allow you to create specific objects without even typing their names. As of 0.9.0077 (which hasn't been released yet at the time of writing) you can use the following shortcuts to create special objects. In the notation below optional parts of a format will be surrounded by square brackets and hashes (#) will be used to indicate numeric values. So #,#[,#] means;
at least two numeric values separated by a comma, with an optional second comma and third number.
A complete list of special formats (not all of these are supported yet in 0.9.0076):
"∙∙∙ If the format starts with a double quote, then the entire contents (minus any other double quotes) will be placed into a Text Panel.
//∙∙∙ If the format starts with two forward slashes, then the entire contents will be placed in a Text Panel.
~∙∙∙ If the format starts with a tilde, then the entire contents will be placed in a Scribble object.
#,#[,#] If the format contains two or three numerics separated by commas, a Point parameter will be created with the specified coordinates.
+[#] If the format starts with a plus symbol followed by a numeric, then an Addition component will be created.
-[#] If the format starts with a minus symbol followed by a numeric, then a Subtraction component will be created.
*[#] If the format starts with an asterisk symbol followed by a numeric, then a Multiplication component will be created.
/[#] If the format starts with a forward slash symbol followed by a numeric, then a Division component will be created.
\[#] If the format starts with a backward slash symbol followed by a numeric, then an Integer Division component will be created.
%[#] If the format starts with a percent symbol followed by a numeric, then a Modulus component will be created.
&[∙∙∙] If the format starts with an ampersand symbol, then a Concatenation component will be created.
=[∙∙∙] If the format starts with an equals symbol, then an Equality component will be created.
<[*] If the format starts with a smaller than symbol, then a Smaller Than component will be created.
>[*] If the format starts with a larger than symbol, then a Larger Than component will be created.
[# *] Pi If the format contains the text "Pi" with an optional multiplication factor, then a Pi component will be created.
# If the format can be evaluated as a single numeric value, then a Slider will be created with the specified initial value and sensible™ lower and upper limits.
#<# If the format contains two numerics separated by a smaller than symbol, a Slider with the specified limits will be created. The initial slider value will be equal to the lower limit.
#<#<# If the format contains three numerics separated by a smaller than symbol, a Slider with the specified limits will be created. The initial slider value will be the value in the middle.
#..# If the format contains two numerics separated by two or more consecutive dots, a Slider with the specified limits will be created. The initial slider value will be equal to the lower limit.
#..#..# If the format contains three numerics separated by two or more consecutive dots, a Slider with the specified limits will be created. The initial slider value will be the value in the middle.
#/#/[#] If the format contains two or three numerics separated by forward slashes, a Calendar object will be created. The order of value is day/month/year. If year is omitted then the current year is used. Note that a second slash is required because #/# is interpreted as a number and thus results in a Slider.
#:#[:#] [am/pm] If the format contains at least two numerics separated by a colon, a Clock object is created. Seconds are optional, as are am/pm suffixes.
f([...[,...[,...]]]) [= *]If the format starts with a lower case f followed by an opening bracket, an Expression component is created. A list of comma separated arguments can be provided as inputs, and anything after the optional equals symbol becomes the expression string.
Note that decimal places will be harvested from formats that indicate sliders. I.e. the format 0..2..10 is not the same as 0..2..10.00, as the former will create an integer slider from zero to ten whereas the latter will create a floating point slider with two decimal places from zero to ten.…
Added by David Rutten at 3:24pm on February 18, 2013
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
u might already noticed.
Second great thing is that is quite fast, precise and versatile (for this kind of things); also is way OPEN (meaning you can attach and or interface it with almost anything you can imagine, meaning hardware, and other sw components, etc (like a CNC machine (additive manufacturing toys..) or any sw like C# component)) making a GREAT HUGE difference with almost any other CAD (and CAM sw i must say)
i made a simple fully functional CAM component - highly powerful ! - in a couple of days...
also tested an arduino interface (meaning control over almost any elctronic device out there)... in a matter of hours...
and saw and can easily think about lots and lots of extremely cool usages of this great tool in almost any area ...
So that's why i would suggest - and will do something about for - it (or similar tools) to be teached at first stages of education !
But power comes with responsability. and is far better exploited when your are smart ;)
I think people that uses GH will be n-times as good when they don`t forget manufacturing.
This includes teachers btw....
Interesting thing to account is that all things that GH is great at (a LOT) means reducing dramatically the time spent to model almost anything...
But usually the purpose (unless the objective is just learning or doing some kind of virtual art (both legal stuff btw...;) but guess it might not be your case now and after graduating..)) is to end up by actually building some real 3D stuff...
So what Joseph is poining is key...
If you have a good teacher.. i guess it should pay more and more attention not just at your gh skills but rather the way in which you use the power, versatility and extra time gh (and additive manufacturing tech) saves, to think about how to design the stuff focusing on the ultimately relevant stuff...
optimisation...
So..
I would say that any heat interchanger like the one involved in your thesis, has to deal with fluids.. have to account for some sort of life span (involving cheaper an ideally no maintenance needed along its life...), and of course also critical the costs of manufacturing.
so... be the best one...
use GH smartly ! ie...
account for different profile paths for oil and water.. they're different fluids meaning they have different specific heat, viscosity, blah... and so... they might not even traverse the interchanger at same flow ratio, etc.
So... maybe you want to start by reshaping the grid... (parametrically...!) so you can arbitrarily and dynamically modify and get to see interactively in your definition the areas ratio of sections so as to finaly get to set the "ideal" (meainng optimum) relative areas (sections) ratio of oil to water paths... (or whatever other fluids could be !), and the material also...
Secondly you might also consider that triangles might not be well suited for the conduit sections because are not the best shape to carry most fluids... (hoses are of circular sections...worst case are kinda rectangular with rounded corners..;) not only because the're easy to manufacture but also because they minimise (optimize) flowing energy losses AND are less prone to (ie salt or debree deposits in the interior) ). so think about rounded shapes, of if you want some regular polygons stuff but 5 or more faces...kinda circular...got it ?
I love bees by the way..
and if you happen to need more interchange area (obviously another (and probably the #1 key one) figure you should be displaying interactively in your definition ) you can always add some more extrusion length...
third... the twisting stuff is cool... (artistically ;)) but i 100% agree with Joseph is far likely to involve higer costs for manufacturing with no clear benefit on surface maximization... and most probably some other losses in added friction to the flow of fluids (meaning higher costs for pumping, etc...)...
fourth...
consider the area, (then the volume!) of the "building material"... you should optimise that too ! so this could be another one of your interactive displays...
in this case... you not only can see optimisation by reducing the amount of materials to build your interchanger...
but you can also notice that if the "building tech" involves the well and common additive manufacturing process of extrusion deposits... that surface area, and that extrusion length, meaning volume and cost of raw material, also mean TIME to manufacture... and i guess you teacher will find good for you to consider and mention that one too...
fifth...
finally (for now hehe), and globally most important in the short term :)
if the objective of yor teacher is for you just to learn GH and impress him and the rest of the world then, ok, do the twist the swirl and imagine all kind of sea star and or ondulated conduit sections (maybe some recursive forms (fractals...) like snowflakes... or any n-arms (mutant !) starfishes shapes) but make sure you first get to know and validate what it will be the objectives of your evaluator...
.. in the near end this is all about passing your thesis while learning GH while having fun.. isn't it ?
go for it and best of luck !
ps: for the mid and long term.. some day take a look at linear optimisaton if you already didn't.
i think GH is a great tool to try out some linear optimisation stuff directly linking geometry related figures (areas, volumes...) along with costs figures !...
I haven't seen anything like that yet (but since i'm only a few months old in gh, i think is likely to already be something or this stuff out there. )
If not... well you can always be the first !
(and this particular case of your thesis is a great example (few key variables) to try out "automatic optimisation")
https://en.wikipedia.org/wiki/Simplex_algorithm
that... by the way...has lots to do with spatial geometry...
…
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
…