rameters, which forces the user to connect all three curve input parameters (even if only 2 are required) to avoid the message 'Input parameter ... failed to collect data'. How can I set up the curve inputs so that null values are valid? I'm currently registering these as curve parameters as below, and suspect the answer lies in using a different method for parameter registration.
protected override void RegisterInputParams(GH_Component.GH_InputParamManagerpManager)
{
pManager.Register_SurfaceParam(
"Reference Surface", "S", "Surface on which laths are to be generated", GH_ParamAccess.item);
pManager.Register_CurveParam(
"Surface curves 1", "Curves 1", "Set of curves across surface in first direction", GH_ParamAccess.list);
pManager.Register_CurveParam(
"Surface curves 2", "Curves 2", "Set of curves across surface in second direction", GH_ParamAccess.list);
pManager.Register_CurveParam(
"Surface Curves 3", "Curves 3", "Set of curves across surface in third direction", GH_ParamAccess.list);
pManager.Register_DoubleParam(
"Lath Offsets 1", "LO1", "Offset from surface to centreline of first layer", 0.0, GH_ParamAccess.item);
pManager.Register_DoubleParam(
"Lath Offsets 2", "LO2", "Offset from surface to centreline of second layer", 0.0, GH_ParamAccess.item);
pManager.Register_DoubleParam(
"Lath Offsets 3", "LO3", "Offset from surface to centreline of third layer", 0.0, GH_ParamAccess.item);
pManager.Register_IntegerParam(
"Seed Value (0, 1, 2)", "Seed", "Seed value for weave offsets (0 for no weave, 1 or 2 for weave)",0, GH_ParamAccess.item);
}
Thanks!
Alex
…
Added by Alex Baalham at 9:48am on October 1, 2012
rk and I will just clarify some of the details. I will also note that I do not know what the shadings output of the decomposeByType component is supposed to do as Mostapha put it there a long time ago and I was not sure what his intentions were. Going down a list of clarification points:
1) You are right that you should either connect up the shade breps to the EPContext component or just plug the HBObjwShades into the RunSimulation component (never do both). However, connecting the breps to the EPContext component is greatly undesirable for two reasons: It will make the simulation run much longer and the energyPlus calculation will not account for the surface temperatures of the blinds (it will assume they are the same temperature as the outdoor air, which is very wrong in a lot of cases). When you connect up the HBObjwShades to run the simulation, EnergyPlus will understand the blinds as abstract objects defined only by a numeric parameterization and not as actual geometry. This enables the calculation to run fast and is also enough of a description that E+ can calculate the temperature of the blinds, thereby accounting for the heat that can be re-radiated from the blinds to the indoors when they get hot in the sun. This more desirable way of running the blinds was how I imagined the component being run most of the time and I mostly included the shadeBreps so that you have a visual of what you are simulating.
2) When you use the more desirable HBObjWShades to approximate your blinds, you should use the blindsSchedule input in order to tell E+ when the shades are pulled (this is instead of the transShcedule on the EPContext component).
3) The zoneData inputs on the EPWindowShade component are meant to help in an entirely different workflow, which evaluates shade benefit based on energy simulation results. I apologize if it seems confusing to have two major uses of the component in one but we have so many Honeybee components right now and I did not want to make 2 separate ones when they seemed so similar. See this example file to see how to do energy shade benefit (https://app.box.com/s/oi64zoj5u1slz494grzhgmdkx7yie9jo).
Ok. I think that clears up everything that I know. Now to the part that I do not. As I said, Mostapha put in the shadings input there a long time ago and I do not know what his intentions were. Abraham, as you know, I am about to do a major revision of the EPWindowShade component to make it compatible with OpenStudio, include drapes/generic shades in addition to blinds, and I also should figure out how to do electrochromic glazing. I can easily include all of the visualized shades as output from the decomposeByType component when I do this. However, I do not want to interfere with other intentions Mostapha had when he put the input in. If he could confirm that this was in-line with his vision for the shadings output, I will implement it soon.
-Chris
…
n due at the end of march. i am hoping to see if i can do this as a sort of "HIVE MIND" experiment with one or two or more posters to the forum. i have uploaded two files to http://www.formpig.com/nine_bar-FAR and I have the following goals:
1. To "kinematically iterate" various formal building envelopes based upon a 50' x 100' lot that "conform" to the nine bar linkage geometry.
2. This lot would have "setbacks" consisting of two 5' side setbacks, a 10' rear yard setback and a 25' front yard setback. max height on the structure is 32' and the allowable overhangs into the setbacks are 2'. I would like to find a way to use the "nine bar geometry" to construct a series of iterations for "floors", "walls" and "ceilings", which would then be tied to a volumetric (cubic volume), or a total square footage (perhaps based upon two horizontal section cuts) which was based upon a given number that I will provide per local building code.
3. Laid on top of this we would also have "mcmansion ordinance" requirements based upon the pdf enclosed. i expect to have this "tent restriction" data in digital form to upload to ftp shortly.
It would be up to you individually or collectively to determine how best to position this "in the real world" based upon the lot, setbacks, zoning requirements etc. For instance, perhaps the nine bar configuration has its vertices coplanar with the 50' x 100' x 32' envelope restrictions and then the chosen volume is "trimmed' by the setback requirements. Or perhaps the nine-bar configuration is generated completely within the setbacks, or perhaps it is generated 2' outside of the setbacks so as to take advantage of the 2' overhang allowance on the setbacks, etc.
*
Given an opportunity to develop the work in a second phase we would have an opportunity to tie this into various efficiencies such as Bill of Materials (wall floor and ceiling square foot calculations), envelope to volume calculations, solar panel efficiencies (solar orientation and envelope geometry) etc, etc (love to get suggestions for this).
*
I've become /really/ convinced that this would be a /really/ interesting entry based upon my just finishing up Kas Oosterhuis' Towards a New Kind of Building: A Designer's Guide for Non-Standard Architecture". In an ideal world I was hoping that it would be possible to hash this out discussion-wise and then literally passing it around on the list after someone eventually made the first move by tossing out a rough ghx script. My expectation would be to finalize it rapidly in the next two weeks. Something of a contemporary version of a design charette.
However, I realize this may not be workable so if you have experience in this arena and particularly if you think this is a brief that is straighforward enough to be almost literally implemented in Grasshopper, please contact me for any wage and/or contract fee requirements.
I'm getting a bit of a late jump on this but my hope is that with the right participant(s) that I can thrash it together quick enough for the first round.
info@formpig.com…
case for sure (started by Giorgio a couple of days before). Ive got involved because I exploit ways to "relax" shapes on nurbs (say patterns created by Lunchbox or "manually) without using any kind of mesh (more explanations soon).
Here's 5 test cases (SDK appears that doesn't have some "thicken surface" thing ... thus the algo that finds the "whole" shapes is rather naive) VS 2 Kangaroo "methods" and the why bother (he he) option as well.
If the goal is to "fit" these shapes within the nurbs ... does it work so far? No I'm afraid (appears that "springs" used are not the proper ones - or [Kangaroo1 option] the lines that pull should been originated from valance 2 points only)
Tricky points:
1. Internalize appears having a variety of serious issues (see Input inside definition) - Load Rhino file first (but even so ...).
2. Pull to surface is deactivated - this is not the issue here (and it's very slow).
3. Since Starling/WB alter the "curves - points" related order
the issue here (Pull points to curves) is to correspond apples to apples:
and that's what Anemone does:
From chaos :
to order:
this means that prior activating Kangaroo you should double click to the Anemone start component in order to "sort" properly the curves.
But .. fact is that results are pathetic:
more soon
best, Peter…
bsp;
-Vehicle elements (3D objects and a component for custom vehicles; models from Google Warehouse)
-Traffic Velocity Graphs, drawn on every trajectory curve (allow custom graphs drawn)
-Traffic regulation elements (such as Traffic Lights and Stop Signals) and traffic density
-Particle Systems on trajectory curves, just to manage the traffic regulations and avoid collisions based on security distances
-Traffic Vehicle Animation Modes (Dots, Bounding Boxes or complex Meshes with attributes for final rendering (Giulio Piacentino´s Render Animation)
-Vehicle Lights and Vehicle Sights, to make visual studies
Team:
-Sergio del Castillo Tello (Doctor No, lead programmer)
-Everyone that wants to be involved, support.. these tools
The development of Roadrunner is planned to take part within a Research Group Program at ETSAM (University of Architecture in Madrid); This forum group is created just to test the interest of the community, while we keep on developing (it is still being tested), probably we will share the whole thing in the future. Cheers!
Traffic Cluster Scheme
Traffic Elements
Traffic Urban Systems
Vehicle Elements
Roadrunner - overview
Roadrunner 0 Basics
Roadrunner 1 Modes
Roadrunner 2 Elements
Roadrunner 3 Urban Systems…
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.
…
tal fabrication tools. DLAB will investigate natural growth processes in relation to innovative concepts of architectural tectonics and fabrication. We will carefully interweave these concepts with interaction and participatory design to create full-scale working prototypes. The programme will be formulated as a two-phase process. During the initial phase participants will benefit from the unique atmosphere and facilities of AA’s London home. The second phase will shift to AA Hooke Park campus and revolve around the fabrication and assembly of a full-scale architectural intervention.
Some of the most prominent features which the participants will be exposed to during DLAB include:
Teaching team: Participants engage in an active learning environment where the large tutor to student ratio (5:1) allows for personalized tutorials and debates.
Facilities: The Digital Prototyping Lab (DPL) in AA London houses cutting-edge facilities for the fabrication of physical outputs through digital fabrication techniques. The facilities at AA Hooke Park allow for the fabrication of one-to-one scale prototypes with a 3-axis CNC router.
Computational skills: The toolset of DLAB includes but is not limited to Rhinoceros, Processing, Arduino, and Grasshopper.
Theoretical understanding: The dissemination of fundamental design techniques and relevant critical thinking methodologies to the participants through theoretical sessions and seminars forms one of the major goals of DLAB.
Professional awareness: Participants ranging from 2nd year students to PhD candidates and full-time professionals experience a highly-focused collaborative educational model which promotes research-based design and making.
Fabrication: According to the specific agenda of each year, a one-to-one scale prototype is fabricated and assembled by design teams.
Lecture series: Taking advantage of its unique location, London, DLAB creates a vibrant atmosphere with its intense lecture programme conveying the diverse expertise of professionals in the areas of digital design and fabrication techniques.
Applications
The deadline for applications is 8 July 2013.
An application can be made by completing the online application form or completing the PDF application form and emailing it to visitingschool@aaschool.ac.uk.
Fees
The AA Visiting School requires a total fee of £1,660 per participant, which includes a £700 deposit and a £60 Visiting Membership.
Fees are non-refundable. Fees do not include flights. Train tickets between London-Hooke Park, accommodation, food in Hooke Park, and materials are included in the fees.
Students need to bring their own laptops, digital equipment and model making tools.…
re
Minimum principal curvature
by the way, look at this picture.... if I only use surface curvature the result doesn't seems right as well. Maybe I did some mistakes? thanks :)
Gene
import rhinoscriptsyntax as rs
import Rhino as rc
a = []
b = []
if ((u or v) is None):
u = 0.5
v = 0.5
c_u = Srf.IsoCurve(0,u)
c_v = Srf.IsoCurve(1,v)
if (Density < 2 or Density is None):
Density = 2
if Scale is None:
Scale = 6
ScaleFactor = -Scale
for i in range(0, Density+1):
Normal_u = Srf.NormalAt(i/Density, u)
su = Srf.CurvatureAt(i/Density, u)
#s = Srf.CurvatureAt(0.5, 0.5)
#print(s.Kappa(0.5))
Normal_u_length = rs.VectorLength(c_u.CurvatureAt(i/Density))
#Normal_u_length = Normal_u_length*rs.VectorLength(s.Direction(0))
Normal_u_length = Normal_u_length * su.Kappa(0.5)
Normal_u= Normal_u*Normal_u_length
#print(type(Normal_u))
Point_u = c_u.PointAt(i/Density)
a.append(Point_u)
b.append(Point_u + Normal_u*ScaleFactor)
for i in range(Density+1):
Normal_v = Srf.NormalAt(v, i/Density)
sv = Srf.CurvatureAt(v, i/Density)
Normal_v_length = rs.VectorLength(c_v.CurvatureAt(i/Density))
Normal_v_lengthTuple = rs.SurfaceCurvature(Srf, [v,i/Density])
Normal_v_length = Normal_v_length * Normal_v_lengthTuple[7]
Normal_v = Normal_v*Normal_v_length
Point_v = c_v.PointAt((i)/Density)
a.append(Point_v)
b.append(Point_v + Normal_v*ScaleFactor)
mid = int(len(b)/2)
bu = b[:mid]
bv = b[mid:]…