Amuse yourself by trying to figure what kind of series logic could deploy (or not) these room unit combos across the blue space grid shown.
2. Let's assume that surgery etc etc departments are sited in some ground floor and their requirement for rooms is variable ... meaning that some kind of heuristic GH approach must be applied here (for instance : fill the first level with rooms required by all departments with min distance from a given core and if more are required go to next floor etc etc).
The real room unit cluster looks like that (all units are prefab)
3. Voids in the whole cluster deployment (avoid Soviet type of bloc aesthetics) mean that culling could be challenge here (we need ...er..."visual" culling , so to speak)
4. After finishing some solution create custom preview(s) in order to visualize what dept owns what rooms.
5. If in trouble with Architectural things > relax > be cool > open 3d PDF > be a great Architect in just 10 easy steps.
PS: of course I know GH clusters...but as they are they violate my rule N1: never walk the walk if no return is possible, he he. But assuming that David could resolve the return issue (sure he can) this is NOT the answer for my "proposal" for multiple Canvas - again like multiple Views in any CAD stuff these days. Just imagine clusters with some serious hierarchy depth > where am I ? what input comes from what output?
I'll be back with a chaotic case (Series in complete anarchy) in order to demonstrate the critical necessity for a visual Tree Manager/Viewer (a visual thing within the GH visual thing). For manager read : decomposer, composer, visual identifier (per data item/branch) tree re-mapper, anything actually.
more soon (and a in depth analysis about what a Tree Manager/Viewer should do - in an ideal world, that is)
Cheers, Peter
…
urely; an inevitable symptom of developing a piece of software on what Generative Components was doing almost 10 years ago, and creating a generation of users who have the power but not the insight in to how to use these tools properly. Ever seeing, never perceiving.
@ André-Jacques BODIN: as answers so far seem to be coming via links, try this: http://www.bentley.com/en-US/Products/GenerativeComponents/
you can download the latest version for free and it is infinitely more superior to GH. The learning curve is steeper but worth it. Out of experience I can tell you that the problem you have would be solved via your own skill and intelligence in a matter of seconds, rather then clumsily relying on somebody else to write some code 'packaged' as a component, and ultimately restricting your capacity to explore novel design solutions in an intelligent way.
If you are going to work in practice then unfortunately GH becomes utterly useless as it can only really be used in the initial stages of design. Its merely a toy for students and hobbyists. If you are just starting out, invest your time more wisely and learn something which can be used over the entire life cycle of project. It's so versatile that you essentially have unlimited potential and all operations remain fully in your control, or put in another way; you're not restricted by the idiosyncrasies of another programmer who's 'components' might be totally unsuitable for a novel idea you may want to explore therefore killling it.
…
find my initial files, reports and errors (Running E+ simulation on the initial setup took hours and ended up with numerous errors)
I got a number of questions and would appreciate if you could answer them:
1- I have duplicated zones using "Honeybee Move". Is this the correct way to duplicate zones and if yes, should I rename all surfaces afterwards? I have renamed zones but not surfaces (The tower has 40 floors = 10 x typical group of 4 floors)
2- Should I convert all curvilinear objects to faceted geometry (or only windows and window-walls should be flat)?
3- In the next stage, I will add a second skin as the outer facade. Spiral structural elements (insulated thermal mass) are between interior and exterior areas, partly exposed to the sun. Should I split both interior and exterior zones to subtract these elements, and then solve the adjacencies?
4- To simplify the procedure and make it faster, I may simulate only 4 floors. Is it possible to force-hide the top roof and the lowest floor from the sun and other environmental factors? If yes, how? and do you know how much accuracy in the results would be lost in this case? 5- The outer skin would be all in glass, therefore in reality, the direct sun will affect the inner skin and the structural elements. I read somewhere that in HB+E+ simulations, direct sun turns to diffuse after passing the first layer of glass. Is that true? If yes, how can I make the inner skin exposed to direct sun in the simulation? Thank you very much for your time.
Best,
Aryan
…
try to get the output. In this case the output needs to be set before requesting for it. I am doing it with this call:
ret = gsaobj.Output_Init_Arr(1,"Global","A1",14003001,3)
In API help the call is documented like this:
short Output_Init_Arr (long iFlags, string sAxis, string sCase, enum ResHeader header, long num1dpos)
so this call has 5 arguments (long, string, string, long, long) (the enums are defined as longs)
This call works, because when I print the ret, i get 0 that is "succeded" so everything works so far.
Then I request the output with the following:
results = []
ret = gsaobj.Output_Extract_Arr(10,results,numcomponents)
In API help the call is documented like this:
short Output_Extract_Arr(long iRef, SAFEARRAY(struct GsaResults)*arrayResults, long* numComponents)
I am getting the error "
Runtime error (ArgumentException): Could not convert argument 1 for call to Output_Extract_Arr."
So it seems that is not accepting 10 as a long in the beginning (assuming that argument 1 is the first). I already tried passing a variable as long, using long(10) there, nothing works.
Furthermore I don't know if the other two variables are correct like that. I come from VBA where I need to declare everything but AFAIK python is more permissive in this sense. "results" should be a dynamic array of objects and "numcomponents" a long.
Any help would be appreciated!
Thanks! :)
…
stributes structural supports for a uniformly loaded domain using e.g. the internal energy of the loaded domain as fitness. Here the uniformly loaded domain is represented by the trimmed surface. My genomes are the support positions (green crosses), which are restricted to a set of predefined grid points. I’m currently using an (i,j)-coordinate indexing for these grid points (illustrated in the viewport just below) as opposed to a sequential , “one-dimensional” numbering (illustrated in the viewport further down).
(i,j)-indexing systemAltenative, sequential indexing system
The support positions are computed by two gene pools; one governing the i-index, Gene List {i}, and one governing the j-index, Gene List {j}, of each support. The value of slider 0 in Gene List {i} is paired with the value of slider 0 in Gene List {j} etc. and the amount of sliders corresponds to the amount of supports. The screen shot below depicts the slider constellation corresponding to the support distribution depicted above. Unfortunately the j-index represented in the sliders needs remapping as the number of j-indices vary for each i-index (horizontal row of grid points). With the current setup I have 12^6 x 9^6 = 1,6 x 10^12 different genomes. If I were to use the sequential, “one-dimensional” numbering, I would only use one gene pool with sliders ranging from 0 to 76 meaning that remapping could be avoided and thereby having only 76^6 = 1,9 x 10^11 different genomes.
So, my current genome setup causes a bunch of issues related to the Evolutionary Solver: Remapping Changing one of the j-index sliders, will not necessarily change the related support position but it will still facilitate another genome to be calculated by the solver. (This problem could be eliminated by using the sequential, “one-dimensional” numbering)
Switching slider values around If the values of e.g. slider 0 were to be switched around with the values of slider 5, this again would yield a new genome but an identical solution. (This problem cannot be eliminated by using the sequential, “one-dimensional” numbering)
Coincident support positions Two or more supports may be located in the same position. (This problem cannot be eliminated by using the sequential, “one-dimensional” numbering)
I find it impossible to imagine the fictive “fitness landscape” of this problem and not only because of the multidimensional genome characteristic but just as much because of these listed, intertwined peculiarities. I’ve tried running the Simulated Annealing Solver as well, but my experience is that the Evolutionary Solver yields better results. To my awareness, the solver uses some kind of topographical proximity searcher. This is why, I think that the solving process itself benefits more from analysing the (i,j)-index system, in which neighbouring grid points hold more uniform topographical information than the sequential, “one-dimensional” numbering, which might have big ID-numbering gaps between neighbours. Have I understood this correctly?
Cheers…
cusing on dynamic sketches and prototyping. The workshop will be held in New York City during the weekend of February 19 and will be co-taught by Marius Watz (evolutionzone) and Studio Mode.
Description:The paradigm of scripting within ubiquitous modeling platforms such as Rhino or Maya allows users to generate complex form by accessing an underlying geometry engine and performing iterative functions. This paradigm is typically based on run-once execution, making it unsuitable for designing interactive or time-based behaviors. By implementing workflows that utilize Processing to create real-time software sketches, we can design dynamic systems that can act as standalone tools for parametric design, input mechanisms to feed other platforms, or processors of existing or sensor-based data sets.
This fast-paced workshop will focus on interactive parametric design strategies. Using Processing as our base platform, we will design real-time dynamic behavior systems, implement interfacing techniques for fluid use, and iteratively prototype the solutions in physical format through rapid prototyping and digital die-cutting. Through a series of focused exercises and design tasks, each attendee will build a stand-alone parametric design sketch and work through the process of prototyping, realizing a set of solutions through computer numerically controlled equipment (Makerbot “Thing-O-Matic” and KNK High-Force Cutters). An optional third workshop day is offered to those participants desiring further time to develop individual projects or lines of research. As part of a larger online infrastructure, modeLab, this workshop provides participants with continued support and knowledge to draw upon for future learning.
Interactive Parametrics was conceived through a collaboration between Studio Mode/modeLab and Marius Watz/evolutionzone.…
Ruby, [9] R, [10] PHP ,[11] MATLAB [12]
Maybe it can find it's way into GH somehow..
when using the default GH random number generator i mostly use much higher seed values.…
Added by Robert Vier at 10:08am on December 27, 2012
f Virtual Build Technologies will debut their Rhino plug-in RhinoBIM and showcase its functionality. The presentation will cover using RhinoBIM for Structural Design Modeling, Structural Analysis, and more.
Title:
RhinoBIM Debut Webinar
Date:
Friday, March 4, 2011
Time:
9:00 AM - 10:30 AM PST
…
Added by Mary Fugier at 1:04pm on February 24, 2011
p others facing similar issues. 1) Letting Grasshopper perform the "implied" loop can be substantially slower than making the loop yourself inside the Python script. This is understandable, however the strangest thing is that it is MUCH slower if the definition has been saved than when it has not (by about a factor of 10)! 2) Setting type hints seems to be slower than inputting data with "No Type Hint". This depends a bit on which type is being input, but this seems to be fairly consistent. In the attached example by about a factor of 3. I suppose this is understandable, but not exactly ideal. 3) Outputtings lists with many items will often take longer than the actual computation performed by the script. I suppose this is more of a Grasshopper thing. My workaround has been to wrap the list in a Python list and pass this along as an item, which will be ALOT faster with large lists (this was crucial to both the Tower and ShapeOP where we pass around large amounts of constraints).
4) Calling certain RhinoCommon methods appear to be randomly much more expensive than using the C# scripting component. For instance, when iterating over a mesh's vertices and calling Mesh.Vertices.GetConnectedVertices() the elapsed time sum of these calls seem to be comprised of only a few vertices which randomly change every time the script is run. The amount of vertices differ on different machines, but the pattern remain consistent. I'm not sure if these bottlenecks are just examples of me being dumb, if so I hope you can enlighten me to the errors of my ways :) Attached some screenshots of an unsaved/saved definition which demonstrates the described issues. Also please find the gh definition attached. Best, Anders Edit: Logged this on Github here. Update: Added point 4), new screenshot and file demonstrating this behaviour.
System: Rhino Version 5 SR11 64-bit (5.11.50226.17195, 02/26/2015) Grasshopper 0.9.0073 GHPython 0.6.0.3 Laptop …
size component supported only ground PV panels and angled roof PV panels.
Download the newest PV SWH system size component from here (Click on "View Raw" to download it. Then move the downloaded .ghuser file to File->Special Folders->User Objects Folder, an confirm to overwrite it with previously located one).
Just a few opinions on the project you are currently working on:This kind of fixed, non-transparent (overhang) PV panels attached to a building facade are vert convenient for locations with higher latitudes.The reason for this is because they (fixed overhang PV panels) are dimensioned according to the sun position at summer solstice. Elevation angles on summer solstice at higher latitude locations are lower, than those of lower latitude locations.Due to Incheon's low latitude (37), you will get rather short length of the PV panels* : less than 10 centimeters (0.097 meters in the attached .gh file below). As you have mentioned, Galapagos needs to be used too.I will just mention some of the good and bad ways in which the upper issue could be somewhat avoided:1) Increasing the vertical distance between PV panels (PV panels appear above every second window).2) Increase the tilt angle. This will increase the length of PV panels also, but will decrease the final annual AC energy output.An example of this solution has been applied at FKI building in Seoul (latitude: 37N):I already did some tests (with tilt angles: 40, 45, 55) and this does not seem like a good solution, though.3) Shrinking the "sun window" by using the minimalSpacingPeriod_ input. In Photovoltaics, a planner is suppose to make the 9h to 15h part of the sun window free of any obstructions. If you try to decrease the "sun window" to 10 to 14h, the length of your PV panels will increase. You can try to experiment a little bit with this (set your minimalSpacingPeriod_ to 21th of June 10 to 14hours). In general, shrinking the sun window on summer solstice is not a good principle during planning.4) Using tracking PV panels, not fixed ones. But Ladybug Photovoltaics components do not support this kind of PV systems. They only support fixed ones.I would personally go with the first option. You can also experiment with the second and third one.Comment back if you have any other questions.-----------------------* By "length of the PV panels" I mean the: tiltedArrayHeight_ input of the PV SWH system size component.…