tically give you back all the items of the list. However, if you give it a list of lists (as you are in this example) it doesn't know to extract the items in the internal lists. The script I suggest simply reinterprets each list as a single item, and relies on the component data processing to split out the items list by list. This also has the advantage (over 筑梦NARUTO's solution) of keeping each list in its own grasshopper data tree branch.
If you'd rather avoid the clunkiness of a second script component, you'll have to compose a datatree yourself. That will look something like this:
import math as m
import Rhino
from Grasshopper.Kernel.Data import GH_Path
from Grasshopper import DataTree
pi = m.pi
angle =0
pts = DataTree[Rhino.Geometry.Point3d]()
c=0
for i in rs.frange(0,5,0.5):
angle +=(pi/30)
layer = []
for j in rs.frange(0,2*pi,pi/15):
x= 5*m.sin(j+angle)
y= 5*m.cos(j+angle)
layer.append( Rhino.Geometry.Point3d(x,y,i))
pts.AddRange(layer,GH_Path(c))
c = c+1
a = pts
…
to explain the ultimate goal in case it helps to clarify. I have all the elements i need now to pull this together thanks to your help, as you say most critical things are already implemented or not relevant to this particular thread. With your fret generator and equal spacing generator and my primitive convoluted solution for compound radius fretboard i have everything i need but need some time to cleanly implement and pull it together now.
as to your questions/coments:
1/ I don't care about Excel files in this context. The SIMPLE solution is to just copy/paste sets of string gauges into as many panels as you need and switch between them.
this was just to explain that ultimately there are a lot of different input patterns but all the data for them does already exist. for sure it is not necessary but in the end it's a feature i would like to implement since it will make the patch much more practical.
2/ What are "scale length low E string" and "scale length high e string"? Are they the actual string lengths of the bass and treble strings?
This is the initial decision taken by the luthier: which scale lengths to use for the multiscale build. While anything that makes sense goes here luthiers will probably want to choose some common values, say 24.75" (like most Gibson guitars) or 25.5" (like a Fender Stratocaster)
P.S. I did the rotations at the points where the treble string intersects the virtual bridge and nut (blue lines), so rotation has no effect on its length.
P.P.S. In case it isn't obvious, rotation has no effect on string spacing either.
This is the kind of things i don't know cause i'm zero in maths and i usually have to try out and measure to know for sure :-) as i said my initial instinct would have been to rotate around the 'zero frets' center point simply because everything is built aroun d the X axis. If you rotate around the treble string (the high e string) would the distance of the upper fretboard edge to the x-axis be the same than from the lower fretboard edge to the x-axis ?
for running data through panels, thanks for the tip, i do this mainly to visualize the values without having to hover over the outputs, good to know i shouldn't patch them onward from the panel.
PS: For the height of the strings above the fretboard (the 'action'), it's not as complicated as it sounds and most of the time an experienced luthier or guitar tech will have no problem achieving whatever low action desired if the neck is straight and built properly and the frets level and dressed properly. there's a german company who's built a machine to do the 'perfect setup': the PLEK machine
i'm sorry it takes me much longer to digest and implement all this, i will post back when i've merged everything together but i think i have evrything so far
…
hit Commit.
I'm wondering how hard it would be to have an edit box which shows the
number the user could click inside of then type in a new number, then
hit enter. :)
2) How would I go about using one line from a table and assign each
field to a variable? Then, move a slider or something and use the values
from the next row?
background: I'm recreating elbows, Tees, and other fittings using
paramatric scripts, then baking and exporting them. Here's one source
table, http://www.wardfittings.com/Assets/PDFs/0902CatalogColorOld.pdf
page 5, the uniform elbows.
Current Setup: the attached ghx file. Create a point at 0,5,0 in a blank
document with units set to inches, then assign that point to the top
left 'Center Pnt' in the ghx file.
Current workflow:
a) Modify variables A, B, H, and Nominal Dia to match one line from the
table in the linked PDF file, page 5, table of regular elbows.
b) Select the 'Nodes' and 'Surfaces' with a drag box
c) Click 'Bake'
d) Switch to Rhino window, do the 'sellast' command.
e) Drag baked objects along Y axis so the center point is at 0,0,0
f) Run 'Join'
g) Run 'Cap'
h) set the 'node' points to a layer called 'nodes'
i) set the surface to a layer called 'fit-3d'.
j) select the surfaces and nodes
k) export selected
This elbow that I'm doing only has 12 rows, so doing it the above method
doesn't take THAT long. I'm also going to be doing a couple with larger
tables like the Tee on page 8, and in other spec files. As you can
imagine, entering in EACH value into a slider is a bit tedious.
I'd love to take the pdf table, run it through an OCR program to convert
to excel, modify the headers so the ghx script knows what they are, then
paste it into grasshopper, or save it and have grasshopper read it, and
I be able to move a slider or something to to select one line at a time.
Has anyone done something similar? ie: assigned one row in a table to a
predefined set of variables, each variable coming from one field in the row?
Thanks for taking the time to read this message. :)
I'm making a rhino script to do steps d-k, so that part will be much faster.
-Suthern…
is a tour through the different workshops we have organized in theTPceu from September 2010 when we started with this initiative.I take this opportunity to thank you all for your participation directly or indirectly to make all of this possible.
La exposición consiste en un recorrido por los diferentes talleres que hemos organizado en el TPceu desde septiembre de 2010 que arrancamos con ésta iniciativa.
Aprovecho para agradeceros a todos vuestra participación dirécta o indirecta para conseguir que todo ésto se haya hecho posible.
Organization: Pablo Delgado, Andrés Velasco Muro, Jaime Díaz Álvarez
more info at TP ceu…
urve. In this Curve I have defined the points, I exploded the segments and have added a Perp Frame on the ends of each segment.
Oriented on each Perp Frame I have created a Rectangle from which I have drawn a Box Rectangle.
Each 'other' (odd or even, or each 'second' rectangle in the list) of these rectangles needs to get a negative length value so it doesn't point outward of the curve, but instead so that it has it's length perpendicular to the segment.
So, eventually I want to make it so that each segment has a Box Rectangle placed on it's outermost point, pointing inwards. Half of these Box Rectangles is already oriented in the right direction, but I don't know how to single out half of them, or construct two lists with the 1st, 3rd, 5th, 7th, etc. and the 2nd, 4th, 6th, 8th etc.
I have added screenshots, I am making this as a personal project for a school project on the Art Academy and am really eager to learn to master this Grasshopper a bit more.
Before trying to do it this way, I tried to do it with Sweep1 Rail, but could not get the orientation along the segment, and also I didn't manage to find out how to limit the Sweep1 Rail to a certain distance (like 30mm for example).
I had imagined this should be done by projecting a second line of 30mm from a segment outer end inwards from both sides and using this second 30mm long line to put the Sweep 1 Rail on. Then I could close the ends, do a Union, Merge all Faces and be done.
However, I couldn't figure it out and the method I'm trying to solve now has gotten me further down the line of the process.
The next step in my process will be to be able to generate a structure on a point of a curve where I can project a certain shape on. Then I want to export this collection of shapes as an STL and 3D-print them. (I have built 2 3D-printer all by myself).
The parts are connectors to connect cheap aluminium extrusions together with minimal effort so I can start prototyping a shape for a small carriage I am designing.
If my explanation is unclear, please tell me, I am new to this, and my mother-language is Dutch, so mathematical terms are a bit difficult for me to understand, but please do use diffcult terms in an explanation where needed. I can only learn :)
Hi from a very happy new user of Grasshopper!
…
arametric Design, in the history of architecture, has defined many rules for current designers and for future practitioners to follow. One of the strongest aspects that are prominent from this style is ‘geometry’. Arguably, there is nothing new about geometry and aesthetics forming the most prominent aspect of any style or era. The language of any style, in the long history of architecture, is visually defined by geometry or shape, beyond the principles that define the core of the style. In the distinguishable style of parametric architecture, geometry has played and is continuing to play an integral role. And with this fairly young style, there are many strings of myths and false notions associated.
The workshop aims to provide a detailed insight to ‘parametric design’ and embedded logics behind it through a series of design explorations using Rhinoceros & Grasshopper platforms, along with understanding of data-driven fabrication strategies. An insight to Computational Design and its subsets of Parametric Design, Algorithmic Design, Generative Design and Evolutionary Design will be provided through presentations, technical sessions & studio work, with highlighting agenda of using data into Hands-on fabrication of a parametrically generated design. A strong focus will be made on ‘geometry’ and ‘matter’.
// Methodology
Workshop has been structured to teach participants the use of Grasshopper® (Generative modelling plug-in for Rhinoceros) as a generative tool, and ways to integrate it with Hands-on Fabrication process. A strong agenda on ‘geometry’ and ‘matter’ will form the focus of the studio with design experimentation through computational & parametric techniques, culminating into a manually fabricated wall panel using understanding of data-driven design during the course of workshop.
Day 1 Topics / Agenda
Rhinoceros 3D GUI and basic use
Installing Grasshopper & plug-ins
Grasshopper GUI
Basic logic, components, parameters, inputs, numbers, simple geometry, referenced geometry, locally defined geometry, baking, etc.
Lists & Data Tree: management, manipulation, visualization, etc.
Design Experimentations with Geometry & Data
Understanding Data for Manual Fabrication
Day 2 Topics / Agenda
Design Experimentations with Geometry, Form, Matter
Data for effective numbering and strategizing during Manual Fabrication
Collaborative effort for Hands-on ‘making’ process
Analysis & Evaluation of Fabricated Geometry
Documentation…
Analysis Tools (LAT). Our plugin has come a long way in the last 4 years and, while the legacy version will still include some small updates and contributions, we are confident in saying that the changes will be far fewer and the plugin more stable in the following months as we switch gears into the LAT effort. I can say personally that (save for a couple of small capabilities) I have made it through my list of critical features and I will hereafter be working on making these features cross-platform, cleanly-implemented, and well-documented in the new Ladybug Analysis Tools software package. 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.
The majority of changes with this release represent “icing on the cake” after a long, multi-year effort to connect to the major open source engines and datasets. So, without further adieu, here is the list of the new capabilities added with this release:
LADYBUG
Stereographic Sky Projections - Thanks to several code contributions from Byron Mardas, all Ladybug sky visualizations now support stereographic projections! Such projections are useful for understanding the hemispherical visualizations in a 2D format and they also make it easier to overlay different sky datasets on top of one another. Check here for an example file showing the sun path overlaid with helpful/harmful parts of the sky and see here for an example file using shading masks representing strategies (like an overhang) on top of the helpful / harmful portions of the sun path.
Wind Rose Upgrades - Devang Chauhan has added several new features to the Ladybug wind rose including both visual and numerical outputs of average wind velocity and frequency for each petal of the rose. Not only does this enhance the usefulness of the rose but it also paves the way for the use of the wind rose to set up CFD simulations once Butterfly is released in the near future. The new features of the wind rose can be seen in this hydra example file.
Complete Set of Local Thermal Discomfort Models - After the last release included components to evaluate radiant asymmetry discomfort (which can be modeled using these example files: 1, 2), today’s release completes Ladybug’s suite of local discomfort models from ASHRAE and the ISO by adding components to account for discomfort from cold draft. Specifically, two draft models have been added for different types of situations. The first is an older model published by P.O. Fanger, which was developed through experiments where subjects had cold air blown on the back of their neck (the most sensitive part of the body to draft). While this is useful for understanding a worst-case scenario, it can greatly overestimate the discomfort for cases of draft at ankle level - a more common occurrence that typically results from the tendency of cold air to sink. For this situation, a second draft discomfort model has been included, which is specifically meant to forecast ankle draft discomfort. The model is currently undergoing review for integration into ASHRAE-55 and a publication outlining the derivation of this model can be found here:
Liu, S., Schiavon, S., Kabanshi, A. and Nazaroff, W. (2016), Predicted Percentage Dissatisfied with Ankle Draft. Indoor Air. Accepted Author Manuscript. doi:10.1111/ina.12364 (http://escholarship.org/uc/item/9076254n).
Special thanks is due to Shichao Liu, Toby Cheung and Stefano Schiavon for sharing the model and the results of their study with the development team. The integration of draft models completes the full integration of ASHRAE-55 and EN-15251 with Ladybug. Now, you can rest assured that, if there is a certain thermal comfort standard that you need to fulfill for a given project, you can model it with the ‘bug!
Window-Based Draft Model - With the integration of draft models, the first question that one might ask is “how should these models be applied to typical design cases?” While the (soon-to-be-released) Butterfly plugin for OpenFOAM should open up a Pandora’s box of possible situations, this release of Ladybug includes a simplified downdraft model from cold vertical surfaces, which helps model several typical cases of draft discomfort. The model has been validated across several papers:
Heiselberg, P. (1994). Draught Risk From Cold Vertical Surfaces. Building and Environment, Vol 29, No. 3, 297-301
Manz, H. and Frank, T. (2003). Analysis of Thermal Comfort near Cold Vertical Surfaces by Means of Computational Fluid Dynamics. Indoor Built Environment. 13: 233-242
It has been built into the “Ladybug_Downdraft Velocity” component and has been included in an example file illustrating discomfort from cold windows in winter. The example is intended to show when glazing ratio and window U-Values are small enough to eliminate perimeter heating - a practice that is aesthetically unpleasing, costly to maintain and wasteful in its energy use.
Operative Temperature on the Psychrometric Chart - This is a feature that should have been added a long time ago but we are finally happy to say that the Ladybug_Psychrometric Chart can draw a comfort polygon assuming that the air temperature and radiant temperature are the same value (aka. an operative temperature psychrometric chart). This operative temperature chart is the format that is needed to use the ASHRAE-55 graphical method and is generally a better representation of the range of comfort in cases where one does not intend to hold the radiant temperature constant. This operative temperature capability is now set as the default on the component but you can, of course, still bring back the older comfort polygon by simply plugging in a value for meanRadiantTemperature_.
Contour Map Visualizations - Using the same inputs as the Ladybug_Recolor Mesh component, the new Ladybug_Contour Mesh component allows you to generate contoured color graphics from the results of any analysis. Now, you to maximize the use of your high-resolution studies with contours that highlight thresholds and gradients!
Image Texture Mapping for Colored Meshes - Antonello DiNunzio has added the very useful Ladybug_Texture Maker component, which allows you to bake Ladybug colored meshes with image texture maps (as opposed to the classic method that used colored vertices). This enables the creation of transparent Ladybug meshes, making it even easier to overlay Ladybug graphics with one another and with Rhino geometry:
This component also adds the ability to render Ladybug + Honeybee meshes with other rendering programs like V-Ray and 3ds Max. So you can produce Ladybug graphics like this!
Finally, image-mapped textures are also the format required for gaming and Virtual Reality software like Unity and Augmented Reality programs like Augment. So now you can export your Ladybug meshes all of the way to the virtual world!
Rhino Sun Component - If you have ever had to set up the sun for a rendering plugin and wished that you could just take your Ladybug sun and use that, then you are in luck! Byron Mardas has contributed a component that lets you set the Rhino sun based on your EPW location data, your north direction (if different from the Y-Axis) and any time of day that you want. Not only does this make it easier to coordinate the Rhino sun with your Ladybug visualizations, but you can also use it for real time shadow previews by setting your Rhino view to “Rendered” and scrolling through a slider.
Rendered Ladybug Animations - With both the image texture mapping and the Rhino sun components released, your first thought might be “it would be great if I could use this all in a rendered animation!” Thankfully, Ladybug has added a new component to help you here. The Ladybug_Render View component works in essentially the same way as the Capture View component, allowing you to make a series of images as you animate through a slider. The major benefit here is that it works with both Rhino Render and V-Ray so that animations like this can be produced effortlessly:
Cone of Vision Added - Antonello Di Nunzio has added a component that allows you to visualize various cones of vision in order to help inform your view studies. You can fine tune parameters to include just text-readable or full peripheral vision and use the resulting view cone to constrict the results of your “Ladybug_View Analysis” studies.
Terrain WIP Components Released as the Gismo Plugin - Our friend Djordje has released a new plugin Gismo - a plugin for GIS environmental analysis. As a result the following 5 terrain components: Horizon Angles, Flow Paths, Terrain Shading Mask, Terrain Generator 2, Terrain Analysis, have been removed from Ladybug+Honeybee's WIP section and are added to Gismo.
HONEYBEE
Search, Select, and Import the Hundreds Outputs from EnergyPlus/OpenStudio - Many of the power users in our community know that EnergyPlus is capable of writing several hundred different outputs from the simulation (well beyond what the basic Honeybee result readers can import). While Honeybee has always allowed one to request these outputs by adding them to the simulationOutputs_ of the component, there has not been an official workflow for searching through all of the possible outputs or importing their specific results… until now! We have added the "Honeybee_Read Result Dictionary" component, which allows you to parse the Result Data Dictionary (or .rrd file) that EnergyPlus outputs during every run of a given model. This allows you to see all of the outputs that are available for the model and you can even search through this list to find a particular output that you are interested in. Once you find what you are looking for, simply copy the text output from the component into a panel and and plug this into simulationOutputs_. Then you can use the "Honeybee_Read EP Custom Result" component to bring your custom results into GH after rerunning the simulation. The example file of an evaporative cooling tower shows how to use the workflow to request and import in the energy removed by the tower.
OpenStudio HVAC System Sizing Results - After the full integration of HVAC in the last release, we realized that a number of people wanted to run EnergyPlus models simply to evaluate the size of the Heating/Cooling system in the model (obtained from the EnergyPlus autosize calculation that is run at the start of every simulation). Such a sizing calculation can be a great way to quantify the anticipated savings from a given strategy (like shading) on the size/cost of the building’s HVAC system. To get the results of the sizing calculation, all that one needs to do is connect the output eioFile from the OpenStudio component to the Honeybee_Read HVAC Sizing component. The outputs will indicate the peak heating/cooling loads of each zone (in Watts) as well as the size of each piece of HVAC equipment in the model. The next time that you are on a project that is about to value-engineer out an exterior shading system, use the workflow in the following example file to show that the client will probably end up paying for it with a more expensive HVAC system: Quantifying HVAC Sizing Impact of Shade.
Improved Memory Usage When Building Large Energy Models - As we take the capabilities of Honeybee to larger and larger models, many of us have begun to run up against a particular limitation of our machines: memory. After upgrading our machines to have 32 GBs of RAM, there was only one way left to alleviate the problem: restructure some of the code. Honeybee now uses an enhanced approach that ensures all the previous iterations of Honeybee objects will be removed from the memory once there is a change. In any case, the considerations of memory are definitely something that we intend to improve with the future Honeybee[+] plugin.
Workflow to Import gbXML Files - While GrizzlyBear has been around for several years, enabling us to export Honeybee zones to gbXML, we have gone for quite some time without a workflow to import gbXML files to Honeybee. The new Honeybee_gbXML to Honeybee component addresses this and establishes an easier path to import models from Revit into honeybee. You can read more about the component in this post.
Window Frame Capabilities Added to OpenStudio - After the implementation of LBNL THERM / WINDOW capabilities in the last two releases, there was one final bridge to build in the Honeybee workflow - fully connecting LBNL WINDOW to Honeybee’s OpenStudio workflow. This release of Honeybee will now write all FrameAndDivider objects exported from LBNL WINDOW glazing systems into the energy simulation, enabling you to account for the frame’s thermal bridging effects. As long as the construction is brought in with the Honeybee_Import WINDOW IDF Report component, the frames associated with the construction will be assigned to all windows that have the construction. Finally, it is worth noting that the current Honeybee will also write all glass spectral data as well as gas (or gas mixture) materials into the simulation. This means that essentially all properties of any IDF export that one makes from LBNL WINDOW can be factored into the OpenStudio energy simulation (with the only exception being BSDF materials).
OpenStudio Daylight Sensors Added - In our previous releases of Honeybee, the only means of correctly account for daylight sensors in an energy simulation was to run an annual daylight simulation and use the resulting schedules for the lighting in the energy simulation. However, this can take a lot of time and work to set up and run, particularly if the daylight control (at the end of the day) will be driven by just one sensor per room. Now, we have added another option, which uses OpenStudio/EnergyPlus’s built-in daylight controls. You can assign just a point and an illuminance target on the “Set Zone Thresholds” component and the lighting will be automatically adjusted in the course of the simulation. It should also be noted that the addition of daylight sensors has also coincided with the addition of blind/shade control based on glare. The same sensor point for daylight can be used to drive dynamic shades in the energy simulation based on glare experienced at this point. This example file shows how to set up daylight controls on the EnergyPlus model and check the lighting power results to see the effect.
Better Defaults for Natural Ventilation - After many good people wrote to me informing me that Honeybee overestimates natural ventilation airflow and I wrote back showing the way that I intended natural ventilation to be set up with the component, it dawned on me that I had selected some poor component defaults. Accordingly, this release includes a window-based natural ventilation option on the Set EP Airflow component that corrects for some of the common issues that I have seen. Insect screens are included by default and the component runs a general check to see if wind-driven cross ventilation is possible before auto-assigning it. The component will air on the side of more-conservative, lower airflow rates unless the user overrides the defaults. Finally, it’s worth noting that all of these changes have not affected the freedom of the Custom WindAndStack option on the component. The new defaults can be viewed in this example file.
CFD Results Can be Plugged into Microclimate Maps - In preparation for the (very soon) release of the Butterfly that connects to the OpenFOAM CFD platform, we just wanted to note that all of the microclimate map recipes can now take an input of a csv file with a matrix of CFD results for wind speed. For the time being, we have used these to produce very high-accuracy, high resolution maps of outdoor comfort. There will be more to follow soon!
We should also note that, in the last release I mentioned that we would be phasing out the EnergyPlus component so that all efforts are focused on the OpenStudio component. While I reiterate that all of the features of the EnergyPlus component are available in the OpenStudio component and I encourage everyone to use the OpenStudio component in order to take advantage of its HVAC capabilities, I have come to realize that many prefer to use the EnergyPlus component out of habit and have not yet gotten the time to understand why the OpenStudio component is an improvement over the EnergyPlus component. As a result, we have decided to leave the EnergyPlus component in place for the time being so that everyone has more time to understand this. The future Ladybug Analysis Tools platform will only interact with EnergyPlus through OpenStudio and so it is recommended that everyone use these two components in the Honeybee plugin will serve as an educational resource to understand our current path moving forward with OpenStudio.
Lastly, it is with great pleasure that we welcome Devang Chauhan and Byron Mardas to the developer team! As mentioned previously Devang has contributed several updates to the Ladybug Wind Rose in addition to finding and solving a multitude of bugs in other components. Byron has contributed code that has enabled the previously-mentioned stereographic sky projections along with a better method for running the Ladybug Sky Mask. Finally, Byron has contributed the Rhino Sun component, which allows you to coordinate your Rhino renders with your Ladybug data. Welcome to the Ladybug team, gentlemen!
As always let us know your comments and suggestions. Cheers!
Ladybug Analysis Tools Development Team…
hat since we create a list of materials and we assign them to surfaces - volumes the next step could be to have an Life Cycle Analysis and Financial assessment produced.
The most common form to produce an LCA into a form that is commonly used and easily communicated is in the form of Environmental Product Declarations (EPDs) that follow ISO 14025:2006. As every form of LCA, EPDs raise a bunch of question regarding their boundaries and the accuracy of the results especially if we include the factor of location. In comparison with other LCA practices though, EPDs have to be followed by Product Category Rules (defining the boundaries of the study) that can be reviewed by external parties if the EPD is to go public. Part from that EPD results reflect each stage of the life cycle of a product including potential benefits from Reuse or Recycling. Finally if you have a system - for example a building - you can add the EPDs of the different subcomponents forming the building and get a final EPD for the building itself - the point where I think HB's functionality is fully aligned.
The financial assessment can easily be concluded if one has the price of the material he/she uses. Finally the environmental indicators of the EPDs (LCI, LCIA) can be translated into Shadow Costs (Shadow costs for Environmental Indicators here) and added to the final financial assessment as an option.
I have developed a similar plug-in (in C#) for Grasshopper for my master's thesis last year. The project focused on the comparison between constructing normally and constructing implementing Design for Deconstruction practices in steel buildings. The idea was to compare the two cases based on their environmental and financial performance. In the process I included also options for transportation of the material and for shadow cost, embodied energy and carbon assessment and more. The final outcome can be visualised in Rhino's viewports and exported to excel sheets. The plug-in is connected to local db with EPD data for steel profiles. The same scheme though can be followed for any type of material if we have the right database to connect it to!
Please have a look if interested at the report here! And let me know if you have any questions!
Please note that the report includes 3+ chapters dedicated to design for deconstruction practices e.t.c that are irrelevant with the topic but maybe interesting to read:)
Also if someone is interested in the report I can always send it to you.
(I will upload a video -runthrough of the plug-in later this week)
I would be very interested to have these capabilities in LB and HB and happy to help realising it!
Thanks
Tasos
…
mplex the models are. If we are running multi-room E+ studies, that will take far longer to calculate.
Rhino/Grasshopper = <1%
Generating Radiance .ill files = 88%
Processing .ill files into DA, etc. = ~2%
E+ = 10%
Parallelizing Grasshopper:
My first instinct is to avoid this problem by running GH on one computer only. Creating the batch files is very fast. The trick will be sending the radiance and E+ batch files to multiple computers. Perhaps a “round-robin” approach could send each iteration to another node on the network until all iterations are assigned. I have no idea how to do that but hope that it is something that can be executed within grasshopper, perhaps a custom code module. I think GH can set a directory for Radiance and E+ to save all final files to. We can set this to a local server location so all runs output to the same location. It will likely run slower than it would on the C:drive, but those losses are acceptable if we can get parallelization to work.
I’m concerned about post-processing of the Radiance/E+ runs. For starters, Honeybee calculates DA after it runs the .ill files. This doesn’t take very long, but it is a separate process that is not included in the original Radiance batch file. Any other data manipulation we intend to automatically run in GH will be left out of the batch file as well. Consolidating the results into a format that Design Explorer or Pollination can read also takes a bit of post-processing. So, it seems to me that we may want to split up the GH automation as follows:
Initiate
Parametrically generate geometry
Assign input values, material, etc.
Generate radiance/ E+ batch files for all iterations
Calculate
Calc separate runs of Radiance/E+ in parallel via network clusters. Each run will be a unique iteration.
Save all temp files to single server location on server
Post Processing
Run a GH script from a single computer. Translate .ill files or .idf files into custom metrics or graphics (DA, ASE, %shade down, net solar gain, etc.)
Collect final data in single location (excel document) to be read by Design Explorer or Pollination.
The above workflow avoids having to parallelize GH. The consequence is that we can’t parallelize any post-processing routines. This may be easier to implement in the short term, but long term we should try to parallelize everything.
Parallelizing EnergyPlus/Radiance:
I agree that the best way to enable large numbers of iterations is to set up multiple unique runs of radiance and E+ on separate computers. I don’t see the incentive to split individual runs between multiple processors because the modular nature of the iterative parametric models does this for us. Multiple unique runs will simplify the post-processing as well.
It seems that the advantages of optimizing matrix based calculations (3-5 phase methods) are most beneficial when iterations are run in series. Is it possible for multiple iterations running on different CPUs to reference the same matrices stored in a common location? Will that enable parallel computation to also benefit from reusing pre-calculated information?
Clustering computers and GPU based calculations:
Clustering unused computers seems like a natural next step for us. Our IT guru told me that we need come kind of software to make this happen, but that he didn’t know what that would be. Do you know what Penn State uses? You mentioned it is a text-only Linux based system. Can you please elaborate so I can explain to our IT department?
Accelerad is a very exciting development, especially for rpict and annual glare analysis. I’m concerned that the high quality GPU’s required might limit our ability to implement it on a large scale within our office. Does it still work well on standard GPU’s? The computer cluster method can tap into resources we already have, which is a big advantage. Our current workflow uses image-based calcs sparingly, because grid-based simulations gather the critical information much faster. The major exception is glare. Accelerad would enable luminance-based glare metrics, especially annual glare metrics, to be more feasible within fast-paced projects. All of that is a good thing.
So, both clusters and GPU-based calcs are great steps forward. Combining both methods would be amazing, especially if it is further optimized by the computational methods you are working on.
Moving forward, I think I need to explore if/how GH can send iterations across a cluster network of some kind and see what it will take to implement Accelerad. I assume some custom scripting will be necessary.…