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…
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
----------------------------------------------------------------------------------------------…
but rather than keep everyone waiting, I've decided to share some as they become ready.
This also has the advantage that questions about components can be more easily grouped under the relevant post - so please do add any questions / comments / bugs / suggestions about these examples below.
So today I am posting some examples of the mesh utilities that come with the new release.
While these are not directly physics based, many of the forces and types of relaxation in Kangaroo are designed to work with meshes, and in the process of development I've ended up adding a number of simple utilities to make working with them a little easier.
I recommend also installing Weaverbird which has many more subdivision functions and other useful tools for working with meshes in Grasshopper. Also Plankton, Turtle, MeshEdit and Starling extend these possibilities still further.
Diagonalize
This component replaces every edge of a mesh with a new face. The new faces will always be quads, except for along the boundaries, where they will be triangles. It can be used to easily create diagrids. The input mesh can contain any mix of triangles and quads.
When treating the edges of a quad mesh as springs, diagonalizing it will often significantly change its physical behaviour. If you are trying to planarize a quad mesh, diagonalizing may sometimes allow you to stay closer to a target shape if it matches the curvature directions better.
diagonalize.gh
Checkerboard
This component assigns the faces of a mesh into a checkerboard pattern. The output is a list of 1s and 0s (which could represent black/white or true/false) which can be used to dispatch the faces into 2 lists, where no pair of adjacent faces have the same colour.
One nice application I found for this is applying alternating clockwise and counter-clockwise rotations as shown below. Also, on occasion you may want to planarize a quad mesh, but have some constraints on the shape and grid that prevent this, and triangulating only alternating quads to give a hybrid quad/tri mesh can sometimes be a good compromise, allowing a bit more freedom.
Note - Not all meshes can be assigned a checkerboard pattern!
As a simple example, take a mesh with 3 quads around one vertex - If we assign one black face, then both the neighbouring faces should be white, but then we have 2 white faces adjacent to one another, which violates the checkerboard condition.
Generally, we can say that if a mesh has any internal vertex with an odd number of faces around it, then we cannot apply a consistent checkerboard pattern to it (although not having any odd valence vertices is not in itself an absolute guarantee that a mesh is 'checkerboardable').
checkerboard.gh
WarpWeft
This sorts the edges of a quad mesh into 2 lists of line segments, which are like the warp and weft directions of a fabric. They can also be seen as a sort of mesh equivalent to the u and v isocurves on a NURBS surface.
This can be useful if you want to control the shape of a tension structure, because it allows you to assign different stiffnesses in the 2 directions.
As with the checkerboard component, not all meshes can be consistently assigned warp/weft directions. It follows a similar rule - all internal vertices should have an even number of adjacent faces. With a bit of care, it is usually possible to model the initial mesh in such a way as to allow this.
This component also has an output telling us whether or not each line is on a boundary of the mesh, as we will often want to treat these differently.
Same mesh relaxed with different warp/weft stiffness:
warpweft.gh
MeshCorners
This one is hopefully fairly self explanatory. In many simulations we want to anchor the corner points of a mesh. This saves us having to pick them manually in Rhino.
It works on quad meshes, and looks around the boundary vertices for any which do not have exactly 3 connected edges.
corners.gh
That's all for now. Coming soon - a "mesh tools 2" post explaining more of the components.…
r." I'm sorry to hear that, I take the interface and ease-of-use rather seriously so this sounds like a fundamental failure on my part. On the other hand, Grasshopper isn't supposed to be on a par with most other 3D programs. It is emphatically not meant for manual/direct modelling. If you would normally tackle a problem by drawing geometry by hand, Grasshopper is not (and should never be advertised as) a good alternative."What in other programs is a dialog box, is 8 or 10 components strung together in grasshopper. The wisdom for this I often hear among the grasshopper community is that this allows for parametric design."Grasshopper ships with about 1000 components (rounded to the nearest power of ten). I'm adding more all the time, either because new functionality has been exposed in the Rhino SDK or because a certain component makes a lot of sense to a lot of people. Adding pre-canned components that do the same as '8 or 10 components strung together' for the heck of it will balloon the total number of components everyone has to deal with. If you find yourself using the same 8 to 10 components together all the time, then please mention it on this forum. A lot of the currently existing components have been added because someone asked for it."[...] has a far cleaner and more intuitive interface. So does SolidWorks, Inventor, CATIA, NX, and a bunch of others."Again, GH was not designed to be an alternative to these sort of modellers. I don't like referring to GH as 'parameteric' as that term has been co-opted by relational modellers. I prefer to use 'algorithmic' instead. The idea behind parameteric seems to be that one models by hand, but every click exists within a context, and when the context changes the software figures out where to move the click to. The idea behind algorithmic is that you don't model by hand.This is not to say there is no value in the parametric approach. Obviously it is a winning strategy and many people love to use it. We have considered adding some features to GH that would make manual modelling less of a chore and we would still very much like to do so. However this is such a large chunk of work that we have to be very careful about investing the time. Before I start down this road I want to make sure that the choice I'm making is not 'lame-ass algorithmic modeller with some lame-ass parametrics tacked on' vs. 'kick-ass algorithmic modeller with no parametrics tacked on'.
Visual Programming.I'm not exactly sure I understand your grievance here, but I suspect I agree. The visual part is front and centre at the moment and it should remain there. However we need to improve upon it and at the same time give programmers more tools to achieve what they want.
Context sensitivity."There is no reason a program in 2014 should allow me to make decisions that will not work. For example, if a component input is in all cases incompatible with another component's output, I shouldn't be able to connect them."Unfortunately it's not as simple as that. Whether or not a conversion between two data types makes sense is often dependent on the actual values. If you plug a list of curves into a Line component, none of them may be convertible. Should I therefore not allow this connection to be made? What if there is a single curve that could be converted to a line? What if you want to make the connection now, but only later plan to add some convertible curves to the data? What you made the connection back when it was valid, but now it's no longer valid, wouldn't it be weird if there was a connection you couldn't make again?I've started work on GH2 and one of the first things I'm writing now is the new data-conversion logic. The goal this time around is to not just try and convert type A into type B, but include information about what sort of conversion was needed (straightforward, exotic, far-fetched. etc.) and information regarding why that type was assigned.You are right that under some conditions, we can be sure that a conversion will always fail. For example connecting a Boolean output with a Curve input. But even there my preferred solution is to tell people why that doesn't make sense rather than not allowing it in the first place.
Sliders."I think they should be optional."They are optional."The “N” should turn into the number if set."What if you assign more than one integer? I think I'd rather see a component with inputs 'N', 'P' and 'X' rather than '5', '8' and '35.7', but I concede that is a personal preference."But if I plug it into something that'll only accept a 1, a 2, or a 3, that slider should self set accordingly."Agreed.
Components."Give components a little “+” or a drawer on the bottom or something that by clicking, opens the component into something akin to a dialog box. This should give access to all of the variables in the component. I shouldn't have to r-click on each thing on a component to do all of the settings."I was thinking of just zooming in on a component would eventually provide easier ways to access settings and data."Could some of these items disappear if they are contextually inappropriate or gray out if they're unlikely?"It's almost impossible for me to know whether these things are 'unlikely' in any given situation. There are probably some cases where a suggestion along the lines of "Hey, this component is about to run 40,524 times. It seems like it would make sense to Graft the 'P' input." would be useful.
Integration."Why isn't it just live geometry?"This is an unfortunate side-effect of the way the Rhino SDK was designed. Pumping all my geometry through the Rhino document would severely impact performance and memory usage. It also complicates the matter to an almost impossible degree as any command and plugin running in Rhino now has access to 'my' geometry."Maybe add more Rhino functionality to GH. GH has no 3D offset."That's the plan moving forward. A lot of algorithms in Rhino (Make2D, FilletEdge, Shelling, BlendSrf, the list goes on) are not available as part of the public SDK. The Rhino development team is going to try and rectify this for Rhino6 and beyond. As soon as these functions become available I'll start adding them to GH (provided they make sense of course).On the whole I agree that integration needs a lot of work, and it's work that has to happen on both sides of the isle.
Documentation.Absolutely. Development for GH1 has slowed because I'm now working on GH2. We decided that GH1 is 'feature complete', basically to avoid feature creep. GH2 is a ground-up rewrite so it will take a long time until something is ready for testing. During this time, minor additions and of course bug fixes will be available for GH1, but on a much lower frequency.Documentation is woefully inadequate at present. The primer is being updated (and the new version looks great), but for GH2 we're planning a completely new help system. People have been hired to provide the content. With a bit of luck and a lot of work this will be one of the main selling points of GH2.
2D-ness."I know you'll disagree completely, but I'm sticking to this. How else could an omission like offsetsurf happen?"I don't fully disagree. A lot of geometry is either flat or happens inside surfaces. The reason there's no shelling (I'm assuming that's what you meant, there are two Offset Surface components in GH) is because (a) it's a very new feature in Rhino and doesn't work too well yet and (b) as a result of that isn't available to plugins.
Organisation.Agreed. We need to come up with better ways to organise, document, version, share and simplify GH files. GH1 UI is ok for small projects (<100 components) but can't handle more complexity.
Don't get me wrong, I appreciate the feedback, I really do, but I want to be honest and open about my own plans and where they might conflict with your wishes. Grasshopper is being used far beyond the boundaries of what we expected and it's clear that there are major shortcomings that must be addressed before too long. We didn't get it right with the first version, I don't expect we'll get it completely right with the second version but if we can improve upon the -say- five biggest drawbacks (performance, documentation, organisation, plugin management and no mac version) I'll be a happy puppy.
--
David Rutten
david@mcneel.com…
rmation?" I know that this can already be accomplished using the brilliant Kangaroo plugin, but I wanted a simpler and faster (yet still accurate) single component that could replicate this unique curve using a variety of inputs: the length of the rod/wire, the width/distance between the endpoints, the height of the bend, and the tangent angle at the start. I also wanted make the unknowns (such as height if only length and width are known) easily accessible for plugging into additional components.
The resulting script, being an all-in-one solution, is somewhat unwieldy, but it could easily be broken down into smaller components (custom .gha's which I don't have the ability to code). If someone wants to tackle this, please do! I'm not an expert coder by any means, and as this was only my second time diving into Grasshopper scripting, if the script seems somewhat strange, that's probably why. I did try to comment the code pretty well though. Here's the full description:
--------------------------------------------------
DESCRIPTION: This beast creates the so-called 'elastica curve', the shape a long, thin rod or wire makes when it is bent elastically (i.e. not permanently). In this case, force is assumed to only be applied horizontally (which would be in line with the rod at rest) and both ends are assumed to be pinned or hinged meaning they are free to rotate (as opposed to clamped, when the end tangent angle is fixed, usually horizontally). An interesting finding is that it doesn't matter what the material or cross-sectional area is, as long as they're uniform along the entire length. Everything makes the same shape when bent as long as it doesn't cross the threshold from elastic to plastic (permanent) deformation (I don't bother to find that limit here, but can be found if the yield stress for a material is known).
Key to the formulas used in this script are elliptic integrals, specifically K(m), the complete elliptic integral of the first kind, and E(m), the complete elliptic integral of the second kind. There was a lot of confusion over the 'm' and 'k' parameters for these functions, as some people use them interchangeably, but they are not the same. m = k^2 (thus k = Sqrt(m)). I try to use the 'm' parameter exclusively to avoid this confusion. Note that there is a unique 'm' parameter for every configuration/shape of the elastica curve.
This script tries to find that unique 'm' parameter based on the inputs. The algorithm starts with a test version of m, evaluates an expression, say 2*E(m)/K(m)-1, then compares the result to what it should be (in this case, a known width/length ratio). Iterate until the correct m is found. Once we have m, we can then calculate all of the other unknowns, then find points that lie on that curve, then interpolate those points for the actual curve. You can also use Wolfram|Alpha as I did to find the m parameter based on the equations in this script (example here: http://tiny.cc/t4tpbx for when say width=45.2 and length=67.1).
Other notes:
* This script works with negative values for width, which will creat a self-intersecting curve (as it should). The curvature of the elastica starts to break down around m=0.95 (~154°), but this script will continue to work until M_MAX, m=0.993 (~169°). If you wish to ignore self-intersecting curves, set ignoreSelfIntersecting to True
* When the only known values are length and height, it is actually possible for certain ratios of height to length to have two valid m values (thus 2 possible widths and angles). This script will return them both.
* Only the first two valid parameters (of the required ones) will be used, meaning if all four are connected (length, width or a PtB, height, and angle), this script will only use length and width (or a PtB).
* Depending on the magnitude of your inputs (say if they're really small, like if length < 10), you might have to increase the constant ROUNDTO at the bottom
REFERENCES: {1} "The elastic rod" by M.E. Pacheco Q. & E. Pina, http://www.scielo.org.mx/pdf/rmfe/v53n2/v53n2a8.pdf {2} "An experiment in nonlinear beam theory" by A. Valiente, http://www.deepdyve.com/lp/doc/I3lwnxdfGz {3} "Snap buckling, writhing and Loop formation In twisted rods" by V.G.A. GOSS, http://myweb.lsbu.ac.uk/~gossga/thesisFinal.pdf {4} "Theory of Elastic Stability" by Stephen Timoshenko, http://www.scribd.com/doc/50402462/Timoshenko-Theory-of-Elastic-Stability (start on p. 76)
INPUT: PtA - First anchor point (required) PtB - Second anchor point (optional, though 2 out of the 4--length, width, height, angle--need to be specified) [note that PtB can be the same as PtA (meaning width would be zero)] [also note that if a different width is additionally specified that's not equal to the distance between PtA and PtB, then the end point will not equal PtB anymore] Pln - Plane of the bent rod/wire, which bends up in the +y direction. The line between PtA and PtB (if specified) must be parallel to the x-axis of this plane
** 2 of the following 4 need to be specified ** Len - Length of the rod/wire, which needs to be > 0 Wid - Width between the endpoints of the curve [note: if PtB is specified in addition, and distance between PtA and PtB <> width, the end point will be relocated Ht - Height of the bent rod/wire (when negative, curve will bend downward, relative to the input plane, instead) Ang - Inner departure angle or tangent angle (in radians) at the ends of the bent rod/wire. Set up so as width approaches length (thus height approaches zero), angle approaches zero
* Following variables only needed for optional calculating of bending force, not for shape of curve. E - Young's modulus (modulus of elasticity) in GPa (=N/m^2) (material-specific. for example, 7075 aluminum is roughly 71.7 GPa) I - Second moment of area (or area moment of inertia) in m^4 (cross-section-specific. for example, a hollow rod would have I = pi * (outer_diameter^4 - inner_diameter^4) / 32 Note: E*I is also known as flexural rigidity or bending stiffness
OUTPUT: out - only for debugging messages Pts - the list of points that approximate the shape of the elastica Crv - the 3rd-degree curve interpolated from those points (with accurate start & end tangents) L - the length of the rod/wire W - the distance (width) between the endpoints of the rod/wire H - the height of the bent rod/wire A - the tangent angle at the (start) end of the rod/wire F - the force needed to hold the rod/wire in a specific shape (based on the material properties & cross-section) **be sure your units for 'I' match your units for the rest of your inputs (length, width, etc.). Also note that the critical buckling load (force) that makes the rod/wire start to bend can be found at height=0
THANKS TO: Mårten Nettelbladt (thegeometryofbending.blogspot.com) Daniel Piker (Kangaroo plugin) David Rutten (Grasshopper guru) Euler & Bernoulli (the O.G.'s)
--------------------------------------------------
Edit: More on the math behind this here.
Cheers,
Will
…
Added by Will McElwain at 4:08pm on February 26, 2014
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.…
e think. Also, its easier to catch an error because the malicious component simply turns red/orange (in most cases). However, if you are adept at scripting, you are probably very used to recursive looping & conditional evaluation which you miss majorly in GH (it is possible in very limited ways through using series components or comparer components). So an adept scriptor may soon end up switching back to Rhinoscript unless they find the shift from VBscript to VB.net really fast & smooth (which is rare).
GH ofcourse has the advantage of keeping it all 'alive' and changing things with sliders/graphs/image painting, compared to Rhinoscript which is a run-once operation -- so that's where one makes a choice between recursive looping (in RS) & live interactivity (in GH). I'd say RS mostly wins the battle because interactivity is fancy, but recursion can be a necessity.
Now to VB.net. The one barrier I have hit most often with GH is speed. If you were working on a fairly large data set, or doing a number of surface/polysurface/brep operations, you hit the performance ceiling real fast, which is when the interactivity becomes almost useless -- because its nowhere close to real time anymore even if you had 12gb ram. Thus steps in VB.net (A bit of clever scripting can make a really significant difference).
Working a series of geometric operations in a code component is much faster than doing it through native GH components due to the fact that each native component comes with tonnes off error trapping code, preview generation (I think even if you turn it off, its still being computed, only not displayed), etc. while with VB, you can circumvent a lot of that.
If GH were to handle geometry even remotely comparable to what GC/Catia* can do, it would have a long way to go -- I am not sure if that is even the objective. For instance, I am currently working on a tower where all geometry is only meshes and polylines - no degree 3 curves, no surfaces/polysurfaces. This is because if the entire tower is to stay 'alive', Meshes are the lightest option with the amount of geometry being generated. And most of it is through code... there's only the sliders and a couple of other components that are GH native -- and its still in GH due to the interactivity. (I think there's a vast potential with Meshes that GH/Rhino are really not tapping into. There are all the building blocks, but no significant implementation. Giulio's weaverbird plugin is just a small example).
*GC/Catia cost significantly more than Rhino itself, and GH is a free plugin to Rhino. Morever, these softwares were written to be parametric modelling softwares from day1, unlike GH which is an add-on over the RhinoSDK, which was never developed from such a perspective. So a very very unfair comparison there, but GH is becoming so significant that its got a forum of its own -- gaining an almost 'independent software' status. I just hope the McNeel marketing people are not listening :)…
we're actually using PET sheets for our flexures. We try to design so that the flexures don't go through more than +/- 30 degrees of deflection. If the angular deflection is kept small, the lifetime can definitely be on the order of 1000000 cycles.
As for the design process (item 2), ideally the designer would be able to use a simple 3D CAD tool to design a model of a robot, and the geometry would be represented by dimensioning the individual parts in the model. Maybe there should be some parametric primitive kinematic building blocks like four bar linkages, box frames, etc. that a user could build up a robot from. But, the key functionality the tool needs to provide is for the designer to be able to visualize how the robot will move when it's fabricated. This could mean observing (or plotting) the motion of a leg, a wing, or a series of body segments. Ideally, then, the tool would generate an unfolding of the design. How this would work is still very vague - maybe the user would assist in the unfolding, maybe there would be an optimization routine that computes optimal unfoldings based on criteria like minimal waste, or fewest pieces (I would *not* constrain the problem to construction from a single monolithic piece as in origami). The biggest problem we have right now, is that our design process is totally divorced from fabrication. Even if we went through the trouble of extruding individual thin plates in Solidworks and creating an assembly for visualizing the kinematics of a mechanism, that particular representation doesn't transfer easily to the fabrication process because it's essentially monolithic.
Item 3: The 2D drawing is simple a drawing done manually in Solidworks. There are different layers for flexure cuts, outline cuts, and potentially any cuts to be made in the plastic flexure layer. Depending on the robot, there may be many separate pieces for different parts and linkages in a single robot. For example, the drawing for a robot containing a fourbar linkage may have the linkage laid out as a physically separate piece consisting of five rigid links connected by four flexure hinges. During assembly, the designer would then fold up that linkage and insert it into the robot wherever it's supposed to go. If you're curious you can see some sample 2D drawings for older designs here: http://robotics.eecs.berkeley.edu/~ronf/Prototype/ under the "Example Structures" heading.
I noticed Kangaroo seems to be a popular choice for physical simulations. I don't really even need to include forces like bending resistance - I'm happy to allow the design tool to approximate flexures as pin joint-type hinges. Once the design is unfolded, the details of how to cut the flexures could be worked out in a post-processing step. I wouldn't expect the tool to be able to realistically simulate the bending of the hinges.
I'm going to have to dig a lot deeper into understanding Grasshopper and Kangaroo. I only just got started with Grasshopper today by following the folding plate tutorial on wa11ace.com.au today. …