he field of digital design, fabrication, emerging technology and makers. the experts spend two weeks in bratislava, developing their research project and at the end of their residency we invite eager and interested people – fellows – to form a think-tank and take part in the pinnacle of the project.the event will be highly experimental and no specific result is guaranteed. the event will be accessible also to people who want to observe and learn, however the purpose of the gathering is not to teach, but rather to experiment, consult, make and network. the rese arch lab is not a tutorial workshop, it’s a platform for common development.
download a pdf
research project
the project questions the current condition of the large scale 3d printing capabilities. while small scale, desktop 3d printers emerge each day with better and better quality of the output, large scale printing is based mostly on low fidelity concrete printing, or in few cases not-so-high-quality metal printing.we will try to develop new solutions for large scale, rapid 3d printing by merging different technologies. those will constitute the main structure of the designed output, while the 3d printing will be seen only as the solidifying agent.we will utilize the kuka robot with an attached abs/pla extruder as the main production tool.
call for fellows
the fellows will join the last 4 days of the research, consult the current state, come up with new ideas and help verify and test the outputs. the fellows are being called for through a portfolio and cv selection process. the exceptional individuals who can both, benefit from and contribute to the project will be selected by mateusz zwierzycki and jan pernecky. no specific number of open positions are available and it is possible that no one will be chosen.
call for trainees
it will be possible to attend the rese arch lab to the people with no expertise or previous experience. they will take a role of observers or trainees. it has to be explicitly stated though, that the event is not meant to teach any specific software or skills and the experiments can fail in achieving an output.
application
to apply send an email at lab@rese-arch.org. the deadline for the submissions is monday, 6 april 2015 at noon 12pm.
costs
the participation fee is fixed 150€ for the fellows and 200€ for the trainees. this covers only the participation at the rese arch lab event. the traveling expenses and accommodation costs need to be covered by the participants themselves.
equipment
various equipment will be available – including 3d printers, 3d scanners, milling machines, laser cutters, vinyl cutters.most of all, rese arch and partners have to their full disposal a robotic arm kuka kr15/2.
the requirements
if you find yourself proficient in: parametric design (viewed as aesthetics), 3d printing, robotics, scripting, architectural geometry, cam technologies or woodworking then the event will be surely interesting for you. at the same time we seek for people with exceptional sense for aesthetics, as the final output will be designed together (not just by the project leader).on the hardware/software side, we need you to bring your own laptop. we will work mainly with rhino/grasshopper.…
rototyping techniques, the programme will investigate patterns of emergence, differentiation and complexity in natural formation processes which will be transformed to digital simulation platforms for design purposes. In contemporary architectural processes, a significant diversion from linear parametric tools towards generative design simulations is taking place. The design and analysis processes will reflect this shift by focusing on simulations, whereby attention will be kept on the process of design generation as opposed to the final form itself. The design agenda of the programme will revolve around the design and fabrication of a one-to-one scale pavilion.
The programme will be formulated as a two-phase process:
Stage 1: Participants will gain an understanding of formation processes in nature, coupled with core concepts related to complexity. During this stage, basic and advanced tutorials on generative design algorithms and analysis tools will be provided. AA Istanbul VS will perform as a team-based workshop promoting collaboration and research. Participants will be introduced to advanced fabrication techniques.
Stage 2: Participants will propose design interventions based on the skills and knowledge gained during the first stage. Study models of various scales will be produced, finally followed by the fabrication and assembly of a full scale working prototype which unifies the design goals of the programme.
The design agendas of AA Athens and AA Istanbul Visiting Schools will directly create feedback on one another, allowing participation in either one or both Programmes.
Prominent features of the programme / skills developed:
Participants will be part of an active learning environment where the large tutor to student ratio (4:1) allows for personalized tutorials and debates.
The toolset of AA Istanbul includes but is not limited to Rhinoceros, Grasshopper, and Processing.
Participants will have access to large-scale digital fabrication tools.
Design seminars and international lecture series will support the key objectives of the programme.
Eligibility
The workshop is open to current architecture and design students, PhD candidates and young professionals.
Accreditation
Participants receive the AA Visiting School Certificate with the completion of the Programme.
Applications
The AA Visiting School requires a fee of £600 per participant, which includes a £60 Visiting Membership fee. Discount options for groups or for those wishing to apply for both AA Istanbul and AA Athens Visiting Schools are available. Please contact the AA Visiting School Coordinator for more details.
The deadline for applications is 30 May 2016. No portfolio or CV, only requirement is the online application form and fees.
For more information, please visit:
http://www.aaschool.ac.uk/STUDY/VISITING/istanbul
http://ai.aaschool.ac.uk/istanbul/
For inquiries, please contact:
elif.erdine@aaschool.ac.uk…
dologies and large-scale prototyping techniques from previous years, while bringing together a range of experts from internationally acclaimed academic institutions and practices, Architectural Association, Zaha Hadid Architects, among others.
AA Istanbul Visiting School will investigate the inherent associations between form, material, and structure through the rigorous implementation of innovative design and fabrication techniques. Computational methods for design, analysis, and fabrication will be coupled with physical experimentation. The key objective of AA Istanbul Visiting School will comprise the design and fabrication of a one-to-one scale prototype realized by the use of robotic fabrication techniques.
The programme will be formulated as a two-phase process:
Stage 1: Participants will gain an insight of material processes, computational methods, and various fabrication techniques, culminating with core concepts related to complexity in design practices. During this stage, basic and advanced tutorials on generative design algorithms and analysis tools will be provided.
Stage 2: Participants will propose design interventions based on the skills and knowledge gained during the first stage. Study models of various scales will be produced, finally followed by the robotic fabrication and assembly of a full scale working prototype which unifies the design goals of the programme.
The design agendas of AA Athens and AA Istanbul Visiting Schools will directly create feedback on one another, allowing participation in either one or both Programmes.
Prominent features of the programme / skills developed:
Participants will be part of an active learning environment where the large tutor to student ratio (4:1) allows for personalized tutorials and debates.
The toolset of AA Istanbul includes but is not limited to Rhinoceros and Grasshopper, as well as analysis software.
Participants will have access to advanced digital fabrication tools.
Robotic design and fabrication processes will formulate the physical prototyping phase of the programme.
Eligibility
The workshop is open to current architecture and design students, PhD candidates and young professionals. Prior software knowledge is not required.
Accreditation
Participants receive the AA Visiting School Certificate with the completion of the Programme.
Applications
The AA Visiting School requires a fee of £600 per participant, which includes a £60 Visiting Membership fee. Discount options for groups or for those wishing to apply for both AA Istanbul and AA Athens Visiting Schools are available. Please contact the AA Visiting School Coordinator for more details.
The deadline for applications is 14 June 2017. No portfolio or CV, only requirement is the online application form and fees.
For more information, please visit:
http://www.aaschool.ac.uk/STUDY/VISITING/istanbul
http://ai.aaschool.ac.uk/istanbul/
For inquiries, please contact:
elif.erdine@aaschool.ac.uk…
a and we'll stop adding new stuff. At this point the Grasshopper version will be rolled to 1.0 Beta 1 and we'll keep on fixing serious bugs, resulting in Grasshopper 1.0 Beta 2 etc. etc. until the product is stable enough to be treated as a commercially viable product.
This does not mean Grasshopper will no longer be free. Robert McNeel & Associates (who develop and own the copyrights to Grasshopper) haven't decided yet whether or not to sell Grasshopper or whether to keep it as a free plug-in for Rhino customers.
As soon as Grasshopper 1.0 goes into beta, all development (apart from the odd bug-fix) stops and we start typing on Grasshopper 2.0. It will probably be a few months until the first 2.0 WIP version is released but basically the whole process starts over.
What are we looking to accomplish for 1.0 and which things are planned for 2.0 and beyond? The only major feature still missing in 1.0 is the Remote Control Panel. This feature was removed at some point and has been partially rewritten since then. Once it's finished, we consider the 1.0 feature set to be complete.
To be honest we've made very few concrete plans yet concerning 2.0, however it's clear that some things need to be at least seriously considered and researched. Here follows a list in no particular order:
Documentation System. This is one of the things we know we're going to do as we've already started. The Grasshopper help system will need to be rewritten and a lot of help topics need to be typed up. We have a pretty good idea what it is we want to accomplish with the new help and how we're going to go about it.
Vocabulary. Along with new documentation we'll critically analyse the current terminology and vocabulary of Grasshopper. We'll probably come up with glossaries and style sheets. We want to use words that are —at best— self documenting and —at worst— non ambiguous.
SDK and core library cleanup/improvement. Grasshopper was the first large scale product I ever developed and a lot of mistakes were made in the SDK design. A lot of functions and classes have been marked obsolete over time and many operations are not properly bottlenecked. I also want to add a lot more events so it's easier for code to keep close tabs on what's going on at any given moment.
GUI platform. At the moment Grasshopper is pure .NET winforms using GDI+ for all the interface drawing. There are certain performance issues with using large GDI+ surfaces and certain limitations on what we can and cannot draw. We will be investigating other graphics pipelines such as WPF, OpenGL, DirectX, OpenTK and whatever else seems promising.
Multi-threading. It is clear that some components are embarrassingly parallel, and since almost every single laptop and desktop has at least 4 cores these days it would be a shame not to use them. We will investigate what it takes to implement multi-threading as a standard feature.
Large file support. Grasshopper becomes awkward to use when a document contains more than a hundred or so components. We need to both improve the interface to provide methods for layering or grouping sub-algorithms and also add ways to reduce memory and computational overhead.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
lly it should not make much of a difference - random number generation is not affected, mutation also is not. crossover is a bit more tricky, I use Simulated Binary Crossover (SBX-20) which was introduced already in 1194:
Deb K., Agrawal R. B.: Simulated Binary Crossover for Continuous Search Space, inIITK/ME/SMD-94027, Convenor, Technical Reports, Indian Institue of Technology, Kanpur, India,November 1994
Abst ract. The success of binary-coded gene t ic algorithms (GA s) inproblems having discrete sear ch sp ace largely depends on the codingused to represent the prob lem variables and on the crossover ope ratorthat propagates buildin g blocks from pare nt strings to childrenst rings . In solving optimization problems having continuous searchspace, binary-co ded GAs discr et ize the search space by using a codingof the problem var iables in binary st rings. However , t he coding of realvaluedvari ables in finit e-length st rings causes a number of difficulties:inability to achieve arbit rary pr ecision in the obtained solution , fixedmapping of problem var iab les, inh eren t Hamming cliff problem associatedwit h binary coding, and processing of Holland 's schemata incont inuous search space. Although a number of real-coded GAs aredevelop ed to solve optimization problems having a cont inuous searchspace, the search powers of these crossover operators are not adequate .In t his paper , t he search power of a crossover operator is defined int erms of the probability of creating an arbitrary child solut ion froma given pair of parent solutions . Motivated by t he success of binarycodedGAs in discret e search space problems , we develop a real-codedcrossover (which we call the simulated binar y crossover , or SBX) operatorwhose search power is similar to that of the single-point crossoverused in binary-coded GAs . Simulation results on a number of realvaluedt est problems of varying difficulty and dimensionality suggestt hat the real-cod ed GAs with t he SBX operator ar e ab le to perform asgood or bet t er than binary-cod ed GAs wit h t he single-po int crossover.SBX is found to be particularly useful in problems having mult ip le optimalsolutions with a narrow global basin an d in prob lems where thelower and upper bo unds of the global optimum are not known a priori.Further , a simulation on a two-var iable blocked function showsthat the real-coded GA with SBX work s as suggested by Goldberg
and in most cases t he performance of real-coded GA with SBX is similarto that of binary GAs with a single-point crossover. Based onth ese encouraging results, this paper suggests a number of extensionsto the present study.
7. ConclusionsIn this paper, a real-coded crossover operator has been develop ed bas ed ont he search characte rist ics of a single-point crossover used in binary -codedGAs. In ord er to define the search power of a crossover operator, a spreadfactor has been introduced as the ratio of the absolute differences of thechildren points to that of the parent points. Thereaft er , the probabilityof creat ing a child point for two given parent points has been derived forthe single-point crossover. Motivat ed by the success of binary-coded GAsin problems wit h discrete sear ch space, a simul ated bin ary crossover (SBX)operator has been develop ed to solve problems having cont inuous searchspace. The SBX operator has search power similar to that of the single-po intcrossover.On a number of t est fun ctions, including De Jong's five te st fun ct ions, ithas been found that real-coded GAs with the SBX operator can overcome anumb er of difficult ies inherent with binary-coded GAs in solving cont inuoussearch space problems-Hamming cliff problem, arbitrary pr ecision problem,and fixed mapped coding problem. In the comparison of real-coded GAs wit ha SBX operator and binary-coded GAs with a single-point crossover ope rat or ,it has been observed that the performance of the former is better than thelatt er on continuous functions and the performance of the former is similarto the lat ter in solving discret e and difficult functions. In comparison withanother real-coded crossover operator (i.e. , BLX-0 .5) suggested elsewhere ,SBX performs better in difficult test functions. It has also been observedthat SBX is particularly useful in problems where the bounds of the optimum
point is not known a priori and wher e there are multi ple optima, of whichone is global.Real-coded GAs wit h t he SBX op erator have also been tried in solvinga two-variab le blocked function (the concept of blocked fun ctions was introducedin [10]). Blocked fun ct ions are difficult for real-coded GAs , becauselocal optimal points block t he progress of search to continue towards t heglobal optimal point . The simulat ion results on t he two-var iable blockedfunction have shown that in most occasions , the sea rch proceeds the way aspr edicted in [10]. Most importantly, it has been observed that the real-codedGAs wit h SBX work similar to that of t he binary-coded GAs wit h single-pointcrossover in overcoming t he barrier of the local peaks and converging to t heglobal bas in. However , it is premature to conclude whether real-coded GAswit h SBX op erator can overcome t he local barriers in higher-dimensionalblocked fun ct ions.These results are encour aging and suggest avenues for further research.Because the SBX ope rat or uses a probability distribut ion for choosing a childpo int , the real-coded GAs wit h SBX are one st ep ahead of the binary-codedGAs in te rms of ach ieving a convergence proof for GAs. With a direct probabilist ic relationship between children and parent points used in t his paper,cues from t he clas sical stochast ic optimization methods can be borrowed toachieve a convergence proof of GAs , or a much closer tie between the classicaloptimization methods and GAs is on t he horizon.
In short, according to the authors my SBX operator using real gene values is as good as older ones specially designed for discrete searches, and better in continuous searches. SBX as far as i know meanwhile is a standard general crossover operator.
But:
- there might be better ones out there i just havent seen yet. please tell me.
- besides tournament selection and mutation, crossover is just one part of the breeding pipeline. also there is the elite management for MOEA which is AT LEAST as important as the breeding itself.
- depending on the problem, there are almost always better specific ways of how to code the mutation and the crossover operators. but octopus is meant to keep it general for the moment - maybe there's a way for an interface to code those things yourself..!?
2) elite size = SPEA-2 archive size, yes. the rate depends on your convergence behaviour i would say. i usually start off with at least half the size of the population, but mostly the same size (as it is hard-coded in the new version, i just realize) is big enough.
4) the non-dominated front is always put into the archive first. if the archive size is exceeded, the least important individual (the significant strategy in SPEA-2) are truncated one by one until the size is reached. if it is smaller, the fittest dominated individuals are put into the elite. the latter happens in the beginning of the run, when the front wasn't discovered well yet.
3) yes it is. this is a custom implementation i figured out myself. however i'm close to have the HypE algorithm working in the new version, which natively has got the possibility to articulate perference relations on sets of solutions.
…
ack to .ghx?
This is in relation to a discussion I've been having with David Rutten & Scott Davidson about GH consuming memory in a relatively large GH definition (~. I think what I've learned from this is that one should limit the size of the GH file, or put some incremental stops in the definition to limit the length of calculations that it runs at once. Is this a valid conclusion?
The GH file we're talking about is 7Mb & the Rhino file is about 120Mb, but when working w/ the GH def. I try to only keep about 2 curves turned on.
Here's a summary of the discussion:
Hi Mike,thanks for sending it over. I've been fiddling with the file for about 10 minutes and it climbed from 1.7 GB to 1.9GB, but then I've been switching previews on which means more meshes get calculated so you'd expect a higher memory consumption. It is possible we're leaking memory, but if you're working for hours on end, memory fragmentation might also explain part of the increase. Basically, memory gets fragmented just like disks get fragmented after prolonged use, difference is that memory cannot be defragmented unless you restart the application and allow it to start with a clean slate. I'll try and find any leaks we may have missed in the past.Goodwill,David
──────────── David Rutten
On 09/03/2011 06:19, Mike Calvino wrote:
Thanks very much David for the quick response. I've attached the files zipped. I can't figure out what's doing it. After working in the file for awhile, the memory usage in the Windows Task Manager climbs . . . it's gotten to 1.57+Gb before I exited GH & Rhino5Wip & let it dissipate, then restart & work for awhile before it does it again. It probably takes like 4 or 5 hours before it gets that high. That's the highest it's gotten, & that only happened while I was working in a Rhino file that had all of the elements baked into it - turned off at least, but it still climbed to 1.57+Gb. It seems to climbs when you work in the file & move around in both the GH def. & the Rhino file. Like turn on a few of the Extr components at the right end of the "StandareRibExtuder" groups, you can watch the MemUsage go up, but when you turn them off, it does not go down. - goes up fast at this point. Maybe I need to figure out how to do the definition with fewer components, I'm sure that's part of it, but I must confess, I think I'm still early on in the learning curve.I really hope that this is not operator error on my part & I do apologize up front if it is. I have done a disk cleanup, I have tried excluding .3dm & .ghx files from my NOD32 antivirus, no change. I hope you can find something.Let me know if you have any trouble with the files.See if you find anything & please let me know . . . thanks!Cheers! --Mike CalvinoCalvino Architecture Studio, inc.www.calvinodesign.com
…
about it.
2. Nick's comment below got me thinking about unit testing for clusters. Being able to work will data flowing in from outside the cluster or having multiple states to test against could be really cool. Creating definitions that were valid across a general cross section of possible input parameters was a significant issue for us. It was all too easy to write the definition as if we were drawing (often we were working from sketches) and then have it fail when the input parameters changed slightly.
4. I wasn't thinking about threading the solver itself. I was thinking along the lines of some IDEs that I've seen which compile your project while you type it. I know that threading within components and at the rhinocommon-level is a freaking hard problem that has been discussed at length already. (although when, 5-10 years from now, it's finished it will be very cool)
Let's say the solver is threaded and the canvas remains responsive. As soon as you make a change to the GH file, the solver needs to be terminated as it is now computing stale data.
What if the solver was a little more atomic and like a server? A GH file is just a list of jobs to do with the order of the jobs and the info to do them rigidly defined - right? The UI could pass the solver stuff to do and store the results back in the components on a component by component basis (i have no idea what the most efficient way to do this is in reality - I'm just talking conceptually) this might even allow running multiple solvers to allow for at least the parallelism the might be built into a given GH file to be exploited (not within components but rather solving non-interdependent branches of components simultaneously). This type of parallelism would more than make up for the performance hit you alluded to for separating the UI and the solver (at least for most of the definitions i write).
I was imagining a couple of scenarios:
a) Writing a parallel module: solver starts chewing away - you see it working - you know it's done 1/3 of the work - if you have something to do at that point you could connect up to some of the already calculated parameters and write something in parallel to the main trunk which is still being solved.
b) Skipping modifications: you need to make a series of interventions at different intervals along a section of code. Sure you could freeze out that bit of a section of down steam code and make modifications so you can observe the effects more quickly. Unfreeze a bit more and repeat etc. etc. until your done and then unfreeze that big chunk at the end to make sure you haven't blown anything up. Just letting it resolve as far as it can while you sit there waiting for inspiration seems a lot more intuitive to me though.
On a file which takes 15 minutes to solve that's no big deal, but you certainly don't want to be adding a 20 millisecond delay to a solution which only takes 30 milliseconds.
You also wouldn't notice it at that point :-) perhaps for things where it would really make a difference, like Galapagos interactivity, it could be disabled - or could the existing "speed" setting just digest this need? Since the vast majority of time that Gh is solving is on files under active development not on finished code, i think qualitative performance is probably more important that quantitative performance (again with cases like Galapagos needing to be accommodated). In our case the code only had to "work" once since its output went to a cnc machine to make a one off project and it didn't really matter if it took 15 seconds or 15 hours for the final run.
Lastly, I have no way to predict how long a component is going to take. I can probably work out how far along in steps a component is, but not how far along in time.
that's ok, from a user point of view, just seeing a percentage tick along once in a while would be nice reassurance that the thing is just slow and has not, in fact, crashed. Maybe there could be two modes of display: the simple percentage version for unpredictable code and, for those of us able to calculate the time taken for our algorithm based on the number of input parameters, a count down in seconds or minutes or whatever.
I think a good place to start with these sort of problems is to keep on improving clusters, ... etc etc
i totally agree.
…
Added by Dieter Toews at 7:53pm on September 4, 2013
ives that have been shared so far.
Intersect Shouldn't Punt When Encountering Areas of Intersection
Several posts talk about how Booleans are really just shortcut implementations of the Intersect/Trim/Split/Join (ITSJ) design pattern. Agreed. I realized this when trying to understand and resolve my first Boolean related problem. So when I broken down my characterization to the 4 component steps, I found is that it was the Intersect operation that was generating an erroneous (read: incomplete) set of intersection curves. I posted my findings along with a possible solution in an email to McNeel tech support and in this Rhino discussion an edited version of which I’ve quoted again below. But the only response I received from McNeel was that I shouldn't expect any changes in the product that improves Booleans.
The unexpected behavior I've been having with Rhino, and by extension Grasshopper, is that the current implementation of the Rhino Intersect command is generating an incomplete network of curves when given 2 surfaces having regions that are (almost) coincident. When Intersect determines that there's no single curve able to represent the intersection in those areas, but rather an area of intersection, Intersect erroneously doesn't generate any curve to represent that portion of the intersection — which is mathematically incorrect. This decision to "punt" in these situations renders the generated results to not be useful for subsequent steps of the ITSJ design pattern. Rather than not including these areas of intersection in the network of curves, Intersect should generate any non-kinky, non-looping curve(s) through a region of intersection that connects with all other intersection curves adjacent to the region. Any valid curve is far more useful — and mathematically correct — than no curve through these regions.
Informative and Detailed Error Reporting Will Save Users’ Time
A number of users feel as I do that the error information available when an operation fails is insufficient.
The Rhino Learning Curve Is Fractally Steep
While some responses have suggested that I’m just too new to Rhino, a number of long-time Rhino users have said that they are continually “learning” the product's idiosyncrasies, and expect that they will never really know what the product will do every time. What they’ve learned from their years of experience is how to hack their designs to work around Rhino’s quirks.
I conclude from these stories that, sure, I’m green, but that I, all of us, are destine to be forever “green” because the current development methodology results in a product that can never really be understood.
Wow.
In his reply above @Paul N Jeffies said…
One thing that's important to understand when using Rhino for this kind of thing is that Rhino does not have a particularly meaningful conception of a 'solid object' - solids are defined simply as a collection of (infinitely thin) NURBS surfaces joined together with no gaps between. That's part of the reason for the problems with booleans in Rhino, but it also means that you don't really need boolean operations since you can do everything by exploding the polysurface and using the Intersect/Trim/Split commands on the individual surfaces to build up the boundary surfaces you want, then rejoin into a solid afterwards.
As a software architect with ~40 years of tech experience, I would again suggest that the root cause of the product's unknowability is the lack of rigor so far exhibited in defining the layers of abstraction. If proper rigor were applied, then, from a user’s perspective, a solid really would be a solid. The proper way to reduce a solid to a set of adjacent surfaces would be to use a function like ExplodeSolid, and to get a set of curves from a surface we would have to use ExplodeSurface, and so on. So rigor doesn’t prohibit users from pulling back the curtain, but rather empowers the core development team to enforce encapsulation at the current layer of abstraction — whether point, curve, surface, solid, or whatever.
The Solution Begins With Changing The Conversation
With all this said, I don’t believe that Rhino is fatally flawed or impossible to fix. I also don't believe that the resulting loss of productivity is the users' fault. I do believe though that the first step is for all, McNeel and users, to name the condition, raise this as a high priority, work collaboratively to define a corrected abstraction stack, and add appropriate rigor to the implementation of the next major release.
About a month ago I spent about 1/2 hour searching through the Rhino discussions for topics related to The Boolean Problem. I found literally 100's of posting, with many noops like I am now saying they were giving up and going to another tool because Rhino’s learning curve was too steep. Yes, filleting and trimming are two other big Rhino problems that I believe have similar roots. Yet I wonder whether these deep-seated challenges could, in fact, be overcome — by first changing the conversation.
I’d again ask what other, more experienced users think.
- Bob…
Added by neobobkrause at 2:49pm on October 4, 2016
ly has finally metamorphosed to have all known major bugs fixed and is ready to be used by a larger number of people in our community.
Butterfly is powered by OpenFOAM, which is a validated and open-source engine for Computational Fluid Dynamics (CFD). Primarily, Butterfly assists with exporting geometry and other input parameters from the CAD + scripting interface to the OpenFOAM engine. The Grasshopper plugin supports live results visualization that updates as the CFD simulation iterates. The Dynamo plugin supports results visualization once the analysis is over or paused.
For installation instructions and guidance on getting started, check out the Butterfly wiki page. There, you can find step-by-step installation directions and tutorial videos. There also 3 YouTube playlists for getting you started with installing OpenFOAM for Windows and using Butterfly for Grasshopper and Butterfly for Dynamo.
Similar to other ladybug tools, Butterfly uses an external validated engine (in this case, OpenFOAM) and you need to install it first to get the insect up-and-running. However, unlike Radiance and EnergyPlus, OpenFOAM doesn’t have a native installation for Windows and it requires Linux to run. Accordingly, the current version of “OpenFOAM for Windows” uses a technology called docker to run a Linux virtual machine on your system, inside which OpenFOAM operates. While this sounds complicated, the good news is that all of this setup has been packaged into the installer for “OpenFOAM for Windows.” So running this installer with all its defaults should give you everything you need.
The bad news is that the installation can fail if you don’t check your Windows system properly beforehand or don’t follow every step carefully afterwards. You will also need to run Rhino, Revit, and OpenFOAM as an administrator to ensure Butterfly works properly (by right-clicking each launcher for the program and selecting “Run As Administrator"). This said, if you follow the steps carefully, you should have no issues with the installation. You can find some of the issues that people faced during the alpha testing and the solutions to them here.
Butterfly is the first plugin that is fully developed based on the structure that I discussed before which consists of a core library and [+] libraries for specific software (in this case Grasshopper and Dynamo). We hope this structure to extend ladybug tools to more platforms by re-using the current code. We will provide a better documentation with more details on this matter in the near future but for now you can use the API for butterfly, butterfly_grasshopper and butterfly_dynamo for customizing or extending the current development.
Finally, having access to a powerful CFD engine from inside parametric/generative modeling environments is a great power and as Spider-Man or Uncle Ben once said:
“with great power comes great responsibility!”
We believe in learning by doing and we don’t expect you to be a CFD expert to get started with butterfly however we expect you to educate yourself along the way. If you have never used OpenFOAM before here is a great presentation to get started. We also highly recommend checking out the official OpenFOAM User Guide that goes through most of its functionality. Finally, we have also collected a number of other learning resources on this page that can be a good starting point.
We understand that you will have questions about the plugins which you can post to this forum or Dynamo discussion forum however CFD related issues and questions should be posted to CFD Online.
I like to thank everyone who have helped us with the development and testing during the last year or so, and special thank to Theodore who single-handedly educated me through the process of migrating to OpenFOAM and developing butterfly. Butterfly wasn’t possible without Theodore!
As always let us know about your comments and suggestions.
Happy flying the butterfly! Happy Spring!
…