housing for an LED PCB. The object is a parametric series of discs with an opening inside made up of a mirrored curve [drawn in Rhino, mirrored in GH]
It is madde up of N number of discs which can be varied through the distance between the circular outline using a divided curve [straight line in GH]. The length of the object can be varied using a length parameter, and the shape using a graph mapper.
I've chosen to cap the end two discs by creating two sets of outlines. One set has the central aperture cutout for the PCB, whereas the other set is a trimmed circle [achieved using the "trim box" layer profile in Rhino]
I then cull the outer two curves from one array, and the inner N-2 curves from the inner array.
The final outcome I am after is to create the housing as both an STL and a 2d template for laser cutting. This is a learning exercise for me as well as a cool project.
I had it working OK, but then I adjusted the profile for the PCB and joined it and now it is giving me some grief. I am sure the answer is obvious. The problem is the PCB profile is made up of 3 polycurves, whereas the disc profile is one planar curve. I have no problem using the flatten option so there are only N sets of curves coming out of the "Join Curves" component. However when I cull the curves, the planar curves making up the exterior edge cull fine, but the interior curves [the joined, PCB profile] culls in a different [irrational?] order to what I would expect. If I connect the single planar curve to the culls section, it works fine, but the joined line section just won't play.
In the instance uploaded N = 10, based on spacings. And index white it appears that 0 and 9 are diagonal to what I'd expect, although if you fiddle with the values they go all over the place.
Can someone please help me and explain what I did wrong? Files are attached... I have screen grabbed the relevant section, but it is grouped in red and labelled as "problem child" :)
Many thanks for your help, sorry if this looks like a clusterf**k, first time for everything... any advice very much appreciated, not just relating to my problem.
All the best
Nick…
ree-form surface or polysurface.
As mentioned in the discussion title, I would like to create a look, similar to the beijing water cube, but not on a planar surface. And also the bubbles should only be very slightly tensioned.
I have tried 3 methods, they are all in the .gh file and best result ( smoothness of bubble) gives the "extrude to point" method. The problem is, the resulting mesh borders are not even close to the original surface, because of u,v setting to 1. I want the bubbles to have the original outline as border line. I don´t know if this is even possible.
The other methods are not very satisfying. ( I tried "inflate mesh" and third method was to patch the surface and point)
If somebody took a look in the file, I would be very glad.
Also there is another problem with the offset of the voronoi curves. Depending on the offset distance, the algorythm gives bad results. I used the clipper plugin, and have currently seen also pics of lines sticking out of the offset. Is there any solution for this?
For the bubbles, I have also seen similar solutions in the forum, but don´t know how to achieve them.Here is the pic of this solution, also posted in this forum and the discussion is here:http://www.grasshopper3d.com/forum/topics/non-planar-voronoi-definition?commentId=2985220%3AComment%3A832079The result I see here, has rounded borders of the voronoi extrusion, which I would not like to get. So I hope this is enough information.thx a lot.
Merken…
nts for Ladybug too. They are based on PVWatts v1 online calculator, supporting crystalline silicon fixed tilt photovoltaics.
You can download them from here, or use the Update Ladbybug component instead. If you take the first option, after downloading check if .ghuser files are blocked (right click -> "Properties" and select "Unblock").
You can download the example files from here.
Video tutorials will follow in the coming period.
In the very essence these components help you answer the question: "How much energy can my roof, building facade, solar parking... generate if I would populate them with PV panels"?
They allow definition of different types of losses (snow, age, shading...) which may affect your PV system:
And can find its optimal tilt and orientation:
Or analyse its performance, energy value, consumption, emissions...
By Djordje Spasic and Jason Sensibaugh, with invaluable support of Dr. Frank Vignola, Dr. Jason M. Keith, Paul Gilman, Chris Mackey, Mostapha Sadeghipour Roudsari, Niraj Palsule, Joseph Cunningham and Christopher Weiss.
Thank you for reading, and hope you will enjoy using the components!
EDIT: From march 27 2017, Ladybug Photovoltaics components support thin-film modules as well.
References:
1) System losses:
PVWatts v5 Manual, Dobos, NREL, 2014
2) Sun postion equations by Michalsky (1988):
SAM Photovoltaic Model Technical Reference, Gilman, NREL, 2014
edited by Jason Sensibaugh
3) Angle of incidence for fixed arrays:
PVWatts Version 1 Technical Reference, Dobos, NREL, 2013
4) Plane-of-Array diffuse irradiance by Perez 1990 algorithm:
PVPMC Sandia National Laboratories
SAM Photovoltaic Model Technical Reference, Gilman, NREL, 2014
5) Sandia PV Array Performance Module Cover:
PVWatts Version 1 Technical Reference, Dobos, NREL, 2013
6) Sandia Thermal Model, Module Temperature and Cell Temperature Models:
Photovoltaic Array Performance Model, King, Boys, Kratochvill, Sandia National Laboratories, 2004
7) CEC Module Model: Maximum power voltage and Maximum power current from:
Exact analytical solutions of the parameters of real solar cells using Lambert W-function, Jain, Kapoor, Solar Energy Materials and Solar Cells, V81 2004, P269–277
8) PVFORM version 3.3 adapted Module and Inverter Models:
PVWatts Version 1 Technical Reference, Dobos, NREL, 2013
9) Sunpath diagram shading:
Using sun path charts to estimate the effects of shading on PV arrays, Frank Vignola, University of Oregon, 2004
Instruction manual for the Solar Pathfinder, Solar Pathfinder TM, 2008
10) Tilt and orientation factor:
Application for Purchased Systems Oregon Department of Energy
solmetric.com
11) Photovoltaics performance metrics:
Solar PV system performance assessment guideline, Honda, Lechner, Raju, Tolich, Mokri, San Jose state university, 2012
CACHE Modules on Energy in the Curriculum Solar Energy, Keith, Palsule, Mississippi State University
Inventory of Carbon & Energy (ICE) Version 2.0, Hammond, Jones, SERT University of Bath, 2011
The Energy Return on Energy Investment (EROI) of Photovoltaics: Methodology and Comparisons with Fossil Fuel Life Cycles, Raugei, Fullana-i-Palmer, Fthenakis, Elsevier Vol 45, Jun 2012
12) Calculating albedo: Metenorm 6 Handbook part II: Theory, Meteotest 2007
13) Magnetic declination:
Geomag 0.9.2015, Christopher Weiss…
.
Things have been working swimmingly in many areas of the plugin, but one particular problem has been tough to solve. I have two components that are trying to read/write to the same memory at the same time, causing Rhino exceptions and crashes.
The conflicts appear to be happening between two components -- one is a "Layer Events Listener" that reports essentially what type of layer event just happened. The other is a "Set Layer Visibility" component that toggles the visibility of a list of layers.
The code:
public class LayerTools_LayerEventsListener : GH_Component { /// <summary> /// Initializes a new instance of the LayerTools_LayerListener class. /// </summary> public LayerTools_LayerEventsListener() : base("Layer Events Listener", "Layer Listener", "Get granular information about the layer events happening in the Rhino document.", "Squirrel", "Layer Tools") { }
/// <summary> /// Registers all the input parameters for this component. /// </summary> protected override void RegisterInputParams(GH_Component.GH_InputParamManager pManager) { pManager.AddBooleanParameter("Active", "A", "Set to true to listen to layer events in the Rhino document.", GH_ParamAccess.item, false); pManager.AddTextParameter("Exclusions", "E", "Provide a list of exclusions to stop reading specific events (Added, Deleted, Moved, Renamed, Locked, Visibility, Color, Active).", GH_ParamAccess.list); pManager[1].Optional = true; }
/// <summary> /// Registers all the output parameters for this component. /// </summary> protected override void RegisterOutputParams(GH_Component.GH_OutputParamManager pManager) { pManager.AddBooleanParameter("Initialized", "I", "Whether the listener changed from passive to active.", GH_ParamAccess.item); pManager.AddTextParameter("Document Name", "doc", "Name of the Rhino document that is changing.", GH_ParamAccess.item); pManager.AddTextParameter("Layer Path", "path", "Path of the modifed layer.", GH_ParamAccess.item); pManager.AddIntegerParameter("Layer Index", "ID", "Index of the modified layer.", GH_ParamAccess.item); pManager.AddIntegerParameter("Sort Index", "SID", "Sort index of the modified layer.", GH_ParamAccess.item); pManager.AddTextParameter("Event Type", "T", "Type of the modification.", GH_ParamAccess.item); pManager.AddBooleanParameter("Added", "A", "If the layer has been added.", GH_ParamAccess.item); pManager.AddBooleanParameter("Deleted", "D", "If the layer has been deleted.", GH_ParamAccess.item); pManager.AddBooleanParameter("Moved", "M", "If the layer has been moved.", GH_ParamAccess.item); pManager.AddBooleanParameter("Renamed", "R", "If the layer has been renamed.", GH_ParamAccess.item); pManager.AddBooleanParameter("Locked", "L", "If the layer locked setting has changed.", GH_ParamAccess.item); pManager.AddBooleanParameter("Visibility", "V", "If the layer's visibility has changed.", GH_ParamAccess.item); pManager.AddBooleanParameter("Color", "C", "If the layer's color has changed.", GH_ParamAccess.item); pManager.AddBooleanParameter("Active", "Act", "If the active layer has changed.", GH_ParamAccess.item); }
/// <summary> /// This is the method that actually does the work. /// </summary> /// <param name="DA">The DA object is used to retrieve from inputs and store in outputs.</param> protected override void SolveInstance(IGH_DataAccess DA) { bool active = false; List<string> exclusions = new List<string>();
DA.GetData(0, ref active); DA.GetDataList(1, exclusions);
RhinoDoc thisDoc = null;
bool initialize = false;
string dName = null; string activePath = null; int layerIndex = -1; int sortIndex = -1; string eventType = null; bool added = false; bool deleted = false; bool moved = false; bool renamed = false; bool locked = false; bool visibility = false; bool color = false; bool current = false;
if (active) { thisDoc = RhinoDoc.ActiveDoc;
initialize = (!previouslyActive) ? true : false;
RhinoDoc.LayerTableEvent -= RhinoDoc_LayerTableEvent; RhinoDoc.LayerTableEvent += RhinoDoc_LayerTableEvent; previouslyActive = true;
} else {
RhinoDoc.LayerTableEvent -= RhinoDoc_LayerTableEvent; previouslyActive = false; }
if (ev != null) { dName = ev.Document.Name; layerIndex = ev.LayerIndex; eventType = ev.EventType.ToString();
if (!exclusions.Contains("Active")) { if (ev.EventType.ToString() == "Current") { // active layer has just been changed current = true; }
}
if (!exclusions.Contains("Moved")) { if (ev.EventType.ToString() == "Sorted") { // active layer has just been changed moved = true; }
}
if (!exclusions.Contains("Added")) { if (ev.EventType.ToString() == "Added") { // layer has just been added activePath = ev.NewState.FullPath; added = true; }
}
if (!exclusions.Contains("Active")) { if (ev.EventType.ToString() == "Deleted") { // layer has just been added
deleted = true; } }
if (ev.EventType.ToString() == "Modified") { // layer has been modified activePath = ev.NewState.FullPath;
//skip sortindex eventType = ev.EventType.ToString();
if (ev.OldState != null && ev.NewState != null) { if (!exclusions.Contains("Locked")) { if (ev.OldState.IsLocked != ev.NewState.IsLocked) locked = true;
} if (!exclusions.Contains("Visibility")) { if (ev.OldState.IsVisible != ev.NewState.IsVisible) visibility = true; }
if (!exclusions.Contains("Moved")) { if (ev.OldState.ParentLayerId != ev.NewState.ParentLayerId) moved = true; }
//if (ev.OldState.SortIndex != ev.NewState.SortIndex) moved = true; if (!exclusions.Contains("Renamed")) { if (ev.OldState.Name != ev.NewState.Name) renamed = true; }
if (!exclusions.Contains("Color")) { if (ev.OldState.Color != ev.NewState.Color) color = true; } }
} }
DA.SetData(0, initialize); DA.SetData(1, dName); DA.SetData(2, activePath); DA.SetData(3, layerIndex); DA.SetData(4, sortIndex); DA.SetData(5, eventType); DA.SetData(6, added); DA.SetData(7, deleted); DA.SetData(8, moved); DA.SetData(9, renamed); DA.SetData(10, locked); DA.SetData(11, visibility); DA.SetData(12, color); DA.SetData(13, current);
}
static bool previouslyActive = false; Rhino.DocObjects.Tables.LayerTableEventArgs ev = null;
void RhinoDoc_LayerTableEvent(object sender, Rhino.DocObjects.Tables.LayerTableEventArgs e) { ev = e;this.ExpireSolution(true); }
And for the layer visibility component:
public LayerTools_SetActiveLayer() : base("Set Active Layer", "SetActiveLayer", "Set the active layer in the Rhino document.", "Squirrel", "Layer Tools") { }
/// <summary> /// Registers all the input parameters for this component. /// </summary> protected override void RegisterInputParams(GH_Component.GH_InputParamManager pManager) { pManager.AddBooleanParameter("Active", "A", "Set to true to change the active layer in Rhino.", GH_ParamAccess.item, false); pManager.AddTextParameter("Path", "P", "Full path of the layer to be activated.", GH_ParamAccess.item); }
/// <summary> /// Registers all the output parameters for this component. /// </summary> protected override void RegisterOutputParams(GH_Component.GH_OutputParamManager pManager) { pManager.AddIntegerParameter("Layer ID", "ID", "Index of layer that has been activated.", GH_ParamAccess.item); pManager.AddBooleanParameter("Status", "St", "True when the layer has been activated.", GH_ParamAccess.item); }
/// <summary> /// This is the method that actually does the work. /// </summary> /// <param name="DA">The DA object is used to retrieve from inputs and store in outputs.</param> protected override void SolveInstance(IGH_DataAccess DA) { bool active = false; string path = "";
if (!DA.GetData(0, ref active)) return; if (!DA.GetData(1, ref path)) return;
int layer_index = -1; bool status = false;
if (path != null) {
Rhino.RhinoDoc doc = Rhino.RhinoDoc.ActiveDoc; Rhino.DocObjects.Tables.LayerTable layertable = doc.Layers;
layer_index = layertable.FindByFullPath(path, true);
if (layer_index > 0) { // if exists RhinoDoc.ActiveDoc.Layers.SetCurrentLayerIndex(layer_index, true); status = true; } }
DA.SetData(0, layer_index); DA.SetData(1, status); }
Now originally I was getting exceptions when changing multiple layers' visibility properties, which would cause the Event Listener to fire and try to read the Visibility property before the memory has been released by the Set Layer Visibility component. That led me to add an "Exceptions" input, that would allow me to disable the reading of Visibility events at the source in the Layer Events listener. That helped me manage about 95% of the crashes I was getting, but I still get strange crashes in other event properties, even when that property shouldn't be affected. For instance, I am getting a crash here on the Name property in the event from the delegate function, even though I am only changing Visibility at any one time:
I have a few ideas but they all seem pretty hacky. One is to try to set a flag that is readable by any component in the plugin -- so that the event listener can see if a "set" component is currently running and abort before causing an exception. The other is creating a delay in the event listener, somthing like 200ms, to allow any set components to finish what they are doing before reading the event. Neither seems super ideal.
Any ideas?
Thanks,
Marc
…
nd improvements. Many of the new features and components announced in the last release have become stable and have emerged from their WIP section. Additionally, after two years of work, we are happy to announce that we finally have full support of an OpenStudio connection within Honeybee, which has ushered in a whole host of new features, notably the modelling of detailed HVAC systems. 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.
LADYBUG
1 - Solar Hot Water Components Out of WIP
After much beta-testing, bug-fixing, and general development, all of the Photovoltaic and Solar Hot Water components are now fully out of WIP! The main component is based on a Chengchu Yan's publication. Components have been added to Ladybug thanks to the efforts of Chengchu Yan and Djordje Spasic.. See Djorje’s original release post of the solar hot water components for more information on the components that just made it out of WIP.
2 - New Terrain Shading Mask Released in WIP
In addition to Djordje’s prolific addition of renewable energy components, he has also contributed a widely-useful component to generate terrain shading masks, which account for the shading of surrounding mountains/terrain in simulations. While initially added to assist the solar radiation radiation and renewable energy components, the component will undergo development to optimize it for energy and daylight simulations over the next few months. Another new component called Horizon Angles can be used to visualize and export horizon angles. You can test them out now by accessing them in the WIP section. For more information, see Djordje’s release post on the GH forum here.
3 - New Mesh Selector Component
After realizing that the Optimal Shade Creator component has applications to a whole range of analyses, it has now been re-branded as the Mesh Selector and has been optimized to work easily with these many analyses. Specifically, the component selects out the portion of a mesh that meets a given threshold. This can be the portion of a shade benefit analysis meeting a certain level of shade desirability, the portion of a radiation study meeting a certain level of fulx, the portion of a daylight analysis meeting a certain lux threshold, and much more!
4 - Solar Adjusted Temperature Now Includes Long Wave Radiation
Thanks to a question asked by Aymeric and a number of clarifications made by Djordje Spasic, the Solar Adjusted Temperature component now includes the ability to account for long-wave radiative loss to the sky in addition to it original capability to account for short wave radiation from the sun. As such, the component now includes all capabilities of similar outdoor comfort tools such as RayMan. The addition of this capability is also paralleled by the addition of a new horizontalInfraredRadiation output on the ImportEPW component. See the updated solar adjusted example file hereto see how to use the component properly.
5 - Support for both Log and Power Law Wind Profiles
In preparation for the future release of the Butterfly CFD-modelling insect, the Ladybug Wind Profile component now includes the option of either power law or log law wind profiles, which are both used extensively in CFD studies. Thanks goes to Theodoros Galanos for providing the formulas!
6 - New Radiant Asymmetry Comfort Components
Prompted by a suggestion from Christian Kongsgaard, Ladybug now includes components to calculate radiant asymmetry discomfort! For examples of how to use the components see this example file for spatial analysis of radiant asymmetry discomfort and this example for temporal analysis.
7 - Pedestrian Wind Comfort Component Released in WIP
In preparation for the impending release of the butterfly CFD-modelling insect, Djordje Spasic with assistance from Liam Harrington has contributed a component to evaluate outdoor discomfort and pedestrian safety. The component identifies if certain areas around the building are suitable for sitting, building entrances-exits, window shopping... based on its wind microclimate. Dangerous areas due to high wind speeds are also identified.You can check it out now in the WIP section.
HONEYBEE
1 - New HVAC Systems and Full OpenStudio Support
After a significant amount of development on the part of the OpenStudio team and two years of effort on the part of LB+HB developers, we (finally!) have full support for an OpenStudio connection within Honeybee. By this, we mean that any energy simulation property that can be assigned to a HBZone will be taken into account in the simulation run by the OpenStudio component. The connection to OpenStudio has brought with it several new capabilities. Most notably, you can now assign full HVAC systems and receive energy results in units of electricity and fuel instead of simple heating and cooling loads. This Honeybee release includes 14 built-in HVAC template systems that can be assigned to the zones, each of which can be customized:
0. Ideal Air Loads 1. PTAC | Residential 2. PTHP | Residential 3. Packaged Single Zone - AC 4. Packaged Single Zone - HP 5. Packaged VAV w/ Reheat 6. Packaged VAV w/ PFP Boxes 7. VAV w/ Reheat 8. VAV w/ PFP Boxes 9. Warm Air Furnace - Gas Fired 10.Warm Air Furnace - Electric 11.Fan Coil Units + DOAS 12.Active Chilled Beams + DOAS 13.Radiant Floors + DOAS 14.VRF + DOAS
Systems 1-10 are ASHRAE Baseline systems that represent much of what has been added to building stock over the last few decades while systems 11-14 are systems that are commonly being installed today to reduce energy use. Here is an example file showing how to assign these systems in Honeybee and interpret the results and here is an example showing how to customize the HVAC system specifications to a wide variety of cases. To run the file, you will need to have OpenStudio installed and you can download and install OpenStudio from here.
In addition to these template systems within Honeybee, the OpenStudio interface includes hundreds of HVAC components to build your own custom HVAC systems. OpenStudio also has a growing number of user-contributed HVAC system templates that have been integrated into a set of scripts called "Measures" that you can apply to your OpenStudio model within the OpenStudio interface. You can find these system templates by searching for them in the building components library. Here is a good tutorial video on how to apply measures to your model within the OpenStudio interface. Honeybee includes a component that runs these measures from Grasshopper (without having to use the OpenStudio interface), which you can see a demo video of here. However, this component is currently in WIP as OpenStudio team is still tweaking the file structure of measures and it is fairly safe to estimate that, by the next stable release of Honeybee, we will have full support of OpenStudio measures within GH.
2 - Phasing Out IDF Exporter
With the connection to OpenStudio now fully established, this release marks the start of a transition away from exporting directly to EnergyPlus and the beginning of Honeybee development that capitalizes on OpenStudio’s development. As such THIS WILL BE THE LAST STABLE RELEASE THAT INCLUDES THE HONEYBEE_RUN ENERGY SIMULATION COMPONENT.
The Export to OpenStudio component currently does everything that the Run Energy Simulation component does and, as such, it is intended that all GH definitions using the Run Energy Simulation component should replace it with the OpenStudio component. You can use the same Read EP Result components to import the results from the OpenStudio component and you can also use the same Energy Sim Par/Generate EP Output components to customize the parameters of the simulation. The only effective difference between the two components is that the OpenStudio component enables the modeling of HVAC and exports the HBZones to an .osm file before converting it to an EnergyPlus .idf.
For the sake of complete clarity, we should state that OpenStudio is simply an interface for EnergyPlus and, as such, the same calculation engine is under the hood of both the Export to OpenStudio component and the Run Energy Simulation component. At present, you should get matching energy simulation results between the Run Energy Simulation component and a run of the same zones with the OpenStudio component (using an ideal air system HVAC).
All of this is to say that you should convert your GH definitions that use the Run Energy Simulation component to have the OpenStudio component and this release is the best time to do it (while the two components are supported equally). Additionally, with this version of Honeybee you will no longer need to install EnergyPlus before using Honeybee and you will only need to install OpenStudio (which includes EnergyPlus in the install).
3 - New Schedule Generation Components
Thanks to the efforts of Antonello Di Nunzio, we now have 2 new components that ease the creation of schedule-generation in Honeybee. The new components make use of the native Grasshopper “Gener Pool” component to give a set of sliders for each hour of the day. Additionally, Antonello has included an annual schedule component that contains a dictionary of all holidays of every nearly every nation (phew!). Finally, this annual schedule component can output schedules in the text format recognized by EnergyPlus, which allows them to be written directly into the IDF instead of a separate CSV file. This will significantly reduce the size of files needed to run simulations and can even reduce the number of components on your canvas that are needed to add custom schedules. For more information, see Antonello’s explanatory images here and Antonello's example file here. You can also see a full example file of how to apply the schedules to energy simulations here.
4 - EnergyPlus Lookup Folder, Re-run OSM/IDF, and Read Result Dictionary
With the new capabilities of OpenStudio, we have also added a number of components to assist with managing all of the files that you get from the simulation. In particular, Abraham Yezioro has added a Lookup EnergyPlus Folder component that functions very similarly to the Lookup Daylight Folder component. This way, you can run an Energy simulation once and explore the results separately. Furthermore, we have added components to Re-Run OpenStudio .osm files or EnergyPlus .idf files within Grasshopper. These components are particularly useful if you edit these .osm or .idf files outside of Honeybee and want to re-run them to analyze their results in Grasshopper. Lastly, a component has been added to parse the .rdd (or Result Data Dictionary) file that EnergyPlus produces, enabling you to see all of the possible outputs that you can request from a given simulation.
5 - Electric Lighting Components Out of WIP
After Sarith Subramaniam’s initial components to model electric lights with Radiance in the last release, we are happy to report that they have been fully tested and are out of WIP. Improvements include support for all types of light fixture geometries and the ability to use the components in a more “Grasshoppery” list-like fashion. See Sarith’s original release post for more information and several example files showing how to use the components can be found here. 1 , 2 , 3 .
6 - Improvements to THERM Components
A number of bug fixes and improvements have been made to the THERM components in order to make their application more flexible and smooth. Special thanks is due to Derin Yilmaz , Mel King , Farnaz , Ben (@benmo1) , and Abraham Yezioro for all of the great feedback in the process of improving these components.
7 - HBObject Transform Components
After some demand for components that can ease the generation of buildings with modular zone types, two components to transform HBObjects with all of their properties have been added to the 00 | Honeybee section. The components allow you to produce copies of zones that are translated or rotated from the original position.
8 - Comfort Maps Supports PET and Integration of CFD Results
Thanks to the addition of the ‘Physiological Equivalent Temperature’ (PET) component by Djordje Spasic in the last stable release, it is now possible to make comfort maps of PET with Honeybee. PET is particularly helpful for evaluating OUTDOOR comfort with detailed wind fields at a high spatial resolution. As such, the new PET recipe has also been optimized for integration with CFD results. The windSpeed_ input can now accept the file path to a .csv file that is organized with 8760 values in each column and a number of columns that correspond to the number of test points. Components to generate this csv from Butterfly CFD results will be coming in later releases. Stay tuned!
As always let us know your comments and suggestions.
Enjoy!Ladybug Analysis Tools Development Team
…
to incorporating math and geometry in computational design education, Paneling Tools
Marlo Ransdell, PhD Creative Director, at FSU , Digital Fabrication in Design Research and Education
Andy Payne, LIFT architects | Harvard GSD | FireFly
Jay H Song, Chair, Jewelry School of Design, Jewelry as Personal Expression, Extra+Ordinary@Jewelry.com
Pei- Jung (P.J.) Chen, Professor of Jewelry, SCAD
Gustavo Fontana, designer/co-founder nimbistand, Diseñar, desarrollar y comercializar productos por tu cuenta.
Joe Anand, CEO MecSoft Corporation, RhinoCAM
Julian Ossa, Chair, Industrial Design Director, Diseño – Una opción de vida a todo vapor!, UPB
Minche Mena, SHINE Architecture, Principal
J. Alstan Jakubiec, Daylighting and Environmental Performance in Architectural Design Solemma, LLC
Carlos Garnier R&D Director / Jaime Cadena – General Director, Plug Design, www.plugdesign.com.mx
Mario Nakov, www.chaosgroup.com [ V-Ray ]
Andres Gonzalez, RhinoFabStudio
Workshops:
o) Paneling Tools
o) RhinoCAM
o) Rhinology in Design, for Jewelry
o) Footwear
o) V-Ray: Jewelry Design
o) V-Ray: Architects and Industrial Designers
o) FireFly
o) J. Alstan Jakubiec, DIVA
The cost for each workshop or the Lectures is 95.0 US$
To register:
WORK-SHOPS April 2 - RHINO DAY
WORK-SHOPS April 3 - RHINO DAY
REGISTRATION RHINO DAY
NOTE: All students and faculty members that register to this event, will receive a Rhino 5 Educational License at the event.
…
- nickname is rather the best approach - and not on active group, but that's irrelevant anyway).
Step back (assuming that you are talking about the "Tens_from_random_blah_blah" definition):
1. Engineering is the art of demystifying (or we are promising that anyway, he he). This means that you start defining (better: outlining) some topology for things based on some "generic" rules (like the ones applied for the masts,cables,cones etc etc). These things are kept in some kind of structure (Lists, DataTrees etc). Things are few in 99.99999% of cases (i.e. : even the biggest membrane "module" has, say, 20-50 masts per "module").
2. Then ... handling things "individually" (mostly modifying) becomes the most critical part. See this (an x "possible" solution by combining a myriad of "options" : a no cones membrane solution, in plain English):
3. But the above is impossible (for more than obvious reasons). You should deploy masts in some high/low sequence in order to achieve some meaningful convex/concave formation that could work.
4. This "works" : 5. This doesn't:
6. This works partially (the formation at the back is "flat" == undo able):
7. This is utterly kitsch (and faulty as the case6 - the back portion):
So it's quite obvious that without a (quite complex) capability to individually control things (in this occasion : mast heights) the whole definition is a waste of computer time. Additionally the more the solution is "demystified" (some curve is defined, some random points are created, some masts are in place, some cables appear etc etc) the more additional constrains are required in order to "narrow" the possibilities (In plain English : sliders should control other sliders as regards their min/max values, true/false, you/me etc etc).
Remember that we are talking about ONE (mast height) out of a myriad things that you should control "manually" (it's utterly pointless to mastermind some kind of "generic" rules - or use naive attractors etc etc) .You'll see the difference when I'll completely reform the definition by adding individual control upon anything.
PS: what about the blocks? (the real life stuff that actually make any solution possible). Can you imagine a 2nd set of "restrictions" imposed by "a child to his parent"? (Assembly/Component modeling , that is).
more soon
…
the results myself and I am open to changing the name/description of the input based on what you have found here. modulateFlowOrTemp is not the best name for what seems to be going on and we should change it to reflect more what is happening in the IDF.
Here is how I am understanding the results of the different cases:
1) When the variable flow option is selected (and the outdoor air set to "None"), the heating and cooling of the space seems to happen only through re-circulation of the indoor air. My comparison to a VAV system was not appropriate and perhaps it would be better to compare it to a window air conditioner or a warm air furnace, which, as far as I understand, only re-circulate indoor air and do not bring in outside air.
2) My reasoning for the name modulateFlowOrTemp came mostly from my realization that the supply air temperature remained within the defined limits when the variable flow option is selected (and the outdoor air set to "None"). When the outdoor air was set to Maximum or Sum, the supply air temperature went way out of the temperature limits that I initially set. I realize now that the flows are varying in both cases and the name of the input really must change.
3) I think that the reason why we don't see any effect from the air side economizer is because the heating/cooling energy results that you get from an ideal air system are just the sum of the sensible and the latent heat added/removed from the zone by the system. This value of heat added or removed from the zone does not change whether the added/removed heat comes from outside air or from a cooling/heating coil. Since there is no cooling coil or boiler or chiller in an ideal air system, there is no way to request an output of the energy added/removed by such a coil or chiller as opposed to that removed/added by outside air. In other words, the air side economizer option on the ideal air system is practically useless because it does not help us differentiate the cooling that comes from the outside air vs. that which comes from a coil. All that it does is change the outdoor air fraction while keeping the reported cooling/heating values the same.
Please let me know if you think that this explanation makes sense, Burin and, in light of all this, I am very interested in your suggestions.
From my own perspective, I am now convinced that the default should definitely have the outside air requirements set to "None" since, otherwise, we cannot distinguish cooling/heating that happens from addition of outside air and that which must be supplied by a coil. At least when we get rid of the outside air requirement, we can be sure that the ideal air system values are only showing heating/cooling from a coil or HVAC system.
I have decided to remove the airsideEconomizer input since it seems to give misleading expectations. I am going to recommend here on out that, if you want to estimate the effect of increasing outside air on cooling, you should use the "Set EP Airflow" component, use fan-driven natural ventilation, and you should connect a custom CSV schedule of airflow. You will have to create such a schedule with native GH components using the outside air temperature, your zone setpoints, and the times that you are cooling in your initial run of E+. Either you do this or you set up a full-blown system with OpenStudio.
I have also decided to get rid of the heatRecovery input since it seems like this will also produce misleading expectations by the same logic.
Lastly, I am going to change the name of the modulateFlowOrTemp_ input to outdoorAirReq_. The default will be to have no indoor air requirement as stated above but you can input either "maximum" or "sum" to have the IDF run accordingly.
Let me know if this sounds good or if you have suggestions. Updated GH file attached. The github has the new Ideal Air Loads component. Make sure that you have sync correctly and restart GH after updating your components.
-Chris…
with this machine.
As Jason says, Rhino and Grasshopper are mainly single-threaded, so I prioritized single core speed and got an i7 4790k, which comfortably overclocks to 4.7GHz (with a decent air cooler, but no fancy liquid cooling).
The Kangaroo2 solver is actually multi-threaded now, but the difference this makes is not great as you might imagine. Using 4 cores is certainly nowhere near 4 times faster, because although parts of the calculation are easily parallelized, everything still needs to be recombined at each iteration, and this is usually the bottleneck. I think there is still room for some improvement in how it is multi-threaded, but I wouldn't hold your breath for any massive changes on this front soon.
I'd be interested to know how the performance scales with the Xeon chips (more cores, significantly more expensive, but relatively low clock speeds). At the time I made the guess that they weren't worth it, but it would be good to really test this out.
RAM is relatively cheap these days, so I went with 32GB of it at 2133MHz. It does seem that the speed of the RAM matters, as enabling XMP in the BIOS (to make it run above the default 1333) seemed to make a noticeable difference.
Graphics-wise my personal feeling is that the gaming oriented GTX cards offer better value than the much more expensive 'professional' Quadro range - and have read that the hardware between the 2 has historically been very similar or even identical despite the Quadros being several times the price, with the difference being mainly in the drivers. There are some threads on discourse.mcneel.com about this, and it seems that recent GTX cards like the 970 do very well in Holomark (the Rhino performance benchmarking tool).
I got a GTX 770 (this was just before the 900 series came out), which is probably way overkill just for Rhino/Grasshopper, as they don't use the GPU for more than display (Though some of the render plugins do, and I think for those more CUDA cores is what matters, so there GTX is probably still better value.)
Probably swapping this for a much cheaper card wouldn't make much difference to Rhino/GH performance anyway (though if you want to use the PC for other stuff like gaming or virtual reality it does).
I don't have much experience with AMD cards, so can't comment on how they compare to Nvidia.
Eventually I do hope to make Kangaroo run the physics on the GPU, and potentially this does have a big speed impact. Nvidia recently released some impressive demos of their FLEX engine, which really fly with a decent graphics card. That is very much game-physics, and not suitable for most of the things Kangaroo is used for, but theoretically Kangaroo could also be adapted to use CUDA (or OpenCL), though it involves a lot of big changes, and I don't have a timeline for this yet.
In the much shorter term there are some things in the pipeline that should speed up Kangaroo for certain things like collisions between large numbers of objects, just by using some different algorithms.
Altogether my machine was still well under €2K, and I've been really happy with it. That said, the difference in performance between this and my 4 year old €700 i5 laptop is actually not that huge in day-to-day Grasshopper usage. It does seem that there is a strong case of diminishing returns with buying a PC - I'd hazard a guess that even spending 3 times this amount (as another thread on this forum was discussing recently) you'd be hard pushed to get anything that made a really significant difference to the experience of using it, and if you really want to spend more money, you would be better off just upgrading more frequently (and getting a nice monitor(s)).
Anyway, a long ramble, I hope some of it is useful. As I said, I'm no hardware expert, and would be interested to hear different opinions.
I also think it will be nice to make a simple benchmarking tool for Kangaroo and have people run it on their various machines and report back results (as with Holomark), to help others make informed decisions on these things. I'll try and put something together for this soon.
…
onents (radiation, sunlight-hours and view analysis) which let you study the effect of the orientation of your building and the analysis result. When you come to a question similar to "what is the orientation that the building receives the most/least amount of radiation?" is probably the right time to use this component.
HOW?
I'll try to explain the steps using a simple example. Here is my design geometries. The building in the center is the building to be designed and the rest of the buildings are context. I want to see the effect of orientation on the amount of the radiation on the test building surfaces from the start of Oct. to the end of Feb. for Chicago.
First I need to set up the normal radiation analysis and run it for the building as it is right now. [I'm not going to explain how you can set up this since you can find it in the sample file (Download the sample file from here)]
Now I need to set up the parameters for orientation study using orientationStudyPar component. You can find it under the Extra tab:
At minimum I need to input the divisionAngle, and the totalAngle and set runTheStudy to True. In this case I put 45 for divisionAngle and 180 for the totalAngle which means I want the study to be run for angles 0, 45, 90, 135 and 180.
[Note1: The divisionAngle should be divisible by totalAngle.]
[Note 2: If you don't provide any point for the basePoint, the component will use the center of the geometry as the center of the rotation.]
[Note 3: You can also rotate the context with the geometry! Normally you don't have the chance to change the context to make your design work but if you got lucky the rotateContext input is for you! Set it to True. The default is set to False.]
You're all set for the orientation study, just connect the orientationStudyPar output to OrientationStudyP input in the component and wait for the result!
The component will run the study for all the orientations and preview the latest geometry. To see the result just grab a quick graph and connect it to totalRadiation. As you can see in the graph 135 is the orientation that I receive the maximum radiation. Dang!
If you want to see all the result geometries set bakeIt to True, and the result will be baked under LadyBug> RadaitionStudy>[projectname]> . The layer name starts with a number which is the totalRadiation.
Mostapha…