ey provide all the means to what I try to achieve.
What I need is to get a fast (as possible) evaluation of passive heat/solar gain from a certain facade. I know my building can cool to a certain degree (lets say 80 W/m2 - now lets forget other internal gains) and I want to be sure my facade is not letting excessive amounts of heat into the room/building. Normally I would make a full blown simulation to count my overheating hours and thereby evaluate my facade. To speed up the process, the idea is just to evaluate overheating hours in a faster way. So what I am thinking is that excessive amounts may estimated by counting high intensity irradiation patches in a critical sky-component or whatever such thing would be called that surpasses my sensible cooling load. My hope is that any facade visible to the sky-patches would very similar to the number of overheating hours if properly calibrated to a simulated model. However I have no idea right now, if this can be done.
Why do this? Speed, convenience, whole building thermal analyses.
@Chris and @Abraham The critical sky-component is made with LBs radiance component radiation and filtering the beam-components with highest effects from a yearly epw-file.
@Chris Conductive heat gains are also important especially if the facade is badly insulated, so the next step is to filter the outdoor temperature parallel with that critical sky-component and then do a static heat transfer analysis and combine that with the effect from direct sun influence. Again, no idea if it works.
Hope it makes sense. I a little embarrassed I drew you into this little experiment. This was not at all the point of the discussion. But now we are into it I like to know what you think. If it works its kinda neat, at least i think it is.
/K…
nza dal centro delle facce ad un punto fisso per determinare quant'è il valore dell'offset per quella faccia.
Prova questa soluzione per ora:
- abilita il componente disattivato all'inizio;
- il componente curve offset non funziona bene, domani vedo se riesco a crearne uno migliore;
- inforna (bake) la brep risultante e convertila in mesh da rhino;
- per dargli spessore, fai l'offset solido della mesh in rhino per l'ultima fase, funziona meglio.
I've used the distance from the center of the faces to a fixed point to determine the value of the offset.
Try like this:
- enable the first component disabled;
- offset curve don't work perfectly, I'll try to fix it maybe...
- bake the brep and convert it into mesh in rhino;
- for the thickness, do a solid offset of the mesh in rhino for last phase, it just works better.…
n account of the position of the sun and weather cannot be expressed in terms of a single set of luminous intensity values (which is what IES files do).
With regards to your example files, I agree with Chris. The primary reason for the low illuminance levels is that the light bounces are getting lost in the tube. Have you checked with the manufacturer/distributor if the location of the IES file should be inside the tube and not flush with the ceiling? Physically modelling such tubes in lighting software like Radiance (which is what HB uses) or AGI32 is a fairly expensive proposition. This is one of the reasons why manufacturers provide photometric data for such devices (however simplistic that data might be).
The candelamultiplier increases or decreases the luminous intensity values. So it will have a direct impact on the calculation. The primary reason for having that input was to enable users to do some testing with different lamp types and environmental factors such as dirt depreciation. You need not change them for your simulation. Assuming that the IES file is inside the tube, in order to make this calculation work inside HB you'd have to crank up the calculation settings to a very high level (start with -ab 10 -ad 4096).
Finally, due to shortcomings in the annual simulation software (Daysim), IES files will not work directly work with annual calculations. However, there is a fairly easy workaround for that issue. In case you are planning to run annual calculations with IES files, please let us know here.
Sarith…
me research involving shades and and solar radiation and I need the sun's path through the entire year to fully optimize the design. This far I've been able to simulate what I want by having my shadders following a mock solar orbit around them, what I need to know is to use a model that simulates solar paths, use it as an attractor point and have my shadding surfaces follow it, pretty much like that I am doing right now (or so I think)
Here's where my questions come around:
I remember finding somewhere on the internet a definiton that simulates the sun's path through the year; I think I can find it again and use it for my purposes. I think that I could just run the GH definition, bake the geometry and then upload it to Ecotect and have it run so I can get the data and keep working over that, then feed the geometry again to Ecotect, ad nauseam. However I think that is a very slow process.
Is there a way that I can run an Ecotect plug in of sorts within GH, that way I can get my data IN grasshopper and model accordingly?
Does that make sense?
Thanks a lot for any input.…
Added by Antonio Tamez at 3:40am on October 24, 2011
s for the sunlight hours analysis.
I'm producing BRE Annual Probable Sunlight Hours calculations and so to match the BRE approach, I'm using 100 sun vectors, each representing 1% of probable sunlight hours. I could use the Sunpath and Analysis Period components to produce sun positions for the whole year, but this gives results that do not fully reflect the BRE methodology - which is important here. I'm detailing this just to clarify that this isn't a full annual calc of 8760 hours for 350 surfaces.
Anyway, when I run the calc, it takes about an hour to run, but the Sunlight Hours Component itself reports a calculation time of 3 seconds! Does this mean that the rest of the time is all about prepping the brep geometry? If so, is there a reason why this is much slower than when using a view of sky recipe and exporting to radiance. For the same project, I completed a view of sky calculations and based on the number of test points and -ad setting, this was completing about 5.25 billions rays so I understand why that took an hour.
Any thoughts as to why the sunlight hours calc seems to take so long?
thanks
Nick
…
s topology gets pretty bad for use in CAD programs, since they are "in and out" at the same time. Generate naked edges and non-manifold edges. The problem itself is when I make an offset of the surfaces, which create "bad objets" in Rhino. I'm using Mantis, a plugin for Mathematica software, and one based on this the Math Surfaces script from http://www.co-de-it.com/wordpress/code/grasshopper-code. Both give me errors. I have tried to make a merge with the normal flip in the same model, but the error continues. If I do a split, in Rhino, there is no problem to create a solid offset, but the opposite is totally different if I make a Mirror. Can you help me with this complicated issue? Thank you.…
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~
…
thought that architect's love for drawing comes from the necessity of translate abstract ideas into built 3D reality, and the technology behind that 2D representation has not evolve so much until some decades ago. Our teachers come from that times: times when computers try to find their place in the reality representation world. If you try to imagine that people that have always drawn with pencils adapting to this new tools...some become fan of new methods, other just keep the old fashion workflow (like Andrew said in the article, Schumacher VS Graves)
We've bear (at least Andrew and me :P) in 80's with first video games, computers (I still remember my old x286 with 1Mb RAM and 20Mb of HD and that MS-DOS interface)...New technology was natural for us...But there is a big difference between traditional drawing and new computer aided tools: the learning curve. To draw you only need to take a pen and put over a paper (that interface is understood by children easily) , but traditional computational tools (new touch interfaces are out of this group) are based in a complex logic and environment that is not easy to understand for some people.
In the workshops I'm teaching in, I try to put all that tools (new and old one) in my students hands and motivate them to mix and use them together (Andrew knows a little bit about that :P). Why not to make a lines sketch with GH and then print it and render with some markers?; the last step could be scan the result and enhance it in Photoshop adding textures, vegetation, some background...There are no rules, only a bunch of tools to explore and use to develop your ideas, evolve and finally represent them.
I bet to the touch interfaces (with some augmented reality sauce) like that one that will be able to blend both worlds, analog and digital, offering that fluidity and natural interaction that Grave miss in digital tools. And our generation attached to this "not natural" interfaces will need to change its mind and adapt to that new and amazing interface that our children will love.
Only to complete:
<iframe width="560" height="315" src="http://www.youtube.com/embed/aXV-yaFmQNk" frameborder="0" allowfullscreen></iframe>…
Added by Ángel Linares at 5:40pm on September 10, 2012