eñadores, y creativos interesados en el aprendizaje de metodos avanzados de generación y racionalización de geometría compleja, y su implementación en distintas etapas del proceso de diseño.
Se abordaran los conceptos básicos para hacer frente a diversas problemas de diseño a través de la implementación de una serie de plataformas computacionales con el objetivo de construir un flujo de trabajo que permita optimizar proyectos de diversa escala y explorar esquemas geometricos complejos de manera rápida y eficiente.A lo largo del 6 dias trabajaremos con la plataforma de Modelado 3d Rhinoceros, el entorno de programación visual de Grasshopper y el motor de Renderizado de Vray.Estudiantes: $4,500.00Profesionistas: $5,500.00info+inscripciones:workshop@complexgeometry.com[044] 33 3956 9209[044] 33 1410 8975[044] 81 1916 8657
…
ace Syntax." eCAADe 2013 18 (2013): 357.
http://www.sss9.or.kr/paperpdf/mmd/sss9_2013_ref048_p.pdf
The measure Entropy is newer. I hereby explain it (from my PhD dissertation):
Entropy values, as described in (Hillier & Hanson, The Social Logic of Space, 1984) and specified in (Turner A. , “Depthmap: A Program to Perform Visibility Graph Analysis, 2007), intuitively describe the difficulty of getting to other spaces from a certain space. In other words, the higher the entropy value, the more difficult it is to reach other spaces from that space and vice-versa. We compute the spatial entropy of the node as using the point depth set:
(11)
“The term is the maximum depth from vertex and is the frequency of point depth *d* from the vertex” (ibid). Technically, we compute it using the function below, which itself uses some outputs and by-products from previous calculations:
Algorithm 4: Entropy Computation
Given the graph (adjacency lists), Depths as List of List of integer, DepthMap as Dictionary of integer
Initialize Entropies as List(double)
For node as integer in range [0, |V|)
integer How_Many_of_D=0
double S_node=0
For depth as integer in range [1, Depths[node].Max()]
How_Many_of_D=DepthMap.Branch[(node,depth)].Count
double frequency= How_Many_of_D/|V|
S_node = S_node - frequency * Math.Log(frequency, 2)
Next
Entropies [node] = S_node
Next
…
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)
…
ysim.ning.com/
When you run the simualtion you will notice on the batch terminal that Daysim is also being called, so you may want to consider how Daysim uses Radiance files & data.
Regarding your current problem, I think you stumbled onto something weird and interesting.
Interior and exterior readings appear to differ by 40 in the best case scenarios. Even setting the transmittance to 1 yields similar results. I tried changing from cummulative sky to climate sky and got similar values. Changing the test points did nothing either.
I think, (yet I'm too lazy to prove this) that the difference in values stems from diffuse radiation over the sky dome.
If you delete everything except the glass you'll notice that interior values are like 80-90% of the exterior values (this seems like the expected behaviour with a transmittance of 1). So, if we consider that a vertical window, part of an opaque box, is receiving radiation from 25% of a sphere, as you start to inset the interior test points the radiation they receive will be a fraction of the 25%.
Let me try to explain this better...The exterior surface receives radiation from a section of a sphere calculated by 180degrees on the xy plane (let’s call this angle theta) and by 90degrees (let’s call this angle phi) in azimuthal elevation. If you integrate this over spherical coordinates (theta from 0 to pi; phi from 0 to pi/2) you will find that it comes to a quarter of a sphere. By comparison, the interior surface will not integrate theta from 0 to 180degrees,nor phi from 0 to 90degrees, instead it will be the subtended angle from the exterior surface as a function of their separation; the farther in you go the smaller the view of the outside.
If my hypothesis is correct there shouldn't be that much difference since the separation is only 10cms...the subtended angle would be like 170 instead of 180 for theta and 85 instead of 90 for phi...overall if you integrate both spherical areas there should only by a difference of 10%.
In conclusion, I believe the unexpected behaviour stems from the previous subtended angle thing. If direct radiation was the only factor the difference would be the aforementioned 10%, which suggests that an additional source of energy is also affected by this. Perhaps indirect and diffuse radiation from other areas of the sky dome.
I’m definitely intrigued on why this is happening. Please post if you figure it out.
Regards,
Mauricio
…
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
r "virtual partitions" as follows:
What I mean "air walls" here, is derived from the description of the E+ documentation with the header of "Air wall, Open air connection between zones". (Page 17, http://apps1.eere.energy.gov/buildings/energyplus/pdfs/tips_and_tricks_using_energyplus.pdf)
As I understand, the term "air wall" used in E+ here refers to a description of something like "boundary condition" between adjacent interzone heat transfer surfaces, but not a kind of "construction or material" (like air space resistance or air gaps within a wall/double glazing window).
The main purpose of introducing the "air wall", is to simulate or approximate the airflow/convection/natural ventilation effect between multiple thermal zones which are connected by a large opening.
In my previous tests, using HBzones and GB, I managed to create the gbXML file which can be successfully imported to DB (without assigning any constructions within HB). And the adjacency condition can be recognized automatically by DB, even when I did not use the "Solve adjacencies" component in HB - shared surfaces between multiple thermal zones are recognized automatically by BD as "internal - partition"(which are standard partitions, but not virtual partitions).
In order to create/approximate "virtual partition", I need to manually draw a "hole" in the standard partition surface (fig.1&2). Again, the reason why we want to use "virtual partitions"(or "air wall") is that it allows airflow between multiple thermal zones which are connected by large openings and we could get different temperature of the each subdivided thermal zone which compose a large thermal zone.
My question is, if there is a possible way to simulate/approximate this kind of "virtual partitions"(or "air wall") in HBzones or in GB? If so, I would like to test if DB recognizes it or not. Actually, we expect that there is no need to involve any manual operations (like drawing a "hole" in the standard partition surface) in DB, due to an automatic optimization loop.
Thank you!
Best,
Ding
fig.1
fig.2
…
unity in Ukraine, which is orientated to contemporary architecture.
The results of CANactions will be published in ACC magazine (link), on the web-sites of “Architectural club” (link), AB "ZOTOV&CO" (www.zotov.com.ua),
Theme
Theme of CANactions 2009 is emergent design techniques.
This theme could include following architectural branches as Digital design, sustainable architecture and other sectors, which by the participants’ opinions, could be EMERGENT.???
Any architectural projects made earlier of specially for the CANactions’09 are allowed for submission.
Presentation
All the projects will be submitted in two phases:
Phase 1 – selection of 10-15 participants of CANactions.
Project has to be sent by e-mail to: (__) in PDF (not less then 300 dpi, not more then 10 Mb).
Phase 2 –the CANactions participants prepare 15-20 min presentation of their projects (screen projector, microphone) and materials for the exhibition in House of Architect, Kyiv. The project has to be presented by author. -> exhibition is the first architecture biennale
Presentation requirements: file should be composed in PDF format on A0 sheets, placed horizontal (not more then 1 sheets). This file should contain sufficient amount of the presentation graphic material, including text explanation up to 300 words.
The raster images should have printing definition not less then 300 dpi. It’s recommended to avoid solid black fillings, because the projects will be printed on ink-jet printer.
The presentation requirements could be changed after phase 1 results.
The presentation materials should be made in Ukrainian (or Russian) and English. Verbal part can be presented in any language.
Tarek Naga, Naga Studio, Los Angeles / USA (I can contact him - he will do it for free)
Awards
DIA (Dessau Institute of Architecture), Germany gives a prize: certificate for the education for 1 (2) semesters of Master-program in DIA for students and young architects (up to 30 years) from Ukraine. The decision about the prize winners will be made by selection board.
Guests presentations
- Daniel da Rocha DIA /Germany/ (flights, accommodation?). Theme: (scripting???)
- Aleksandr Kalachev DIA /Riussian Federation/, Tudor Cosmatu DIA /Romania/, Irina Bogdan DIA /Romania/ - "Parametrically Defined Urban Patterns".
- Grygorii Zotov DIA /Ukraine/ - “The Multicultural Columbarium”.
- Armen Menendian /USA/ - "Blending Parametric Methods With Traditional Design:
"The Danish Pavilion at Shanghai EXPO 2010".
Exhibitions
1. Projects of 10 (15) CANactions participants
2. other projects: Zotov+Co
Bollinger+Grohmann - structural eng.
the very many
C-Space Pavillon / alvin huang
ala _ amanda levete studio
anOtherArchitect
student work, Charles Walker, AA Unit Pavillon
Event schedule
Phase 1: 01.07.2009 – start of the CANactions 2009 and beginning of projects submission.
16.08.2009 - dead-line of the project submission of phase 1.
Phase 2: 17.08.2009 – announcement of the CANactions 2009 participants.
30.08.2009 – dead-line of submission of the CANactions 2009 exhibition materials.
14-26.09.2009 – exhibition of the CANactions 2009 projects in House of Architect, Kyiv.
25-26.09.2009 – CANactions 2009.
26.09.2009 - finnissage / announcement of competition winners for DIA study
Contacts: canactions2009@gmail.com…
Added by Grisha Zotov at 6:32am on August 10, 2009
y case. Here's the thing. There is this subject at my university where we are assigned a famous building and we need to recreate it in Rhino. We're given bonus points if we manage to code some interesting part of it in Grasshopper. So far so good, I'm doing pretty well with Rhino and by far I am happy with the results I've achieved with modelling the given building. Harbin Opera House by MAD is the building I'm trying to model. There is one particular surface:I've built this surface in Rhino and now I'm trying to map pyramids on it. Not only have the pyramids to be different in height, but their height has to be dependent on the curvature of the surface. I'm getting some results but it seems to be exactly the opposite of what I need. I want to have higher/spikier pyramids where my curvature analysis shows red/blue and lower/slopier pyramids where the analysis shows green colour.At the moment I'm not really sure how the code I have works, but it seems that the height of the pyramids is dependent on a distance from a point in space to the projection of the cap-point of a pyramid.Here're my Rhino and Grasshopper files:surface1.3dm
surface1.ghI'd be grateful if someone of you guys could handle my problem. I've got one more issue with this surface, but once I get a solution to the first 1 will let know what the second one is.Thanks in advance and keep well!…