ologies and large-scale prototyping techniques from previous years, while bringing together a range of experts from internationally acclaimed academic institutions and practices, Architectural Association, Zaha Hadid Architects, among others.
AA Istanbul Visiting School will investigate the inherent associations between form, material, and structure through the rigorous implementation of innovative design and fabrication techniques. Computational methods for design, analysis, and fabrication will be coupled with physical experimentation. The key objective of AA Istanbul Visiting School will comprise the design and fabrication of a one-to-one scale prototype realized by the use of robotic fabrication techniques.
The programme will be formulated as a two-phase process:
Stage 1: Participants will gain an insight of material processes, computational methods, and various fabrication techniques, culminating with core concepts related to complexity in design practices. During this stage, basic and advanced tutorials on generative design algorithms and analysis tools will be provided.
Stage 2: Participants will propose design interventions based on the skills and knowledge gained during the first stage. Study models of various scales will be produced, finally followed by the robotic fabrication and assembly of a full scale working prototype which unifies the design goals of the programme.
Prominent features of the programme / skills developed:
Participants will be part of an active learning environment where the large tutor to student ratio (4:1) allows for personalized tutorials and debates.
The toolset of AA Istanbul includes but is not limited to Rhinoceros and Grasshopper, as well as analysis software.
Participants will have access to advanced digital fabrication tools.
Robotic design and fabrication processes will formulate the physical prototyping phase of the programme.
Eligibility
The workshop is open to current architecture, structural engineering, and design students, PhD candidates and young professionals. Prior software knowledge is not required.
Accreditation
Participants receive the AA Visiting School Certificate with the completion of the Programme.
Applications
The AA Visiting School requires a fee of £700 per participant, which includes a £60 Visiting Membership fee. Discount options for groups are available. Please contact the AA Visiting School Coordinator for more details.
The deadline for applications is 15 June 2018. No portfolio or CV, only requirement is the online application form and fees.
For more information, please visit:
http://www.aaschool.ac.uk/STUDY/VISITING/istanbul
http://ai.aaschool.ac.uk/istanbul/
For inquiries, please contact:
elif.erdine@aaschool.ac.uk
…
ll geometry.
The difference with programs like Inventor is that they are made for production, regardless of the fabrication method. I won't go into detail about that, and instead focus on the modeling process.
In this little model, the starting point actually is a bit obvious, the foundation.
The only contents in the 3dm file are 27 lines. These indicate the location of each footing, and the direction of the tilt of each column. Everything else is defined in GH with the use of numbers as input parameters.
Needless to say, instead of those lines you could obviously generate lines and control the number of columns and panels, hence establish their layout, with any algorithmic or non-algorithmic criteria you please. That marks a major difference between GH and Inventor.
You can generate geometry with Inventor via scripting/customization (beyond iLogic), with transient graphics for visual feedback similar to GH's red-default previews. However Inventor's modeling functions are not set to input and output data trees. I won't go into detail on that, but suffice to say that the data tree associativity of GH was for me the first major difference I noticed. I've used other apps with node diagram interfaces like digital fusion for non-linear video editing since the late 90's, so the canvas did not call my attention when I first started using GH.
Anyways, here's a screen capture of the foundational lines:
In the first group of components, the centerlines of the rear columns are modeled:
And the locations in elevation for connection points are set. Those elevations were just numbers I copied from Excel, but you can obviously control that any way you please. I was just trying to model this quickly.
The same was done for the rear columns:
The above, believe it or not, took me the first 5 hours to get.
Here's a screen capture of what the model and definition looked like after 4 hours, not much:
If you're interested, next post I can get into the sketching part you mentioned, which is a bit cumbersome with GH, but not really.
I wouldn't say that using GH to do this little model was cumbersome, it just needed some thinking at the beginning. You do similar initial thinking when working with a feature-based modeler.…
Added by Santiago Diaz at 12:44am on February 24, 2011
o Common - just like C#. But Rhino Python has a "Scripting Language Wrapper" which breaks commonly used taks down to simpler functions.
Here's a general Example:
Take a look at the code on this website http://wiki.mcneel.com/developer/rhinocommonsamples/addline). Generally it's Rhino Common code in three language to create a line. They look equally difficult.
But if you use Rhino Python Scripting you can use an simplified syntax to get the same result. It's very similar to Rhino Script.
The code would be:
import rhinoscriptsyntax as rsstart_point = rs.GetPoint("Get start point")end_point = rs.GetPoint("Get end point")line_id = rs.AddLine(start_point, end_point)
OK - No Error Tracking here, but still you can see that the syntax is much simpler. (And in the end you just have less lines of code you have to debug.
And the good thing about Rhino Python is, that you can mix these approaches. Once you reach a level where Rhino Python Script doesn't get you there, which by the way happens very rarely, you can still use the Rhino Common methods.
Also, in Python Sycripting 99% of what you probably would like to do is available as a "wrapped" script function.
Rhino Python Script is currently also better documented than Rhino Common for C# and VB.Net. If you have used Rhino VB Script before, these functions will be very familar to you.
I'm not sure, why it's currently a separate plug-in. I belive the reason is that Rhino 4 (which is supported by GH) doesn't support Rhino Python. Also it's currently WIP, so it needed to be updated more frequently than GH itself. In the long run (I believe) it might be integrated into GH as a general component
- Martin
P.S.: To use Rhino Python within GH is a little more tricky than my example - but nothing compared to developing C#
P.S.2 Here's the code with Error Tracking:
import rhinoscriptsyntax as rsdef AddLine(): start_point = rs.GetPoint("Get start point") if start_point is None: print "No start point was selected" return end_point = rs.GetPoint("Get end point") if end_point is None: print "No end point was selected" return line_id = rs.AddLine(start_point, end_point) return line_idAddLine()
…
I understand.
I think honeybee and ladybug together are already a great design tool. I didn't realize the whole story with CFD and the various ways you have tried. Have a lot of respect for your project and your colleagues that are working on this, and I hope you guys get enough credit just going for it considering just how ambitious your project is. and open-source equivalence of at least 7 percent equity share too :) as in per owners. if you guys can offer 1 year cliff and 4 year vesting I will consider joining your team. just kidding what your team is doing are beyond me.
After checking simulation CFD 2015, I realized that one big advantage for LB+HB is that well, I didnt see a built in feature of taking account for direct solar gain as part of the simulation.
From the tutorials I have seen, they set the reference temperature to the exterior walls, but there is nothing solar. Here is a rather comprehensive video of how to set up for Simulation CFD . From 10:30 you can see that boundary condition for exterior walls is set with a film coefficient and Reference temperature (around 12:30). At 12:33, there is actually a parameter called radiation right below. I check the parameters for that myself and found that it includes emissivity and reference temperature but not watt hour per square meter like we have it with ladybug.
SO even for a software like simulation CFD, which already seems very sophisticated with the pay-as-you-go cloud parallel simulation option and all, I don't see that it is designed for simulating natural ventilation. Since with SIM CFD it seems that one can be precise about everything including heat plumes from artificial lights in terms of watts so I am guessing that there is a way to model in solar gain as some kind of projected geometry somehow but it is pretty clear that there is EXTRA WORK needed to factor in solar gain there.
I think it would be pretty major if there is a way to model solar radiation and CFD for interior/building envelop together because I have not seen that kind of simulation in the industry.
Thank you for the extra ref cayote and coolvent. I will make check them out along with SAM.
p.s. I reread what I wrote and just wanted clearify I sure didn't refer to any of your work with honeybee or ladybug as "artistic illustration." I meant my pretty arrows :)
…
you get started with them but at the same time that's exactly what makes Honeybee as flexible as it is right now.
I'm borrowing a number of slides from Chris's presentation where he uses the analogy of tool vs toolkit to describe how the vision behind Ladybug + Honeybee is different from other available tools. It's the nature of the toolkit to have several options for the same problem:
At the same time, I totally agree with your comment that there is a great chance in improving the current "toolkit" by re-evaluating the components and re-structure and/or merge them together to make it more user friendly. We tried once to re-structure the components based on our understan... to address similar issues to what you mentioned but the instant feedback was pretty negative. As a result we reverted back to what we had in place.
Here is exactly where we need suggestions from you and other users. Please consider submitting issues for all the changes that you think can make Ladybug and Honeybee easier to learn and use. Now is the best time as we're almost re-writing everything.
The underscores are there for a reason. They indicate which inputs are required, optional or required with a default value. Check number 4.
I'm not sure what do you refer to by blank inputs? Do you mean the separators? If that is the case then yes. That's the limitation that we currently have to group inputs.
Back to the integration of new codes (such as this one) into older components it's not as easy as it sounds mainly because of the way that the current components are developed. I'm doing my best to get this issue solved for the new development. Also once we have an API users can make their own customized components which will make it easier to keep the official components for Ladybug and Honeybee to essential components.
Mostapha…
good value so 4 times would get you there.
Ok. I understood. You have to consider that the mesh displayed is generated by genTestPoints component where the grid size is effectively 0.5m:
The pressure plot you shared above, it seems like your cell size varies, are you using any gradient options in the blockMesh step? In this example there'd be no need, as all areas are equally important.
The pressure plot varies because I have modified the cell grid size of the meshParams component in (0.25, 0.25, 0.25):
Now, I have re-uploaded the basic values of (1,1,1) and modified the cell size in the blockmesh component as you suggested in the previous post:
As cell size by default, this component considers the length/5. So, in this case, there would be a cell size of about (1.5, 1.1, 0.6). It’s correct? But If I display the mesh with load mesh component connected to the case output of the snappyhexmesh component, I find this:
With a cell size of (0.25, 0.25, 0.25) as modified in the screenshot of the blockmesh component reported above, the mesh is extremely dense:
The residuals decrease:
with a more clear image.
Regards,
Francesco…
’s mid-point and whose direction is perpendicular to that edge. The following images are a summary of how I’m currently doing this. Keep in mind that the shared edge is not always parallel with the x, y or z axis… in fact it usually isn’t.
This is the vector I'm trying to get...
This is my workflow:
1- Find centroids of surfaces...
2- Find mid point of the edge. The for each surface, create vector from mid point to centroid and also reverse the direction. Place a point at the end of each vector...
3-Test to see which of the two points for each surface is contained within each surface's boundary and select that point (this parsing is necessary in some cases depending on the shape of the surfaces)...
4-Here is the kicker. In cases where one or both surfaces are skewed, the centroid of that surface is not necessarily "perpendicular" to the mid point of the edges as evident here with surface B. So I create a plane (technically its a "frame") that is perpendicular to the edge...
5-I then pull both points to that plane...
6-From there its pretty straight forward as far as getting the required vector...
So is this the best way to do this. In particular I'm curious if there is an alternative to step 4, but really any comments are welcome.
Thanks,
cbass…
.3 and the Python plugin (IronPython seems to be pre 2.7).
After finally getting my setup to parse and work based on the most simple example files. I'm stuck going forward with XML namespaces.
Can't get ElementTree.register_namespace() to work, think it's due to old python version. Instead I found an old tutorial and workaround defining a variable namespace and using format().
This method worked fine until i got to the fourth nested "child" from root, which is a XLMNS in the XML file. The code below results in:
print "Find: " '{0}define'.format(namespace), "in:"print [elem.tag for elem in root.getiterator() if elem is not root]
print "Is Object: ", root.getiterator('{0}define'.format(namespace))
for define in root.getiterator('{0}define'.format(namespace)): print define.tag, define.attrib, define.text
try: defineexcept NameError: for define in root.getiterator('{http://schemas.mathsoft.com/worksheet50}define'): print define.tag, define.attrib, define.text try: define except NameError: print "Didn't find " '{0}define'.format(namespace)
>>>
Find: {http://schemas.mathsoft.com/worksheet50}define in:['{http://schemas.mathsoft.com/worksheet50}regions',#regions being first child
'{http://schemas.mathsoft.com/worksheet50}region',
'{http://schemas.mathsoft.com/worksheet50}math',
#math being third child, which I can iterate and find
'{http://schemas.mathsoft.com/math50}define', '{http://schemas.mathsoft.com/math50}id', '{http://schemas.mathsoft.com/math50}placeholder',
#.... Long list, can't find any child deeper than math ....
]Is Object: <generator object at 0x000000000000003F>{http://schemas.mathsoft.com/worksheet50}math {'resultRef': '0'} None{http://schemas.mathsoft.com/worksheet50}math {'resultRef': '2'} None{http://schemas.mathsoft.com/worksheet50}math {'resultRef': '4'} NoneDidn't find {http://schemas.mathsoft.com/worksheet50}define
Any thoughts?
Does cElementTree work better with namespaces or is it the same?
From XML file:
<worksheet ... xmlns:ml="http://schemas.mathsoft.com/math50">
<regions>
<region>
<math>
<ml:define>
<ml:id>
....
</ml:id></ml:define></math>
and so on..…
Added by Peter Fajers at 1:11pm on October 5, 2015
deform into rhombic dedocahedrons when they reach equilibrium.
http://mathworld.wolfram.com/CubicClosePacking.html
I was trying to model sphere lattice constrained within a boundary box. When inflated, they would not intersect with each other; they would stay in place; and would be malleable just enough to expand and fill in the gaps in between the spheres.
I started off with the help of this thread here(Thanks for those contributed!). As I understood, there was a bug in Kangaroo2. Solver can't handle more than one item plugged in. So I tried to understand David's Stasiuk's Script and adopted it with a few variations, please see gh file attached.
In the first 5 - I've used David Stasiuk's C# component-variable pressure (posted on June 9, 2015 at 12:25am): 'No. 4.5' being the most successful simulation so far(inflation value is kept very low so that they would not intersect);
although I realised I made some math mistake in setting the close packing grid.(could be checked by plugging voronoi3D to see if the area of the rhombic faces are regular)
No. 6-7 I tried with Kangaroo2 components.
After consulting my tutor(Andrei Jipa)'s help, I realised the following changes could be made:
- The definition posted by David on June 8, 2015 at 4:47pm with constant pressure would've worked better.
- Icosahedrons with WbCatmull(Quad divisions) would result in more even load distribution. With wbloop, vertices more concentrated at poles.
- Load in dir Z could be omitted. Andrei has suggested to use lengths(line) in Kangaroo 2 as 'pressure' instead. And I am trying to improve the grid; and maybe try with David's constant pressure definition. I will keep you guys posted of the progress!
I am new to the parametric world, comments/advice very much appreciated! :) Zhini
…
I miss DA.SetData the component gets null while taking the latency , on the other hand if use it the component has two kicks , is there anyway to get rid the first kick?
GH_Structure<IGH_Goo> D = new GH_Structure<IGH_Goo>(); GH_Structure<IGH_Goo> C = new GH_Structure<IGH_Goo>(); protected override void SolveInstance(IGH_DataAccess DA) { bool sw = false; int delay = 0; DA.GetData(1, ref delay); DA.GetData(2, ref sw); DA.GetDataTree(0, out D); DA.SetDataTree(0, C);
if (sw) C = D.Duplicate();
if (delay > 4)
base.OnPingDocument().ScheduleSolution(delay, cullback);
}
private void cullback(GH_Document doc) { var gate=base.Params.Output[0]; gate.ClearData(); gate.AddVolatileDataTree(C); foreach (IGH_Param i in gate.Recipients) i.ExpireSolution(false); }…
Added by Amin Bahrami at 12:00am on February 12, 2016