t defined from the discussion of radiation exchange between urban surfaces and the sky in urban heat island research (See Oke's literature list below). It will be affected by the proportion of sky visible from a given calculation point on a surface (vertical or horizontal) as a result of the obstruction of urban geometry, but it is not entirely associated with the solid angle subtended by the visible sky patch/patches.
So, I think using "geometry way" to approximate Sky View Factor is not correct. Sky View Factor calculation shall be based on the first principle defining the concept: radiation exchange between urban surface and sky hemisphere:
(image extracted from Johnson, G. T., & Watson, 1984)
Therefore, I always refer to the following "theoretical" Sky View Factors calculated at the centre of an infinitely long street canyon with different Height-to-width ratios in Oke's original paper (1981) as the ultimate benchmark to validate different methods to calculate SVF:
So, I agree with Compagnon (2004) on the method he used to calculate SVF: a simple radiation (or illuminance) simulation using a uniform sky.
The following images are the results of the workflow I built in the procedural modeling software Houdini (using its python library) according to this principle by calling Radiance to do the simulation and calculation, and the SVF values calculated for different canyon H/W ratios (shown at the bottom of each image) are very close to the values shown in Oke's paper.
H/W=0.25, SVF=0.895
H/W=1, SVF=0.447
H/W=2, SVF=0.246
It seems that the Sky View Factor calculated from the viewAnalysis component in Ladybug is not aligned with Oke's result for a given H/W ration: (GH file attached)
According to the definition shown in this component, I assume the value calculated is the percentage of visible sky which is a geometric calculation (shooting evenly distributed rays from sensor point to the sky and calculate the ratio of rays not blocked by urban geometry?), i.e solid angle subtended by visible sky patches, and it is not aligned with the original radiation exchange definition of Sky View Factor.
I'd suggest to call this geometrically calculated ratio of visible sky "Sky Exposure Factor" which is "true" to its definition and way of calculation (see the paper on Sky Exposure Factor below) so as to avoid confusion with "The Sky View Factor based on radiation exchange" as discussed in urban climate literature.
Appreciate your comments and advice!
References:
SVF: definition based on first principle
Oke, T. R. (1981). Canyon geometry and the nocturnal urban heat island: comparison of scale model and field observations. Journal of Climatology, 1(3), 237-254.
Oke, T. R. (1987). Boundary layer climates (2nd ed.). London ; New York: Methuen.
Johnson, G. T., & Watson, I. D. (1984). The Determination of View-Factors in Urban Canyons. Journal of American Meteorological Society, 23, 329-335.
Watson, I. D., & Johnson, G. T. (1987). Graphical estimation of sky view-factors in urban environments. INTERNATIONAL JOURNAL OF CLIMATOLOGY, 7(2), 193-197. doi: 10.1002/joc.3370070210
Papers on SVF calculation:
Brown, M. J., Grimmond, S., & Ratti, C. (2001). Comparison of Methodologies for Computing Sky View Factor in Urban Environments. Los Alamos, New Mexico, USA: Los Alamos National Laboratory.
SVF calculation based on first principle:
Compagnon, R. (2004). Solar and daylight availability in the urban fabric. Energy and Buildings, 36(4), 321-328.
paper on Sky Exposure Factor:
Zhang, J., Heng, C. K., Malone-Lee, L. C., Hii, D. J. C., Janssen, P., Leung, K. S., & Tan, B. K. (2012). Evaluating environmental implications of density: A comparative case study on the relationship between density, urban block typology and sky exposure. Automation in Construction, 22, 90-101. doi: 10.1016/j.autcon.2011.06.011
…
ng is deciding how and where to store your data. If you're writing textual code using any one of a huge number of programming languages there are a lot of different options, each with its own benefits and drawbacks. Sometimes you just need to store a single data point. At other times you may need a list of exactly one hundred data points. At other times still circumstances may demand a list of a variable number of data points.
In programming jargon, lists and arrays are typically used to store an ordered collection of data points, where each item is directly accessible. Bags and hash sets are examples of unordered data storage. These storage mechanisms do not have a concept of which data comes first and which next, but they are much better at searching the data set for specific values. Stacks and queues are ordered data structures where only the youngest or oldest data points are accessible respectively. These are popular structures for code designed to create and execute schedules. Linked lists are chains of consecutive data points, where each point knows only about its direct neighbours. As a result, it's a lot of work to find the one-millionth point in a linked list, but it's incredibly efficient to insert or remove points from the middle of the chain. Dictionaries store data in the form of key-value pairs, allowing one to index complicated data points using simple lookup codes.
The above is a just a small sampling of popular data storage mechanisms, there are many, many others. From multidimensional arrays to SQL databases. From readonly collections to concurrent k-dTrees. It takes a fair amount of knowledge and practice to be able to navigate this bewildering sea of options and pick the best suited storage mechanism for any particular problem. We did not wish to confront our users with this plethora of programmatic principles, and instead decided to offer only a single data storage mechanism.*
Data storage in Grasshopper
In order to see what mechanism would be optimal for Grasshopper, it is necessary to first list the different possible ways in which components may wish to access and store data, and also how families of data points flow through a Grasshopper network, often acquiring more complexity over time.
A lot of components operate on individual values and also output individual values as results. This is the simplest category, let's call it 1:1 (pronounced as "one to one", indicating a mapping from single inputs to single outputs). Two examples of 1:1 components are Subtraction and Construct Point. Subtraction takes two arguments on the left (A and B), and outputs the difference (A-B) to the right. Even when the component is called upon to calculate the difference between two collections of 12 million values each, at any one time it only cares about three values; A, B and the difference between the two. Similarly, Construct Point takes three separate numbers as input arguments and combines them to form a single xyz point.
Another common category of components create lists of data from single input values. We'll refer to these components as 1:N. Range and Divide Curve are oft used examples in this category. Range takes a single numeric domain and a single integer, but it outputs a list of numbers that divide the domain into the specified number of steps. Similarly, Divide Curve requires a single curve and a division count, but it outputs several lists of data, where the length of each list is a function of the division count.
The opposite behaviour also occurs. Common N:1 components are Polyline and Loft, both of which consume a list of points and curves respectively, yet output only a single curve or surface.
Lastly (in the list category), N:N components are also available. A fair number of components operate on lists of data and also output lists of data. Sort and Reverse List are examples of N:N components you will almost certainly encounter when using Grasshopper. It is true that N:N components mostly fall into the data management category, in the sense that they are mostly employed to change the way data is stored, rather than to create entirely new data, but they are common and important nonetheless.
A rare few components are even more complex than 1:N, N:1, or N:N, in that they are not content to operate on or output single lists of data points. The Divide Surface and Square Grid components want to output not just lists of points, but several lists of points, each of which represents a single row or column in a grid. We can refer to these components as 1:N' or N':1 or N:N' or ... depending on how the inputs and outputs are defined.
The above listing of data mapping categories encapsulate all components that ship with Grasshopper, though they do not necessarily minister to all imaginable mappings. However in the spirit of getting on with the software it was decided that a data structure that could handle individual values, lists of values, and lists of lists of values would solve at least 99% of the then existing problems and was thus considered to be a 'good thing'.
Data storage as the outcome of a process
If the problems of 1:N' mappings only occurred in those few components to do with grids, it would probably not warrant support for lists-of-lists in the core data structure. However, 1:N' or N:N' mappings can be the result of the concatenation of two or more 1:N components. Consider the following case: A collection of three polysurfaces (a box, a capped cylinder, and a triangular prism) is imported from Rhino into Grasshopper. The shapes are all exploded into their separate faces, resulting in 6 faces for the box, 3 for the cylinder, and 5 for the prism. Across each face, a collection of isocurves is drawn, resembling a hatching. Ultimately, each isocurve is divided into equally spaced points.
This is not an unreasonably elaborate case, but it already shows how shockingly quickly layers of complexity are introduced into the data as it flows from the left to the right side of the network.
It's no good ending up with a single huge list containing all the points. The data structure we use must be detailed enough to allow us to select from it any logical subset. This means that the ultimate data structure must contain a record of all the mappings that were applied from start to finish. It must be possible to select all the points that are associated with the second polysurface, but not the first or third. It must also be possible to select all points that are associated with the first face of each polysurface, but not any subsequent faces. Or a selection which includes only the fourth point of each division and no others.
The only way such selection sets can be defined, is if the data structure contains a record of the "history" of each data point. I.e. for every point we must be able to figure out which original shape it came from (the cube, the cylinder or the prism), which of the exploded faces it is associated with, which isocurve on that face was involved and the index of the point within the curve division family.
A flexible mechanism for variable history records.
The storage constraints mentioned so far (to wit, the requirement of storing individual values, lists of values, and lists of lists of values), combined with the relational constraints (to wit, the ability to measure the relatedness of various lists within the entire collection) lead us to Data Trees. The data structure we chose is certainly not the only imaginable solution to this problem, and due to its terse notation can appear fairly obtuse to the untrained eye. However since data trees only employ non-negative integers to identify both lists and items within lists, the structure is very amenable to simple arithmetic operations, which makes the structure very pliable from an algorithmic point of view.
A data tree is an ordered collection of lists. Each list is associated with a path, which serves as the identifier of that list. This means that two lists in the same tree cannot have the same path. A path is a collection of one or more non-negative integers. Path notation employs curly brackets and semi-colons as separators. The simplest path contains only the number zero and is written as: {0}. More complicated paths containing more elements are written as: {2;4;6}. Just as a path identifies a list within the tree, an index identifies a data point within a list. An index is always a single, non-negative integer. Indices are written inside square brackets and appended to path notation, in order to fully identify a single piece of data within an entire data tree: {2,4,6}[10].
Since both path elements and indices are zero-based (we start counting at zero, not one), there is a slight disconnect between the ordinality and the cardinality of numbers within data trees. The first element equals index 0, the second element can be found at index 1, the third element maps to index 2, and so on and so forth. This means that the "Eleventh point of the seventh isocurve of the fifth face of the third polysurface" will be written as {2;4;6}[10]. The first path element corresponds with the oldest mapping that occurred within the file, and each subsequent element represents a more recent operation. In this sense the path elements can be likened to taxonomic identifiers. The species {Animalia;Mammalia;Hominidea;Homo} and {Animalia;Mammalia;Hominidea;Pan} are more closely related to each other than to {Animalia;Mammalia; Cervidea;Rangifer}** because they share more codes at the start of their classification. Similarly, the paths {2;4;4} and {2;4;6} are more closely related to each other than they are to {2;3;5}.
The messy reality of data trees.
Although you may agree with me that in theory the data tree approach is solid, you may still get frustrated at the rate at which data trees grow more complex. Often Grasshopper will choose to add additional elements to the paths in a tree where none in fact is needed, resulting in paths that all share a lot of zeroes in certain places. For example a data tree might contain the paths:
{0;0;0;0;0}
{0;0;0;0;1}
{0;0;0;0;2}
{0;0;0;0;3}
{0;0;1;0;0}
{0;0;1;0;1}
{0;0;1;0;2}
{0;0;1;0;3}
instead of the far more economical:
{0;0}
{0;1}
{0;2}
{0;3}
{1;0}
{1;1}
{1;2}
{1;3}
The reason all these zeroes are added is because we value consistency over economics. It doesn't matter whether a component actually outputs more than one list, if the component belongs to the 1:N, 1:N', or N:N' groups, it will always add an extra integer to all the paths, because some day in the future, when the inputs change, it may need that extra integer to keep its lists untangled. We feel it's bad behaviour for the topology of a data tree to be subject to the topical values in that tree. Any component which relies on a specific topology will no longer work when that topology changes, and that should happen as seldom as possible.
Conclusion
Although data trees can be difficult to work with and probably cause more confusion than any other part of Grasshopper, they seem to work well in the majority of cases and we haven't been able to come up with a better solution. That's not to say we never will, but data trees are here to stay for the foreseeable future.
* This is not something we hit on immediately. The very first versions of Grasshopper only allowed for the storage of a single data point per parameter, making operations like [Loft] or [Divide Curve] impossible. Later versions allowed for a single list per parameter, which was still insufficient for all but the most simple algorithms.
** I'm skipping a lot of taxonometric classifications here to keep it simple.…
Added by David Rutten at 2:22pm on January 20, 2015
nd improvements. Many of the new features and components announced in the last release have become stable and have emerged from their WIP section. Additionally, after two years of work, we are happy to announce that we finally have full support of an OpenStudio connection within Honeybee, which has ushered in a whole host of new features, notably the modelling of detailed HVAC systems. As always you can download the new release from Food4Rhino. Make sure to remove the older version of Ladybug and Honeybee and update your scripts.
LADYBUG
1 - Solar Hot Water Components Out of WIP
After much beta-testing, bug-fixing, and general development, all of the Photovoltaic and Solar Hot Water components are now fully out of WIP! The main component is based on a Chengchu Yan's publication. Components have been added to Ladybug thanks to the efforts of Chengchu Yan and Djordje Spasic.. See Djorje’s original release post of the solar hot water components for more information on the components that just made it out of WIP.
2 - New Terrain Shading Mask Released in WIP
In addition to Djordje’s prolific addition of renewable energy components, he has also contributed a widely-useful component to generate terrain shading masks, which account for the shading of surrounding mountains/terrain in simulations. While initially added to assist the solar radiation radiation and renewable energy components, the component will undergo development to optimize it for energy and daylight simulations over the next few months. Another new component called Horizon Angles can be used to visualize and export horizon angles. You can test them out now by accessing them in the WIP section. For more information, see Djordje’s release post on the GH forum here.
3 - New Mesh Selector Component
After realizing that the Optimal Shade Creator component has applications to a whole range of analyses, it has now been re-branded as the Mesh Selector and has been optimized to work easily with these many analyses. Specifically, the component selects out the portion of a mesh that meets a given threshold. This can be the portion of a shade benefit analysis meeting a certain level of shade desirability, the portion of a radiation study meeting a certain level of fulx, the portion of a daylight analysis meeting a certain lux threshold, and much more!
4 - Solar Adjusted Temperature Now Includes Long Wave Radiation
Thanks to a question asked by Aymeric and a number of clarifications made by Djordje Spasic, the Solar Adjusted Temperature component now includes the ability to account for long-wave radiative loss to the sky in addition to it original capability to account for short wave radiation from the sun. As such, the component now includes all capabilities of similar outdoor comfort tools such as RayMan. The addition of this capability is also paralleled by the addition of a new horizontalInfraredRadiation output on the ImportEPW component. See the updated solar adjusted example file hereto see how to use the component properly.
5 - Support for both Log and Power Law Wind Profiles
In preparation for the future release of the Butterfly CFD-modelling insect, the Ladybug Wind Profile component now includes the option of either power law or log law wind profiles, which are both used extensively in CFD studies. Thanks goes to Theodoros Galanos for providing the formulas!
6 - New Radiant Asymmetry Comfort Components
Prompted by a suggestion from Christian Kongsgaard, Ladybug now includes components to calculate radiant asymmetry discomfort! For examples of how to use the components see this example file for spatial analysis of radiant asymmetry discomfort and this example for temporal analysis.
7 - Pedestrian Wind Comfort Component Released in WIP
In preparation for the impending release of the butterfly CFD-modelling insect, Djordje Spasic with assistance from Liam Harrington has contributed a component to evaluate outdoor discomfort and pedestrian safety. The component identifies if certain areas around the building are suitable for sitting, building entrances-exits, window shopping... based on its wind microclimate. Dangerous areas due to high wind speeds are also identified.You can check it out now in the WIP section.
HONEYBEE
1 - New HVAC Systems and Full OpenStudio Support
After a significant amount of development on the part of the OpenStudio team and two years of effort on the part of LB+HB developers, we (finally!) have full support for an OpenStudio connection within Honeybee. By this, we mean that any energy simulation property that can be assigned to a HBZone will be taken into account in the simulation run by the OpenStudio component. The connection to OpenStudio has brought with it several new capabilities. Most notably, you can now assign full HVAC systems and receive energy results in units of electricity and fuel instead of simple heating and cooling loads. This Honeybee release includes 14 built-in HVAC template systems that can be assigned to the zones, each of which can be customized:
0. Ideal Air Loads 1. PTAC | Residential 2. PTHP | Residential 3. Packaged Single Zone - AC 4. Packaged Single Zone - HP 5. Packaged VAV w/ Reheat 6. Packaged VAV w/ PFP Boxes 7. VAV w/ Reheat 8. VAV w/ PFP Boxes 9. Warm Air Furnace - Gas Fired 10.Warm Air Furnace - Electric 11.Fan Coil Units + DOAS 12.Active Chilled Beams + DOAS 13.Radiant Floors + DOAS 14.VRF + DOAS
Systems 1-10 are ASHRAE Baseline systems that represent much of what has been added to building stock over the last few decades while systems 11-14 are systems that are commonly being installed today to reduce energy use. Here is an example file showing how to assign these systems in Honeybee and interpret the results and here is an example showing how to customize the HVAC system specifications to a wide variety of cases. To run the file, you will need to have OpenStudio installed and you can download and install OpenStudio from here.
In addition to these template systems within Honeybee, the OpenStudio interface includes hundreds of HVAC components to build your own custom HVAC systems. OpenStudio also has a growing number of user-contributed HVAC system templates that have been integrated into a set of scripts called "Measures" that you can apply to your OpenStudio model within the OpenStudio interface. You can find these system templates by searching for them in the building components library. Here is a good tutorial video on how to apply measures to your model within the OpenStudio interface. Honeybee includes a component that runs these measures from Grasshopper (without having to use the OpenStudio interface), which you can see a demo video of here. However, this component is currently in WIP as OpenStudio team is still tweaking the file structure of measures and it is fairly safe to estimate that, by the next stable release of Honeybee, we will have full support of OpenStudio measures within GH.
2 - Phasing Out IDF Exporter
With the connection to OpenStudio now fully established, this release marks the start of a transition away from exporting directly to EnergyPlus and the beginning of Honeybee development that capitalizes on OpenStudio’s development. As such THIS WILL BE THE LAST STABLE RELEASE THAT INCLUDES THE HONEYBEE_RUN ENERGY SIMULATION COMPONENT.
The Export to OpenStudio component currently does everything that the Run Energy Simulation component does and, as such, it is intended that all GH definitions using the Run Energy Simulation component should replace it with the OpenStudio component. You can use the same Read EP Result components to import the results from the OpenStudio component and you can also use the same Energy Sim Par/Generate EP Output components to customize the parameters of the simulation. The only effective difference between the two components is that the OpenStudio component enables the modeling of HVAC and exports the HBZones to an .osm file before converting it to an EnergyPlus .idf.
For the sake of complete clarity, we should state that OpenStudio is simply an interface for EnergyPlus and, as such, the same calculation engine is under the hood of both the Export to OpenStudio component and the Run Energy Simulation component. At present, you should get matching energy simulation results between the Run Energy Simulation component and a run of the same zones with the OpenStudio component (using an ideal air system HVAC).
All of this is to say that you should convert your GH definitions that use the Run Energy Simulation component to have the OpenStudio component and this release is the best time to do it (while the two components are supported equally). Additionally, with this version of Honeybee you will no longer need to install EnergyPlus before using Honeybee and you will only need to install OpenStudio (which includes EnergyPlus in the install).
3 - New Schedule Generation Components
Thanks to the efforts of Antonello Di Nunzio, we now have 2 new components that ease the creation of schedule-generation in Honeybee. The new components make use of the native Grasshopper “Gener Pool” component to give a set of sliders for each hour of the day. Additionally, Antonello has included an annual schedule component that contains a dictionary of all holidays of every nearly every nation (phew!). Finally, this annual schedule component can output schedules in the text format recognized by EnergyPlus, which allows them to be written directly into the IDF instead of a separate CSV file. This will significantly reduce the size of files needed to run simulations and can even reduce the number of components on your canvas that are needed to add custom schedules. For more information, see Antonello’s explanatory images here and Antonello's example file here. You can also see a full example file of how to apply the schedules to energy simulations here.
4 - EnergyPlus Lookup Folder, Re-run OSM/IDF, and Read Result Dictionary
With the new capabilities of OpenStudio, we have also added a number of components to assist with managing all of the files that you get from the simulation. In particular, Abraham Yezioro has added a Lookup EnergyPlus Folder component that functions very similarly to the Lookup Daylight Folder component. This way, you can run an Energy simulation once and explore the results separately. Furthermore, we have added components to Re-Run OpenStudio .osm files or EnergyPlus .idf files within Grasshopper. These components are particularly useful if you edit these .osm or .idf files outside of Honeybee and want to re-run them to analyze their results in Grasshopper. Lastly, a component has been added to parse the .rdd (or Result Data Dictionary) file that EnergyPlus produces, enabling you to see all of the possible outputs that you can request from a given simulation.
5 - Electric Lighting Components Out of WIP
After Sarith Subramaniam’s initial components to model electric lights with Radiance in the last release, we are happy to report that they have been fully tested and are out of WIP. Improvements include support for all types of light fixture geometries and the ability to use the components in a more “Grasshoppery” list-like fashion. See Sarith’s original release post for more information and several example files showing how to use the components can be found here. 1 , 2 , 3 .
6 - Improvements to THERM Components
A number of bug fixes and improvements have been made to the THERM components in order to make their application more flexible and smooth. Special thanks is due to Derin Yilmaz , Mel King , Farnaz , Ben (@benmo1) , and Abraham Yezioro for all of the great feedback in the process of improving these components.
7 - HBObject Transform Components
After some demand for components that can ease the generation of buildings with modular zone types, two components to transform HBObjects with all of their properties have been added to the 00 | Honeybee section. The components allow you to produce copies of zones that are translated or rotated from the original position.
8 - Comfort Maps Supports PET and Integration of CFD Results
Thanks to the addition of the ‘Physiological Equivalent Temperature’ (PET) component by Djordje Spasic in the last stable release, it is now possible to make comfort maps of PET with Honeybee. PET is particularly helpful for evaluating OUTDOOR comfort with detailed wind fields at a high spatial resolution. As such, the new PET recipe has also been optimized for integration with CFD results. The windSpeed_ input can now accept the file path to a .csv file that is organized with 8760 values in each column and a number of columns that correspond to the number of test points. Components to generate this csv from Butterfly CFD results will be coming in later releases. Stay tuned!
As always let us know your comments and suggestions.
Enjoy!Ladybug Analysis Tools Development Team
…
s, the participants will focus on the key advantages of Grasshopper’s capabilities through a range of design challenges in order to aid designers in both their drafting tasks and modelling capabilities.
The workshop covers many concepts such as Object Attributes/Parameters, Data Types, Data Structures, and Designing with Algorithms. Specifically, this course will focus on understanding both Lists and Data Trees, as well as the best practices for integrating Grasshopper into your Professional Design Workflow. The workshop offers guided curriculum and continuous support, based on in-depth and professional learning experiences.
Workshop outcomes:Teach the participants how to:-
+ be proficient in parametric logics learning the key benefits of parametric techniques in architecture design workflow (when to use it & how to use it)+ Correctly communicate with different 3D and BIM packages in order to keep the geometry clean and light while preserving all NURBS information.+ Develop architecture design based on mathematical equations to create non-standard free form building skin.+ Create a pattern that changes dynamically based on specific inputs which can be applied over the building façade, interior walls or ceiling or even floor pattern.+ Automate and Optimize design variables to achieve the optimum solution for the design problem.
Program Outline:
DAY 1:-Introduction to Parametric Design -Introduction to Grasshopper & Rhino (technical tools).
DAY 2:-Exploring the parametric workflow. -Setup the design algorithm & generating a list of data.
DAY 3:-Introducing the new ways of generating parametric curves and surfaces.-Parametric form generation in-dept
DAY 4:-Introducing Data Tree logic and parametric transformations.-Creating Associative techniques – Attractors (points, curves and vectors).
DAY 5:-Working with advanced form generation with dynamic pattern.-Parametric optimization based on environmental analysis -featuring the Performance-Driven Design possibilities
DURATION:6 – 8 hours per day [50 - 60 hours Total]Every Saturday [9.00 Am : 1.00 Pm & 2.30 Pm : 6.00 Pm]
PREREQUISITES:No need of any specific knowledge of Rhinoceros or Grasshopper.
REGISTRATION:In order to register, you will need to fill the Registration Form .https://docs.google.com/forms/d/1PckdW1hrWs9fJAHWBZlVsuhH8K0PfDuMWIpXHT_4FYw/viewform
REGISTRATION DEADLINE:23th October 2014.…
Added by ayman wagdy at 7:48am on October 19, 2014
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)
…
an almost planar tissue (your case) can cause a variety of issues up to the undo able state (metal parts/components grow in size as well for no reason). See forces estimated by FF below.
2. Therefor I strongly suggest to consider Plan B (a) mastermind a secondary "anchor" capability in order to achieve a far more stable system (b) use a mount design that can support this (and comply with the attractor concept of yours). Here's a variable mount custom system (mostly machined AND not cast) that is suitable for the scope (Rhino reads the stp file OK .... but makes a colossally big file - thus I attach here the original).
3. On first sight lot's of things in this system appear "odd". For instance: is it stable? Why these double cables are used? How far can be adjusted? (that's a classic case for feature driven parametric design - not doable with Rhino).
4. This concept (strut axis exported only) is tested in FORMFINDER and some other far more complex membrane apps that I use quite often (not RhinoMembrane). Here's is what FF tells us about:
Observe a different kind of "stress" when this is converted to radial type:
5. If you insert the stp file to the Rhino file provided (exactly as exported from FORMFINDER - no mods of mine of any kind) you'll see what goes where (and why). That way the usage of double cables is rather obvious (and a lot other things - for instance the way that the struts achieve "equilibrium", see the slots in the base mount plate.
6. If this approach is worth considering your definition requires some serious rethinking (far more simpler/manageable with the drawback that the real parts they are "static" they can adjust only as far this particular solution allows them to do - controlling them parametrically is clearly impossible with the current state of R/GH capabilities).`
All in all: this case works because the cables push the anchor points downwards and the struts push them upwards.
more in a while
…
in App store.
2. Modelo now supports VR! check out this video:
3. We've added a specular option in the rendering settings. So now you can have your design rendered a little bit shinny-er.
4. There is also a "filters" option in this panel, with which you can get some interesting image post processing effects. We are expanding this filter library, if you have any suggestions, please let us know.
5. This one is very important and has been requested by our customers for a long time. Now when you upload a model, you can grab the reviews(3d comments, screenshots,sketches) from your previously uploaded model! This works really conveniently if you use Modelo for your design review/presentation, cause you don't have to recreate the same 3d anchor views every time you made some changes to your design.
6. Also, our developer API is almost ready, which means if anyone is interested in developing a grasshopper plugin that works with Modelo, they can!
There are some many other updates and bug fixes happened. I don't want to list all of them here. Definitely stay subscribed with our newsletter. Modelo is thrived to grow into a more comprehensive platform! If you have any good ideas about our platform, please do not hesitate to let me know!
Here is our Youtube channel: https://www.youtube.com/channel/UCufBShhLtUQepsit9ilI-AA
Cheers
Qi…
Added by Suqi to Modelo at 1:24pm on October 18, 2016
cribes a set of machine movements in X, Y and Z (Z being Pen Up and Pen Down) directions. It very closely related to G-code in this way - just slightly more simple than G-code overall.
For tool selection you use the Select Pen - SPx - command, x is the number of the pen you are using. As I'm using a vinyl cutter without a pen/tool changer I just use SP1 in the file header/ini of the cutter.
Without knowing the full spec of your machine it is hard to say for certain BUT all of my experience with CNC machines - of all sizes and spec levels - the actual control files are pretty much the same. Very simple text based HPGL or G-code text files run all motion control - even on things like 7 axis robot arms etc. For plotting I'd expect you'd be able to get a usable HPGL/PLT file without a lot of work - its just a matter of matching the file to what the machine is expecting.
To answer your question about getting the file to the printer its maybe best to explain it this way: there are two parts to this project1/ Create the correctly formatted text/hpgl/plt file ready to send to the printer2/ Send the file to printer
For part 1/ the procedure is:
Select the curves you want to printConvert the curves into a set of pointsFormat these points into HPGL Save this HPGL as a text file
For 2/ we need a way to stream the text file to a printer port
To do this I've used an old dos command line technique that allows allow you to 'copy' a text file to a printer LPT or COM port:
copy /b c:\spool\ini.plt LPT1
Type the above into a DOS command line and it will send a text file called ini.plt to the printer on LPT1 port. As you'll see in my attached code I use os.system calls in my python code to send files when needed.
So your original code was doing some strange things with the conversion from curves to points. Lines/Polylines were OK - with the code just using the line end points. For curves and polycurves the code code was exploding these into segments and then dividing into set of points. However this led to two issues: - curves that started off as closed polycurves would end up being plotted as open curve segments - which is not very good for a cut file and not very smooth for a plot file.- the division of the curves to points was by distance - and if this wasn't an exact division of the length of the curve the end point would not match up with the next line - again not ideal for a cutting file which needs to be a closed curve.
To solve the above I changed to using rs.ConvertCurveToPolyline - with the tolerance set to match the HPGL resolution of 0.025mm - this converts all curves needed to plot to polylines, leaves everything closed and ends points line up perfectly.
I had one other problem with my setup - I ran into a file size/curve number/plotting points upper limit. A small number of curves would cut/plot fine, however at a certain number in one file the print driver would throw an error and the plotter would not even start plotting the file. I could not work out where is the system this limit was being imposed. The current working version of my code is attached - it gets around this file size limit by creating a separate print file for each curve required and sending them to the plotter in sequence. Not as completely tidy as I'd like as it flashes up a cmd window on every loop - but plots/cuts are perfect.
The final 'nice touch' for the project is I've created a custom tool bar button to run the script - all I have to do to cut a file is hit the button on the tool bar, select the curves and hit enter = SO EASY!
I've attached my latest code, a sample HPGL file to plot a rectangle, and a screen shot of setting up the custom toolbar button.
Cheers
DK…
eration!
See an example work flow for designing, simulating and analysing a Photovoltaic system below.
Download a Grasshopper and Rhino example file:
https://www.dropbox.com/s/krbszlplj5i40dz/017_HBgeneration%20Rhino%20model.3dm?dl=0
https://www.dropbox.com/s/lxneuzal3mipd2q/017_HBgeneration.gh?dl=0
See a quick introduction and tutorial videos here: https://www.youtube.com/playlist?list=PLrx2KnyhaJ5YXo5hpk8Q9q4Vy99O5IegK
1. Select a building to mount a photovoltaic generator on (seen in Rhino in green).
2. Select a surface within that building to mount a photovoltaic generator on (seen in Rhino in green).
3. Create a Honeybee context surface from that surface.
4. Place a photovoltaic generator on that Honeybee context surface by using the Honeybee generation component. Honeybee_Generator_PV and connecting the context surface to it's input _HBSurfaces. Then you can specify both the performance and the financial data of the photovoltaic generator.
5. Create a Honeybee generation system which consists of the photovoltaic generator in 4. By using the component Honeybee_generationsystem and connecting 4 to its input PVHBSurfaces_. Then you can specify the annual maintenance cost of this system.
6. Run the simulation in Energy Plus by connecting 5. to the input HBGenerators_.
7. Read the results of the simulation:
- The electricity produced by the Honeybee generation system in 5.
- The net purchased electricity of the facility (the Honeybee zone) to which the Honeybee generation system is attached to. This is the electricity consumed by the facility less the electricity generated by the Honeybee generation system.
- The financial costs of the Honeybee generation system; capital, maintenance and replacement costs.
8. Calculate the net present cost of the Honeybee generation system in 5 assuming a 25 year lifetime.
9. Visualise the net present cost.
…
de in Italy: gli architetti Arturo Tedeschi, computational designer e autore del bestseller “Parametric Architecture with Grasshopper” e Maurizio Degni, i fashion designer Flavia Migani, Simone Bruno e Chiara Cola ed infine dello shoe designer Alessio Spinelli, vincitore del concorso Who’s On Next 2011 nella categoria Accessori.
Frutto della loro energia e sinergia emozionale è un’opera corale che fonde le singole discipline nel rispetto delle loro identità, generando un innovativo manifesto espressivo e produttivo basato sull’integrazione dei tradizionali strumenti di disegno con processi parametrici elaborati al computer, oramai potente sistema d’indagine e sperimentazione formale per ogni disciplina artistica.
L’installazione, composta da quattro abiti completi e due calzature collocati all’interno di una scultura parametrica in costante dialogo con lo spazio espositivo, è il punto d’incontro tra decenni di ricerca teorica e una nuova consapevolezza progettuale. Il contributo musicale di Davide Severi, la documentazione dell’intero processo creativo e i video firmati da Francesco Ricci Lotteringi si offrono allo spettatore coinvolgendolo in un apprendimento multidisciplinare.
__
In the evocative setting of the Cloister of Bramante, from July 7th to 10th, a new project created by Double comes to life: NU:S.
An extraordinary and engaging installation, which examines the contamination between Fashion and Architecture and attempts to break the mold of the Roman art scene taking advantage of the important creative contribution of young and talented members of Made in Italy: the architects Arturo Tedeschi (computational designer and author of the bestselling "Parametric Architecture with Grasshopper ") and Maurizio Degni; the fashion designers Chiara Cola, Simone Bruno, Flavia Migani, and Alessio Spinelli (shoe designer winner of the 2011 Who's On Next in Accessories category). The concept and the creative direction are the undertaking of Antonella Buono. The result is a harmonious work that merges the individual disciplines while respecting their identities creating an innovative expressive manifesto, thanks to the use of a revolutionary architectural language: the parametricism .
Parametricism is a paradigm which utilises digital models generated through new techniques of computer programming, which today can be considered as equally powerful systems of investigation and formal experimentation, as are considered conventional drawing tools.
The installation, which is the culmination of decades of theoretical research and a new planing knowledge, consists of four dresses, complete with accessories, which are located within a parametric framework in constant dialogue with the exhibition space, involving the audience in a multidisciplinary learning process.
The installation soundtrack was composed by Davide Severi, a talented musician with a substantial knowledge of reinassance music and strong digital music background.
…