ucture.
With two modifications:
1. Each interlocking part shares its edges with neighboring parts. I want to separate the edges by creating another surface of user-defined width in between the edges.
2. Join ends of the hexagon from which this pattern has been derived using a triangle(red triangle in figure below). Actually, can also be done manually if its too difficult to script in GH.
Also, I want to control the groove height and width.
Could anyone share the script or help me create one for this purpose?
Best regards,
Sushant…
ing ways to leverage simulation results from ladybug and inform design of building envelops with benefits that can be modeled. Given 20 percent of the cost of a project typically goes to the facades, and maybe a half of that goes to the openings, there is a good enough reason to question how to materialize that 10 percent, which can result in 10-30 percent difference in total energy comsumption.
I think ideally radiation analysis, natural ventilation and daylight analysis on floors should all inform opening sizes and placements, as well as the building sections at large. However natural ventilation seems to be the most complicated one because it couples airflow and thermo dynamics. I have a definition setup so that I can batch simulations for radiation analysis and daylight analysis, but natural ventilation is the missing link. So for what I am doing now I will select a handful of design that seem to work the best based on the two available analysis and convert all the geometry into CAD files so that I can run them in an evaluation copy of autodesk simulation CFD. So for now I can do this in 2 stages.
But for the future, given the possibility of actually have that as a part of grasshopper feature, which would be lovely, I want to understand the science behind it and share some links.
(http://www.wbdg.org/resources/naturalventilation.php) In this link the author outlines quite a few general principles and variables to consider for natural ventilated buildings.
For example, how stack effect works.
Qstack = Cd*A*[2gh(Ti-To)/Ti]^1/2, where
Qstack = volume of ventilation rate (m³/s)Cd = 0.65, a discharge coefficient.A = free area of inlet opening (m²), which equals area of outlet opening.g =9.8 (m/s²). the acceleration due to gravityh = vertical distance between inlet and outlet midpoints (m)Ti = average temperature of indoor air (K), note that 27°C = 300 K.To = average temperature of outdoor air (K)
The thing about natural ventilation is that not only the sizes and positioning of openings of the facade facing predominant wind matter, but also the openings on the other side matter. The vertical distance between the inlets and outlets also need to be taken into account. The author suggests that naturally ventilated buildings should be no wider than 45 feet.
and in this pdf presentation it discusses CFD for natural ventilation and illustrates why it is not easy
http://isites.harvard.edu/fs/docs/icb.topic882838.files/L17.6205Airflow-Modeling_Ibarra.pdf
and in this pdf briefly outlines the approach taken by designbuilder
http://isites.harvard.edu/fs/docs/icb.topic472869.files/DesignBuilder%20Simulation%20Training_HSD.pdf
Lastly a wide spectrum of environmental analysis works by e3lab
http://www.e3lab.org/research
http://www.e3lab.org/green-buildings
If I make progress on a way to tie the three analysis together (radiation, daylight and natural ventilation), I wont forget to post it on this thread.
Thanks.…
e represents wind flow more accurately in lower heights. The general formula for the log wind profile is:
U(z) = (u*/k)[ln((z-d)/zo)] + psi(z, zo, L) (1)
where U(z) is the mean horizontal wind speed at heigh z, u* is the friction velocity (velocity scale representative of velocities close to a solid boundary), k is the von karman constant (empirically set at 0.41 for rough and smooth surfaces), d is the displacement height, zo is the specific surface roughness, and psi is a stability term.
Most cases assume neutral stability in the atmosphere to eliminate the psi term (i.e. z/L = 0) If not there are much more complex calculations required between temperature and wind speeds, essentially requiring numerical simulations to calculate the profile. With eliminating the psi term, it is easy to calculate the wind speed at any height z, provided we know the wind speed at reference heigh z1, like so:
U(z)/U(z1) = ln((z-d)-zo)/ln((z1-d)-zo1) -> U(z) = .... (2)
where z is the height we are interested in, zo is the roughness height in our case area, z1 is the reference height and zo1 is the reference roughness of the measurements. These are the measurements in the EPW file. The added information so far compared to the power law is that we also need the roughness level of the EPW data (usually near airports where roughness is very low, like 0.0002).
Another simpler way is to calculate the friction velocity first by:
u*=kU(z)/ln(z/zo), (3)
assuming d=0 and z is the reference height of the measurements. Then we can use this to calculate the wind profile.
While d=0 is an assumption I can understand, I do not really agree with accounting for a similar roughness level between the area of measurements and the case area. This is highliy problem and context specific. Especially in urban environments in my opinion it is almost always wrong.
The displacement height (d) is usually calculated as 2/3 of the average height in the area of interest (sometimes "average" has a qualitative connotation as "characteristic"). Accounting for displacement height does introduce a problem though, the wind profile below d meters is undetermined, since ln(x) is undefined for x<0. In order to solve there is a two-step approach which forms these two equations:
U(z) = (u*/k) x ln(z/zo1) for z < a*d
and
U(z) = (u*/k) x ln((z-d)/zo), for z > a*d
Literature mentions that the choice of zo1 and a (i.e. the boundary of the 2 profiles) is quite arbitrary and not very influential in the results. Usually, zo1 is much lower than zo since lower roughness is expected on a higher height, especially in urban zones.
The way I understand it, I think even implementing the simple formula (1) and then using (2) to calculate the profile is enough. For the inclusion of the displacement zone I imagine additional inputs would be required from the users and it would be their responsibility to conduct some sort of sensitivity analysis on the results. Equation (3) would be ok if no data on roughness level of the EPW measurement is available.
Anyways, that's my 0.02c. Bear with me and the mistakes herein, this isn't my specialty by a long shot and I'm just delving into all of this.
Some references:
Wikipedia ofc.
sts.bwk.tue.nl/drivingrain ( a nice page with a lot of additional references. The two-method was mentioned here).
wind-data.ch/tools/profile.php? (a nice online tool that calculates log-wind profiles) and gives the most commonly reproduced values (in the literature) for zo.
Wilcox, Turbulence Modeling for CFD (this is more related to CFD but it gives some background on the physics of the log-law)
Argain et al. 2008, Estimation of the Friction Velocity in Stably Stratified Boundary Layer Flows Over Hills (an example of the complicated calculations when not assuming a neutral stability in the atmosphere)
American Society of Civil Engineers (1999), Wind Tunnel Studies of Building and Structures (as always very good reference, provides the standard categories for zo values)…
t defined from the discussion of radiation exchange between urban surfaces and the sky in urban heat island research (See Oke's literature list below). It will be affected by the proportion of sky visible from a given calculation point on a surface (vertical or horizontal) as a result of the obstruction of urban geometry, but it is not entirely associated with the solid angle subtended by the visible sky patch/patches.
So, I think using "geometry way" to approximate Sky View Factor is not correct. Sky View Factor calculation shall be based on the first principle defining the concept: radiation exchange between urban surface and sky hemisphere:
(image extracted from Johnson, G. T., & Watson, 1984)
Therefore, I always refer to the following "theoretical" Sky View Factors calculated at the centre of an infinitely long street canyon with different Height-to-width ratios in Oke's original paper (1981) as the ultimate benchmark to validate different methods to calculate SVF:
So, I agree with Compagnon (2004) on the method he used to calculate SVF: a simple radiation (or illuminance) simulation using a uniform sky.
The following images are the results of the workflow I built in the procedural modeling software Houdini (using its python library) according to this principle by calling Radiance to do the simulation and calculation, and the SVF values calculated for different canyon H/W ratios (shown at the bottom of each image) are very close to the values shown in Oke's paper.
H/W=0.25, SVF=0.895
H/W=1, SVF=0.447
H/W=2, SVF=0.246
It seems that the Sky View Factor calculated from the viewAnalysis component in Ladybug is not aligned with Oke's result for a given H/W ration: (GH file attached)
According to the definition shown in this component, I assume the value calculated is the percentage of visible sky which is a geometric calculation (shooting evenly distributed rays from sensor point to the sky and calculate the ratio of rays not blocked by urban geometry?), i.e solid angle subtended by visible sky patches, and it is not aligned with the original radiation exchange definition of Sky View Factor.
I'd suggest to call this geometrically calculated ratio of visible sky "Sky Exposure Factor" which is "true" to its definition and way of calculation (see the paper on Sky Exposure Factor below) so as to avoid confusion with "The Sky View Factor based on radiation exchange" as discussed in urban climate literature.
Appreciate your comments and advice!
References:
SVF: definition based on first principle
Oke, T. R. (1981). Canyon geometry and the nocturnal urban heat island: comparison of scale model and field observations. Journal of Climatology, 1(3), 237-254.
Oke, T. R. (1987). Boundary layer climates (2nd ed.). London ; New York: Methuen.
Johnson, G. T., & Watson, I. D. (1984). The Determination of View-Factors in Urban Canyons. Journal of American Meteorological Society, 23, 329-335.
Watson, I. D., & Johnson, G. T. (1987). Graphical estimation of sky view-factors in urban environments. INTERNATIONAL JOURNAL OF CLIMATOLOGY, 7(2), 193-197. doi: 10.1002/joc.3370070210
Papers on SVF calculation:
Brown, M. J., Grimmond, S., & Ratti, C. (2001). Comparison of Methodologies for Computing Sky View Factor in Urban Environments. Los Alamos, New Mexico, USA: Los Alamos National Laboratory.
SVF calculation based on first principle:
Compagnon, R. (2004). Solar and daylight availability in the urban fabric. Energy and Buildings, 36(4), 321-328.
paper on Sky Exposure Factor:
Zhang, J., Heng, C. K., Malone-Lee, L. C., Hii, D. J. C., Janssen, P., Leung, K. S., & Tan, B. K. (2012). Evaluating environmental implications of density: A comparative case study on the relationship between density, urban block typology and sky exposure. Automation in Construction, 22, 90-101. doi: 10.1016/j.autcon.2011.06.011
…
mal surface usually derived via patch (God help us) on a boundary and some holes.
Note: I've mentioned God ... because patch (either using Rhino or GH) is a "bit" temperamental. I could provide a C# thingy that does this "automatically" ... but is quite probably off-topic here (not a new user task).
All that since you find K1/K2 a bit "complex" (but in general Kangaroo is rather the best add-on that GH has to offer not to mention the open nature of K2).
The bad news are that from that point and on ... you'll need K if you are after placing "patterns" (== the art of pointless if you ask me) in a minimal surface (or something that mimics a minimal surface).
The ugly news are that a thing that mimics a tensile membrane ...
Part 2 soon, best, Peter…
ously accounts for the thermal resistance in solid conduction through the width of the material. U = R^(-1).... R= L / lambda-solid ( per unit area - m^2 K / W)
The boundary conditions are likely being considered for convection and radiative transfer. Esentially the U-Value as used in the building industry is a coupling for:
Solid Conduction = ( lambda-solid / Length )* (T1 -T2)
Radiative Transfer = (1- reflectance) (irradiance) ... this is a simplification, it can get super complex
Convective Transfer = hahaha I cannot remember this... but it's essentially (Tsurface - T1) / Convective Resistance.
I just want to reiterate that I am not certain of the calculations carried out in therm. However, I am confident that the U-value is a simplification that couples all thermal exchange mechanisms into the reciprocal of a single resistance. U = 1 / R-coupled.
Hope this helps,
Mauricio…
ve collections since each double is related with a given Curve pair. The code captured below does that by accepting doubles or creates them (as Point to Point distance) and thus makes the required Clusters. Unfortunately is carried over solely via code.
2. On a much simplified level the following finds pairs of prox Curves. Also carried over solely via code.
Since you are asking about "commands" I assume that you are not familiar with coding.
…
, distributed with a slider.
I've made intervals from a series, using shift command. It's all fine but one; the last interval wraps to the very first, so it includes all the numbers in the series. I've been struggling for the past hour to fix this, but the hardwired solution I found makes the code meaninglessly long:/
I'm not sure if I was able to explain the situation correctly, so I'm attaching the file. You'll notice the oddity as soon as you see it :)
So I have two questions,
1) How can I fix this?
2) Is there a more efficient way to get the result I want, because my code seems kinda long?
Thanks in advance,
K…
ndfloor as groundfloor?
2. As I posted somewhere else this morning, here again: What's the right procedure to save E+materials into an *.idf so that created and (from library) chosen materials appear after HB's flying? Floors and Ceilings don't get E+materials from library...
3. I don't get heating- and cooling loads out of my model. Can it be that point 1. is the reason for that?
All I'm talking about in the attached file is pinky.
Attached you find the E+ Sim-Report and the *.gh file.
T h a n k y o u very much in advance!
Daniel…
SOFTWARE: Arduino Rhino PLUGINS: Grasshopper, Firefly Arduino is interfaced with a modified version of the Quadstepper Firmata written by Jason K. Johnson and Andy Paine. All Controlling of the Delta Robot is done in Firefly, a plugin for Grasshopper in Rhino. Attached are two Grasshopper files that are the necessary files for basic operation and control of the Stratum Networks Delta Robot. One file brings the machine to it's homing position while the other controls the path it takes to make the artifact. See SPARKFUN for Quadstepper Motor Driver schematics
…
Added by Wouter Bert at 5:41am on December 5, 2015