- nickname is rather the best approach - and not on active group, but that's irrelevant anyway).
Step back (assuming that you are talking about the "Tens_from_random_blah_blah" definition):
1. Engineering is the art of demystifying (or we are promising that anyway, he he). This means that you start defining (better: outlining) some topology for things based on some "generic" rules (like the ones applied for the masts,cables,cones etc etc). These things are kept in some kind of structure (Lists, DataTrees etc). Things are few in 99.99999% of cases (i.e. : even the biggest membrane "module" has, say, 20-50 masts per "module").
2. Then ... handling things "individually" (mostly modifying) becomes the most critical part. See this (an x "possible" solution by combining a myriad of "options" : a no cones membrane solution, in plain English):
3. But the above is impossible (for more than obvious reasons). You should deploy masts in some high/low sequence in order to achieve some meaningful convex/concave formation that could work.
4. This "works" : 5. This doesn't:
6. This works partially (the formation at the back is "flat" == undo able):
7. This is utterly kitsch (and faulty as the case6 - the back portion):
So it's quite obvious that without a (quite complex) capability to individually control things (in this occasion : mast heights) the whole definition is a waste of computer time. Additionally the more the solution is "demystified" (some curve is defined, some random points are created, some masts are in place, some cables appear etc etc) the more additional constrains are required in order to "narrow" the possibilities (In plain English : sliders should control other sliders as regards their min/max values, true/false, you/me etc etc).
Remember that we are talking about ONE (mast height) out of a myriad things that you should control "manually" (it's utterly pointless to mastermind some kind of "generic" rules - or use naive attractors etc etc) .You'll see the difference when I'll completely reform the definition by adding individual control upon anything.
PS: what about the blocks? (the real life stuff that actually make any solution possible). Can you imagine a 2nd set of "restrictions" imposed by "a child to his parent"? (Assembly/Component modeling , that is).
more soon
…
the results myself and I am open to changing the name/description of the input based on what you have found here. modulateFlowOrTemp is not the best name for what seems to be going on and we should change it to reflect more what is happening in the IDF.
Here is how I am understanding the results of the different cases:
1) When the variable flow option is selected (and the outdoor air set to "None"), the heating and cooling of the space seems to happen only through re-circulation of the indoor air. My comparison to a VAV system was not appropriate and perhaps it would be better to compare it to a window air conditioner or a warm air furnace, which, as far as I understand, only re-circulate indoor air and do not bring in outside air.
2) My reasoning for the name modulateFlowOrTemp came mostly from my realization that the supply air temperature remained within the defined limits when the variable flow option is selected (and the outdoor air set to "None"). When the outdoor air was set to Maximum or Sum, the supply air temperature went way out of the temperature limits that I initially set. I realize now that the flows are varying in both cases and the name of the input really must change.
3) I think that the reason why we don't see any effect from the air side economizer is because the heating/cooling energy results that you get from an ideal air system are just the sum of the sensible and the latent heat added/removed from the zone by the system. This value of heat added or removed from the zone does not change whether the added/removed heat comes from outside air or from a cooling/heating coil. Since there is no cooling coil or boiler or chiller in an ideal air system, there is no way to request an output of the energy added/removed by such a coil or chiller as opposed to that removed/added by outside air. In other words, the air side economizer option on the ideal air system is practically useless because it does not help us differentiate the cooling that comes from the outside air vs. that which comes from a coil. All that it does is change the outdoor air fraction while keeping the reported cooling/heating values the same.
Please let me know if you think that this explanation makes sense, Burin and, in light of all this, I am very interested in your suggestions.
From my own perspective, I am now convinced that the default should definitely have the outside air requirements set to "None" since, otherwise, we cannot distinguish cooling/heating that happens from addition of outside air and that which must be supplied by a coil. At least when we get rid of the outside air requirement, we can be sure that the ideal air system values are only showing heating/cooling from a coil or HVAC system.
I have decided to remove the airsideEconomizer input since it seems to give misleading expectations. I am going to recommend here on out that, if you want to estimate the effect of increasing outside air on cooling, you should use the "Set EP Airflow" component, use fan-driven natural ventilation, and you should connect a custom CSV schedule of airflow. You will have to create such a schedule with native GH components using the outside air temperature, your zone setpoints, and the times that you are cooling in your initial run of E+. Either you do this or you set up a full-blown system with OpenStudio.
I have also decided to get rid of the heatRecovery input since it seems like this will also produce misleading expectations by the same logic.
Lastly, I am going to change the name of the modulateFlowOrTemp_ input to outdoorAirReq_. The default will be to have no indoor air requirement as stated above but you can input either "maximum" or "sum" to have the IDF run accordingly.
Let me know if this sounds good or if you have suggestions. Updated GH file attached. The github has the new Ideal Air Loads component. Make sure that you have sync correctly and restart GH after updating your components.
-Chris…
with this machine.
As Jason says, Rhino and Grasshopper are mainly single-threaded, so I prioritized single core speed and got an i7 4790k, which comfortably overclocks to 4.7GHz (with a decent air cooler, but no fancy liquid cooling).
The Kangaroo2 solver is actually multi-threaded now, but the difference this makes is not great as you might imagine. Using 4 cores is certainly nowhere near 4 times faster, because although parts of the calculation are easily parallelized, everything still needs to be recombined at each iteration, and this is usually the bottleneck. I think there is still room for some improvement in how it is multi-threaded, but I wouldn't hold your breath for any massive changes on this front soon.
I'd be interested to know how the performance scales with the Xeon chips (more cores, significantly more expensive, but relatively low clock speeds). At the time I made the guess that they weren't worth it, but it would be good to really test this out.
RAM is relatively cheap these days, so I went with 32GB of it at 2133MHz. It does seem that the speed of the RAM matters, as enabling XMP in the BIOS (to make it run above the default 1333) seemed to make a noticeable difference.
Graphics-wise my personal feeling is that the gaming oriented GTX cards offer better value than the much more expensive 'professional' Quadro range - and have read that the hardware between the 2 has historically been very similar or even identical despite the Quadros being several times the price, with the difference being mainly in the drivers. There are some threads on discourse.mcneel.com about this, and it seems that recent GTX cards like the 970 do very well in Holomark (the Rhino performance benchmarking tool).
I got a GTX 770 (this was just before the 900 series came out), which is probably way overkill just for Rhino/Grasshopper, as they don't use the GPU for more than display (Though some of the render plugins do, and I think for those more CUDA cores is what matters, so there GTX is probably still better value.)
Probably swapping this for a much cheaper card wouldn't make much difference to Rhino/GH performance anyway (though if you want to use the PC for other stuff like gaming or virtual reality it does).
I don't have much experience with AMD cards, so can't comment on how they compare to Nvidia.
Eventually I do hope to make Kangaroo run the physics on the GPU, and potentially this does have a big speed impact. Nvidia recently released some impressive demos of their FLEX engine, which really fly with a decent graphics card. That is very much game-physics, and not suitable for most of the things Kangaroo is used for, but theoretically Kangaroo could also be adapted to use CUDA (or OpenCL), though it involves a lot of big changes, and I don't have a timeline for this yet.
In the much shorter term there are some things in the pipeline that should speed up Kangaroo for certain things like collisions between large numbers of objects, just by using some different algorithms.
Altogether my machine was still well under €2K, and I've been really happy with it. That said, the difference in performance between this and my 4 year old €700 i5 laptop is actually not that huge in day-to-day Grasshopper usage. It does seem that there is a strong case of diminishing returns with buying a PC - I'd hazard a guess that even spending 3 times this amount (as another thread on this forum was discussing recently) you'd be hard pushed to get anything that made a really significant difference to the experience of using it, and if you really want to spend more money, you would be better off just upgrading more frequently (and getting a nice monitor(s)).
Anyway, a long ramble, I hope some of it is useful. As I said, I'm no hardware expert, and would be interested to hear different opinions.
I also think it will be nice to make a simple benchmarking tool for Kangaroo and have people run it on their various machines and report back results (as with Holomark), to help others make informed decisions on these things. I'll try and put something together for this soon.
…
uick answers. Below you will find some suggestions, but don't think of them as rules and especially don't think of them as guarantees.
1. Choose a descriptive title for your post
Don't call your question "Help!" or "I have a problem" or "Deadline tonight!", but actually describe the problem you are having.
2. Be succinct but clear in your wording
People need to know some details about your problem in order to understand what sort of answers would satisfy you, but nobody cares about how angry your boss or how bad your teacher or how tight your deadline is. Talk about the problem and only the problem. If you don't speak English well, you should probably post in your native language as well as providing a Google Translation of your question.
3. Attach minimal versions of all the relevant files
If you have a GH/GHX file you have a question about, attach it to the post. Don't expect that people will recreate a file based on a screen-shot because that's a lot of pointless work. It's also a good idea to remove everything non-essential from a GH file. You can use the 'Internalise Data' menu option to cut everything to the left of a parameter:
If you're importing curves or Breps or meshes from Rhino, you can also internalise them so you won't have to post a 3DM file as well as a GH file. If you do attach large files, consider zipping them first. Do not use RAR, Ning doesn't handle it.
It is especially a good idea to post files that don't require any non-standard components if at all possible. Not everyone has Kangaroo or Hoopsnake or Geco installed so if your file relies on those components, it might not open correctly elsewhere.
4. Include a detailed image of the GH file if it makes sense
If your question is about a specific (group of) components, consider adding a screenshot of the file in the text of the post. You can use the Ctrl+Shift+Q feature in Grasshopper to quickly create nice screenshots with focus rectangles such as this:
5. Include links to online resources if possible
If you have a question about Schwarz Minimal surfaces, please link to a website which talks about these.
6. Create new topics rather than continuing old ones
It's usually better to start a fresh question, even if there's already a discussion that kinda sorta tangentially touches upon the same issue. Please link to that discussion, but start anew.
7. This is not a 'do my work for me' group
Many of us like to help, but it's good to see effort on our part being matched by effort on your part. Questions in the form of 'I need to do X but cannot be bothered to try and learn the software' will (and should) go unanswered.
7b. Similarly, questions in the form of 'How do I quickly recreate this facade that took a team of skilled professionals four months to figure out?' have a very low success rate.
--
David Rutten
Lead Grasshopper Development
Robert McNeel & Associates…
Added by David Rutten at 12:58pm on October 1, 2013
: ----------------------------------------------------------------------------------------------
1)
Hi Clemens I've analysed a plate structure using Karamba and wanted to do a convergence analysis on results computed as a function of the number of elements.
Now, when strictly looking at the result magnitudes of internal energy (IE) and maximum displacement (w_max), it's acceptable, that their relative deviations are very small. But I cannot explain the tendencies of their graphs. From what I know, FEM should always compute underestimated results when compared to analytical solutions. So I don't understand why both the IE and w_max seem to be decreasing for an increasing number of elements.
But my main concern is the behaviour of the peak moment, it seems to be simply hill climbing untill suddenly a singularity kicks in. I initially wanted to use the peak moment as a fitness value for optimisation, but with this behaviour, I don't think that would make sense. I've attached my GH file as well.
It would be much appreciated if you could enlighten me on these subjects. Cheers Daniel Andersen
2)
Hi Daniel,
I could not run your definition because I have not all the plug-ins installed that you use.
You are basically right that the displacement should increase with a finer mesh. However the result of the shell analysis also depends on the shape of the triangles (well formed vs. very distorted). In order to test this, I think it would be interesting to use a very simple example (e.g. rectangular plate with one column) where you can easily control mesh generation. Would you like to start a discussion on this in the karamba group at http://www.grasshopper3d.com/group/karamba?
It is not a good idea to use the bending moment at a singularity for optimization because the result will be heavily mesh dependent. Also real columns do have a certain diameter and modeling them as point supports introduces an error.
Best,
Clemens
3)
oh, and by the way!
Here's some relevant literature on handling peak moments: https://books.google.dk/books?id=-5TvNxnVMmgC&pg=PA219&lpg=PA219&dq=blaauwendraad+plates+and+fem&source=bl&ots=SdDcwnrSA1&sig=6HulPmKNIhqKx4_rGxitteMC4CU&hl=da&sa=X&ved=0CDEQ6AEwA2oVChMIg66k0LPaxgIVgY1yCh1KPAeY#v=onepage&q=chapter%2014&f=false (Blaauwendraad, J., 2010. Plates and FEM : Surprises and Pitfalls, see Chapter 14) It would be great if a feature dealing with peak moments could be incorporated in Karamba. In my work, I ended up exporting my models to Robot in order to verify the moment values. Best, Daniel
4)
Hi Daniel,
thank you for your reply and the link to Blaauwendraads excellent book!
At some point I hope to include material nonlinearity in Karamba which will help in dealing with stress singularities.
If you want you could open a discussion with a title like 'moment peaks in shells at point-supports'. Then we could copy and paste the text of our conversation into it.
Best,
Clemens
----------------------------------------------------------------------------------------------…
make quad mesh usable with Kangaroo and with limited inputs parameters in order to simulate funicular structures like "Vaulted Willow" or "Pleated Inflation" from Marc Fornes and the Verymany.
Here is a first attempt script.
As inputs there are :
Lines_in, just lines, no duplicates, on XY plane could have Z values, but the algorithm works on a , on XY plane could have Z values, but the algorithm works on a flat representation.
Tolerance is used to glue lines when points are closer than tolerance
Width is the half width of the “roads” going through the network
Angle is the shape of the ends of the roads, 0° means flat end, 180° a totally rounded end
Deviation is the shift generating spikes or enabling to generate pleated geometry
N_u is the number of subdivision along the “roads”, image above with 3 subdivisions on the roads
N_u is the number of subdivision across the “roads”
Zbool if false everything is flat, if true the mesh is in 3d, best with angle = 180° or -180°
For the outputs there is the topology of the network (like Sandbox)
As outputs geometry are put on datatree, each branch represent a path on the road, above 3 paths, which are brep output.
Adding a diagonal there are now 4 paths so 4 branches
The mesh M goes with F which are fixed points, anchor in Kangaroo.
U and V are lines in datatree, there will be used as spring in Kangaroo, U above
This script could be used to draw sort of roads, like in here https://codequotidien.wordpress.com/2013/03/22/hemfunction/
But the primary purpose is to do that.
…
main attention is set on easy to handle interface , which should be used at a early stage of conceptual design to respond to external and internal influences in a intelligent and sustainable way.
Participants will use the software Grasshopper as a parametric modeling plug-in for Rhino. The usage of this graphical algorithm editor tightly integrated with Rhino’s 3-D modeling tools open up the possibility to construct highly parametrical complex models. To generate this complexity we will use live linkages to several programs listed below:
• Autodesk Ecotect Analysis and Radiance via GECO
• Processing, Excel or Open Office via gHowl
• FEA software GSA via SSI
In this 3 intense days, the participants should learn the workflow of the plug-ins with the help of examples and get an overview of the different software’s, there possibilities for evaluating the performance of a design or the usage of additional tools to be not chained to a single system .
(e.g. parametrical accentuation, parametrical formation, parametrical reaction)
TIME AND LOCATION
27th – 29th September 2010Leopold-Franzens university innsbruck/austria
Technik Campus | ICT - building
Technikerstraße 21a
A - 6020 Innsbruck | Austria
47°15’50.71”N 11°20’43.45”E
detailed program as pdf-version
FOR WHOM
All levels are welcome (students & professionals)
The only requirement is knowledge of Rhino and Basic Grasshopper.
You will need a level which corresponds to the Grasshopper Primer course outline.
FEES
21 hours
professionals: 395€
students (bachelor/master): 250€.
REGISTRATION
please send a email to to.from.uto@gmail.com attached with following information :
Last Name
First Name
Date of Birth
Nationality
Email Address
Current Address
Profession or proof of student status
After submitting you will receive an email with a PayPal link to complete registration.…
hops, design sessions & symposia across 5 cities in India. We encourage all architecture & design students and professionals to join us in this novel experimentation event and aid in 'Filling The Void'; Void in Architecture, Void in our Cities, Void in Education. REGISTRATIONS ARE OPEN NOW.
rat[LAB] Computational Design Tour - INDIA
Agenda // Filling The Void
1 country // 5 cities // 1 agenda // 100+ students // 25+ professionals // 5 exhibitions // 1 publication
Void is typically defined as null, invalid, empty or redundant and has a psychological perception of a ‘negative’. Through years of development in India, there has been an organic urban growth and inorganic architectural growth which has led to formation of voids in a physical and a metaphorical sense. There also exist voids as gaps between architecture, cities, education and technology. ‘Filling The Void’ looks at void as an opportunity, potential and a driver of change for architecture & design education in India.
// Cities & Dates*
Mumbai – 22nd June to 24th June 2015 (Monday to Wednesday)
Chennai - 29th June to 1st July 2015 (Monday to Wednesday)
Bengaluru – 3rd July to 5th July 2015 (Friday to Sunday)
Chandigarh - 16th July to 18th July 2015 (Thursday to Saturday)
New Delhi – 6th August to 8th August 2015 (Thursday to Saturday)
*Venue details are published on rat[LAB] website.
// Registration Dates
// Early-bird Registrations Open: 08 May 2015
// EXTENDED Early-bird registrations End: 05 June 2015
// General Registrations End: 15 June 2015 (Or till seats last)
…
diseño, construcción y entendimiento de nuestro entorno.
BIM está poniendo a disposición de los diseñadores y gestores auténticas bases de datos que pueden generarse, conectarse y editarse de forma paramétrica, proporcionando una sólida capa de realidad a los ejercicios de diseño generativo y computación que son objeto de estudio en Algomad, el seminario que busca popularizar la programación y la parametrización en el diseño y en la experiencia de nuestro entorno construido.
Tras un paréntesis en 2015, Algomad vuelve con el objetivo de demostrar cómo una visión computacional del BIM es una oportunidad para mejorar la forma de trabajar de ingenieros, arquitectos, constructoras y operadores de edificios e infraestructuras, tendiendo un puente entre las técnicas de diseño digital más avanzadas y la realidad de la construcción.
Algomad 2016 tendrá lugar en el centro de Madrid, en IE School of Architecture and Design, IE University, los días 3, 4 y 5 de Noviembre de 2016 y comprenderá 4 talleres así como ponencias a cargo de expertos de primer nivel.
Estructura de Algomad 2016
Algomad 2016 se estructura en torno a tres áreas temáticas principales:
BIM, como la metodología total específica para el sector de la construcción.
Computación, englobando las aplicaciones de programación y parametrización al diseño de edificios e infraestructuras.
Realidad, como marco de trabajo, buscando siempre resolver problemas reales a través de los dos puntos anteriores.
Público objetivo
Arquitectos, arquitectos técnicos, ingenieros y en general académicos, estudiantes de últimos cursos y profesionales del mundo inmobiliario y de la construcción que compartan un interés por la digitalización de nuestro sector. Se espera un nivel mínimo en el uso de herramientas BIM y de parametrización. Algomad proporcionará formación adicional y gratuita en las herramientas básicas a emplear en los talleres para asegurar un correcto desempeño.…
ively and creatively solve today’s product development challenges.
Our Rhino3D Foundations for Industrial Design class provides an in-depth look at 2D and 3D tools and methods with Rhino3D, a NURBs surface modeling software. In this class, we will systematically work through Rhino3D’s core features, using them to model the various components of a consumer product. Over the course of 3 days, we’ll cover some foundational topics, including Rhino interface and navigation, Rhino3D object types and properties, creating and editing 2D and 3D geometry, procedural modeling, automation, transforming geometry, Rhino modeling best practices, freeform vs. precision modeling, and exporting geometry.
You’ll take away the following:
Navigate the Rhino modeling environment
Create, edit, and modify curves, surfaces, and solids
Precision model using coordinate input and object snaps
Use transformation and universal deformation tools
Apply best practices for layer management and model annotation
Download the course one-pager. Need more information? Connect with us.
This class is ideal for:
Industrial designers who are new to Rhino3D and want to learn its concepts and technical features in an instructor-led environment.
For groups of 10 or more, contact Mode Lab at hello@modelab.is
Interested in additional training options?
https://www.modelab.is/upcoming-computational-design-events…