ceros.
Public concerné /
Architectes et designers, utilisateurs de Rhino souhaitant paramétrer Rhinocéros à l’aide de Grasshopper, programme
associant des composants et une structure de graphe interagissants avec le modèle Rhino.
Une bonne connaissance de Rhinocéros est nécessaire. La langue de la formation est le français.
Structure et Objectif de la formation /
La formation se déroule sur 3 jours : les 2 premières journées sont consacrées aux « fondamentaux » de Grasshopper
avec en préambule une introduction au design et à l’architecture paramétrique et leurs impacts dans la conception, la
création et la construction.
La troisième journée sous forme d’atelier est dédiée à l’étude de cas concrets proposés par les stagiaires, qui, quelques
jours avant la formation, pourront envoyer leurs projets par mail à info AT rhinoforyou DOT com
Les stagiaires, après la formation, pourront rester en contact avec les formateurs de HDA par le biais du blog
complexitys.com et le twitter @HDA_Paris. La durée de cette formation permettra d’atteindre une autonomie et une
bonne compréhension basée sur des exemples concrets.
3 Formules possibles /
3 jours ( Initiation+Atelier ) : du lundi 20 septembre au mercredi 22 septembre
2 jours ( Initiation ) : lundi 20 et mardi 21 septembre
1 jour ( Atelier ) : mercredi 22 septembre
Programme ind icatif des notions traitéES pendan t la formation /
Introduction à la conception Paramétrique . Rhinoscript, Grasshopper: différences et similarités . Interface
graphique de Grasshopper . Objets, Données, Listes . Opérateurs scalaires : La mathématique de
Grasshopper . Gestions des données : la logique de Grasshopper . Vecteurs, Points, Lignes, Surfaces : La
géométrie de Grasshopper . Listes, Arbres, Branches . Le dessin paramétrique: exercices divers et exemples
. Références, Bibliographie, Support de cours . Ateliers d’architecture et design paramétrique (3ème jour) .
Moda lité de la formation /
Venir avec un PC portable équipé de Rhinocéros version 4.0 SR 7 et de la dernière version du plug-in
Grasshopper (téléchargeable sur www.grasshopper3d.com).
Le coût du stage est de 350 € HT/jour par personne.
Réserver votre place dès que possible car les places sont limitées à 10 participants maximum.
Inscriptions et renseignements: Jacques Hababou, info AT rhinoforyou DOT com
Pour en savoir plus sur l’architecture paramétrique: www.complexitys.com…
s are not required)
// Agenda
Parametric Design, in the history of architecture, has defined many rules for current designers and for future practitioners to follow. One of the strongest aspects that are prominent from this style is ‘geometry’. Arguably, there is nothing new about geometry and aesthetics forming the most prominent aspect of any style or era. The language of any style, in the long history of architecture, is visually defined by geometry or shape, beyond the principles that define the core of the style. In the distinguishable style of parametric architecture, geometry has played and is continuing to play an integral role. And with this fairly young style, there are many strings of myths and false notions associated.
The workshop aims to provide a detailed insight to ‘parametric design’ and embedded logics behind it through a series of design explorations using Rhinoceros & Grasshopper platforms, along with understanding of data-driven fabrication strategies. An insight to Computational Design and its subsets of Parametric Design, Algorithmic Design, Generative Design and Evolutionary Design will be provided through presentations, technical sessions & studio work, with highlighting agenda of using data into Hands-on fabrication of a parametrically generated design. A strong focus will be made on ‘geometry’ and ‘matter’.
// Methodology
Workshop has been structured to teach participants the use of Grasshopper® (Generative modelling plug-in for Rhinoceros) as a generative tool, and ways to integrate it with Hands-on Fabrication process. A strong agenda on ‘geometry’ and ‘matter’ will form the focus of the studio with design experimentation through computational & parametric techniques, culminating into a manually fabricated wall panel using understanding of data-driven design during the course of workshop.
…
nally used on the pre-intersected multizone file, which also needed the full exterior distribution only.
Running your revised version now on these machines here, the result is identical to the one you posted above (below screenshot from run on my machine; and yes, the last GH file I sent is the one from which the previous screenshots originated)
(CMap result from your attached script ComfMap_CWM, ran on MD machine)
That is, incidentally, identical to what my script produced even before your changes!
In an earlier post, you showed a result image that comes much closer to what I would expect the output to be (so, in fact, you have already produced two different results):
(screenshot from your earlier post on July 11, 2016 at 10:05pm)
The "error" I was/am hence chasing is in the difference between these two results. The last screenshot from your earlier results shows a radiant temperature dropoff that is much more in line with the contribution of the cold glazing temperatures as evident in the E+ results. What do you think?
Apart from that, I am glad that now, at last, our outputs from the same script are identical on both machines. The usercustomLibrary has not changed, I have however attached it again. Other GH files are usually not open, no; the last results all came from single open file GH instances.
Thank you for your help again Chris- it's an interesting issue. I owe you a beer (or a few) should you stop by in Berlin one day!
Best,
Max
…
whole design intent, but this is what Inventor is good at. The way it packages bits of 'scripted' components into 'little models' that can be stored and re-assembled is central to MCAD working.
The Inventor model shown is almost 5 years old. We don't model like that any more, however it does offer a good idea of general MCAD modeling approaches.
iParts is useful in certain situations, it could've been useful in the above model, its usefulness is often in function of the quantity of variants/configurations.
So much is scripted in GH, maybe it should also be possible to script/define/constrain/assist the placement/gluing of the results?
...
Starting point: I think we are talking across purposes. AFAIK, the solving sequence of GH's scripted components is fixed. It won't do circular dependencies... without a fight. The inter-component dependencies not 'managed' like constraints solvers do for MCAD apps.
Components and assemblies are individual files in MCAD.
Placement of these within assemblies in MCAD is a product of matrix transforms and persistent constraints. There is no bi-directional link, the link is unidirectional (downflow only), because of the use of proxies.
Consequently, scripting the placement of components is irrelevant in GH, unless you decide that each component needs to be contained in its own separate file.
This also brings up the point that generating components and assemblies in MCAD is not as straightforward. In iParts and iAssemblies, each configuration needs to be generated as a "child" (the individual file needs to be created for each child) before those children can be used elsewhere.
You notice the dilemma, if you generate 100 parts, and then you realize you only need 20, you've created 80 extra parts which you have no need for, thus generating wasteful data that may cause file management issues later on.
GH remains in a transient world, and when you decide to bake geometry (if you need to at all), you can do that in one Rhino file, and save it as the state of the design at that given moment. Very convenient for design, though unacceptable for most non-digital manufacturing methods, which greatly limits Rhino's use for manufacturing unless you combine it with an MCAD app.
One of the reasons why the distributed file approach makes perfect sense in MCAD, is that in industry you deal with a finite set of objects. Generative tools are usually not a requirement. Most mechanical engineers, product engineers and machinists would never have any use for that.
The other thing that MCAD apps like Inventor have, is the 'structured' interface that offers up all that setting out information like the coordinate systems, work planes, parameters etc in a concise fashion in the 'history tree'. This will translate into user speed. GH's canvas is a bit more freeform. I suppose the info is all there and linked, so a bit of re-jigging is easy. Also, see how T-Flex can even embed sliders and other parameter input boxes into the model itself. Pretty handy/fast to understand, which also means more speed.
True. As long as you keep the browser pane/specification tree organized and easy to query.
:)
Would love to understand what you did by sketching.
I'll start by showing what was done years ago in the Inventor model, and then share with you what I did in GH, but in another post.
Let's use one of the beams as an example:
We can isolate this component for clarity.
Notice that I've highlighted the sectional sketch with dimensions, and the point of reference, which is in relation to the CL of the column which the beam bears on. The orientation and location of the beam is already set by underlying geometry.
Here's a perspective view of the same:
The extent of the beam was also driven by reference geometry, 2 planes offset from the beam's XY plane, driven by parameters from another underlying file which serves as a parameter container:
Reference axes and points are present for all other components, here are some of them:
It starts getting cluttered if you see the reference planes as well:
Is I mentioned earlier, over time we've found better ways to define and associate geometry, parameters, manage design change, improving the efficiency of parametric models. But this model is a fair representation of a basic modeling approach, and since an Inventor-GH comparison is like comparing apples and oranges anyways, this model can be used to understand the differences and similarities, for those interested.
I haven't even gotten to your latest post yet, I will eventually.…
Added by Santiago Diaz at 10:36am on February 26, 2011
he picture (4).
Previously, I had a problem with generating intersections between the two directions of the beams, but a colleague helped me by extending beams, so there was no problem with lines of intersection. But this solution has generated curl (5) at the highest vertex geometry, which I ignored in order to repair it before printing, perhaps this mean my problem with my beam spread properly. Only when the beams is 19, does not jump no problem, but I still can not distribute them properly.
(1)
(2)
(3)
(4)
(5)
I tried to show as simply as possible by removing or signing my code in GHX file.
Thank you in advance for your help
…
work with color to fit it into this logic (porous structure)?the range of colors: from white to yellow, orange, red. to blackis not so nice, saying, does not match to the design of the house.So there for it should only show the material what carries this pattern.So my question in yours case:i think that the picture of you must be thought as invert, so that it's become functional as well. if you thought this as invert,than you musst icrease the surface division,so that the rays of the sun can be disturbed to penetrate the house.that is a good the example:http://www.detail.de/inspiration/fuenf-hoefe-in-muenchen-100701.htmlin your case, the function of the patterns would get parametric significance. where more sunlight, consequently a denser pattern, and of course vice versa.therefore, the attractor should be the solar/sun system.http://digitalsubstance.wordpress.com/2011/12/07/facade-porosity-ad...What do you mean, i still see a version of you?http://www.youtube.com/watch?v=JoqDYcCDOTgThanks…
roduced the same error.
I tried to run them again with the file already open and I got this (I imagine predictable) error:
Sorry! But the number of available CPUs on your machine is 4.
Honeybee set the number of CPUs to 4.
Grid-based Radiance simulation
The component is checking ad, as, ar and aa values. This is just to make sure that the results are accurate enough.
Good to go!
Current working directory is set to: C:\ladybug\Parametric_Shading_Wall\psw_z0.25_t.025_y.2_r90_m3_lux\gridBasedSimulation\
Failed to remove the old directory.
WindowsError(32, 'The process cannot access the file because it is being used by another process')
Failed to read the results!
rtrace: fatal - (psw_z0.25_t.025_y.2_r90_m3_lux_RAD.oct): truncated octree
rtrace: fatal - (psw_z0.25_t.025_y.2_r90_m3_lux_RAD.oct): truncated octree
rtrace: fatal - (psw_z0.25_t.025_y.2_r90_m3_lux_RAD.oct): truncated octree
rtrace: fatal - (psw_z0.25_t.025_y.2_r90_m3_lux_RAD.oct): truncated octree
Runtime error (PythonException): Failed to read the results!
rtrace: fatal - (psw_z0.25_t.025_y.2_r90_m3_lux_RAD.oct): truncated octree
rtrace: fatal - (psw_z0.25_t.025_y.2_r90_m3_lux_RAD.oct): truncated octree
rtrace: fatal - (psw_z0.25_t.025_y.2_r90_m3_lux_RAD.oct): truncated octree
rtrace: fatal - (psw_z0.25_t.025_y.2_r90_m3_lux_RAD.oct): truncated octree
Traceback:
line 336, in script
@Mostapha, if it is indeed a different issue, what do you think it could be?
Thanks again,
-Nicholas…
ky.exe did not accept -p parameter and made empty sky.cal file.
----
Edit: solved run problem, Bee did not download OpenStudioMasterTemplate.idf
Get it here: https://github.com/mostaphaRoudsari/Honeybee/issues/119
Now get empty HDR:
C:\ladybug\prox\imageBasedSimulation>rpict -i -t 10 -vtv -vp 245.129 -226.458 20 0.405 -vd -0.549 0.656 -0.518 -vu -0.332 0.397 0.855 -vh 42.862 -vv 26.991 -v l 0 -vs 0 -vl 0 -x 800 -y 600 -af prox_RAD_Perspective.amb -ps 8 -pt 0.15 -pj 0.6 -dj 0 -ds 0.5 -dt 0.5 -dc 0.25 -dr 0 -dp 64 -st 0.85 -ab 2 -ad 1024 -as 175 -ar 150 -aa 0.200 -lr 4 -lw 0.050 -av 0 0 0 prox_RAD.oct 1>prox_RAD_Perspectiv e.unf rpict: 0 rays, 0.00% after 0.0000 hours rpict: skybright`c__ladybug_skylib_cumulativeSkies_SINGAPORE_SGP_SINGAPORE_SGP_1 : undefined variable rpict: 1020 rays, 4.91% after 0.0000 hours
----
Hi friends,
trying to get a cumulative sky image metric to run and encountered an issue with the image-based metrics component. It throws:
Runtime error (KeyNotFoundException): honeybee_materialLib Traceback: line 768, in main, "<string>" line 1442, in script
I guess this is some sort of setup issue on my end, or I messed up the definition? Any help appreciated.
Thanks,
Max
…
you working on a PV system which will power a domestic hot water boiler?
To answer your questions:1) Each grasshopper component (ghpython being one of those too) is using grasshopper's data matching algorithm. This algorithm takes care of complex issues which may arise from combining lists with single items, data trees with different number of items per branch and so on.I think there is a way of introducing a call to other processor's threads per each inputted surface, but this will be a very difficult job, as it will require writing a custom data matching algorithm. I do not think I am up to that task.Instead I tried to introduce the multithread only to the final part of the PVsurface component and one of its time consuming parts: calculation of sun angles, solar radiation and ac/dc power output.I attached the test file below, but sadly it didn't go well: the multithreaded version mostly runs at the same time as the regular version.I do not think I am qualified enough to answer why is that so, but I think that it may have something to do with the type of the function that the multithreading is applied to: the code is suppose to run few separate functions a couple of thousand times, and work with a couple of lists. From my experience, the multithreading works the best when a single list or two are supplied to a single function. I may be wrong on this.I am very sorry to say that I can not implement this feature.2) I am not familiar if open source PV modules database has been released.But one can always download the data for specific modules from producers websites. It can then easily be transferred to a .csv file or other text file.Ladybug Photovoltaics are based on NREL's PVWatts model.In comparison with other commercial software applications, PVWatts offers a more generalized system model, with some of the values and characteristics being assumed or embedded.The Fuentes empirical thermal model we are currently using follows the same logic: it generalizes the Module characteristics. The following characteristics are only editable: module efficiency, temperature coefficient and module mount type.It may be possible to replace Fuentes with some other, less generalized 5 parameter thermal model. But as an architect, I would definitively need help on this.
Sorry if my reply did not fulfill your expectations, and thank you for the kind words!…