l coarse mesh
Subdividing this mesh into strips of thin quads
Relaxing/Planarizing this mesh
Splitting and Unrolling
In this post I deal with the first 2 of these stages.
You can download the example definition here:
developable_strips_tutorial.gh
Drawing the initial mesh
To begin with we need a simple quad mesh. This can be modelled manually in Rhino, and only needs to use enough quads to give the topology and very rough form. No need to worry too much about the exact geometry or dimensions at this point, as we will refine and alter it as we go.
One very important thing that we do need to bear in mind though is that all internal vertices must have even valence (I covered this a bit in the earlier post here).
So for example, this is bad:
(because the highlighted vertex is surrounded by 5 faces)
While this is good (and can still be relaxed to the same shape):
(the top and bottom vertices have valence 8, and the vertices between the arms have valence 4)
With a little practice it should be possible to convert any mesh into one that meets this condition.
The reasons why we need this condition should become more clear in the later steps.
First subdivision
This is where we choose how many strips we want our final model to have, by applying a few rounds of subdivision using the Refine component (you could also use Weaverbird here):
Sorting the face directions
While quad meshes do not carry the same information about u/v directions as a NURBS surface, the individual faces do have a sort of direction given by their vertex ordering. However, these face directions are usually not consistently arranged, especially after subdivision.
The Kangaroo MeshDirection component attempts* to orient all the faces in a mesh so that they match with their neighbours.
For example, before sorting, if we draw a line from the midpoint of the first edge of each face to the midpt of its opposite edge, we might get something like this:
Whereas after sorting, we should get something like this:
*note that I say it attempts to orient the faces consistently. In some cases no valid solution exists, for instance if 3 or 5 faces meet around a vertex, hence the requirement mentioned at the start for even valence vertices.
Directional Subdivision
Now that we have consistent face directions across the mesh, we can apply further subdivision, but this time in one direction only. So we go from roughly square quads to thin rectangles. The idea is that as we apply higher levels of this directional subdivision, the final relaxed result goes towards something semi-discrete. A NURBS surface is fully continuous, and a mesh is fully discrete (made up of separate facets), while this strip model will be smooth in one direction and faceted in the other.
Go to part 2 for the next step of the process
…
ooking for an efficient way to perform glazing of complex shapes.
I've only followed the Energy modelling workshops so far so i may have missed some essential components or workflows to achieve my needs. But i've made an attached definition with all my current attempts to get a proper HBzone with the numerous windows faces i will always have to deal with in this project.
I first thought that i was not using the HBObjWGZ correctly, then after some readings it was maybe an upgrading issue, then effectively i had my Therm 7.5 that needed to be reinstaled, but then ... I must be missing an essential HB tricks or workflow i guess ...
So I divided my attempt in two series :
- The Serie 1 : is a simplier version of the project step i'm working on but i'd be glad to achieve it first !
- The Serie 2 : is the real final direction of the project, which consist in sorting/dispatch faces to windowon one side and to an other material on the other, according to the winter sun and a pourcentage param.
Despite it is more complicated than the Serie one, it seems seems to create the same diversity of issues.
Until now, with the 5 different combinations of Serie 1, and the 3 of Serie 2, with and without using the different Glazing/window components, here are the logs i got from both HBZone component or OpenStudio component:
From OpenStudio - "1. The simulation has not run correctly because of this severe error: ** Severe ** BuildingSurface:Detailed="00073E23257843B6A948", invalid Construction Name="ETFE" - has Window materials.">> Has to deal with the way i'm trying to assign too early a customized EPConstruction material ? Done it wrong ? I tried to reload it in the library but doesn't change anything...
From OpenStudio - "1. The simulation has not run correctly because of this severe error: ** Severe ** BuildingSurface:Detailed="000579CD749E46DFA5EA", invalid Construction Name="EXTERIOR WINDOW" - has Window materials.">> Is it an issue in the way i define my surfs both as "WINDOW" (5) for srfType and Outdoors on the same component ?
From Create HBZone -"1. Solution exception:'EPZone' object has no attribute 'shdCntrlZoneInstructs'"
>> Happens when i try to introduce my ETFE EpMaterial after creating my first HBZone, with a Set EP Zone Construction, so this material seems to be not working either before and after trying to create an HB Zone
From Create HBZone- "1. Solution exception: 73df51a3b2144b1e858b has been moved, scaled or rotated."If you need to move or rotate a Honeybee object you should use Honeybee move, rotate or mirror components. You can find them under 12|WIP tab.
>> >> wich seems to exist in some on other thread Here and was a coding bug supposed to be fixed.
And last but not least ...
From OpenStudio - "1. The simulation has not run correctly because of this severe error: ** Severe ** checkSubSurfAzTiltNorm: Outward facing angle of subsurface differs more than 90.0 degrees from base surface.2. The simulation has failed because of this fatal error: ** Fatal ** GetSurfaceData: Errors discovered, program terminates" .
I'm attaching the file with each attempt in this post. The definitions are disabled and the log already copied separatly so there is no need to compute each of them to see what's wrong.
If someone from the beginner to one of the Kings of HoneyBee has any relevant answer/solution to this attempt with complex geometry Issue it will be really nice for me so i could to move forward !!
Thanks in advance guys and have a great day !
…
y from the Rhino model and having the absorption coefficients of the materials that are entered into Pachyderm, why is it not possible to generate a reverberation time diagram, without the need to start any analysis?
MAPPING METHOD: When for example the mapping of the Strenght Index (G) is generated through the "create map" option, succesively I can´t generate any other energy criterion map, but I have to redo the simulation.
Is it a limitation of the software or am I wrong something?
MAPPING METHOD: I kindly wanted to ask what is the difference between minimum and detailed convergence and why the number of reflections order it takes into account for the simulation is not specified. The mapping method take care only of the Raytracing Method or the Image Source too?
MAPPING METHOD: Why is the mapping value that can be exported to Rhino not generated for all the calculation raster points, but maximal only for 100 values?
MAPPING METHOD: This method hasn't been implemented in Grasshopper yet, has it?
RAYTRACING METHOD (Pach:RT): I did a raytracing through the components of GH, using only the Pach_RT, and I had these curious results in terms of time:
RaysCount: 15.000, IS_Order:1 = 5min
RaysCount: 15.000, IS_Order:2 = 12min
RaysCount: 15.000, IS_Order:3 = 3min
RaysCount: 15.000, IS_Order:4 = 8min
RaysCount: 15.000, IS_Order:5 = 3min
Why a raytracing with only 2 order, is more and more extensive than the 3/4 and 5 order?
ANALYSIS RESULT: Would there be a way to export all the results of a simulation, as is done via Odeon, to a .txt list?
I apologize in advance for asking so many questions, I hope you can find the time to answer,
Yours sincerely from Müller-BBM…
RESENTERS PETER ARBOUR seele KEITH BOSWELL Skidmore Owings & Merrill MARK E. DANNETTEL Thornton Thomasetti LISA IWAMOTO IwamotoScott JASON KELLY JOHNSONFuture Cities Lab/California College of the Arts HAO KO Gensler BILL KREYSLER Kreysler & Associates ANDREW KUDLESS Matsys/California College of the Arts CHRIS LASCH Aranda\Lasch ARNOLD LEE HOK MIC PATTERSON Enclos, Corp. M. MIN RA Front GEOFF ROSSI Element DENNIS SHELDEN Gehry Technologies ANN SMITH Cambridge Architectural MARCELLO SPINAP-A-T-T-E-R-N-S SANJEEV TANKHA Buro Happold BEN TRANEL Gensler PHIL WILLIAMS Webcor Builders & Consulting Group
DIGITAL FABRICATION WORKSHOPS
8 LU/HSW or 8 LU credits (depending upon workshop choice)
Friday, July 27th 2012 9:00 AM – 6:00 PMCalifornia College of the Arts San Francisco, California
PARAMETRIC ENVELOPES WITH GRASSHOPPERANDREW KUDLESS Matsys Design/California College of the Arts
COMPOSITE FACADES IN ARCHITECTUREBILL KREYSLER & JOSHUA ZABEL Kreysler & Associates
RESPONSIVE BUILDING FACADESJASON KELLY JOHNSON Future Cities Lab/California College of the Arts
SCRIPTED FACADESCHRIS LASCH Aranda/Lasch
PARAMETRIC FACADE TECTONICSKEVIN MCCLELLAN & ANDREW VRANA Digital Fabrication Alliance
BIM MODELING WITH REVIT/INTRO TO VASARIGERMAN APARICIO California College of the Arts & Autodesk Fellow
Facade technologies are developing at a more dynamic rate than almost any other issue related to construction today with an impact on performance, sustainability, materials, fabrication, design, delivery and much more. What was once thought impossible is now an everyday reality, and the future promises accelerating change.
Presented by Enclos and The Architect’s Newspaper, COLLABORATION will bring together in a two-day event, the industry, the profession, and the academy to explore the evolution and the issues surrounding today’s high tech building envelope through case studies and lectures presented by foremost
practitioners, as well as panel discussions, and workshops conducted by leaders in the AEC profession.
Aimed at architects, building owners and developers, general contractors, engineers, fabricators, material suppliers, educators, and students, the event’s panels and sessions address the transformative opportunities created by new technologies and resources. From using BIM for communicating effectively with fabricators, to energy modeling, to retrofitting practices and the latest design tools, the COLLABORATION conference offers an unprecedented opportunity to survey the possibilities of designing in the digital age.
Who Should Attend
Architects, designers, engineers, building owners, developers, and facade consultants interested in gaining increased understanding of cutting-edge building envelope technologies.…
_b2 texfunc WoodGrain_tex
6 xgrain_dx ygrain_dx zgrain_dx woodtex.cal -s 0.01
0
1 0.075
WoodGrain_tex plastic WoodGrain_NonColor2
0
0
5 0.364 0.187 0.072 0.006 0.0
This creates the texture (on the table) below:
Is it possible for me to use a multi-modifier material like this in Honeybee ?
Thanks,
Sarith
(Update: I figured out a hack to do this in MSH2RAD but I still don't know if it is possible to add this to the Honeybee Library).…
a machine that is light and very sturdy. I have taken my Macbook Pro all around the world, carry it with me every day, even dropped it a few times and its still totally fine. Its thin and light.
2) You get some actual support for your hardware even a few years down the line. My Macbook Pro is from 2012 and I can still walk in to any Apple Store and get help with it, which I have done many, many times in different places around the world - I never had to show a receipt or was charged any money for help. There is no PC/Laptop manufacturer in the world with anything close to that, because companies like Asus, Dell, etc. bring out dozens of new versions of laptops every year, so its much harder to service them after a few years.
3) This is the most important one, which usually people forget when they say that Macbooks are overpriced: Resale Value. If you have ever tried to sell an old PC/Laptop (I have a few times), you will know how little value they have even after just 2-3 years. Macbooks retain their value very well and even after 4 years you can still get 50% of your original price.
4) Of course you can install Windows on it and it runs perfectly. I have MacOS and Windows on it and both run absolutely fine. On the Windows side I have Rhino+GH, Maya and a few others. Having Windows is good, because some software still only runs on Windows (looking at you, 3DSMax!). Most other software also runs on MacOS. In the interest of sanity it is great to have an alternative to Windows for all the day to day stuff, like Mail, Calender, Photos, Presentations, etc. that just always works.
5) As for performance: Yes, Macbook Pros dont necessarily have the latest and greatest in graphics cards (the rest is on par with PC laptops), but unless you want to play games you will not need it. VRay RT can do GPU rendering, but you wont get great performance from a Notebook GPU anyways and it doesnt make sense to do rendering on a laptop (especially since you have a workstation). You could get one of the older Macbook Pro Retina Late 2013 or Mid 2014 models with the GTX750M by Nvidia, which will be usable to render using VRay RT, but of course not huge performance. Better to invest in a good used graphics card for your workstation like an Nvdia GTX980ti, which is the best value for money for GPU rendering right now (lots of used ones available).
So at least consider also getting a Macbook Pro. You can buy refurbished models (depending where you are) and they are like new, but a lot cheaper or even get an older one thats used. It will be a worthwile investment.
Take it from someone who has used dozens of PCs and Macs in my lifetime and have to do the IT support here at work (where we also use both).
I still have my Macbook Pro Retina from 2012 and its still running perfectly, super fast, and I can use Rhino and GH for huge files, do GPU Rendering with Octane Render and all sorts of other heavy computing stuff.
Hope that helps.…
Added by Armin Seltz at 11:12am on September 19, 2016
he Cordyceps. Maybe some of you find this helpful/useful.
So basically, the Cordyceps is a physical module with 4 knobs and 1 slider. The knobs give an output between 1 and 1000, while the physical slider outputs 0-359. And of course, for this physical module I wrote a plugin to communicate with it. The knobs are intended to be the variables that modifies the design, while the physical slider is intended to be connected to the camera component.
Here I will put up "the recipe" for all to make their own module. You will be able to download the plugin as well.
Please send me a message if you want the 3D-files for the knobs, the box and slider knob. They've been made to directly 3D-print.
Plugin:
https://github.com/zakadjeb/Cordyceps/blob/master/Cordyceps/Cordyce...
Code for Arduino IDE:
https://github.com/zakadjeb/Cordyceps/blob/master/Arduino/_Arduino_...
What you need:
1x - Arduino (Leonardo, UNO or whatever)
4x - Potentiometers
1x - Sliding potentiometer
1x - Breadboard
Bundle of jump wires.
1. So, a potentiometer is a variable resistor, which is basically a component that changes the resistance between the voltage and the ground.
If A is supplied with 5V then B must be connected to Ground. The W will give "read" the resistance, and thus should be placed in Analog input (A0-A5) on the Arduino. The slider potentiometer works the same way.
2. Now connect the 4 pots to each their Analog input. The slider is supposed to be in A4. So to make sure:
A0: Knob1
A1: Knob2
A2: Knob3
A3: Knob4
A4: Slider
3. Now it's time to connect the voltage! Using the breadboard, the voltage can be sent through 1 line, the Ground as well. It should be quite easy to connect them.
4. Now, download the Arduino IDE and copy-paste the code I supplied above. In the IDE, you need to let it know which Arduino you're working with, and which port is should send the script.
5. Almost there. Download the plugin. Open the port you're using through the plugin. Set Start to True and the Cordyceps should be within you.
This recipe will be updated!
Let me know if there are any issues.
// Zakaria Djebbara…
he Cordyceps. Maybe some of you find this helpful/useful.
So basically, the Cordyceps is a physical module with 4 knobs and 1 slider. The knobs give an output between 1 and 1000, while the physical slider outputs 0-359. And of course, for this physical module I wrote a plugin to communicate with it. The knobs are intended to be the variables that modifies the design, while the physical slider is intended to be connected to the camera component.
Here I will put up "the recipe" for all to make their own module. You will be able to download the plugin as well.
Please send me a message if you want the 3D-files for the knobs, the box and slider knob. They've been made to directly 3D-print.
Plugin:
https://github.com/zakadjeb/Cordyceps/blob/master/Cordyceps/Cordyce...
Code for Arduino IDE:
https://github.com/zakadjeb/Cordyceps/blob/master/Arduino/_Arduino_...
What you need:
1x - Arduino (Leonardo, UNO or whatever)
4x - Potentiometers
1x - Sliding potentiometer
1x - Breadboard
Bundle of jump wires.
1. So, a potentiometer is a variable resistor, which is basically a component that changes the resistance between the voltage and the ground.
If A is supplied with 5V then B must be connected to Ground. The W will give "read" the resistance, and thus should be placed in Analog input (A0-A5) on the Arduino. The slider potentiometer works the same way.
2. Now connect the 4 pots to each their Analog input. The slider is supposed to be in A4. So to make sure:
A0: Knob1
A1: Knob2
A2: Knob3
A3: Knob4
A4: Slider
3. Now it's time to connect the voltage! Using the breadboard, the voltage can be sent through 1 line, the Ground as well. It should be quite easy to connect them.
4. Now, download the Arduino IDE and copy-paste the code I supplied above. In the IDE, you need to let it know which Arduino you're working with, and which port is should send the script.
5. Almost there. Download the plugin. Open the port you're using through the plugin. Set Start to True and the Cordyceps should be within you.
This recipe will be updated!
Let me know if there are any issues.
// Zakaria Djebbara…
r." I'm sorry to hear that, I take the interface and ease-of-use rather seriously so this sounds like a fundamental failure on my part. On the other hand, Grasshopper isn't supposed to be on a par with most other 3D programs. It is emphatically not meant for manual/direct modelling. If you would normally tackle a problem by drawing geometry by hand, Grasshopper is not (and should never be advertised as) a good alternative."What in other programs is a dialog box, is 8 or 10 components strung together in grasshopper. The wisdom for this I often hear among the grasshopper community is that this allows for parametric design."Grasshopper ships with about 1000 components (rounded to the nearest power of ten). I'm adding more all the time, either because new functionality has been exposed in the Rhino SDK or because a certain component makes a lot of sense to a lot of people. Adding pre-canned components that do the same as '8 or 10 components strung together' for the heck of it will balloon the total number of components everyone has to deal with. If you find yourself using the same 8 to 10 components together all the time, then please mention it on this forum. A lot of the currently existing components have been added because someone asked for it."[...] has a far cleaner and more intuitive interface. So does SolidWorks, Inventor, CATIA, NX, and a bunch of others."Again, GH was not designed to be an alternative to these sort of modellers. I don't like referring to GH as 'parameteric' as that term has been co-opted by relational modellers. I prefer to use 'algorithmic' instead. The idea behind parameteric seems to be that one models by hand, but every click exists within a context, and when the context changes the software figures out where to move the click to. The idea behind algorithmic is that you don't model by hand.This is not to say there is no value in the parametric approach. Obviously it is a winning strategy and many people love to use it. We have considered adding some features to GH that would make manual modelling less of a chore and we would still very much like to do so. However this is such a large chunk of work that we have to be very careful about investing the time. Before I start down this road I want to make sure that the choice I'm making is not 'lame-ass algorithmic modeller with some lame-ass parametrics tacked on' vs. 'kick-ass algorithmic modeller with no parametrics tacked on'.
Visual Programming.I'm not exactly sure I understand your grievance here, but I suspect I agree. The visual part is front and centre at the moment and it should remain there. However we need to improve upon it and at the same time give programmers more tools to achieve what they want.
Context sensitivity."There is no reason a program in 2014 should allow me to make decisions that will not work. For example, if a component input is in all cases incompatible with another component's output, I shouldn't be able to connect them."Unfortunately it's not as simple as that. Whether or not a conversion between two data types makes sense is often dependent on the actual values. If you plug a list of curves into a Line component, none of them may be convertible. Should I therefore not allow this connection to be made? What if there is a single curve that could be converted to a line? What if you want to make the connection now, but only later plan to add some convertible curves to the data? What you made the connection back when it was valid, but now it's no longer valid, wouldn't it be weird if there was a connection you couldn't make again?I've started work on GH2 and one of the first things I'm writing now is the new data-conversion logic. The goal this time around is to not just try and convert type A into type B, but include information about what sort of conversion was needed (straightforward, exotic, far-fetched. etc.) and information regarding why that type was assigned.You are right that under some conditions, we can be sure that a conversion will always fail. For example connecting a Boolean output with a Curve input. But even there my preferred solution is to tell people why that doesn't make sense rather than not allowing it in the first place.
Sliders."I think they should be optional."They are optional."The “N” should turn into the number if set."What if you assign more than one integer? I think I'd rather see a component with inputs 'N', 'P' and 'X' rather than '5', '8' and '35.7', but I concede that is a personal preference."But if I plug it into something that'll only accept a 1, a 2, or a 3, that slider should self set accordingly."Agreed.
Components."Give components a little “+” or a drawer on the bottom or something that by clicking, opens the component into something akin to a dialog box. This should give access to all of the variables in the component. I shouldn't have to r-click on each thing on a component to do all of the settings."I was thinking of just zooming in on a component would eventually provide easier ways to access settings and data."Could some of these items disappear if they are contextually inappropriate or gray out if they're unlikely?"It's almost impossible for me to know whether these things are 'unlikely' in any given situation. There are probably some cases where a suggestion along the lines of "Hey, this component is about to run 40,524 times. It seems like it would make sense to Graft the 'P' input." would be useful.
Integration."Why isn't it just live geometry?"This is an unfortunate side-effect of the way the Rhino SDK was designed. Pumping all my geometry through the Rhino document would severely impact performance and memory usage. It also complicates the matter to an almost impossible degree as any command and plugin running in Rhino now has access to 'my' geometry."Maybe add more Rhino functionality to GH. GH has no 3D offset."That's the plan moving forward. A lot of algorithms in Rhino (Make2D, FilletEdge, Shelling, BlendSrf, the list goes on) are not available as part of the public SDK. The Rhino development team is going to try and rectify this for Rhino6 and beyond. As soon as these functions become available I'll start adding them to GH (provided they make sense of course).On the whole I agree that integration needs a lot of work, and it's work that has to happen on both sides of the isle.
Documentation.Absolutely. Development for GH1 has slowed because I'm now working on GH2. We decided that GH1 is 'feature complete', basically to avoid feature creep. GH2 is a ground-up rewrite so it will take a long time until something is ready for testing. During this time, minor additions and of course bug fixes will be available for GH1, but on a much lower frequency.Documentation is woefully inadequate at present. The primer is being updated (and the new version looks great), but for GH2 we're planning a completely new help system. People have been hired to provide the content. With a bit of luck and a lot of work this will be one of the main selling points of GH2.
2D-ness."I know you'll disagree completely, but I'm sticking to this. How else could an omission like offsetsurf happen?"I don't fully disagree. A lot of geometry is either flat or happens inside surfaces. The reason there's no shelling (I'm assuming that's what you meant, there are two Offset Surface components in GH) is because (a) it's a very new feature in Rhino and doesn't work too well yet and (b) as a result of that isn't available to plugins.
Organisation.Agreed. We need to come up with better ways to organise, document, version, share and simplify GH files. GH1 UI is ok for small projects (<100 components) but can't handle more complexity.
Don't get me wrong, I appreciate the feedback, I really do, but I want to be honest and open about my own plans and where they might conflict with your wishes. Grasshopper is being used far beyond the boundaries of what we expected and it's clear that there are major shortcomings that must be addressed before too long. We didn't get it right with the first version, I don't expect we'll get it completely right with the second version but if we can improve upon the -say- five biggest drawbacks (performance, documentation, organisation, plugin management and no mac version) I'll be a happy puppy.
--
David Rutten
david@mcneel.com…
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.
…