Table of Contents 
Previous Chapter SEED
This section describes the key terms and concepts that underlie SEED and its modules and are used in our communications about them. The section is subdivided into subsections presenting the concepts related to building design and the SEED environment in general, those related to the support modules for each phase of SEED, and those related to the specific module considered in this document, SEED-Config, which supports the generation of schematic configurations for a given project.
A client program specifies the client's goal in terms of what is to be built where, when, at which cost, and under which expectations. An explicit program should state at least the following:
- site and site-related restrictions, specifications etc.
- building type and overall indication of size (e.g., total square footage of rentable space for an office building, total no. of students for a school, or no. of bedrooms for a residence)
- budget
- references to applicable codes, standards, and regulations.
A project is initiated by a client program and includes every process executed and every product produced during the development of a design that satisfies the client's goals as expressed in the client program. Work with a project may involve several module sesssions of several different modules.
An architectural program elaborates the client program in terms of the following major parts:
- specification of context (e.g., site characteristics)
- specification of main functional units and components needed to achieve the client's goal
- references to the applicable building codes and regulations
A functional unit is an identifiable object intended to perform a specific function or combination of functions in a building (e.g. a living room, a load-bearing wall). A functional unit has associated constraints and criteria on its shape, size, placement, relations with other functional units etc.
A functional unit can contain other functional units, in which case it is also called a functional component. Examples are a wall containing opaque and transparent parts, or a radiology department containing a waiting area and procedure rooms. Note that the opaque parts of the wall can contain the structural, insulation, air barrier and rainscreen components that comprise it, and the wall itself can be a funtional unit contained in a functional component such as an external enclosure system. The units contained in functional unit are its constituent units or constituents for short.
Within a partial solution, functional units take one of three states: unallocated, allocated (or complete) and partially allocated (or incomplete).
With respect to a problem we have to distinguish between those functional units that are part of the original problem specification and those that are introduced in the process of design. The original functional units provide the (more-or-less) unalterable context for the design session, Thus we call these the context functional units of the problem.
A design unit is a part of the spatial or physical structure of a building with an identifiable spatial boundary. In a complete design, each design unit has a functional unit associated with it. Design units can contain other design units (the latter units are said to elaborate the former) so that a hierarchical decomposition of design units reflects a hierarchical decomposition of the associated functional units and vice-versa.
The reason why we distinguish between functional and design units originates in the SEED-Layout module. A layout problem is typically defined in terms of functional units to be allocated. The units that directly contribute to the intended function of the building are normally given explicitly in the architectural program. The task then is to allocate these units in a layout and to add additional units needed, but not specified in the program, e.g. circulation spaces. In doing this, it may happen that a designer wants to exchange two functional units in a layout, e.g. switch the positions of living room and dining room. In traditional design, this can be done simply by changing the labels that identify these areas; the implication is that this switch also exchanges the constraints associated with the respected functions, which are managed by the designer. However, in an automated system that does not distinguish between functional and design units in the above sense, this operation would be more complicated because the units, together with their labels and associated constraints, would have to be moved physically in a step-wise process that may be quite tedious. But if the system is able to make the present distinction, we can make this operation as natural as in the traditional mode by giving designers the opportunity to change the functional unit associated with a design unit, which would automatically change the constraints associated with the design unit.
The general reason to make the distinction is that it makes explicit the difference between a design problem and its solution. Functional units specify problems to be solved; design units specfity one solution to the problem. Design units may be altered, deleted or inserted in multiple states without affecting the problem information. Storing the two types of information together would entail complicated and error-prone book-keeping and consistency maintenance.
Additional advantages arise from this possibility. For example, a designer will be able to change the constraints on a design unit in response to its particular placement without changing the general constraints it inherits from the associated functional unit. Furthermore, we can easily introduce configuration templates, i.e. configurations of design units characterized by a specific spatial organization or technology, where some or all of the units have no associated functional units; this gives us the opportunity to specify existing building conditions independent of the architectural program. The distinction that we make appears to introduce this kind of flexibility in a clear and conceptually simple way.
It is interesting to note that if one substitutes the term technical solution for the term design unit in the above definitions, our view of functional units and design units and of their relations mirrors very closely the view underlying the general AEC reference model (GARM) developed within the STEP/PDES integration effort [Gielingh 88]. This suggests to us that these distinctions may be extensible to other phases or modules of SEED and may indeed provide a basis for integrating SEED into larger efforts.
Context design units are analoguous to context functional units. They are part of the problem specification. Context design units may or may not have associated functional units in the problem specification.
A spatial unit is a design unit that may be occupied by a user of a building (e.g., a room).
A physical unit is a non-occupiable design unit, e.g., the structural, mechanical, and enclosure components of a building.
A phase is a subprocess in the overall project that addresses a specific task. It is characterized by the type of problem it addresses and the type of solution it produces; e.g., the schematic layout phase transforms an architectural program (which describes the problem to be solved) into a schematic layout (the solution to the problem). Phases are partially ordered based on the information they generate.
A module of the SEED system provides software support for an entire phase.
A module session is a specific invocation of a SEED module. It has a start and an end, and operates on run-time memory that is separate from the database.
A saved session is a session that a designer decides to suspend (without ending) and plans to resume from the same state of the system at a later time.
The database is a collection of information that supports modules and their components. This information falls into two categories:
- project-independent information stored for reuse across projects (e.g., prototypes or cases)
- project-specific information for reuse across sessions (e.g., design versions, design histories)
Unless otherwise noted, the term database refers to both types of information.
In the context of a module session, the term problem refers to the problem to be solved in the session. A problem includes both the functional units to be satisfied and the context of design units in which the problem is to be solved.
A problem statement is the representation of a problem in a module session.
An active problem statement is a problem statement in a module session on which the designer can operate directly from the screen. There is never more than one active statement in a session.
In the context of a module session, the term solution refers to a solution to a problem to be solved in the session. The solution of one phase may become (part of) the problem of another phase.
A partial solution is an incomplete solution in terms of the problem it is intended to solve. For example, a partial solution to a layout problem is a layout that does not allocate all functional units in the associated problem statement.
A problem-solution pair is a problem statement and one related solution.
A problem-solution tuple is an ordered set, or "chain", of problem-solution pairs, where the solution of one pair defines (part of) the problem of the next pair.
A problem solution tree is a collection of problem-solution tuples that share the problem part of their first problem-solution pair, which is the root of the tree.
A case is a problem-solution tuple that is stored in the database for reuse. It is minimally indexed by the problem part of the first pair of the tuple and may contain natural language annotation. In SEED-Pro, a client program (problem) stored with an architectural program (solution) may be a case. In SEED-Layout, an architectural program (problem) stored with a schematic layout (solution) may be a case. In SEED-Config, a schematic layout, stored with a configuration developed for that layout may be a case. A related client program, architectural program, schematic layout and confugration design is an example of a case that extends across phases.
Note: The following description of Design Space is outdated. Design Spaces are now not hierarchical. Expect a future update.
In general, a design space is the structured set of all (partial or complete) solutions to a design problem, where the structure on the set allows us to traverse the space in an orderly fashion.
In the context of the present module (as well as other modules such as SEED-Layout), a design space is implicitly defined by the combination of a problem statement, a starting state, and a collection of operators that derive states from states, where the states represent partial or complete solutions of the problem given in the problem statement and the operators are the rules of a spatial grammar. The space is the collection of all states that can be derived by applying the operators to the starting state under the problem statement.
Design spaces are the primary objects that structure SEED-Config. They record transformations, i.e., derivational connections between states. Such transformations may occur based on changes in either the problem specification or solution parts of a state. Design spaces are hierarchical in that a constituent functional unit in a state may describe a problem and thus another design space, the head of which is associated with that problem. This lower level space is represented in the space above it as one of its problem-solution pairs that is embedded in a state of the higher level space.
Figure 2 : States in a design provide a view of design spaces lower in the design space hierarchy by embedding one state in the lower design space into a state.
A (part of a) design space is explicitly defined by a collection of explicitly represented states. In each of these states both the design and the problem may vary.
The active design space is the design space associated with the active problem statement.
A derivation is a problem-solution tree of uniform arity 1 (except for its single leaf node which is called the result of the derivation) that records the actual process of development of a design state from the root of its design space to the state. Derivations include the technologies that were used at each step in the derivation.
A state in a design space comprises a problem-solution pair in that space.
A state is a starting state or the result of applying operators to a starting state, where each state represents a partial or complete solution to the given problem.
An active state is a state in a module session on which the designer can operate directly from the screen. There is never more than one active state in a module session.
In the context of the SEED architecture, a component is a part of a module that supports a set of logically related subtasks. Components are polymorphic; that is, the same component names are used in every module: input, problem specification, generation, evaluation, and output. Each component in a module provides function analogous to that provided by the same-named components in the other modules.
The input component provides the read interface to the database. It translates stored data format to module-specific format. It may extract the input needed by an earlier module session from the output produced by a later module session and thus supports iterative design.
The specification component produces a problem statement for the current session. It supports user modification, expansion, and editing of that statement.
The generation component supports the derivation of an or several solutions (solution alternatives) for a problem specified in the current session.
The evaluation component derives an evaluation of a solution available in the current session with respect to the associated problem statement.
The output component provides the write interface to the database. It translates module-specific formats into stored database formats.
SEED-Config uses all of the concepts from SEED-Layout and adds many of its own. This document includes the both SEED-Config and SEED-Layout concepts.
A technology is a collection of computational mechanisms to create and instantiate design and functional units satisfying the requirements of a class of functional units in a design context based on specific construction technology or form generation principles.
Example: A set of grammar rules to create a partition (design unit) between two given spaces (context) satisfying requirements of visual and acoustic privacy (functional unit) using the dry wall construction technology. Another example: An executable function in a procedural programming language that wraps an unelaborated wall (design unit) around a set of spatial design units (context), satisfying a requirement for weather enclosure (functional unit). This process may lead to the creation of additional functional units specifying requirements for additional design units needed as parts-of the instantiated design unit.
In SEED-Config there are two core types of computations involving technologies:
- Matching. Given a set of unallocated FU's in a design state find those technologies that can be used to instantiate the FU's in the context of the DU's of the design state.
- Instantiation. Given an FU from a given design state and a technology matching it, instantiate the technology in the design state, possibly creating new FU's in the process.
Technologies are the only mechanisms in SC that can generate design units. Different design tasks may require different technologies. These are created by new type of actor in SC, the technologist.
A technology set is a set of technologies. These are made available as part of a problem and are the components out of which a problem solution can be composed.
At the knowledge level, technology sets are organised in refinement, elaboration and use relations. A technology refines another technology if its instantiation introduces no new DU/FU pairs. That is, a refinement of a technology into another technology in effect substitutes the new technology for the old one. They both realise the same functional unit. A technology elaborates another technology if its instantiation produces new DU/FU pairs. That is, an elaboration of a technology changes the local structure of the problem statement. A technology uses another technology if one of the components of an elaboration of the technology is that other technology.
The relations of refinement, elaboration and use are also used to define technologies. At the knowledge level, a refined technology retains all of the properties of its source technology and adds additional properties. A technology that is an elaboration of another technology is constrained but not defined by the properties of its source technology. The additional DU/FU pairs it creates on instantiation reflect these constraints. Similarly, a technology that is used by another technology is constrained by the properties of the using technology. Refinement and elaboration bear a striking analogy to the `or' and the `and' respectively in and/or trees. A single technology may have multiple refinements or elaborations; each of these is an `or' branch of an and/or tree. An elaboration of a technology substitutes for that technology multiple technologies; together these can be collected under an `and' branch set of an and/or tree. The following figures use the usual graphic devices for diagramming and/or trees to show the refinement/elaboration structure of steel and timber technologies respectively. Intoducing the use relation converts the strict tree given by refinement and elaboration into a directed acyclic graph (a DAG). Use arcs are shown in the figures as curves connecting distinct portions of a technology tree.
Figure 3 : A steel flooring technology represented as a directed acyclic graph combining refinement, elaboration and use relations.
Figure 4 :A timber flooring technology represented as a directed acyclic graph combining refinement, elaboration and use relations.
That technologies require matching and instantiation capabilities and that they occur in defining relations to each other suggests that, at the symbol level, technologies are implemented via some combination of rule-based and object-oriented programming.
Within a SEED-Config session there is always available a set of technologies. As mentioned above, these are the source of all generative operations. These available technologies determine the refinement state of allocated functional units. If a functional unit is allocated via a technology that has refinements or elaborations defined over it in the available set of technologies, that functional unit is said to be incomplete. On the other hand, a functional unit that is allocated via a technology that has no refinements or elaborations is complete.
A question that will often be asked of a technology set is "given a functional unit, what are the techologies from the set that meet some or all of the functions specified in the functional unit?".
Several technology sets are available to a designer in a SEED session. The set called available technologies comprises all technologies that have been used in past sessions on the same problem, that have been read into the problem session and that have not been deleted by the designer. Subsets of this set, called technology groups, are defined by the designer to be used in parts of the design task. The set of available technologies is itself a technology group. At any one time, one of these technology groups is the current technology, which is used as the source of technologies for all operations in SEED-Config.
Following is an example of a technology set for walls which is organized by constructional system. In this set, technologies may appear as refinements and elaborations of other technologies.
Wall
........................... Stud ................... Platform .........................Wood
........................ Metal
.................... Balloon
..............Post & Beam ................ Panel Infill .......................... Stud
....... Composite Panel
.... Manufactured Unit
........ Detached Frame .......................... Stud
...... Composite Panel
... Manufactured Unit
.................... Masonry ........................ Brick ......................... Solid
....................... Cavity
................ Reinforced
.................... Concrete .............. Hollow Unit
....................... Cavity
................ Reinforced
.................... Concrete ........................ In situ
...................... Precast
....................... Tilt-up
....... Structural Frame ...................... Curtain ......................... Panel
................. Rainscreen ................... Masonry
......................... Stone
........ Precast concrete
... Manufactured panel
Following is an example of a technology set for massing design that is organised by form-making strategy. Technologies in this set would be used to articulate a basic massing which in turn would typically be derived from a SEED-Layout representation. Note that these technologies are named by the actions that they perform on designs.
Massing
...............Bay pull/push ...... One level
....... All levels
..............Round volume ...... Coalesce
....... Separate
.............Detach volume
...........Overlap volume
.....................Place axis ............... Central
.................... Edge
.Shift spaces along axis
In SEED-Config a context is a configuration of functional units and design units. It is typical that changes to the context are constrained. Contexts serve as initial states for problem exploration.
A target is a predicate consisting of logically connected conditions that stops the automatic generation of configurations when the conditions are satisfied. The conditions that can be used are the following:
- a ordered list of the functional units to be allocated (this implicitly bounds the extent of generation);
- elapsed clock time;
- score; details have to be worked out;
- maximum number of states generated;
- whether technology refinements and/or elaborations are to be considered;
- the search control strategy to be used; and
- maximum number of alternatives that meet the specifications of the functional units.
The system supports the flexible combination of these conditions in any logical statement consisting of conjuncts and disjuncts. The target is intended to support operations such as the following:
- generate functional units that describe enclosures between spaces;
- generate next configuration; this would be specified by a target with only one functional unit in its list and a maximum number of states equal to one;
- generate all configurations of a given set of functional units with score better/worse than the specified score;
- generate as many complete configurations of a given set of functional unit as is possible within the specified clock time and maximum number of states; and
- generate a specified number of alternative configurations of a given set of functional units.
In the first module prototype, we assume that all conditions are conjuncts.
A massing is a functional unit that specifies a collection of spatial units to be allocated in a state. A massing may be allocated as a collection of design units -- in this case, each design unit will have a corresponding functional unit, called a massing element, that is a constituent of the massing. These may correspond to rectangles from a layout in SEED-Layout and in their most simple form are extrusions of those rectangles after the rectangles have been assigned a nominal size. The shape of a massing element can be changed from a strict rectangular extrusion. Massings and the SEED-Layout problems to which they correspond provide context in which other technical systems generated by SEED-Config are placed.
Massings are generated by technologies that transform 2-dimensional rectangles into 3-dimensional spatial design units and by technologies that modify spatial design units.
A massing element is a component of a massing. A volume-occupying object in three dimensional space. When two massing elements are adjacent they define a separation surface between them. The following three specific types of massing demonstrate specialisations of massings to circulation systems. Each such type of massing would have associated technologies to develop them.
A vertical circulation element is an design unit that allocates a massing that specifies a circulation between floors of a building.
A stair is a design unit that refines a vertical circulation element. It is suitable for vertical circulation elements that specify unassisted vertical circulation between floors.
An elevator is a design unit that refines a vertical circulation element. It is suitable for vertiacal circulation elements that specify mechanical vertical circulation between floors.
An enclosure is a functional unit that comprises a collection of enclosures or enclosure elements. These are called its sub-enclosures. An enclosure may have properties and tests associated with it. The tests of an enclosure apply to all of its sub-enclosures. Enclosures are allocated as design units that describe solutions to an enclosure. Enclosures do not presume a technology by which they will be realized -- such distinctions being made at the time enclosures are allocated as design units. Thus a wall is a design unit placed to allocate (or realize) an enclosure.
Enclosures are represented as design units either directly as a single design unit that describes a possibly abstract response to the enclosure problem or indirectly as a composition of design units that collectively comprise the enclosure.
Enclosures and enclosure elements have two sides. These sides correspond to sides in the design units that allocate the enclosures. When an enclosure separates an internal from an external space its sides are labeled respectively with inside and outside.
All of the functions that might be addressed by an enclosure would present a very long list and a problematic categorization. In early versions of SEED we will restrict the functions of an enclosure to no more than the following (where known we list the tests we propose for these functions after each item):
- Energy flow control - determined by parallelized R-Values.
- Fire separation - determined by code categorization of construction systems.
- Visual privacy - computed via physical separation.
- Acoustic privacy - determined by attenuation calculations.
- Air movement control - determined by a crack method.
- Natural ventilation
- View
- Spatial separation
- Compatibility with structural support system.
Enclosures are classified by these functions and not by the types of construction that realize them. In particular, enclosure names should not presume the geometry of the design units that will eventually allocate them. Thus an enclosure between two spaces that requires a fire rating and light admission cannot be called either a wall or a roof until some commitment to its geometry is made as a design unit. To continue the example, presume that the above enclosure is between two spaces whose separation surface is vertical. It would be allocated as a design unit as a wall which, in the first instance, might only have the polygon of the separation surface as its geometry.
This policy of requiring a separation of functional specification from geometric realization is apparently at variance with the SEED-Layout policy of giving functional units names that reflect the existance of spaces to satisfy them. The behavior of the system could be very similar to SEED-Layout though. If use cases that add both abstract design units and functional units are used to define enclosure functional units then the names of the design units can appear as descriptors in the functional unit display. If use cases that allocate functional units alone are used, then the their description as architectural elements is simply deferred.
An enclosure element is a functional unit that describes a physical separation between two spaces. Several enclosure elements can separate two spaces in which case they cannot physically overlap, but may not collectively exhaust the separation surface between the two spaces. Enclosure elements are represented as design units that may represent single or composite construction elements.
A wall is a design unit that allocates an enclosure between spaces for which the separation surface is vertical.Walls may have windows punched into them: such windows create additional constituent enclosures in the enclosure corresponding to the wall.Walls are called external if they separate the inside from the outside of a building, and internal if they separate internal spaces in a building. Walls are instantiations of technologies.
A wall which carries no structural load. It is called full if it extends from floor to ceiling, otherwise it is called partial. Partitions are instantiations of technologies.
A window is a design unit that is surrounded by a wall and contributes to the enclosure allocated by the wall. Windows typically exist to admit light or natural ventilation, or to provide view or visual connection between spaces. Windows are instantiations of technologies.
A skylight is essentially a window placed in a roof. As a consequence its technical detailing will usually be very different from a normal vertical window. Skylights are instantiations of technologies.
A roof is a design unit that allocates an enclosure betwee internal and external spaces for which the separation surface is non-vertical. Roofs may have skylights punched into them: such windows create additional constituent enclosures in the enclosure corresponding to the roof. The inside side of a roof is known as its ceiling. Roofs are instantiations of technologies.
A floor assembly is a design unit that allocates an enclosure between internal spaces for which the separation surface is horizontal or nearly so. The bottom side of a floor assembly is its ceiling (and the ceiling of the space(s) below which it bounds). The top side of a floor assembly is its floor (and the floor of the space(s) above which it bounds). Floor assemblies are instantiations of technologies.
A ground floor assembly is a design unit that allocates an enclosure between an internal space and the surrounding site. The top side of a ground floor assembly is its floor (and the floor of the space(s) above which it bounds). Ground floor assemblies are instantiations of technologies.
A door is a design unit that allocates an enclosure between spaces and that provides a capability of variable physical access. When closed it may contribute to energy flow control, fire separation, visual privacy, acoustic privacy, air movement control and spatial separation. When open it may contribute to natural ventilation, view and variable physical access. Doors are instantiations of technologies.
A horizontal door. Hatches are instantiations of technologies.
A structure carrier is a functional unit that performs for structures what enclosures perform for building envelopes. Like enclosures, structure carriers define a problem to be solved without presuming the geometry of a physical solution to the problem.
Structure carriers and their associated technologies will be developed in a future version of this specification.
In SEED-Config a problem is given as a SEED-Layout problem-solution pair, a context, a set of functional units, and a technology set. Configuration problems may be of many sorts, but the first implementation of SEED-Config will address only the following sorts: massing, enclosure and structure.
A massing problem is defined by a SEED-Layout problem-solution pair, a context, a set of massings and a technology set. The context may contain massings, enclosures or structures and their corresponding design units. The technology set will contain technologies capable of computing from the SEED-Layout design units SEED-Config design units that represent the SEED-Layout units in three dimensions.
An enclosure problem is defined by a SEED-Layout problem-solution pair, a corresponding massing, a context, a set of enclosures and a technology set. The context must contain a massing and design units that allocate is and may contain other massings as well as enclosures or structures. The massing gives the three dimensional shape of the enclosure specified in the problem. The technology set will contain technologies capable of developing from the other information in the enclosure problem a set of design units that meet the requirements given in the functional units.
A structure problem is defined by a SEED-Layout problem-solution pair, a corresponding massing, a context, a set of structure carriers and a technology set. The context must contain a massing and its allocated design units and may contain other massings, enclosures or structures. The technology set will contain technologies capable of developing from the other information in the enclosure problem a set of design units that meet the requirements given in the functional units.
A layout is a collection of design units in the form of non-overlapping rectangles with sides parallel to the axes of an orthogonal system of Cartesian coordinates (see Figure 5). SEED-Layout is restricted to this type of layout.
In SEED-Layout, a layout is defined by:
- a set of design units in the form of rectangles
- a set of realizable spatial relations between rectangles in the given set so that exactly one relation is defined for any pair of rectangles in the set; realizable means that there exists a layout of rectangles with these spatial relations
- dimensional bounds on the rectangles as implied by the spatial relations
- a set of functional units so that each rectangle is associated with exactly one functional unit
In SEED-Layout, a layout problem is defined by a functional unit with constituents and an associated context. The context imposes restrictions on the allocation of the functional unit that are not implied by the constraints and criteria associated with as functional unit. The context, in turn, implies an initial state. A solution to the problem allocates the constituents within the given context.
If no explicit context is given, the constraints and criteria of the functional unit may provide a minimal context, for example, minimum and maximum dimensions for the enclosing rectangle, within which generic layouts of the constituents can be generated. However, the functional unit itself cannot be allocated in that case.
If the constituents have, in turn, constituents, the layout problem is hierarchically decomposed into subproblems. A context may be associated with any functional unit in this hierarchy. If it is associated at least with the top unit, a top-down design process can proceed in an orderly fashion as follows: it associates with the top unit a design unit whose dimensional attributes reflect the context restrictions; this design unit is the enclosing rectangle for the entire layout. The constituents can then be allocated within this rectangle. Each design unit associated with a constituent defines, in turn, a context and enclosing rectangle for the allocation of its constituents and thus completes the definition of a layout problem at the next level in the problem hierarchy. The overall problem can thus be solved by solving the layout problems defined at each level by a constituent and its context.
But a bottom-up process, and any combination between bottom-up and top-down approaches, is also possible because we allow functional units by themselves to provide a minimal context for a layout problem.
This view allows us to interpret the hierarchical decomposition of a functional unit into constituents directly as a hierarchical decomposition of a layout problem into subproblems, a major structuring device in both human and computer-based design processes. That is, we do not have to manage two hierarchies simultaneously. It remains to be seen how this close correspondence between problems and functional units extends to other modules. It is certainly implied by the GARM model [Gielingh 88].
A problem statement at any level consists of an explicit specification of a functional unit and its constituents and those context aspects that cannot be inferred from higher level solutions. The initial state of the design space associated with a specific problem statement at a specific hierarchical level may vary: it may reflect context restrictions that result from the allocation of units at higher levels in the hierarchy, or be less restricted (as in bottom-up design). These different initial states lead to different design spaces and therefore to different layout problems according to our definition, but leave the decomposition of the functional unit itself intact. This is the reason why we must distinguish between a layout problem and a functional unit and its constituents, however close they correspond with each other. To summarize this discussion: a functional unit becomes a problem statement when it is associated with a specific allocation context.
The difference between a layout problem and an architectural program is that we reserve the latter term for the specification of the overall design problem posed by the project at hand. This specification may contain information not relevant to layout design and is normally rather unstructured; for example, it may not imply a distribution of functions over different floors. The architectural program can be updated in the course of a project independent of any particular layout task. It should be stored and maintained as a general reference for all modules. A layout problem, on the other hand, reflects a specific structure given to the functional units in an architectural program in response to a specific design intent and a specific context; it may aggregate these units into a hierarchy of components, each of which poses a specific layout problem at a specific level in the hierarchy that can be solved with the support of SEED-Layout.
A consequence of this is that architectural programs as understood in the context of SEED can only be generated and edited in the Architectural Programming Module, while layout problems can be specified and edited only in SEED-Layout. More generally, when a SEED component reads the results produced by other modules, it treats them under a specific perspective that does not make the work in the other modules redundant. It may involve the stripping away of irrelevant data or the addition of structure to the specification. This the rationale behind making the problem specification component an important and integral part of any module.
A spatial relation between two rectangles belongs to one of the following types: left/right or above/below; see [Flemming et al. 88]. Note that more than one of these relations can exist between two rectangles; in Figure 5, for example, rectangle 2 is both above and to the right of rectangle 3. The LOOS representation, however, records only one relation between any two rectangles in a layout.
The spatial relations imply constraints on the size and position of the rectangles in a layout; for example, the right side of rectangle 1 in the layout shown in Figure 5 can never have a larger x-coordinate than the left side of rectangle 2 because rectangle 1 is to the left of rectangle 2.
In SEED-Layout, the term wall is used in a sense that differs somewhat from common usage and reflects the history behind the LOOS system. A wall in a layout represented in SEED-Layout can be viewed in two ways: (1) It indicates the center line on which a physical wall can be placed. (2) It indicates explicitly the above/below or left/right relation between two sets of rectangles in a layout as recorded by the underlying representation. We have found that using walls for the second purpose makes it much easier for designers to comprehend the spatial structure underlying a layout generated by the system, especially the way in which ambiguities are resolved; for example, Figure 6 shows a set of possible walls for the layout shown in Figure 5 indicating that the relation between rectangle 2 and 3 is above/below.
A test is a constraint or criterion associated with a functional unit together with a method to test the degree to which the constraint or criterion is satisfied in a state containing the unit.
Tests are not automatically associated with a functional unit, but must be established explicitly in its definition. This contrasts with constraints such as minimum width, for which default values are established and which are automatically taken into account.
The execution parameters define the form of user interaction with the system during various operations. For example,
- the form and frequency of the display of results
- the destination of display; i.e., what screens are to be used for display
- the type of user interaction desired by the designer; for example, the system may stop after each state and wait for the designer's response before generating the next state, or proceed immediately.
The evaluation parameters define how and when evaluations are performed during generation.
Table of Contents 
Next Chapter