n be obtained for curved NURBS surfaces as well as unconventional window configurations".
And I also noticed the following information form the optional input in the runEnergySimulation component.
"meshSettings_: Optional mesh settings for your geometry from any one of the native Grasshopper mesh setting components. These will be used to change the meshing of curved surfaces before they are run through EnergyPlus (note that meshing of curved surfaces is done since Energyplus is not able to calculate heat flow through non-planar surfaces). Default Grasshopper meshing is used if nothing is input here but you may want to decrease your calculation time by changing it to Coarse or increase your curvature definition (and calculation time) by making it finer".
1) My case is an one-story, rectangular-plan large hall (40m*70m*25m) with a curved roof. The roof surface is a part of a standard sphere and the walls and floor are all planar (the each wall has one curved edge as showed in the image).
For testing, I threw the original curved roof surface into daylight and energy simulations without making customized meshings, because I assumed that it might be automatically converted to meshs by Honeybee - Am I right? As showed in the image, how can I reduce the number of meshs in a proper way? Must two connected surfaces (i.e. wall and roof) be STRICTLY/SEAMLESSLY connected or not (considering different divisions of meshs in the respective surface)? - Is a connection tolerance allowed?
2) But, when I run the annual daylight simulation for this case, it gave me a lot of warnings "oconv: warning - zero area for polygon".- is that normal? and how to avoid this? Does the daylight simulation allow "curved NURBS surfaces"?
3) Moreover, when I run an energy simulation for this case, it costed extremely long time. It was just so long that I did not even have results out of one simulation. - I guessed it might be the problem caused by the curved roof surface (or automatic meshing?), but I don't have experience of converting a curved NURBS/spheral surface into correct meshs that can be recognized by Honeybee simulations (Daylight and Energy) in a proper way.
4) The large window on the wall was generated by the "_glzRatio". But the automatically generated wall meshs around this window are just too "fine", which might largely increase simulation time. Is there a proper way to get rid of it? (Considering that the size, shape and position of the window will have large influence on the daylight distribution in the building, it is worthy to keep the size, shape and position of the window as it should be in reality).
In sum, considering all above, could your please provide me some suggestions/tutorials/links that might be helpful for dealing with "curved NURBS surfaces" in Honeybee simulations.
Thank you all in advance!
Best,
Ding
…
Geometry Gym but for now I would like to use Grasshopper only).
Kansai 1
Kansai 2
I am especially interested in the tubular 3 points truss (Kansai 2 link), although if I could get to know how to do the first type it would be great too. It would need to support a curved shell roof, like on the pictures.
I was thinking of doing it with paneling tools at first but I don't think it is really possible.
If someone knew of a tutorial for this specific design or could tell me how to do it (step by step, or send me some file that he has already done, since I am not very familiar with Grasshopper yet), it would be fantastic!
Thank you in advance for your help!!!!
Philippe…
ation model, and I would be very grateful if you could help me to have a look.
1. The air change rate is assumed to be 0.5 times per hour and the infiltration rate is 0.1 times per hour, so I sum these two values and set the converted infiltration rate per area as 0.0005 m3/s-m2. I don’t know whether it is appropriate to sum these numbers and input them together in the “infiltration rate per area” part?
2. I found in the latest version, there is a component called “air flow”, which can edit natural ventilation, but if I set minIndoorTempForNatVent equal to the heatingSePt as you showed once in the forum, the simulation result of heating is ridiculous high (like 7000 kwh/m2a). If the minIndoorTempForNatVent value is set to be a little higher than the heatingSePt, the heating result looks much normal (like 200 kwh/m2a). I don't know whether there is anything wrong with my model or settings, and hope you could help me.
3. I want to add the cooling and heating COP values (2.8 and 0.8) in my simulation process. I have noticed that in the forum, you mentioned that the new component "setEPIdealAir" can help to add COP, but I am still very confused about how exactly it works. I would be very grateful if you could show me again here.
4. I tried to change the WWR and the U-value of the wall, but I found the results of cooling and heating (especially cooling) vary little, which is not supposed to be like that. I guess there should be something wrong...
That's all for my questions.
Thank you so much for your time in advance. I would be very grateful if you could help me in this model. It would be very helpful for my work.
Thank you again!
Cheers,
Yao…
sh/pull options, any attractor number is well come, any brep tree as input etc etc).
bad news: in most of cases, the mesh looks like this: (+ a permanent red Exo W):
…
the join component and then iterates these curves through a move component(10 vectors) all is in order. Yet when I connect more than a single path the order of the generated curves as they are iterated through the move componenet seems to become arbitrary. All the curves connect, meaning Im pretty sure the first curve in path a is connected to the first curve in path b and c, yet this new curve is now curve 5 for instance.
As suggested I have attached a graf tree component which now seperates these curves in different paths before attaching them to the join slider. The result though, as I connect the latter to the move component, is that the ten resultant curves are iteraed 10 times. So 100 curves altogether instead of 10...
Any help would be awesome... Why does the join command destroy the order of the curves even when it seems to be fulfilling its (joning) function properly?
…
e Voronoi breps.
Load Rhino file first since the 2 are NOT internalized (Box is "stand-alone" anyway). Notice a myriad of conditions that make Exo W red (and some very odd results if you play with values). That's partially expected because a Voronoi brep may yield "tiny" edges that could yield non manifold "tubes" ... but still there's cases that in theory could not cause Exo W any trouble.
See the ex mesh VS the donor brep:
…
ield I had to use some different jumper settings as if I wanted to use the conceptinetics DMX library.
To send a chanel and a value I had to send a string from grasshopper like 001c255w to send the highest DMX value to chanel 1. See description in my code below:
/*jumper setup for Conceptinetics DMX shield:1st jumper to the right: "EN_"2nd jumper to the right: "DE"3rd jumper to the left: "TX-io"4th jumper to the left: "RX-io"
this jumper setup allows the shield to do the following actions without having to change any jumper:- transfer this arduino sketch to the arduino board- receive data from the serial port (grasshopper)- send data to a DMX device
<number>c : Select DMX channel<number>v : Set DMX channel to new value
These can be combined:001c255w002c0w003c0w --> Set channel 1 to value 255 and channel 2 and 3 to value 0.it is important that the channels are being addressed with 3 digits (001c instead of 1c)
http://dmxshield.blogspot.de/ http://playground.arduino.cc/Learning/DMX http://code.google.com/p/tinkerit/wiki/SerialToDmx http://groups.google.com/group/dmxsimple */
#include <DmxSimple.h>
void setup() { Serial.begin(9600); Serial.println("SerialToDmx ready"); Serial.println(); digitalWrite (2, HIGH);}int value = 0;int channel;void loop() { int c; while(!Serial.available()); c = Serial.read(); if ((c>='0') && (c<='9')) { value = 10*value + c - '0'; } else { if (c=='c') channel = value; else if (c=='w') { DmxSimple.write(channel, value); } value = 0; }}
…
rute force algorithm analysing all possible support constellations and their related w[max] values. Therefore I know the global optimum value of the fitness (smallest w[max]) and its related genome (location of the three point supports). Now the reason I've done this, is because I wanted to test whether one type of genome data structure would yield better results when fed to the Evolutionary Solver of Galapagos. The two genome data structures tested were the following types:
Sequential genome indexing for support positions, uses one slider per point support [supports @ node 2, 23 & 25]
Coordinate genome indexing for support positions, uses two sliders per point support [supports @ node (0;2), (3,5) & (4,1)]
My own hypothesis beforehand was that the coordinate indexing system would be the better performer, as I had imagined that the solver might build up some kind of geographic intelligence based on this genome information system.
Based on my tests with the Evolutionary Solver the two genome indexing types seem to perform equally well; they both manage to find the optimal fitness sooner or later with same hit rates. But now I worry that the used example might be too small to draw a final conclusion upon, and as I will be applying the same type of deflection analysis for more complicated deflection cases with both larger and arbitrarily shaped meshes having more than three point supports, I would like to ask:
Should the coordinate indexing system, theoretically speaking, perform better than the sequential indexing system? …
s is like flattening your data PARTIALLY - chopping an index off the end of the branch paths without obliterating the tree entirely. When working with one "set" of input data, a flatten works to get these lists to match up - but when working with multiple sets, we need to be careful to preserve the original branch indices that keep all four of your original regions separate. As a rule, whenever you're feeding two data trees into any component, they should have the same number of branches. (or one should have branches and the other should be a flat list, in other cases).
The rule of thumb I tend to teach is this:
In 90% of cases...
For lists, all your inputs should either have 1 item or N items. That is to say, if you're feeding 4 items into one input and 9 items into another, something is probably wrong.
For trees, all your inputs should have either 1 branch or M branches. That is to say, if you're feeding a tree w/ branches {0;0} to {0;3} into one input, and a tree w branches {0;0;0} to {0;3;8} into the other input, something is probably wrong.
Grasshopper essentially matches up branches first, then lists second. By "matching" I mean it processes them together. Simple example of the Line component - it will match the first branch of points in the A input to the first branch of points in the B input, creating lines between those points, then match the second branches, the third branches, etc. THEN, it applies the same logic to the level of the list (with a pair of matched branches {0;2}, match all the items in those branches to each other - first item in one branch to the first item in the other branch, etc.)
This is a tricky concept but it seems like you're already well on your way to understanding it from your definition - "PShift" is a critical tool in your path management arsenal. I hope this (overly long) response helps clear things up for you!
…