which needs to go in the first line only.
Each value K is one element of the knot vector
XYZ is an individual control point. Each point gets its own line/string in the output list
R is the weight of the XYZ point defined in the same line
I can get all these data into separate lists easily enough using the buttons etc. But getting them into the proper order and moving stepwise down the data to generate the desired output string list is eluding me so far.
My thought is to make an array of columns.
Column one is a list of knot values.
Column two is a list of X values.
Column 3 = list of Y values
Column 4=z values
Column 5 is weight values
etc
The idea would be to read the first value in each list into a list of five elements, then make a string out of it. The second value of each column into a separate string on the next line, then the third value from each column into the third string in the output list and so on.The last few values in the output list will contain knot vector elements only, as there are more of these than there are control points. Some of these curves are very long, with many control points, like hundreds and hundreds.
It seems I should be able to pull the lists of interest and combine them into a tree somehow; so far all I have been able to manage is to get them into a single list by starting with control points, then weaving each list of interest successively into the growing list. I'm thinking I need to get the list for each parameter into an individual branch, then read a path across the branches at each index value. But I am missing something about the terminology. I have watched a few videos and it makes sense when people are pulling nested geometry out of models, but this is a little different. More of a data management issue. I'm sure if I wrestle with it I will get it, but it may not be pretty. Any pointers appreciated. A couple of approaches are attached. Not sure whether to loop a list subset through the data or do something else. Thanks,
Karl in LA…
I am starting to wonder if I have some sort of mismatch between my GHA file and my Diva version, though I'm not sure that would cause these kinds of problems.
Incidentally, I tried creating a brand new file and I get the same results. I cannot save anything with DIVA components in them, they disappear every time. :(
Speaking of 2.0, do you happen to know when that will be released?
Thanks,
Marc
info: Plugin version: 0.8.0066 info: Plugin version: 0.8.0066 info: Object list read info: Plugin version: 0.8.0066 info: Object list read info: Plugin version: 0.8.0066 info: Object list read info: Plugin version: 0.8.0066 info: Object list read info: Plugin version: 0.8.0066 info: Object list read info: Plugin version: 0.8.0066 info: Object list read info: Plugin version: 0.8.0066 info: Object list read error: Component DIVA Daylight Analysis for GH {4ec4ef63-a2e3-4501-891c-dc1107bdd94d} failed to deserialize itself: Method not found: 'Boolean Grasshopper.Kernel.GH_ComponentParamServer.ReadParameterTypeData(GH_IO.Serialization.GH_IReader)'.
error: Component Material {842f969a-3d16-4b32-9aaf-d996bd25181a} failed to deserialize itself: Method not found: 'Boolean Grasshopper.Kernel.GH_ComponentParamServer.ReadParameterTypeData(GH_IO.Serialization.GH_IReader)'.
error: Component Construction Assembly {2f4beddf-fda7-4852-9820-c36101cd316d} failed to deserialize itself: Method not found: 'Boolean Grasshopper.Kernel.GH_ComponentParamServer.ReadParameterTypeData(GH_IO.Serialization.GH_IReader)'.
error: Component Fixed Shade {cc5c1712-3cb4-4e91-b322-ebc050a75c3f} failed to deserialize itself: Method not found: 'Boolean Grasshopper.Kernel.GH_ComponentParamServer.ReadParameterTypeData(GH_IO.Serialization.GH_IReader)'.
error: Component Read Saved Thermal Results {b71b827f-7e12-42a8-a44a-a9ebb1da1596} failed to deserialize itself: Method not found: 'Boolean Grasshopper.Kernel.GH_ComponentParamServer.ReadParameterTypeData(GH_IO.Serialization.GH_IReader)'.
error: Component Viper: Thermal Analysis for GH {8a8fd0f2-dcd8-4c3c-83dd-d74baf8dcaba} failed
…
e it as the same type. It refers to a different type definition apparently.
Error:
error: [A]MassPix cannot be cast to [B]MassPix. Type A originates from '7ea7fec0-99c5-49a8-ae80-af752ac2be94, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' in the context 'LoadFrom' at location 'C:\Users\pnourian\AppData\Local\Temp\7ea7fec0-99c5-49a8-ae80-af752ac2be94.dll'. Type B originates from 'fd0b2126-e10f-49de-9fc9-5504405d4135, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' in the context 'LoadFrom' at location 'C:\Users\pnourian\AppData\Local\Temp\fd0b2126-e10f-49de-9fc9-5504405d4135.dll'. (line: 82)
This is the case:
in component A:
Private Sub RunScript(ByVal x As Object, ByVal y As Object, ByRef A As Object) Dim kjh As New MassPix(2.1, 2.3, 4, 5) A = kjh End Sub
'<Custom additional code> Public Class MassPix Private x As Double Private y As Double Private S As Integer Private K As Integer Sub New(xu As Double, yv As Double, SZ As Integer, KL As Integer) x = Xu y = yv s = Sz k = Kl End Sub End Class '</Custom additional code> End Class
and in component B:
Private Sub RunScript(ByVal x As Object, ByVal y As Object, ByRef A As Object) Dim ABC As MassPix = CType(x, MassPix)
End Sub
'<Custom additional code> Public Class MassPix Private x As Double Private y As Double Private S As Integer Private K As Integer Sub New(xu As Double, yv As Double, SZ As Integer, KL As Integer) x = Xu y = yv s = Sz k = Kl End Sub End Class '</Custom additional code> End Class
the file is attached
ANY HELP IS VERY MUCH APPRECIATED! …
elease, so for now I am back to the basics - using only what is built into the official release for the time being.
Perhaps as plugins are updated, the updated version/ release date/ download link can be added to this compatibility list. If someone has beaten me to this on another site; please let me know.
Plugins I intend to test would solicit compatibility advice for;
CENTIPEDE
CHAMELEON / WORKS /
DIVA
FAR CALCULATOR / WORKS /
FIREFLY / UPDATED / Firefly (1.0067) now works for 0.9.006. Download at www.fireflyexperiments.com
FLOWLINES / WORKS / native tools provided in 0.9 release
GENERATION / WORKS /
GECO / WORKS / update scheduled for 10.08.2012
GH KANGAROO / WORKS / plus more on the way! (per Daniel Piker)
GHOWL / WORKS /
GHYTHON / FIXED / Link to updated file; GhPython 0 5 1 0
GOAT
HAL / PARTIAL COMPATIBILITY / Fix should be available toward end of Aug.
HELIOTROPE \ BROKEN \
HOOPSNAKE
HORSTER / WORKS /
HUMMINGBIRD / WORKS /
LOCAL CODE / WORKS /
LUNCHBOX / WORKS / UPDATED 8.04 DOWNLOAD HERE
MATIS
MESHEDIT / WORKS / update scheduled for 10.08.2012
QUOKKA
SCARAB
SLINGSHOT \ BROKEN \
SOLARCIRCLES
SPIDERWEB / WORKS /
STARLING / WORKS / VER 0.2 AND 0.1
PANELING TOOLS / UPDATED / http://www.grasshopper3d.com/group/panelingtools/forum/topics/pt-gh-new-release-of-august-22-2012
WEAVERBIRD \ BROKEN \
…
ing the maps to the broader community.
At the moment, there are just a few known issues left that I have to fix for complex geometric cases but they should run smoothly for most energy models that you generate with Honeybee. Within the next month, I will be clearing up these last issues and, by the end of the month, there will be an updated youtube tutorial playlist on the comfort tools and how to use them.
In the meantime, there's an updated example file (http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Indoor_Microclimate_Map) and I wanted to get you all excited with some images and animations coming out of the design part of my thesis. I also wanted to post some documentation of all of the previous research that has made these climate maps possible and give out some much deserved thanks. To begin, this image gives you a sense of how the thermal maps are made by integrating several streams of data for EnergyPlus:
(https://drive.google.com/file/d/0Bz2PwDvkjovJaTMtWDRHMExvLUk/view?usp=sharing)
To get you excited, this youtube playlist has a whole bunch of time-lapse thermal animations that a lot of you should enjoy:
https://www.youtube.com/playlist?list=PLruLh1AdY-Sj3ehUTSfKa1IHPSiuJU52A
To give a brief summary of what you are looking at in the playlist, there are two proposed designs for completely passive co-habitation spaces in New York and Los Angeles.
These diagrams explain the Los Angeles design:
(https://drive.google.com/file/d/0Bz2PwDvkjovJM0JkM0tLZ1kxUmc/view?usp=sharing)
And this video gives you and idea of how it thermally performs:
These diagrams explain the New York design:
(https://drive.google.com/file/d/0Bz2PwDvkjovJS1BZVVZiTWF4MXM/view?usp=sharing)
And this video shows you the thermal performance:
Now to credit all of the awesome people that have made the creation of these thermal maps possible:
1) As any HB user knows, the open source engines and libraries under the hood of HB are EnergyPlus and OpenStudio and the incredible thermal richness of these maps would not have been possible without these DoE teams creating such a robust modeler so a big credit is definitely due to them.
2) Many of the initial ideas for these thermal maps come from an MIT Masters thesis that was completed a few years ago by Amanda Webb called "cMap". Even though these cMaps were only taking into account surface temperature from E+, it was the viewing of her radiant temperature maps that initially touched-off the series of events that led to my thesis so a great credit is due to her. You can find her thesis here (http://dspace.mit.edu/handle/1721.1/72870).
3) Since the thesis of A. Webb, there were two key developments that made the high resolution of the current maps believable as a good approximation of the actual thermal environment of a building. The first is a PhD thesis by Alejandra Menchaca (also conducted here at MIT) that developed a computationally fast way of estimating sub-zone air temperature stratification. The method, which works simply by weighing the heat gain in a room against the incoming airflow was validated by many CFD simulations over the course of Alejandra's thesis. You can find here final thesis document here (http://dspace.mit.edu/handle/1721.1/74907).
4) The other main development since the A. Webb thesis that made the radiant map much more accurate is a fast means of estimating the radiant temperature increase felt by an occupant sitting in the sun. This method was developed by some awesome scientists at the UC Berkeley Center for the Built Environment (CBE) Including Tyler Hoyt, who has been particularly helpful to me by supporting the CBE's Github page. The original paper on this fast means of estimating the solar temperature delta can be found here (http://escholarship.org/uc/item/89m1h2dg) although they should have an official publication in a journal soon.
5) The ASHRAE comfort models under the hood of LB+HB all are derived from the javascript of the CBE comfort tool (http://smap.cbe.berkeley.edu/comforttool). A huge chunk of credit definitely goes to this group and I encourage any other researchers who are getting deep into comfort to check the code resources on their github page (https://github.com/CenterForTheBuiltEnvironment/comfort_tool).
6) And, last but not least, a huge share of credit is due to Mostapha and all members of the LB+HB community. It is because of resources and help that Mostapha initially gave me that I learned how to code in the first place and the knowledge of a community that would use the things that I developed was, by fa,r the biggest motivation throughout this thesis and all of my LB efforts.
Thank you all and stay awesome,
-Chris…
greatly appreciate it!!
You can write the number of the question and write your answer next to it, example:
1) a
2) c
3) a) Washington University in St. Louis
4) 2 weeks (1week+1week shipping)
5) 130
6) b
7) b
The survey questions are as follows:
1)
Did you 3D print before?
5)
How much did it cost (in dollars)?
a.
Yes, for a school project
a.
Between 20 & 50
b.
Yes, for a personal project
b.
Between 50 & 80
c.
Between 80 & 120
2)
Print size
d.
Please specify if otherwise: _____ dollars
a.
Between 2 & 6 cubic inches
b.
Between 6 & 12 cubic inches
6)
Do you think the price was expensive?
c.
Between 12 & 20 cubic inches
a.
Not at all
d.
Please specify if otherwise: ____cubic inches
b.
A little bit expensive
c.
Very expensive
3)
Where did you print your object?
a.
School
7)
Were you satisfied with the printed object?
b.
Outside school: _________________
a.
Yes, it was a great print without problems
b.
Not bad, some issues
4)
How long did it take to print?
c.
I was not satisfied, very bad quality
a.
___ days
b.
___ weeks
Thank you very much to all!!
PS: If you did many 3D prints, you can post multiple answers.
Wassef…
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
…
th the most crucial and imposing challenges that Mexico City faces and the ways in which architecture and urbanism can shape the metropolis at different scales. In these sense the progamme sees the city as a laboratory where the virtual and experimental tradition of the Architectural Association finds a fertile and concrete ground for the application of its methodology in Mexico.
“Manufactured Landscapes/Manufactured Urbanities” explores the metropolitan condition understood as a manufactured process by and for human beings. Henceforth the traditional opposing concepts, artificial vs nature, are replaced under the premise, nature does not exist, where nature is not natural but naturalised and the artificial is not an external or impose construct but manufactured intrinsically.
With this as a starting point the programme will study 2 instances of Mexico City’s “Manufactured Landscapes/Manufactured Urbanities”: The ravines in the west of Mexico City, last bastion of the existing “Nature” and its crucial role in the viability of Mexico City and social housing, as the fundamental construct of the “artificial” habitat in the metropolis´s urban tissue. These “Manufactured Landscapes/Manufactured Urbanities” and the ways in which they are designed, produced, reinvented regenerated, show a vast spectrum representative of the crucial urban conditions to be address and therefore they posed an enormous urban and architectonic challenge to confront in order to apply contemporary design methodologies.
To tackle the complexities of the “Manufactured Landscapes/Manufactured Urbanities”, the programme will immerse students and staff in a 10 day intensive workshop within a multidisciplinary environment where national and international experts from various fields will enrich their proposals. Students will work in architecture and/or urban scale teams and will critically assess the impact of their multiple scales interventions.
A backbone of lectures, talks and seminars, including local and international speakers, are designed to broaden and reflect the relevance and the importance of the topic for Mexico City. Finally a public exhibition of student’s work will be held at Centro Cultural de España in autumn 2013.
…
com/forum/topics/kangaroo-matters-relaxing...
For a simplified version of the lost data issue use the modified def attached.
Note:
1. In this case GH stored some data (3 out of 5 nurbs). Notice that the internalized info is dimmed (but "null" is the final output).
2. Image sampler suffers as well - here using a recent photo of me (+ my cat) as a test ("save in file = on" it doesn't work in pretty much all the cases).
If the sampler could work you should see this:
3. Imagine storing captured images in various directories and creating a GH def using some images from, say, directory "capture screens 17".
In some occasions Image sampler stores correctly the image file name ... but mess things as regards the donor directory:
Here's a typical example with image files stored and directory name "replaced":
…