ing illuminance and limiting exposure (lux hours). Hours with direct solar irradiance are likely to exceed the limiting illuminance thresholds, which range from (200 to 50 lux as per Table 3.4 in CIE 157:2004). It makes sense to consider direct illuminance (an ab=0 simulation in Honeybee) separately from a normal illuminance calculation.
Assuming that the museum exhibits have low to high responsivity to light, an ideal solution would minimize direct sunlight. For daylight from the sky and reflected light, it might be enough to keep the illuminance levels below the recommended thresholds and then sum up lux-hours.
Daysim, the annual daylighting engine used by Honeybee and DIVA, is not very accurate for direct-sun calculations. You will get more accurate results if you run your analysis with Radiance directly.
Instead of considering the horizontal illuminance grids, one can create grids that correspond to the dimensions of the exhibit and then average those values. I think single points, as shown in your gh file might not suffice. Calculating lux-hours is by far the simplest part of such a simulation. It will only require averaging these points, extracting them into an array and then summing up that array.…
precise) that unfortunately has more than one staff. This means that I pay the bills (unfortunate to the max). Practice is vertical meaning no Structural/HVAC etc services.
2. AEC Projects are made by teams. Period.
3. Teams are organized with some sort of hierarchy. Period.
4. On each team there's always one leader. Teams can being sampled in group teams - call them clusters (kinda like a List of List of ...)
5. All cluster leaders report to the supreme human being (yours truly). Leader heads are always on my disposal (it's fun to decapitate someone: I do this every Monday).
6. AEC projects are made with 1% idea(s) and 99% of what we call "sludge" (this is not my job: I'm the One , he he).
7. You can't steer any boat if you don't know each @@$#@ nut and bold. In the past there was a naive approach on that matter (ruined automotive companies, potato chip makers, software vendors, political systems, secret service agencies ... etc etc).
8. Efficiency is above all (even above tax-free cash).
9, You can't do ANY AEC real-life thing with what GH has to offer (nor Rhino is an AEC BIM app - it would never be). You simply use GH as a supplement to Generative Components (and/or as stand alone because it's good fun). There's nothing that GH does (I'm speaking solely for AEC as always) that can't being done with Generative Components.
10. I've done so fat 257 projects (a "bit" bigger than a house, he he). Let's say about 51427 drawings (master, master details, details) and 78956 lines of text (specs, cost estimations, space schedules, supplier lists, contracts, cats and 1 dog).
If you combine all the above you'll have the answer (i.e. why I use solely - if possible - code and not GH components). If you can't combine them I'm sorry.
PS: C# is the absolute standard (never judge a language as a "stand-alone" thingy).
best, Peter (Prince of Cynics)
…
he past Architecture was the art of sketching: some "idea" with pencils/crayons + vellum paper (or with some computer) > then "others" trying to make this happen. This in general is known as top-to-bottom approach. Naive and dangerous (for the reputation/reception/acceptance of Architects/Architecture) to the max.
2. These days we work both ways: whilst some work on some "idea" (called it: "assembly") others (in sync mode) resolve the bits and nuts of that "idea" - up to 1:1 level of detail (called it "components"). This is the bottom-to-top approach. Make this your way: NEVER proceed in something whist's not EVERY bit of that something is well addressed (with at least 3-5 ways).
3. The emergence of parametric (GH, Generative Components, Dynamo) in AEC (an approach well known in MCAD word many years ago, mind) made things ... worst: the tremendous topology exploitation capabilities blinded people's mind and they are completely sucked up by the forest forgetting/by passing the critical fact that there's no forest without trees.
4. That's expected: is in the human nature to follow/admire the blink/glam and omit/skip the humble. It's the easy way you know, he he.
5. The tremendous growth of countries the likes of UAE/China/Russia made AEC things ... even worst: lot's of cash available > make us some encomium to Vanity, forget Modesty. You can replace "Vanity" with "New Frontiers" ... if you like fooling yourself.
Some Academics are not capable to understand all that: if they could they would potentially operate in the field (where the pink color is rarely used) and not in fishbowl(s). Some Academics believe that an "idea" is the 99% of the whole whilst actually is less than 1%. But on the other hand anyone can do Architecture (even Architects, he he).
That said (Vanity crisis) you want some other "component" options for this case of yours? (starting with "some" dollars more and ending with the mortgage the house/sell wife+kids option).
take care (and kill them all)…
s (and God knows how many in the next case) that's why (other than the colossal amount of time (for no reason) required for creating them ... try to bake them and measure the file size).
3 .Most non pros believe that the thing that matters the most in engineering is the geometry. Nothing could be further from the truth. Is about the 5% (complex real-life cases etc etc - but this one is very simple geometry wise and not that simple with regard the whole "ideal" AND effective strategy required).
4. So I've included in this Rhino file attached a small portion of your frames as input for the second C#: CAREFULLY study what it does and most importantly why: it gives you the clear indication about why you should attack this on an assembly/component basis by using instance definitions INSTEAD of recreating 14++ K "solids". The difference in performance is COLOSSAL, not to mention the baked Rhino file size.
5. Using instances is IMPOSSIBLE whiteout code (as is the case in 99% or real-life engineering tasks).
6. Geometry was never an issue on that one (is the 5% max of the whole puzzle no matter requirements you may have).
Bad news:
1. Zoom extends doesn't work after importing your data (maybe a NVidia Quadro K4200 driver issue - who knows?): use saved views stored.
So ...the choice is yours, best, Lord of Darkness…
ponents, among other functionalities, is significantly widening the relevance of the toolset.
Meanwhile having used the tools for some time now and have gone through the forum, in my opinion a few critical system controls is still missing - unless I'm missing some understanding.
In order to really make the hourly energy analysis valuable in early massing studies etc. the consideration of indoor climate can be more detailed. The HVAC capacities, max. airrate and min. inlet temperature should be within comfortable ranges and hardsized by user input to reduce internal draft problems. If not considered I find that the analysis could possibly demonstrate good energy behavior and reasonable operative temperature but in reality could cause a bad indoor environment - and when "rectified" at a later stage the energy consumption will increase.
I would like to know how it is possible in HB to set-up a HVAC system with these ventilation controls and a "unlimited" convective/radiant heating system, and how to deal with the issues mentioned below. The inputs parameters exists in the components, but I can't seem to get the right system behaviour.
In the attached file I have gone through 4 scenaries, each with seperate issues in setting up the system (As no template appearantly supports the combined setup the heating system is simulated using an inlet temperature of 99 degrees).
HVACSystem: "ideal air loads" - Issue: no hardsized airrate, no cooling supply air temperature
HVACSystem: "VAV w. reheat" - Issue: no regulation of airrate, no use of input heat supply temperature in heating mode
HVACSystem: "idealairloadsystem" using "additionstrings" -> issue with duplicate zone names
HVACSystem: "idealairloadsystem" using "additionstrings" on multiple zones -> issue with duplicate zone names
Thanks a lot!
Jon…
a pain to use sometimes. I recently found this great post:
http://www.grasshopper3d.com/forum/topics/formatting-numbers-in-grasshopper
which points to the msdn .net framework standard numeric format strings:
http://msdn.microsoft.com/en-us/library/dwhawy9k.aspx
and the custom ones too:
http://msdn.microsoft.com/en-us/library/0c899ak8.aspx
Sooo... today I was trying to make a 2D array generator for RGB values to use with a RGB LED and an Arduino. For instance, declaring a 2D array in Arduino:
int color[3][3]={{255,0,0},{0,255,0},{0,0,255}};
I'm using the blend color component to spit out transitions between two colors. I want the list in the panel to be in the format above, so I used both the expression component and the string format component (are they the same under the hood?). In any case, if I have R, G and B values coming into the component, I want to format them so the come out looking like {R,G,B}, so I can just copy the output in a panel and paste it into the Arduino IDE. But what about {curly braces}. If the expression/format component uses them in it's syntax, for instance:
Format ("{R:0},{G:0},{B:0}",R,G,B)
how do I get them into the formatting string? I tried escaping them like:
Format ("\{{R:0},{G:0},{B:0}\}",R,G,B)
but that just makes the component angry
Escaping characters is explained in the formatting references above. Is it implemented in this component? Should I be looking at a different approach?
I've included a sample file below.
Thanks!
~BB~
…
ing-in-python?commentId=2985220%3AComment%3A628495
For the most part, I got the serial port to work and I could share the port with other components without wiring the components together using a sticky Python dictionary. There were a couple of issues with closing the port (Rhino had to be restarted).
In any case, I'm back at it. I am however going the C# component route with an eye towards writing my own components with visual studio. I am trying to create bidirectional communication with a serial device in grasshopper. I need more control over the serial port that the generic Firefly components can afford. Furthermore, I would like to understand how to program this myself. The first goal would be to create a few components that could handle various serial tasks, one to open/close port, one to read from port and one to write to it. This is not unlike how I got it to work in python, and is also similar to the logic in Firefly's serial components.
The thing that has me stumped with C# is how one shares the port between components? If one component is responsible for creating and opening/closing the port, how do the read/write components address the instance of the port created in the other component? Python has the sticky dictionary, is there something similar in C#? I'm a novice when it comes to C# and how it works within grasshopper, so maybe I'm missing something simple.
I've attached a klunky definition that uses C# to open/close a serial port. I've tried accessing the port with other components, but I don't know enough to make it work. Again, I'm mainly interested in the mechanics of how one component can access the serial port instance created in another component. If I could get some user objects going for now, I'd be happy. In the future, I want to roll my own components. If anyone has any suggestions, code snippets, or any other forms of enlightenment, I'd be greatly appreciative!
Rhino5 x64 + GH version 0.9.0056
Thanks,
~BB~
…
starting as soon as possible.
We're offering challenging projects, insights and contact to leading industry companies, project responsibilities according to abilities and initiative, great work environment and laid-back atmosphere, room to play and evolve,...
Our ideal candidate:
- is passionate about construction, engineering and (computational) design
- is proficient in Rhino / Grasshopper / (GH-)Python
- knows his ways around the Adobe Suite and MS Office
- has a current work permit for Germany
- is a German speaker (other native speakers also welcome, with excellent English skills)
- has an architectural background (Student / BA / MA /...), ideally with work experience
- is interested / has experience in digital manufacturing and prototyping
- will be able to join us shortly
We're looking forward to your applications / inquiries / CVs to: mpelzer@fat-lab.de
View our past projects here: www.fat-lab.com
(Current projects, unfortunately, are non-disclosed)
…
hen you determine their position and number by the "precision_" input. Their number is equal to "precision_ - 1".They are essentially mesh edges, not curves. To hide them, in Rhino application menu choose: Tools -> Options -> View -> Display Modes -> choose your current display mode, and uncheck the "Show mesh wires":
b) How do you change the x- and y-scale of the chart? For instance displaying every 10 degrees of azimuth?
Can you be a bit more precise?You would like to change the labeling of the azimuth directions from 30 degrees step to 10 degrees step? If this is so, you can not do that.
c) My input surface is a hyperbolic paraboloid, facing south symmetrically. How does the component calculate its tilt and azimuth?
All Ladybug Photovoltaics components calculate the amount of AC energy generated by a planar (flat) surface. Tilt and azimuth angles are calculated based on surface normal at 0.5, 0.5 surface parameters. So you can not use the hyperbolic paraboloid as the _PVsurface (or _PV_SWHsurface) input, as it will yield incorrect results. You need to planarize that hyperbolic paraboloid surface first.I attached below an example with default grasshopper components, but the size of the panels is not equal. If you want them to be equal use some paneling Grasshopper plugin like Lunchbox or Paneling tools.…
hreads where Thread I solves object A1 and Thread II solves object A2. As soon as A1 is completed, Thread I can move on to object B1 and as soon as A2 completes, Thread II can move on to object B3 (whichever comes first). When both A1 and A2 are complete, we can spawn a new thread (III) to take care of object B2.
If B2 completes before B3, then Thread III will terminate. If B3 completes before B2, then Thread II terminates. Whichever thread is last will pick up execution of object C3. And so on and so forth.
This sort of threading is actually not guaranteed to help much though, as it is likely that the bottleneck components in the network will still need to be handled by a single thread.
A more efficient solution would be to divvy up the execution per component to multiple threads. If you're trying to compute the Curve Closest Point for 10,000 points and your machine contains 4 cores, then we can assign 2,500 points to the first core, 2,500 points to the second core etc.
This approach will actually work when there's only a few bottleneck components and it also means the order in which components are solved is no longer important.
An even more fine-grained approach to threading would be to make the Curve Closest Point function in the Rhino SDK threaded. There's a lot of looping going on in any given Curve CP computation so the curve could be broken up into loose spans where each span is solved by a different core. Then the partial results get consolidated once all threads finish.
The benefit here is that it would be multi-core for everyone, not just Grasshopper components.
The bad news: Some functions in Rhino are not thread-safe. Meaning that data structures such as NurbsCurves cannot be modified from multiple threads at once as it will compromise their validity. You might well end up with invalid curves and quite possible weird crashes. In very bad cases it might even be that a specific function in our SDK can only be running once, so even if you were to duplicate the curve it would still not work.
Until our SDK is thread-safe there can be no global threading in Grasshopper. I don't know where we're headed with this, but I do know that we've started using some threaded algorithms in the display as of Rhino5, so it seems we're at least getting our feet wet.
--
David Rutten
david@mcneel.com
Seattle, WA…
Added by David Rutten at 5:47pm on November 17, 2010