nd B) daylight autonomy for a single room. A and B are therefore the conflicting objectives, and are connected to the O of octopus component. The geometry iterated is that of a window, on one of the rooms' facades.
I have a grasshopper definition that iterates the window by changing:
1. Window height
2. Window sill height
3. Window width
4. Window position from one side of the wall
1,2,3,4 are therefore the genes. A combination of these genes is a complete window, which is the chromoshome, that i will from now on call solution. All genes are connected to the G of octopus component.
Now regarding the octopus settings, i have these questions so that i can properly calibrate the settings (mutarion rate, crossover rate etc):
1.In the beginning of the octopus simulation, how many are the random solutions generated? (By random i mean totally random, not resulting solutions from mutation or crossover of previous solutions, i am talking about the very first generation). Is this number connected to the population size? Is it 6? How is it defined by octopus? Can somebody control it?
2.The first generation finishes when the number of "individuals to be evaluated" is reached. Then octopus jumps to the second generation. To do so, it keeps a specific number of solutions of the first generation, the so called elite. What is the number of these elite? Is it elitism x population size?
3.The SPEA2 original paper describes step wise the algorithm loop. During the loop, a number of solutions is stored in the elite domain, and from that domain, a number of solutions is used for mating. There are therefore two numbers, one that defines the number of solutions to enter the elite domain, and one that defines the number of solutions to be inserted in the mating pool. In octopus i only see elitism as a setting, which i am guessing is what defines the number of solutions to enter the elite domain. Is that true? How do i define the number of solutions to be copied in the mating pool, where mutation and crossover will occur? This number should be called tournament size, but i can't seem to find it..
4.Why is it that DURING one generation, the number of "individuals to be evaluated" can decrease? Is it because octopus finds out that there are no more possible solutions? (i am using discrete values for the genes)
5.The gene of window width, represented by a grasshopper slider, has 4 possible values: 0,1,2,3. Assuming that the mutation rate is 0.5. Does this mean that mutation of the gene can happen to an extent of 0.5 x 4 = 2? Meaning that the slider position can change for 0 to 2 or from 3 to 1 etc?
6.The mutation probability is dictating whether or not a gene will be mutated, or whether or not the whole solution will be mutated? So for instance, with a mutation probability of 0.5, does it mean that 2 out of the 4 genes are going to be mutated, or 2 out of 4 solutions is going to be mutated. If its the second case, then how is mutation divided between the different genes? Meaning, which of the 4 genes is going to get mutated? Is it random? Is it for all 4 genes?
7.Crossover can occur between 2 subsequent solutions. Crossover rate dictates whether or not crossover will take place? If so, then, assuming that it was chosen for crossover to take place between 2 solutions, which of the genes are going to be exchanged. I mean how many, out of the 4 genes (height, sill height, width, position). Is it random?
8.After clarifying the previous 7 questions, i can run a simulation. Then, is there an indicative number that i can be monitoring, to see that no more generations are required? I know that a good pareto has to be short, with a lot of solutions and with a uniform distribution. But is there a specific number output somewhere, that can inform me that a good pareto has more or less been generated? If there is such indicator...
Thank you all,
i hope this can help others as well,
Iason
…
ll the wires gone. Now you'll have to hook them up again. This is the sort of thing that gets annoying after the third time.
Problem #2. The solution in Grasshopper iterates over all objects and solves each one in turn. Of course a lot of objects depend on other objects, so it usually becomes a cascade of objects solving themselves for the benefit of other objects. It is therefore very difficult to predict the order in which objects are solved.
The root iteration is the same as the display order (back to front), but the topology of the network complicates matters greatly. If you change the topology of the network during a solution, you might end up with whole portions of the network not being solved at all, or, worse, a conflict in the topology checker that makes Grasshopper think a network is self-referencing.
Problem #3. Grasshopper caches all manner of things about a network that can be recomputed from basic principles, but take a long** time to do so. If you start to expire caches where I don't expect you to, we'll either run into null reference errors, or stale cache data, or invalid cache data. Problems like these are very difficult to track down.
Problem #4. File IO. Components get deserialized from ghx files based on their default layout. In your case, we need to solve a component before we know how many outputs it needs. This cannot be done until the file has been completely deserialized. It's a chicken and egg problem, which will result in missing wires every time you open a file.
If you want to have a flexible number of outputs on your component, I'd suggest you add a menu item to your component that will change the output list when clicked, then causes a recompute. This way you won't mess with the network topology during solutions and people don't get their connections pulled out from under them. You'll need to do quite a few things to make this work, but I'll be happy to help you out there:
- Adding menu items and menu click handlers
- Properly removing parameters from a component
- Properly adding parameters to a component
- Recording undo for parameter changes
- Writing custom settings to a ghx archive
- Reading custom settings from a ghx archive and making sure your component is compatible with the ghx layout before it tries to deserialize itself.
--
David Rutten
david@mcneel.com
Poprad, Slovakia
* This sort of thing has cropped up before and it has always been due to human error.
** 2ms or more…
Added by David Rutten at 9:28am on October 19, 2010
strictly with code (BTW: did you crossed Rubicon?).
1. See this: Imagine a curve (say a "rail") that is divided N times and then circles are created with random radii. Circle control points (9, that is) are sampled (obviously) into a DataTree where branches are the rail divisions. Let's call the control points: "start" seed points.
2. Imagine a capability ... that stores all these (the original "seed" control points) into a "parameter" and then each time that a change occurs to them (varying the x/y, on a per point on a per branch on a per plane basis[that provides the Z]) stores the "modified point" into the parameter (at the same index with the old: meaning "deleting" the old) ... and then some other code gets that data and makes curves and lofts them. Reset means: sample again the original "seed" points into that "parameter". Closing are reopening the definition has no effect: the lofted stuff is derived from the (internalized, so to speak) modified points (from the "parameter").
3. A variety of "automation" is available: for instance if you jump from branch to branch and from item to item the value of the selected point is inquired and the sliders that control the new x/y are "set" to 0,0 (meaning no change - yet) values. There's mo "store" mode: it works automatically as far as you modify points or you hit the reset button
4. This does that (only achievable with code):
5. Obviously points can been replaced with anything ... and thus ... we can individually modify items in collections ... and forget for ever attractor points and all that (OK where appropriate, he he).
I'll post 30 similar examples soon in the forthcoming mother of all threads: "GH goes (at last) interactive". Watch this space.
BTW: study the "animation" where points with index 6 are "sequentially" modified. I've added some delay in order to give you time to get the gist of the whole thingy.
best, Lord of Darkness
…
4 explode the text
5 select the exploded text, which are now curves, and the border from step 2 and use the planarsrf command again
6 make your surface using the two curves at top and bottom and a section. Use the sweep2 command
7 select your negative text surfaces and use the flowalongsrf command
maybe the scale of the text can be edited by the size of the surface or of the text but I bet you can figure that out! good luck!…
l design.
2/ Optimization
2.1/ in prefabrication
2.2/ combinatorial
2.3/ approach comparisons (i.e. deterministic vs stochastic)
2.4/ share your research
2.5/ ... etc. the list goes on and on
3/ Share you design rationale and how computation fits in
4/ Need help with this problem...
5/ Challenges and workshops announcements
6/ CD News
7/ Share computational design projects under construction or built (akin to skyscrapercity)
8/ and so many other categories and sub-categories...
Just my first thoughts. That breakdown in optimization is just an example. Maybe 'sections' is an old-school way of seeing things, I just wanted to share some thoughts on the kind of content I look forward to seeing. It can be pragmatic topics, but also theoretical, and allow folks to share their projects and research. Some categories are specific, others broad. I suppose I'm interested in community building with regards to computational design. I think SmartGeometry attempted to accomplish this at some point in the past, to some degree. However their focus appears to be in the workshops and challenges.
I recall the silly flame wars that the CG industry had 20 years ago (lame). I'd avoid that, even if it meant forbidding the mention of any specific software in certain areas or in the entire forum. Which would be tricky, but the endless flame wars and silly comparisons were such a waste of everyone's time in CG.
Without dwelling on this too much yet, I think that the software specific questions belong in software specific forums. If we already had a common language for computational design, you'd just need to add the right description as a meta-tag to any Dynamo or Grasshopper forum post, and you'd be able to find analogous solutions in either forum effortlessly, right?
The Dynamo and Grasshopper forums lack design-centric content. The emphasis is generally on the tools and workflow. Computational design is hybrid in essence, it involves both design and computer programming (be it visual or textual). We could really use a forum for knowledge exchange where the expectation is that both are discussed with equal status.
I disagree that such a forum ought to exclude professional programmers. It should include professional programmers whom have an interest in design, and also include professional designers whom have an interest in computer programming, and everyone in between, and enthusiasts, and artists whom are curious about algorithms as a creative medium, and academics, and students, and etc etc. As long as there is rich content and activity on design as well, not only the computational bit, then the crowd will be diverse and we'll all have more to learn from one another.…
s not imported in the workflow, there is no problem for the intersectMass component, no matter how we change the random seed to generate different groups of breps with overlapping surfaces:
2. However, once we add the mass2Zone component into the workflow, we have this problem as posted here.
3. As you pointed out, the warning is given when "Hzones == True" which only happens when one of the objects in _bldgMassesBefore is recognized as a zone already stored in HB Hive. So, I added one line after line257 to print out the zone name:
4. It seems for the cases that the intersecMass component shows warning, there is a zone name printed:
5. Whereas for those cases that the intersecMass component shows no warning, there is no zone name printed:
6. Even if the zone creation is turned off, there is still zone name printed for cases that intersectMass is unable to process:
So, I agree with you that this might be related to the HoneyBeeHive which stores honeybee zones.
Maybe whenever upstream geometries change that are connected to either intersectMass or Masses2Zones, the HoneyBeeHive has to be cleaned up and zone objects inside need to be recreated.
Hope Chris and Mostapha can kindly take a look and advise if this is the source of the issue.
Thanks.
- Ji…
this was about some boring building I wouldn't respond ... but here we are talking sardines.
Here's my take on that matter:
1. The 4 C# first create/use a nurbs, then define some random planes (and transformations) and then (a) either they place some humble stripes or ... er ... (b) sardines as instance definitions (NOTE: Load Rhino file first).
2. All important decisions are the ones in yellow groups.
3. You control what you get via this (priority on stripes or sardines? that's the 1M Q):
4. If you decide for sardines (the right thing to do) then you must ENABLE the Sardiniser(C)(tm)(US patent pending) as follows:
5. The vodkaFactor on that Sardiniser C# adds some spice in the sardine placement (it does that by altering the priority on the "composite" transformation in use: first randomly rotate then planeToPlane .... or the other thing?).
6. Only the finest Da Morgada sardines are used in this definition:
7. Spot the WARNING in the filter related with what sardine to choose > do it wrong and no hard disk on your workstation > no risk no fun > sorry Amigos, he he.
8. 1M question for you all: why placing sardines (it's real-time you know) is WAY faster than creating these humble stripes?
9. Although the sardines are placed in real time as regards your CPU ... the critical factor is your GPU (display mode: rendered).
10.Still WIP (dancing sardines in the next update).
have some sardine fun, best, Lord of SardineLand…
and Grasshopper. Recently I tried doing some test project just to see what can I do. My target is to design a small house for an atom family. Though as you might think - it'll be a parametric one. And I encountered exactly what's in the title. So here it goes: 1. Something is wrong with the measuring units in the complex profiles. I met this problem while making I-beam. In ArchiCAD it had 127/76 mm while in Grasshopper i had 127000/76200mm so a little bigger. 2. I'm unable to turn off the preview. I mean when I delete something in Grasshopper/Rhino it still exists in ArchiCAD. I have to unlock it and then delete it. 3. Coordinates for points seem broken. They have to be multiplied 1000 times to match. 4. Now one of the most important. Is it possible to somehow SHOW Grasshopper where are already made in ArchiCAD objects. Even if they'll remain still. For example I want to make a parametrical roof. Do I have to model whole building from scratch in Grasshopper or is there some fast way to "import" existing scene so I can limit my work with Grasshopper only to parametrical one. 5. Is it possible to make "points" as controlling points in AC? Like, if I'd like to make a beam in a desired place which I will mark by that point and then I will "show" Grasshopper that point and tell it to make an object in there so I can control it within grasshopper. I tried ti do this using AC Control Point but when I click "Send changes" button, Grasshopper and Rhino crush immediately. It only happens then, with control points. 6. It seems that "move" component won't work with "2D curve" component connected directly. It is possible that some of those problems are outdated. I was playing around in Grasshopper a few months ago, before summer break, but now I plan to try something new and it would be nice to know what to do. I appreciate any answer to any of those questions. Please help, you guys, are my only hope. Thanks in advance! Karol…
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
…