should follow the instruction which mostapha has wrote in https://github.com/mostaphaRoudsari/ladybug/blob/master/resources/I...
Instructions for Installing Ladybug + Honeybee: (Follow steps 1-6 for basic functionality and 1-11 for full functionality) 0. If you have an old version of LB+HB, download the file here (https://app.box.com/s/ds96em9l6stxpcw8kgtf) and open it in Grasshopper to remove your old Ladybug and Honeybee version. 1. Make sure that you have a working copy of both Rhino and Grasshopper installed. 2. Open Rhino and type "Grasshopper" into the command line (without quotations). Wait for grasshopper to load. 3. Install GHPython by downloading the file at this link (http://www.food4rhino.com/project/ghpython?ufh) and drag the .gha file onto the Grasshopper canvas. 4. Select and drag all of the files in the "userObjects" folder (downloaded with this instructions file) onto your Grasshopper canvas. You should see Ladybug and Honeybee appear as tabs on the grasshopper tool bar. (If you are reading this instruction on github you can download them from http://www.food4rhino.com/project/ladybug-honeybee) 5. Download the files at this link (https://app.box.com/s/bh9sbpgajdtmmystv3n4), unzip them and copy the contents to both C:\ladybug and C:\Users\[yourUsername]\AppData\Roaming\Ladybug. 6. Restart Rhino and Grasshopper. You now have a fully-functioning Ladybug. For Honeybee, continue to the following: 7. Install Radiance to C:\Radiance by downloading it from this link (https://github.com/NREL/Radiance/releases/download/4.2.2/radiance-4...) and running the exe. 6. Install Daysim to C:\DAYSIM by downloading it at this link (http://daysim.ning.com/page/download) and running the exe. 8. Install Energy Plus 8.1 to C:\EnergyPlusV8-1-0 by going to the DOE website (http://apps1.eere.energy.gov/buildings/energyplus/energyplus_downlo...), making an account, going to "download older versions of EnergyPlus, selecting 8.1 and running the exe. 9. Copy falsecolor2.exe (http://pyrat.googlecode.com/files/falsecolor2.exe) and evalglare.exe (http://www.ise.fraunhofer.de/en/downloads-englisch/software/evalgla...) to C:\Radiance\bin 10. Download the OpenStudio Libraries (https://app.box.com/s/y2sx16k98g1lfd3r47zi) and unzip them to C:\ladybug\OpenStudio. 11. You now have a fully-working version of Ladybug + Honeybee. Get started visualizing weather data with these video tutorials (https://www.youtube.com/playlist?list=PLruLh1AdY-Sj_XGz3kzHUoWmpWDX...).
It works for me..
Agus…
new component "OSM 3D roof"):
2) Simplified 3D roads can be created by using the network of OSM polylines (through new component "OSM 3D road"):
3) 3D forest.Up until now, Gismo supported generating a single 3d tree whenever such tree was present in openstreetmap.org database. Now it is possible to generate 3d trees in forest areas, by randomly positioning the 3d trees (through new component "OSM 3D forest"):
4) Boolean 3d shapes.Gismo's "OSM 3D" component generates shapes as parts: for example, if a building has irregular shapes across its height, they will all be created individually. Trying to merge them with Grasshopper's "Solid Union" component can sometimes fail.New Gismo "Rhino Boolean Union" components tries to overcome this issue by using a much better Rhino version of this command.
5) Library of common GIS color palettes (gradients).A single component containing 22 of the common color palettes used in GIS applications as ArcGIS and QGIS. For example: elevation, aspect, precipitation...
6) Url to location.Thanks to idea by Alex Ng, it is possible to extract location from a link of the following map websites: Openstreetmap, google maps, bing maps, wego.here, waze:
Version 0.0.3 can be downloaded from here:
https://github.com/stgeorges/gismo/zipball/master
Example files from here:
https://github.com/stgeorges/gismo/tree/master/examples
New suggestions, testing and bug reports are welcome!!…
Added by djordje to Gismo at 1:39am on January 29, 2019
ng is deciding how and where to store your data. If you're writing textual code using any one of a huge number of programming languages there are a lot of different options, each with its own benefits and drawbacks. Sometimes you just need to store a single data point. At other times you may need a list of exactly one hundred data points. At other times still circumstances may demand a list of a variable number of data points.
In programming jargon, lists and arrays are typically used to store an ordered collection of data points, where each item is directly accessible. Bags and hash sets are examples of unordered data storage. These storage mechanisms do not have a concept of which data comes first and which next, but they are much better at searching the data set for specific values. Stacks and queues are ordered data structures where only the youngest or oldest data points are accessible respectively. These are popular structures for code designed to create and execute schedules. Linked lists are chains of consecutive data points, where each point knows only about its direct neighbours. As a result, it's a lot of work to find the one-millionth point in a linked list, but it's incredibly efficient to insert or remove points from the middle of the chain. Dictionaries store data in the form of key-value pairs, allowing one to index complicated data points using simple lookup codes.
The above is a just a small sampling of popular data storage mechanisms, there are many, many others. From multidimensional arrays to SQL databases. From readonly collections to concurrent k-dTrees. It takes a fair amount of knowledge and practice to be able to navigate this bewildering sea of options and pick the best suited storage mechanism for any particular problem. We did not wish to confront our users with this plethora of programmatic principles, and instead decided to offer only a single data storage mechanism.*
Data storage in Grasshopper
In order to see what mechanism would be optimal for Grasshopper, it is necessary to first list the different possible ways in which components may wish to access and store data, and also how families of data points flow through a Grasshopper network, often acquiring more complexity over time.
A lot of components operate on individual values and also output individual values as results. This is the simplest category, let's call it 1:1 (pronounced as "one to one", indicating a mapping from single inputs to single outputs). Two examples of 1:1 components are Subtraction and Construct Point. Subtraction takes two arguments on the left (A and B), and outputs the difference (A-B) to the right. Even when the component is called upon to calculate the difference between two collections of 12 million values each, at any one time it only cares about three values; A, B and the difference between the two. Similarly, Construct Point takes three separate numbers as input arguments and combines them to form a single xyz point.
Another common category of components create lists of data from single input values. We'll refer to these components as 1:N. Range and Divide Curve are oft used examples in this category. Range takes a single numeric domain and a single integer, but it outputs a list of numbers that divide the domain into the specified number of steps. Similarly, Divide Curve requires a single curve and a division count, but it outputs several lists of data, where the length of each list is a function of the division count.
The opposite behaviour also occurs. Common N:1 components are Polyline and Loft, both of which consume a list of points and curves respectively, yet output only a single curve or surface.
Lastly (in the list category), N:N components are also available. A fair number of components operate on lists of data and also output lists of data. Sort and Reverse List are examples of N:N components you will almost certainly encounter when using Grasshopper. It is true that N:N components mostly fall into the data management category, in the sense that they are mostly employed to change the way data is stored, rather than to create entirely new data, but they are common and important nonetheless.
A rare few components are even more complex than 1:N, N:1, or N:N, in that they are not content to operate on or output single lists of data points. The Divide Surface and Square Grid components want to output not just lists of points, but several lists of points, each of which represents a single row or column in a grid. We can refer to these components as 1:N' or N':1 or N:N' or ... depending on how the inputs and outputs are defined.
The above listing of data mapping categories encapsulate all components that ship with Grasshopper, though they do not necessarily minister to all imaginable mappings. However in the spirit of getting on with the software it was decided that a data structure that could handle individual values, lists of values, and lists of lists of values would solve at least 99% of the then existing problems and was thus considered to be a 'good thing'.
Data storage as the outcome of a process
If the problems of 1:N' mappings only occurred in those few components to do with grids, it would probably not warrant support for lists-of-lists in the core data structure. However, 1:N' or N:N' mappings can be the result of the concatenation of two or more 1:N components. Consider the following case: A collection of three polysurfaces (a box, a capped cylinder, and a triangular prism) is imported from Rhino into Grasshopper. The shapes are all exploded into their separate faces, resulting in 6 faces for the box, 3 for the cylinder, and 5 for the prism. Across each face, a collection of isocurves is drawn, resembling a hatching. Ultimately, each isocurve is divided into equally spaced points.
This is not an unreasonably elaborate case, but it already shows how shockingly quickly layers of complexity are introduced into the data as it flows from the left to the right side of the network.
It's no good ending up with a single huge list containing all the points. The data structure we use must be detailed enough to allow us to select from it any logical subset. This means that the ultimate data structure must contain a record of all the mappings that were applied from start to finish. It must be possible to select all the points that are associated with the second polysurface, but not the first or third. It must also be possible to select all points that are associated with the first face of each polysurface, but not any subsequent faces. Or a selection which includes only the fourth point of each division and no others.
The only way such selection sets can be defined, is if the data structure contains a record of the "history" of each data point. I.e. for every point we must be able to figure out which original shape it came from (the cube, the cylinder or the prism), which of the exploded faces it is associated with, which isocurve on that face was involved and the index of the point within the curve division family.
A flexible mechanism for variable history records.
The storage constraints mentioned so far (to wit, the requirement of storing individual values, lists of values, and lists of lists of values), combined with the relational constraints (to wit, the ability to measure the relatedness of various lists within the entire collection) lead us to Data Trees. The data structure we chose is certainly not the only imaginable solution to this problem, and due to its terse notation can appear fairly obtuse to the untrained eye. However since data trees only employ non-negative integers to identify both lists and items within lists, the structure is very amenable to simple arithmetic operations, which makes the structure very pliable from an algorithmic point of view.
A data tree is an ordered collection of lists. Each list is associated with a path, which serves as the identifier of that list. This means that two lists in the same tree cannot have the same path. A path is a collection of one or more non-negative integers. Path notation employs curly brackets and semi-colons as separators. The simplest path contains only the number zero and is written as: {0}. More complicated paths containing more elements are written as: {2;4;6}. Just as a path identifies a list within the tree, an index identifies a data point within a list. An index is always a single, non-negative integer. Indices are written inside square brackets and appended to path notation, in order to fully identify a single piece of data within an entire data tree: {2,4,6}[10].
Since both path elements and indices are zero-based (we start counting at zero, not one), there is a slight disconnect between the ordinality and the cardinality of numbers within data trees. The first element equals index 0, the second element can be found at index 1, the third element maps to index 2, and so on and so forth. This means that the "Eleventh point of the seventh isocurve of the fifth face of the third polysurface" will be written as {2;4;6}[10]. The first path element corresponds with the oldest mapping that occurred within the file, and each subsequent element represents a more recent operation. In this sense the path elements can be likened to taxonomic identifiers. The species {Animalia;Mammalia;Hominidea;Homo} and {Animalia;Mammalia;Hominidea;Pan} are more closely related to each other than to {Animalia;Mammalia; Cervidea;Rangifer}** because they share more codes at the start of their classification. Similarly, the paths {2;4;4} and {2;4;6} are more closely related to each other than they are to {2;3;5}.
The messy reality of data trees.
Although you may agree with me that in theory the data tree approach is solid, you may still get frustrated at the rate at which data trees grow more complex. Often Grasshopper will choose to add additional elements to the paths in a tree where none in fact is needed, resulting in paths that all share a lot of zeroes in certain places. For example a data tree might contain the paths:
{0;0;0;0;0}
{0;0;0;0;1}
{0;0;0;0;2}
{0;0;0;0;3}
{0;0;1;0;0}
{0;0;1;0;1}
{0;0;1;0;2}
{0;0;1;0;3}
instead of the far more economical:
{0;0}
{0;1}
{0;2}
{0;3}
{1;0}
{1;1}
{1;2}
{1;3}
The reason all these zeroes are added is because we value consistency over economics. It doesn't matter whether a component actually outputs more than one list, if the component belongs to the 1:N, 1:N', or N:N' groups, it will always add an extra integer to all the paths, because some day in the future, when the inputs change, it may need that extra integer to keep its lists untangled. We feel it's bad behaviour for the topology of a data tree to be subject to the topical values in that tree. Any component which relies on a specific topology will no longer work when that topology changes, and that should happen as seldom as possible.
Conclusion
Although data trees can be difficult to work with and probably cause more confusion than any other part of Grasshopper, they seem to work well in the majority of cases and we haven't been able to come up with a better solution. That's not to say we never will, but data trees are here to stay for the foreseeable future.
* This is not something we hit on immediately. The very first versions of Grasshopper only allowed for the storage of a single data point per parameter, making operations like [Loft] or [Divide Curve] impossible. Later versions allowed for a single list per parameter, which was still insufficient for all but the most simple algorithms.
** I'm skipping a lot of taxonometric classifications here to keep it simple.…
Added by David Rutten at 2:22pm on January 20, 2015
I am not knowledgeable about google maps nor google maps api, but from what I read the two components will definitely show a bit different results due to different topography sources.If it is judging by this 2010 article, your Terrain Generator component offers much higher precisions for USA. Precision goes up to a couple of meters, which is amazing!!On the global scale it offers either SRTM 1 or 3 arc-second data or 30 arc-second GLOBE data. Again this is from the mentioned article, I couldn't find this information by searching the Google Maps website.Terrain Generator 2 component always uses SRTM 1 arc-second data from opentopography.org, and it is limited to 60 degrees north and does not have data for Antarctica. It does not come with satellite image either which is another very convenient feature that you have!I couldn't find information about the allowed radius provided by the Google maps api free account. I limited the "radius_" input to 100 000 meters, even though opentopography.org provides more than that (I successfully downloaded 300 000, but Rhino 5 was not able to create a topography on my PC from such a large amount of data).Even though I couldn't compare the results from two components, by looking at your upper example_LB_terrain_generator.gh definition: set the "I" input of "Surface from points" component to True. In this way the surface will be interpolated through points, which is what we want.
Again thank you for the permission, and I look forward seeing those high precision topography that Google maps offers!!…
Here I use one which has been refined with a 5 level subdivision...does it appear ok to you or would you recommend going even smaller? Green nodes are the ones loads act upon.
2) 'Local To Mesh' vs 'Global' vs 'Projected Global'
I am applying a positive wind pressure (0,729 kN/m2) in the direction of global positive y axis.
The façade mesh is 1505 m2, of which 1056 m2 runs parallel to the XZ plane.The wind pressure is 0,729 kN/m2 acting in the positive y direction ---> expected resultant of +/- 1056 x 0,729 = 770 kN.
'Global' gives +1098 kN in positive y direction.
'Global Projected' gives a +770 kN resultant in the positive y direction.
'Local to mesh'...gives -770kN along x axis (parallel to the façade according to ModelView) & -215kN along y axis. This surprised me since 'Local to mesh' is indeed the option to chose according to the manual yet I can't see how a wind load perpendicular to the facade would result in the tower moving in a cross-wind direction. 'Global projected' appears to provide the most logical result.
In view of these results, do you think the mesh remains ill-defined, the tower's shape is the culprit...or my choice of coordinate system for the load? What would you recommend?
Thanks again for your feedback, which is greatly appreciated.
Nathan
…
cript that and I attempted tweaking it for several days but I'm having problems achieving the full idea i had.
Problem 1:
Once I Brep a frame of the original cube, and the hoopsnake starts, it does not always select the right face of the frame, sometimes chooses a face inside rather than the exterior one, therefore not always fitting pieces together nicely. I tried applying a bounding box to each frame and use the face of the bounding box as reference for the hoopsnake mirroring but I couldn't figure it out so i got rid of it. So I'm stuck...
Problem 2:
The other thing, is I'm wondering whether its possible to parametrize some sort of structural principle into the linear growth sequence in order for structure to retain realistic structural integrity. For example, when you start hoopsnake, the cube linearly grows (mirrors itself) towards the selected point(s); if the growth goes up and across, how would I make it reach a structural limit to make it go back down to the floor and back up again and continue? Could even be as simple as "after 5 frames/cubes vertically and across it goes back down and then up again towards the referenced point(s)" or something.
PS. "Reset All" in Hoopsnake before doing anything.
Hope someone can help.
Thanks in advance,
Cesco…
tle.
I use rhino with the nurbsrelaxation plugin. Recently we have had rhino do some work to come up with an automated drawing tool via grasshopper.
Since grasshopper has been added to rhino i have noticed that when drawing surfaces and then using the nurbs tool the tools behaviour has changed and is now including iterations at the end of its process doubling the amount of time it takes to draw/finalise the surface/shape.
Below i have included 2 screenshots, the first one shows the surface(yellow edges), and then the cursor showing the nurbs icons (toolbar) and the rest of the info is in the command boxes.
The 2nd one shows info in the command line, detailing what happens once the tool is run (this is where you can see the iterations occuring).
Having done a little research i get the impression that this may be grasshopper related but cannot find any confirmation of this nor of anyone experiencing the same issue.
I also know that nurbsrelaxation is a plug in so not everyone will use this.
Can anyone help me with this as i would like to know why the iterations are occurring and if we can eliminate or reduce them.
Many thanks in advance
Matt…
Added by Matt Fairley at 4:08am on November 10, 2015
j
1
c
e
h
k
2
f
-------------------------------------------------------------------------------------------------
To these...
0;0
0;1
0
a
i
------------------------------------------------------------
0;0
0;1
0;2
0
b
g
j
1
c
h
k
------------------------------------------------------------
0;0
0
d
1
e
2
f
------------------------------------------------------------
Thanx……
ooking for an efficient way to perform glazing of complex shapes.
I've only followed the Energy modelling workshops so far so i may have missed some essential components or workflows to achieve my needs. But i've made an attached definition with all my current attempts to get a proper HBzone with the numerous windows faces i will always have to deal with in this project.
I first thought that i was not using the HBObjWGZ correctly, then after some readings it was maybe an upgrading issue, then effectively i had my Therm 7.5 that needed to be reinstaled, but then ... I must be missing an essential HB tricks or workflow i guess ...
So I divided my attempt in two series :
- The Serie 1 : is a simplier version of the project step i'm working on but i'd be glad to achieve it first !
- The Serie 2 : is the real final direction of the project, which consist in sorting/dispatch faces to windowon one side and to an other material on the other, according to the winter sun and a pourcentage param.
Despite it is more complicated than the Serie one, it seems seems to create the same diversity of issues.
Until now, with the 5 different combinations of Serie 1, and the 3 of Serie 2, with and without using the different Glazing/window components, here are the logs i got from both HBZone component or OpenStudio component:
From OpenStudio - "1. The simulation has not run correctly because of this severe error: ** Severe ** BuildingSurface:Detailed="00073E23257843B6A948", invalid Construction Name="ETFE" - has Window materials.">> Has to deal with the way i'm trying to assign too early a customized EPConstruction material ? Done it wrong ? I tried to reload it in the library but doesn't change anything...
From OpenStudio - "1. The simulation has not run correctly because of this severe error: ** Severe ** BuildingSurface:Detailed="000579CD749E46DFA5EA", invalid Construction Name="EXTERIOR WINDOW" - has Window materials.">> Is it an issue in the way i define my surfs both as "WINDOW" (5) for srfType and Outdoors on the same component ?
From Create HBZone -"1. Solution exception:'EPZone' object has no attribute 'shdCntrlZoneInstructs'"
>> Happens when i try to introduce my ETFE EpMaterial after creating my first HBZone, with a Set EP Zone Construction, so this material seems to be not working either before and after trying to create an HB Zone
From Create HBZone- "1. Solution exception: 73df51a3b2144b1e858b has been moved, scaled or rotated."If you need to move or rotate a Honeybee object you should use Honeybee move, rotate or mirror components. You can find them under 12|WIP tab.
>> >> wich seems to exist in some on other thread Here and was a coding bug supposed to be fixed.
And last but not least ...
From OpenStudio - "1. The simulation has not run correctly because of this severe error: ** Severe ** checkSubSurfAzTiltNorm: Outward facing angle of subsurface differs more than 90.0 degrees from base surface.2. The simulation has failed because of this fatal error: ** Fatal ** GetSurfaceData: Errors discovered, program terminates" .
I'm attaching the file with each attempt in this post. The definitions are disabled and the log already copied separatly so there is no need to compute each of them to see what's wrong.
If someone from the beginner to one of the Kings of HoneyBee has any relevant answer/solution to this attempt with complex geometry Issue it will be really nice for me so i could to move forward !!
Thanks in advance guys and have a great day !
…
rring to the above image)
Area
effective
effective
Second
Elastic
Elastic
Plastic
Radius
Second
Elastic
Plastic
Radius
of
Vy shear
Vz shear
Moment
Modulus
Modulus
Modulus
of
Moment
Modulus
Modulus
of
Section
Area
Area
of Area
upper
lower
Gyration
of Area
Gyration
(strong axis)
(strong axis)
(strong axis)
(strong axis)
(strong axis)
(weak axis)
(weak axis)
(weak axis)
(weak axis)
A
Ay
Az
Iy
Wy
Wy
Wply
i_y
Iz
Wz
Wplz
i_z
cm2
cm2
cm2
cm4
cm3
cm3
cm3
cm
cm4
cm3
cm3
cm
I have a very similar table which I could import to the Karamba table. But I have i_v or i_u values as well as radius of inertia for instance.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
dimensjon
Masse
Areal
akse
Ix
Wpx
ix
akse
Iy
Wpy
iy
akse
Iv
Wpv
iv
Width
Thickness
Radius R
[kg/m]
[mm2]
[mm4]
[mm3]
[mm]
[mm4]
[mm3]
[mm]
[mm4]
[mm3]
[mm]
[mm]
[mm]
[mm]
L 20x3
0.89
113
x-x
4,000
290
5.9
y-y
4,000
290
5.9
v-v
1,700
200
3.9
20
3
4
L 20x4
1.15
146
x-x
5,000
360
5.8
y-y
5,000
360
5.8
v-v
2,200
240
3.8
20
4
4
L 25x3
1.12
143
x-x
8,200
460
7.6
y-y
8,200
460
7.6
v-v
3,400
330
4.9
25
3
4
L 25x4
1.46
186
x-x
10,300
590
7.4
y-y
10,300
590
7.4
v-v
4,300
400
4.8
25
4
4
L 30x3
1.37
175
x-x
14,600
680
9.1
y-y
14,600
680
9.1
v-v
6,100
510
5.9
30
3
5
L 30x4
1.79
228
x-x
18,400
870
9.0
y-y
18,400
870
9.0
v-v
7,700
620
5.8
30
4
5
L 36x3
1.66
211
x-x
25,800
990
11.1
y-y
25,800
990
11.1
v-v
10,700
760
7.1
36
3
5
L 36x4
2.16
276
x-x
32,900
1,280
10.9
y-y
32,900
1,280
10.9
v-v
13,700
930
7.0
36
4
5
L 36x5
2.65
338
x-x
39,500
1,560
10.8
y-y
39,500
1,560
10.8
v-v
16,500
1,090
7.0
36
5
5
I have diagonals (bracings) which can buckle in these "non-regular" directions too, and they do. If I could add those values then in the Karamba model I could assign specific buckling scenarios..... I can see another challenge which will be at the ModifyElement component, I will not be able to choose these buckling lengths, in these directions.
Do you think this functionality can be added within short, or should I try to find another way to model these members?
Br, Balazs
…