Building Design Programming with a Functional Language  A. Paoluzzi Dip. di Disc. Scienti che: Sez. Informatica, Terza Universita,Via Segre 3, 00146 Roma,, Italy V. Pascucci Dip. di Informatica e Sistemistica, Universita \La Sapienza",Via Buonarroti 12, 00185 Roma,Italy ABSTRACT: A quite complex example of building design programming is discussed in this paper. In particular we introduce some operators which allow to easily de ne parametric layout plans, where both single and grouped rooms are constrained both on their linear dimensions and on the relative positioning. Such operators are then used to generate constraint-based models of the hierarchical set of spaces which de ne a terraced building. The given plasm description is completely coordinate free, i.e. all design parts are intrinsically de ned. The relative positioning and dimensioning of parts is obtained using constraints. The whole set of design choices, i.e. the design knowledge, is compactly codi ed within the easily readable plasm description of each plan and section of the building. The 3D model of the building is then automatically generated from plans and sections. The authors believe that such a natural and semantically rich description may be very useful in the design process, mainly if coupled with a very high level (intelligent) graphical interface (to be developed). 1 Introduction The term \Geometric Programming" was introduced to denote the functional approach to geometric design programming with the language plasm developed by the CAD Group at the University of Rome [7, 5]. This language was originally developed as a language for building design, but is being currently experimented also as a general purpose language for modeling highly complex geometric shapes. It can be roughly considered as a geometry-oriented extension of a subset of the functional language FL, developed by Backus, Williams and their group at IBM Almaden [2, 1]. In this paper we discuss the modeling of a building design as a plasm script. This modeling was done starting from the original set of plans, sections and orthographic views. The modeled project (see Fig. 6) is a terraced housing realized in Bologna (Italy) by the Prof. Arch. E. Zambelli at the end of seventies. The terraced housing is composed by the aggregation of a certain number of two- oor houses with basement. The main steps of our design modeling can be summarized as follows:  plan analysis and de nition (in 2D) for the single housing unit;  section analysis and de nition (in 2D) for the single housing unit;  combination of plans and sections, by using the product operator described in [3], in order to automatically generate the volumes of the housing units;  staircase de nition (in 3D) to be matched with the stairwell of the housing units;  aggregation of a set of house pairs, in order to generate the complete model of the terraced housing. It is important to note that plasm was developed not as a graphic language for modeling and simulation but as a true \design language", with the aim of supporting all kinds of designing activities, which consist in shape analysis and synthesis, as well as of supporting the design revision steps. In order to stress this aspect, we choose to discuss the design synthesis at a very high level, as the architect could do in the initial stages of design. This results in a variational reconstruction of a schematic model of the volumes of the housing project. In particular, we will develop our schematic housing model as a set of space polygons, automatically generated starting from 2D plans and sections, but without the opening of doors and windows (at least currently). Some other simpli cations will be indicated at their place in the paper. A more detailed model could be generated at the price of writing much more code, with a quantity of details which cannot be discussed in the present paper. Our aim in developing the plasm language was also to allow as much as possible for automatic translation  This work was partially supported from Italian Research Council, with contract n. 91.03226.64, within the \PF Edilizia" Project. 1 between schematic and detailed layouts and models. This needs some more research and development e ort of the plasm environment. In our current plans we suppose to reach this major goal in two or three years. Notice also that we developed the plasm model without any interaction with the designer, but only starting from the detailed plans and sections of the building. So, the plasm code will re ect our reading of the design, which do not necessarily coincide with the designer view. In other terms, the design decomposition we give in the paper only re ects our reading of the design, and corresponds to only one of the several ways to build the geometric model of the schematic building. Anyway, a closer interaction with the designer would allow for programming his true view of design development process, starting from the initial ideas and \feeding back" everywhere this should be necessary in order to satisfy some design constraint. As the following discussion should make clear, the language seems to have an amazing descriptive power, and should allow the designer to implement in few lines of (generative and variational) plasm code both the structure of the design and the internal and external constraints acting on the geometric shape. Actually, the designer should not be required to be also a computer specialist, but the language should be embedded into a modern interactive user interface, where all the design intentions could be graphically captured and automatically coded as a plasm script. 1.1 Preliminary de nitions Every housing unit in the project contains a basement, a rst oor and a second oor. It is possible to see that the building is made by the aggregation of a fundamental housing unit (see Fig. 1), which is repeated in groups of two or four units at a time. Each group of two or four units is obtained by one or two specular re ection of the same basic unit. Actually, as we show in the following, two minor variations are given of the basic housing unit. After a rst analysis of the design layout we decided to write a few general plasm operators to be extensively used to model the plans. Such functions of general utility must not be written at any new project, but can be stored into persistent les called plasm packages (as they constitute a sort of general design knowledge) which are included and used in several different design projects. Such operators are here given for sake of completeness. The space element which is more frequently instanced in the design is a rectangular space, which will be denoted as O_space and will be de ned as an alias for the primitive plasm function CUBOID: DEF O_space = CUBOID In order to de ne space units which have a more complex hierarchical shape, it is useful to have a function which can be used to specify the relative positioning of (hierarchical) aggregates of spaces. In particular a binary function \^" is given which allow to match two shapes on a speci ed point (see Fig. 2). Often, but not necessarily, these points will coincide with one of a b a(nw^ ne)b d a(nw^ sw)b(se^ sw)d glue:(a(nw^ sw)b(se^ sw)d) Figure 2: Matching and glue of rectangles. the extreme \geographic" points of the containment boxes of the two shapes to be matched. E.g., let sw, se, nw, ne be four \geographic" functions which compute the lowest left, the lowest right, the highest left and the highest right point of a 2D shape (\polyhedral complex" | see [6]), respectively: DEF DEF DEF DEF sw se ne nw = = = = [MIN:1, [MAX:1, [MAX:1, [MIN:1, MIN:2]; MIN:2]; MAX:2]; MAX:2] % % % % south-west south-east north-east north-west % % % % The de nition of the \^" operator will be given as follows, where an ane transformation matrix will be automatically included in a sequence containing the two shapes to be matched, according to the semantics of the ISO standard graphic system PHIGS [4]: DEF ^ (geo1,geo2::IsFun) = STRUCT ~ [S1, (T:<1,2>) ~ parameters,S2] WHERE parameters = (AA:-)~TRANS~[geo1~S1,geo2~S2] END where the formal parameters geo1 and geo2 are usually geographic functions which compute the two points on the argument shapes which have to coincide in the resulting structure. The plasm script which codi es the matching operation described in Figure 2 will be written as follows: DEF a = O_space:<10,20>; DEF b = O_space:<10,15>; a (nw ^ ne) b In order to group three spaces a, b and d in such a way that b is put over a and d to the bottom of a, the following plasm script (see Fig. 2) is de ned. DEF d = O_space:<15,20>; a (nw ^ sw) b (se ^ sw) d To understand this example it is necessary to say that the standard order of execution of the operations within an expression (without parenthesis) is from left to right. Hence, the whole group of spaces is de ned in the local coordinates of the rst shape; then the second shape is placed in this system; then the third shape is matched with a geographic point computed on the y bed1 y bed3 y plan stair laundry stair bath x bath x bed3 x stairweel x terrace x balcony x ground x ground x terrace bed1 x rst bed3 stair bed2 box2 box1 (a) living kitchen terrace (b) bath terrace (c) Figure 1: The three plans of type B. Basement (a), rst oor (b) and second oor (c) and their corresponding polyhedral approximations. group of the rst two shapes, and so on. In order to glue the polyhedral cells of a polyhedral complex into a single element without internal partitions, a specialpurpose glue function is de ned: Then two global variables are de ned which state the width of passage spaces (passage) and a \small" dimension (delta) with respect to the sizes of the design spaces: This function just compute (using the primitive function UKPOL | see [6]) a symbolic description of the polyhedral complex which it is applied to, and then slightly modify it, in order to put together all the convex cells into a single polyhedral cell, and nally commits the reconstruction of the internal data structure to the prede ned function MKPOL. It is so possible to easily de ne a new parametric function L_space which compute the geometric model of a 2D L-shaped space starting from the lateral dimensions, according to the generative scheme of Figure 2, which we have just discussed. The 3D staircase of the whole housing unit will be dened later on in the paper. At this point, i.e. while de ning the plan layouts, it is sucient to leave an empty space within the 2D schematic oors. So, a geometric function floor_base is de ned which returns a 2D polyhedral complex, with an empty cell corresponding to the stairwell. This floor_base will be used to compute by intersection the true geometric shapes of the oors at the various levels in the housing unit. DEF glue = MKPOL~[S1,S2,[FROMTO~[K:1,LEN~S2]]] ~UKPOL DEF L_space (x1,x2,y1,y2::IsReal)= glue:(O_space: (se ^ sw) O_space: (nw ^ sw) O_space:) The last 2D shape of Figure 2 can be so computed by evaluating the plasm expression: L_space:<10,15,20,15> 1.2 Schematic layout plans First of all, we de ne a set of numeric parameters, to be used for common dimensioning reference of the design elements of a single housing unit (see Fig. 1): DEF DEF DEF DEF y_plan = 802.5 % lenght of plans (y axis)%; x_ground = 920 %width of ground floor (x) %; x_terrace = 260 % width of terrace %; x_balcony = 350 % distance first floor center of balcony %; DEF y_bed1 = y_plan * 2/5 % lenght of bedroom %; DEF x_bed1 = y_bed1 * 3/2 % bed aspect ratio %; DEF x_stairwell = y_plan / 3% stairwell lenght % DEF passage = 100 ; DEF delta = 1 DEF floor_base = (glue~STRUCT): * QUOTE:, QUOTE:<-:(x_balcony+delta),x_stairwell-delta>* QUOTE:> Notice that the empty space corresponding to the staircase is de ned smaller (of delta) than the actual dimensions of the staircase, in order to mark its perimeter. By using the design elements de ned at this point, it is now possible to give the layout plan of the rst oor: DEF first_floor = floor (se ^ se) (bath (ne ^ nw) bed (se ^ ne) living) (sw ^ sw) kitchen (se ^ sw) terrace WHERE floor = floor_base & T:1:x_balcony: (O_space:), bath = S:2:-1:(L_space: ), living = S:1:-1:(L_space:), kitchen = L_space:, terrace = O_space: END The plan of the rst oor is made by four spaces: bed, living, bath and kitchen. The rst only is de ned as a O_space, whereas the others are de ned as L_space. The bath is obtained by re ection of the prototype shape with respect to the rst axis (s:2:-1). Analogously, the living is obtained by re ection of the prototype shape with respect to the second axis (s:1:-1). Notice that (s:1:-1) is the scaling on the rst coordinate for the scaling parameter ?1, which results in the appropriate re ection. The geometric model corresponding to the generated shape (see Fig.1) can be obtained by evaluating the expression: first_floor At the same way can be de ned the layout plan of the basement of the housing unit (see Fig. 1). DEF basement_floor =floor(sw ^ sw)internal_spaces WHERE floor = floor_base & T:1:x_balcony:(L_space:), internal_spaces = box1 (nw ^ sw) box2 (ne ^ k:) laundry, box1 = O_space: , box2 = O_space:, laundry = O_space: END In the last de nition the dimensions of the basement have been constrained to those of the rst oor, by making use of the same variables. In particular, it has been stated that the two plans have the same length (y_plan), whereas the basement width will be obtained by adding x_terrace to that of the rst oor, i.e. it is de ned as L_space:. The two basement boxes and the stairwell have the same length, as it was stated that x_stairwell = y_plan=3. Also, another constraint states that box1 has the same width of first_floor. The whole geometric model of this layout can be obtained by evaluating the expression: basement_floor We remember that the whole terraced building is obtained by starting from only two housing units, in the following denoted by A and B. The two units only differ for their second oors, where the unit type A do not contains the room bed3. This room instead is used by the designer to make a sort of bridge over the balcony when the units type B are used. First some reference variables are de ned which are constrained to the values bounded to the variables used for the lower oors. Then two alternative layouts for the second oor are given, denoted as second_floor_A and second_floor_B, respectively: DEF x_first = 945 DEF x_bed3 = x_balcony ; ; DEF y_bed3 DEF x_bath DEF y_bath = y_plan * 3/5 ; = x_first - x_bed3 - x_stairwell ; = y_plan - y_bed3 Before de ning the rst oors it is useful to take into consideration the at oor under the roof, named roof_floor_A and roof_floor_B, which are two appropriately positioned instances of L_space: DEF roof_floor_A = (T:<1,2>:~R:<1,2>:PI~L_space): ; DEF roof_floor_B = glue:(roof_floor_A(nw ^ ne)bed3) So, we can de ne the second_floor_A layout plan as follows: DEF second_floor_A = floor (se ^ se) bath (ne ^ ne) bed2 (se ^ sw) terrace WHERE floor = floor_base & roof_floor_A, bath = L_space:, bed2 =(R:<1,2>:pi~L_space):, terrace = O_space: END Notice that floor is obtained by intersecting with floor_base. In order to de ne the layout plans of type \B" of rst oor, it is then sucient to add an instance of bed3 to roof_floor_A: roof_floor_A DEF bed3 = O_space:; DEF second_floor_B =second_floor_A (nw ^ ne) bed3 1.3 Schematic layout sections The 3D models of both type A and type B housing units are quite dicult to generate, mainly because (a) both 3D models contain several di erent sections and (b) such sections do not necessarily change in correspondence with internal partitions, so inducing very complex space models. Hence, in order to automatically produce the set of space polygons which de ne the 3D schematic models of our housing units, in this paper a new generative method which starts from ordered sets of plans and sections is described. This method is derived by the intersection of extrusions, special case of the generalized product operation described in [3]. In that reference it is shown that the geometric model of the class of buildings with constant plan and section can be generated by pairwise intersecting all the cells of the 3D complexes produced by extruding both the plan and the section (2D complexes), after a proper embedding of them onto two coordinate subspaces of <3 . In the case here discussed, we conversely have to combine an ordered set fP1; : : :; Pm g of plans and an ordered set fS1; : : :; Sng of sections (see Fig. 3). The solution is found by computing mn pairwise intersections of extrusions between an open subset of a plan and an open subset of a section. More formally, we can write that the result is generated as: [m [n (P \ O ) && (S i=1 j =1 i j j \ Oi ) Figure 3: Plans and section of the building unit B, properly embedded in <3. where Oj , Oi denote the open stripe of \constant section" Sj and of \constant plan" Pi , respectively, and where && denotes the intersection of extrusions operator. So, from the analysis of lateral views and sections of the building units, four zones \with constant section" are characterized, as it is shown in Figure 4. Such four sections have a similar structure and, if superimposed to the lateral view, lead to a partitioning in the regular cellular complex shown in Figure 5). The dimensions which de ne the grid underlying such a cellular decomposition are de ned using the same variables which constraint the sizes of the plan elements, according to the following scheme: DEF z_floor =300 %first and second floor heigth%; DEF z_basement =z_floor*0.9 %basement heigth %; DEF DEF DEF DEF DEF DEF hs = h0-z_basement % level of basement %; h0 = 0 % level of first floor %; h1 = h0+z_floor % level of second floor %; h2=h1+((h3-h1)*(l5-l4)/(l5-l3))%constraints%; h3=h1 + z_floor % for the %; h4=h1+((h3-h1)*(l5-l2)/(l5-l3))%roof slope %; DEF DEF DEF DEF DEF DEF l0 l1 l2 l3 l4 l5 = = = = = = 0 ; l0 + l1 + l0 + l1 + l1 + x_bed3 ; x_stairwell ; x_first ; x_ground ; x_ground + x_terrace According to the de ned dimensions, the grid points used as reference for the sections can be computed by row starting from bottom, by using the function section_grid: DEF section_grid = CAT:< add_coord add_coord add_coord add_coord add_coord add_coord hs h0 h1 h2 h3 h4 , , , , , > where the binary function add_coord, which adds the y coordinate to a sequence of real numbers to be interpreted as x coordinates of an aligned subset of grid points, is de ned as follows: section 1 section 2 section 3 section 4 Figure 4: Zones \with constant section". DEF add_coord (xx::IsSeq; y::IsReal) = AA:(AR~[[ID],K:y]):xx Notice that, e.g. add_coord hs=<,,> Starting from the given set of grid points, the four sections of the housing unit can then be de ned simply by (a) selecting for each section the appropriate subset of grid points and (b) grouping the subset of points in order to the de ne the convex cells of the section and (c) grouping the convex cells to de ne some polyhedral cells (only when this is necessary), according to the usual semantics of the primitive function MKPOL (see Reference [6]): DEF section_1 = MKPOL:, % basement % <4,6,8,11>,<6,11,15,12>,<8,9,13>,%first floor% <9,11,15,18,17>, % second floor % <17,18,19>>, % roof % <<1>,<2,3>,<4>,<5>,<6>>> ; DEF section_2 = CAT_POL:, % basement <4,5,8,11>,<8,9,13>, % first floor <9,10,18,17>, % second floor <17,18,19>>, % roof <<1>,<2,3>,<4>,<5>>>> ; DEF section_3 = CAT_POL:, % basement <4,5,8,11>, % first floor % % % % % % h4 DEF y_section_4 = y_plan + delta The functions sel_section_1, sel_section_2, sel_section_3 and sel_section_4, which respec- h3 tively select the part (zone) of a plan to be combined with the sections section_1, section_2, section_3 and section_4, are de ned as follows: h2 h1 DEF sel_section_1 = & ~[k:(stripe:),id]; DEF sel_section_2 = & ~[k:(stripe:),id]; DEF sel_section_3 = & ~[k:(stripe:),id]; DEF sel_section_4 = & ~[k:(stripe:),id] h0 hs l0 l1 l2 l3 l4 l5 where the function stripe, which returns the generic open stripe is given as: Figure 5: Basic grid of the sections de nition. <7,10,18,16>, <16,18,19>>, <<1>,<2>,<3>,<4>>>> ; DEF section_4 = MKPOL:, <4,5,8,11>,<10,11,14>, <7,10,18,16>, <16,18,19>>, <<1>,<2,3>,<4>,<5>>> % second floor % % roof % % % % % basement first floor second floor roof % % % % The section of terraces, denoted as section_terr, is separately de ned by making use of partially open rectangular polyhedra generated by the prede ned function OCUBOID. In this way it is speci ed that the terraces are open spaces which are only partially bounded by polygons: DEF section_terr = STRUCT::: (OCUBOID:<<1,1>,<1,0>>:), T:<1,2>:: (OCUBOID:<<1,1>,<1,0>>:)> The OCUBOID prede ned function is applied rst to a sequence of binary pairs, then to a sequence of equal length of reals. The length of both pairs de nes the intrinsic dimension of the generated hypercuboid; the sequence of binary pairs de nes which facets of such object must be closed and which must be open. E.g., OCUBOID:<<1,1>,<1,0>>: de nes a 2D rectangle (with area a * b) which is closed on all sides but the one de ned by the highest value of the second coordinate. 1.4 Combination of plans and sections In order to combine plans and sections, it is necessary to explicitly indicate what \zone" of each plan must be combined with a \zone" of a section. Consider, e.g., the layout plan of rst oor. The various zones which interact with the four sections are selected by intersection with properly positioned open rectangular stripes. So, the widths of the various plan zones are de ned according to the following variables: DEF y_section_0 = -:delta DEF y_section_1 = 190 DEF y_section_2 = x_stairwell ; ; ; DEF stripe (y1,y2::IsReal) = (T:2:y1:(OCUBOID:<<1,1>,<0,0>>:<10000,y2-y1>)) Analogously, some other functions must be de ned which select the part of a section to be combined with a particular layout plan. With reference to the grid of Figure 5, it is easily veri ed that the section zone corresponding to the basement is constituted (sel_included_pol) by the elements between the y values hs and h0: DEF sel_basement = sel_included_pol:<2,hs,h0> At the same way it is possible to select the zones associated to the rst oor (between h0 and h2) and to the roof (between h3 and h4): DEF sel_first = sel_included_pol:<2,h0,h2> DEF sel_roof = sel_included_pol:<2,h3,h4> ; In order to select the zone corresponding to the second oor it is instead necessary to use a di erent function (sel_including_pol), which select only the elements of a 2D section which contain the y stripe between h2 and h3: DEF sel_second = sel_including_pol:<2,h2,h3> The two functions to select polyhedra which respectively are contained within or contain a stripe zone between min_val and max_val, with respect to the coord reference axis, are de ned as follows: DEF sel_including_pol (coord::IsIntPos; min_val,max_val::IsReal)= (CAT~AA:(IF:>)) ; DEF sel_included_pol (coord::IsIntPos; min_val,max_val::IsReal) = (CAT~AA:(IF:>)) Finally, the \generalized product" (see Reference [3]) && is specialized as the function sel_prod, to be used to combine a zone of a plan with a zone of a section, where the two zones are selected by using the four functions previously discussed. Notice that sel_prod rst by executing a generalized product of plans and sections properly embedded in <3 , then extract the 2D skeleton (@2), i.e. the set of boundary polygons of all the cells, from the generated 3D complex: DEF sel_prod (plan,sect::IsPair) = s1:sect:(s2:plan) (@2~&&:<<1,2,0>,<1,0,2>>) s1:plan:(s2:sect) So, in order to combine the rst oor plan with the rst section we have to evaluate the plasm expression: sel_prod Since several pairs (plan, section) must be combined using the sel_prod operator, it may be convenient to de ne a new higher-level function, which systematically applies sel_prod to the proper argument pairs: DEF combine_plans_sections = (STRUCT~AA:sel_prod~CAT~AA:DISTL~DISTR) In this way the 3D models of two housing units type constitute (together with their re ected images) the whole building, are then given as A and B which DEF unit_A = combine_plans_sections: <<, , , >, <, , , >>; DEF unit_B = combine_plans_sections: <<, , , >, <, , , >> 1.5 De nition of the staircase In this section the staircase structure is de ned to be exactly positioned and matched with the empty space (stairwell) produced together to the automatically generated 3D models of the housing units. The basic elements are a straight ight of stairs and a spiral stair with squared base. In order to de ne the rst it is sucient to put together a set of properly translated rectangular steps. To de ne the second we need to give also a triangular step, as well to connect the various steps with rotations and translations. DEF S_flight (x,y,z::IsReal; n_steps::IsInt) = (STRUCT~##:n_steps): <((T:3:z~EMBED:1):(CUBOID:) STRUCT (R:<2,3>:(PI/2)~EMBED:1): (CUBOID:)),T:<2,3>:> ; DEF L_flight (x,y,z::IsReal;n_turns::IsIntPos) = (STRUCT~##:n_turns): :(PI/2)> WHERE step1 = (S:1:-1~T:1:(-:x)~T:3:z~EMBED:1 ~S:<1,2>:):(SIMPLEX:2) STRUCT (R:<2,3>:(PI/2)~EMBED:1) :(CUBOID:), step2 = (S:2:-1~T:2:(-:y)~T:3:z~EMBED:1 ~S:<1,2>:):(SIMPLEX:2) STRUCT (S:<1,2>:~R:<1,2>:(PI/4) ~R:<2,3>:(PI/2)~EMBED:1) :(CUBOID:), sqr2 = 2 ** 0.5 END The stairs from basement to rst oor (basement_stair) and from rst oor to second oor (first_stair), will be constructed by the basic elements so de ned: DEF basement_stair (x,z::IsReal) = (@2~STRUCT):: ,R:<1,2>:(pi/-2),final_step, (T:<1,2>:~STRUCT~##:3): ::flat, T:<1,2>:: (S_flight:), T:3:(3*Z_step),R:<1,2>:(pi/2)>, T:3:(z-delta):final_step> WHERE X_step = (x - Z_step)/ 2 , Z_step = z / 9 , dd = Z_step / 2 , final_step = S:2:-1:(EMBED:1: (CUBOID:)) , flat = L_flight: END; DEF first_stair(x,y,z::IsReal;n_steps::IsIntPos)= (@2~STRUCT):,<2,max,min>>turn, T:3:z:(EMBED:1:(CUBOID:)), T:<1,3>:<-:X_step,z>,S:3:-1, flight> WHERE n_step_flight = (n_steps - 4) / 2 , X_step = x / 2 , Y_step = (y - X_step) / n_step_flight , Z_step = z / n_steps , flight = S_flight:, turn = L_flight: END The total dimensions of each stair are given as input parameters x, y and z in their function de nition. Notice that y is not given in the definition of basement_stair because it equates x. Notice also that a single STRUCT construct in the staircase de nition put the first_stair above the basement_stair: DEF staircase = STRUCT: :: (first_stair:), T:<1,2,3>:: (basement_stair:) > At this point both the basic housing units can be completed by matching the staircase to the rest of the models: their generative functions can then be de ned as follows: DEF housing_unit_A = staircase STRUCT unit_A ; DEF housing_unit_B = staircase STRUCT unit_B Figure 6: Complete terraced housing. 1.6 Terraced building de nition Now, starting from housing_unit_A and housing_unit_B, two groups of four instances of each unit are built, specularly re ected with respect to the axis x and y . So, the function make_group is de ned to make such an arrangement. Also a global variable DeltaY is de ned to furtherly aggregate such groups of buildings: DEF DeltaY = 2 * y_plan; DEF make_group = STRUCT~[ID,T:2:DeltaY~S:2:-1] ~STRUCT~[ID,S:1:-1] Finally, in order to generate the models of the such groups of four houses, it is sucient to apply the function make_group to the two housing units: DEF group_A = make_group:housing_unit_A ; DEF group_B = make_group:housing_unit_B The terraced building as a whole will then be given as an alternate series of instances of group_A and group_B (see Fig. 6) and of translations with parameter DeltaY: DEF terraced_housing = STRUCT: < group_A,T:2:DeltaY, group_B,T:2:DeltaY, group_A,T:2:(DeltaY + 360), group_B,t:2:DeltaY, group_A > References [1] Backus, J., Williams, J.H. & Wimmers, E.L., 1990. An Introduction to the Programming Language FL. In Research Topics in Functional Programming, D.A. Turner (Ed.), Addison-Wesley, Reading. [2] Backus, J., Williams, J.H., Wimmers, E.L., Lucas, P. & Aiken, A., 1989. FL Language Manual, Parts 1 and 2. IBM Research Report RJ 7100 (67163). [3] Bernardini, F., Ferrucci, V., Paoluzzi, A. & Pascucci, V. 1993. A product operator on cell complexes. Proc. ACM/IEEE 2nd Symposium on Solid Modeling and Applications, J. Rossignac, J. Turner and G. Allen (Eds.), ACM Press, pp. 43{52. [4] Howard,T.L.J., Hewitt,W.T., Hubbold, R.J. & Wyrwas, K.M., 1991. A Practical Introduction to PHIGS and PHIGS PLUS. Addison-Wesley, Reading, MA. [5] Paoluzzi, A., Bernardini, F., Cattani, C. & Ferrucci, V., 1993. Dimension-Independent Modeling with Simplicial Complexes. ACM Transactions on Graphics 12:56{102. [6] Paoluzzi, A., Pascucci, V. & Vicentino, M., 1995. Geometric Programming. A Programming Approach to Geometric Design. Accepted for pubblication on ACM Transactions on Graphics. [7] Paoluzzi, A. & Sansoni, C., 1992. Programming Language for Solid Variational Geometry. Computer Aided Design, 24:349{366.