## Appendix A. Algorithm for exhaustive generation of designs

The pseudo-code for the algorithm for exhaustive generation of designs is given in Figure 18. The algorithm requires an initial design (*initialDesign*), the rule set (*ruleSet*) and a maximum number of rule applications (*maximumSequenceLength)* as input. Outputs are a list of explored designs (*graphs*) and a list (*transformations*) storing each applied rule, the design the rule is applied to, and the resulting design. Starting from an *initial design*, all rules in the rule set (*ruleSet*) are explored exhaustively until a given number of rule applications (*maximumSequenceLength)* from the *initial design*. The algorithm is implemented as a BFS with isomorphism check to not explore already found topologies repeatedly. It explores the design space in levels (*level*) until the maximum number of rule applications (line 2). For each *level*, the algorithm iterates through all rules in the rule set (line 3). The selected rule
$r$
is applied to all graphs from the previous level (*previous*, line 4). For each graph
$g$
, all matches
$m$
of the current rule
$r$
are identified (line 6) and for each match
$m$
a new graph (*newGraph*) is generated by applying rule
$r$
on graph
$g$
at match
$m$
(line 8). The generated graph (*newGraph*) is evaluated (line 9) and if it constitutes a topology that is not found yet in one of the previous levels, (*newTopology* returns *true* in line 10), then the design is stored in the list of designs to be expanded in the next level (*next*, line 11). Each generated graph (*newGraph*) is stored in the list *graphs* (line 13) and for each rule application, the rule and the previous and resulting graph are stored in *transformations* (line 14). Once all rules in the *ruleSet* are applied for the current *level*, the graphs from list *previous* are replaced with those from list *next* (line 18), list *next* is cleared (line 19) and the algorithm continues with the next *level* (line 3).

Figure 18. Pseudo-code for exhaustive generation.

## Appendix B. Analysis of LHSs of rules 2 and 4 for the gearbox case study

In Figure 19, all matches of rule 2 (*delete a shaft*) on the design with UID 2 (see Figure 8) are shown (left). The rule formulation in GrGen is provided on the right of Figure 19. LHS and RHS of the rule are indicated using curly braces. The LHS of the rule consists of a node of type *shaft* (*S0*) and a node of type *gear* (*G0*). In addition, a negative application condition is defined using the *negative* statement. Negative application conditions are used to define patterns that, when present in the graph, prohibit the rule’s application. In case of rule 2, this is when the *gear G0* is reachable from *shaft S0*, or when *shaft S0* can be reached from *gear G0*. The rationale behind this condition is that when no *gear G0* exists that is not reachable by *shaft S0* or can be reached from *S0*, then there exist only power flow paths in the gearbox that involve *S0*. The rule is then not applied since removing *S0* would result in an invalid design, i.e., a design where input shaft and output shaft are not connected. The functions *reachableOutgoing* () and *reachableIncoming* () are used to identify the sets of nodes that can be reached or are reachable from *shaft S0*. The RHS of the rule is defined within the *modify* statement. First, the *shaft S0* is deleted. Then, two rules are applied that remove dangling nodes in the graph. The first is called *deleteUnusedGears* and removes all gears that were connected to *shaft S0*, i.e., those gears that are mounted on *shaft S0*. The second is called *deleteUnusedGearPairsAndShafts*. It searches through the remaining graph to identify gear pairs and shafts that are not required any more since they are not connected to both input and output shaft of the gearbox to form a valid power flow path.

Figure 19. Rule 2 (*delete a shaft*) formulated using a negative application condition.

Figure 20. Rule 4 (*delete a gear pair*) formulated using a negative application condition.

Figure 21. Rule 2 (*delete a shaft*) formulated using a positive application condition.

Figure 22. Rule 4 (*delete a gear pair*) formulated using a positive application condition.

On the left in Figure 19, the two matches of rule 2 on the graph with UID 2 are shown. The *shaft S0* is matched to the same node, since it is the only node of type *shaft* in the graph. The two gears on the right power flow path through the gearbox can be matched to *gear G0* such that the negative application condition is not fulfilled and the rule can be applied to remove the *shaft S0* and the then dangling gear nodes to transform the design into that with UID 1.

Comparing the graphs with UID 2 and UID 1 (see Figure 8), the rule designer might expect that two matches of rule 4 (*delete a gear pair*) are found to delete either the first or the second gear pair of the left power flow path. The transition graph, however, shows that rule 4 is applied to eight different matches on the graph with UID 2 to transform it to the graph with UID 1. Figure 20 shows the rule formulation in GrGen for rule 4. The expression ‘*G0:Gear ?–? G1:Gear*’ indicates that two nodes of type *gear* have to exist and have to be connected by an edge. ‘?–?’ indicates that the direction of the edge connecting the two nodes is not relevant. The remainder of rule 4 is structured similarly to rule 2 and therefore not described here in detail. On the left of Figure 20, the eight matches of rule 4 on the design with UID 2 are shown that transform it to the design with UID 1.

When the human designer understands that rules are not matched as intended, e.g., more often than necessary, the LHS of the rules can be formulated more carefully. Figures 21 and 22 show how this can be done for rules 2 and 4, respectively. The LHSs are reduced to only contain the nodes that have to be removed. Instead of negative application conditions, positive application conditions are used (*independent* statement). The shaft (rule 2) or gear pair (rule 4) are removed from the graph when there is another gear that is neither reachable from the matched node(s), nor can it reach the matched node(s). In addition, the direction of the edge between gear *G0* and gear *G1* in rule 4 is specified to be directed from *G0* to *G1* (*G0*
$\rightarrow$
*G1*) to reduce ambiguity.

## Appendix C. Heuristics for the sliding tile puzzle

Two heuristics are used to steer the search space exploration for the sliding tile puzzle using the algorithm described in Appendix D. They are described in the following.

1. *Heuristic for region*.

Figure 23 (left) presents heuristics for which region to consider in the next iteration. The gray regions define, where the next modifications are performed. When the empty tile (indicated with ‘0’ in Figure 23) is in the top or bottom row, the top or bottom region are selected. When it is in the middle row, further heuristics can be applied or one region can be selected randomly. Given, e.g., the initial puzzle in Figure 15, the lower region is selected based on the heuristic for the region.

2. *Heuristic for patterns*.

The common human strategy to solve the sliding tile puzzle from the top is implemented by defining search patterns. The patterns are described as six character strings and define desirable tile positions giving the tile numbers and ‘*’ as a wildcard symbol. In Figure 23 (right) one example for a heuristic for patterns is given. It assumes that the lower region of the tile puzzle is considered and a tile with number ‘3’ is present in this lower region but no tiles with numbers ‘1’ or ‘2’ are present. The heuristic in Figure 23 (right) defines patterns to identify all puzzles with tile ‘3’ and the empty tile in the upper row of the selected region. This represents one part of the strategy commonly used by humans to move tiles that belong to the upper row (tiles ‘1’, ‘2’, ‘3’) into the middle row and then, in a next step when the upper region is considered, into the upper row, e.g., to replace the ‘5’ in the initial design in Figure 15.

Figure 23. Heuristics for defining regions of sub-problems (left) and search patterns (right).

## Appendix D. Details on the algorithm used to solve the 8-tile puzzle based on rule sequences learnt on the 5-tile puzzle

Figure 24. Process of gaining information on small scale (Step 1) and applying it to explore (Step 2) and solve larger-scale problems (Step 3).

The process to solve the 8-tile puzzle is presented in Figure 24. In Step 1, the transition graph is explored exhaustively for the small-scale puzzle and stored in the 5-tile library. This means all transformations between any 5-tile puzzles are known. In Step 2, the design space of the 8-tile puzzle is explored partially using a BFS approach. It is implemented using a queue. In each iteration the first element in the queue is considered as the current design (Step 2.1). The 8-tile puzzle is subdivided using the heuristic for the region (see Appendix C). The considered region is highlighted in gray in Figure 24. The tiles are then mapped from the 8-tile space to the 5-tile space. In this transformation, the tile numbers are mapped from the numbers
$\{0,1,2,3,4,5,6,7,8\}$
to the number
$\{0,1,2,3,4,5\}$
. The empty tile (number 0) remains in both spaces, the remaining numbers have to be mapped such that the mapped design constitutes a solvable design in the 5-tile space. The mapping for the example iteration shown in Figure 24 is, e.g., (5-tile space – 8-tile space): (1–4), (2–8), (3–3), (4–7), (5–6), (0–0). The same mapping is applied to the search patterns for promising designs that are defined using the pattern heuristic. In Step 2.2, for each pattern, all designs that match it are identified in the 5-tile library. In Figure 24, five example designs matching the heuristics for patterns (see Appendix C) are shown (30****, *03***, *30***, 03****, 3*0***), but many more are possible. The shortest paths, i.e., the rule sequences with the least rule applications, to these designs are identified using the 5-tile library. To avoid exploring an unnecessary large space of the 8-tile puzzle search space, for each pattern heuristic only the generated designs with the shortest rule sequences are considered further (Step 2.3). The considered designs are transformed back into the 8-tile space and are integrated into the larger-scale puzzle, i.e., the changed (gray) and unchanged (white) regions are combined (Step 2.4). For each explored design, a test is performed whether it was already found previously. If not, it is added to the end of the queue (Step 2.5). At the end of the iteration, the rule sequences leading from the first (currently considered) design in the queue to the designs that are now added to the queue are stored in the 8-tile library (Step 2.6). This means that the 8-tile library builds up information about the transition graph of the 8-tile space with the nodes representing puzzles and the edges representing rule sequences. This process is continued until the final design is found. As soon as it is found, the complete sequence to solve the 8-tile puzzle is generated (Step 3) by analyzing the 8-tile library, in which the generated designs in the 8-tile space and the sequences of rule applications to transform them are stored. As in Step 1, it is found by searching the shortest path using a BFS with backtracking with the only difference that instead of single rules, the transformations are sequences of rules.

## References

Aho, A. V., Lam, M. S., Sethi, R. & Ullman, J. D.
2006
Compilers: Principles, Techniques, and Tools. Addison-Wesley Longman Publishing Co., Inc.

Barbati, M., Bruno, G. & Genovese, A.
2012
Applications of agent-based models for optimization problems: a literature review. Expert Systems with Applications
39, 6020–6028.

Brown, K. N.
1997
Grammatical design. IEEE Expert/Intelligent Systems and Their Applications
12 (2), 27–33.

Cagan, J.
2001
Engineering shape grammars. In Formal Engineering Design Synthesis (ed. Antonsson, E. K. & Cagan, J.). Cambridge University Press.

Cagan, J., Campbell, M. I., Finger, S. & Tomiyama, T.
2005
A framework for computational design synthesis: model and applications. Journal of Computing and Information Science in Engineering
5, 171–181.

Cash, P., Stanković, T. & Štorga, M.
2014
Using visual information analysis to explore complex patterns in the activity of designers. Design Studies
35, 1–28.

Chakrabarti, A., Shea, K., Stone, R., Cagan, J., Campbell, M., Hernandez, N. V. & Wood, K. L.
2011
Computer-based design synthesis research: an overview. Journal of Computing and Information Science in Engineering
11, 021003,1–10.

Chomsky, N.
1957
Syntactic Structures. Mouton de Gruyter.

Fu, Z., Depennington, A. & Saia, A.
1993
A graph grammar approach to feature representation and transformation. International Journal of Computer Integrated Manufacturing
6, 137–151.

Geiß, R., Batz, G., Grund, D., Hack, S. & Szalkowski, A.
2006
GrGen: a fast spo-based graph rewriting tool. In Graph Transformations (ed. Corradini, A., Ehrig, H., Montanari, U., Ribeiro, L. & Rozenberg, G.). Springer.

Gips, J.1999. Computer implementation of shape grammars, *NFS/MIT Workshop on Shape Computation*.

Gmeiner, T. & Shea, K.
2013
A spatial grammar for the computational design synthesis of vise jaws. In International Design Engineering Technical Conferences and Computers and Information in Engineering Conference (ASME IDETC), Portland, OR, USA.

Helms, B., Eben, K., Shea, K. & Lindemann, U.
2009
Graph grammars – a formal method for dynamic structure transformation. In 11th International DSM Conference, Greenville, SC, USA.

Hoisl, F. & Shea, K.
2013
Three-dimensional labels: a unified approach to labels for a general spatial grammar interpreter. Artificial Intelligence for Engineering Design, Analysis and Manufacturing
27, 359–375.

Hoisl, F. R.2012. Visual, interactive 3D spatial grammars in CAD for computational design synthesis. Dissertation, Technische Universität München.

Johnson, W. W. & Story, W. E.
1879
Notes on the ‘15’ puzzle. American Journal of Mathematics
2, 397–404.

Kim, H. M., Michelena, N. F., Papalambros, P. Y. & Jiang, T.
2003
Target cascading in optimal system design. Journal of Mechanical Design
125, 474–480.

Königseder, C. & Shea, K.
2015
Comparing strategies for topologic and parametric rule application in automated computational design synthesis. Journal of Mechanical Design
138 (1), 011102-011101–011102-011112; doi:10.1115/1.4031714.
Kumar, M., Campbell, M. I., Königseder, C. & Shea, K.
2012
Rule based stochastic tree search. In Design Computing and Cognition ’12 (ed. Gero, J. S.). Springer.

Li, X. & Schmidt, L.
2004
Grammar-based designer assistance tool for epicyclic gear trains. Journal of Mechanical Design
126, 895–902.

Lin, Y. S., Shea, K., Johnson, A., Coultate, J. & Pears, J.
2010
A method and software tool for automated gearbox synthesis. In International Design Engineering Technical Conferences and Computers and Information in Engineering Conference (ASME IDETC), San Diego, CA, USA.

McKay, A., Chase, S., Shea, K. & Chau, H. H.
2012a
Spatial grammar implementation: from theory to useable software. Artificial Intelligence for Engineering Design, Analysis and Manufacturing
26, 143–159.

McKay, A., Chase, S., Shea, K. & Chau, H. H.
2012b
Spatial grammar implementation: from theory to useable software. Artificial Intelligence for Engineering Design, Analysis and Manufacturing
26, 143–159.

Mullins, S. & Rinderle, J.
1991
Grammatical approaches to engineering design, part I: an introduction and commentary. Research in Engineering Design
2, 121–135.

Pahl, G. & Beitz, W.
1984
Engineering Design. Springer.

Pólya, G.
1957
How to Solve it a New Aspect of Mathematical Method. Doubleday.

Pomrehn, L. P. & Papalambros, P. Y.
1995
Discrete optimal design formulations with-application to gear train design. Journal of Mechanical Design
117, 419–424.

Rinderle, J.
1991
Grammatical approaches to engineering design, part II: melding configuration and parametric design using attribute grammars. Research in Engineering Design
2, 137–146.

Schmidt, L. C. & Cagan, J.
1997
GGREADA: a graph grammar-based machine design algorithm. Research in Engineering Design
9, 195–213.

Schmidt, L. C., Shetty, H. & Chase, S. C.
2000
A graph grammar approach for structure synthesis of mechanisms. Journal of Mechanical Design
122, 371–376.

Slocum, J. & Sonneveld, D.
2006
The 15 Puzzle: How It Drove the World Crazy. The Puzzle that Started the Craze of 1880. How America’s Greatest Puzzle Designer, Sam Loyd, Fooled Everyone for 115 Years. Slocum Puzzle Foundation.

Starling, A. C.2004. Performance-based computational synthesis of parametric mechanical systems. Dissertation, University of Cambridge.

Starling, A. C. & Shea, K.
2005
A parallel grammar for simulation-driven mechanical design synthesis. In International Design Engineering Technical Conferences and Computers and Information in Engineering Conference (ASME IDETC), Long Beach, CA, USA.

Stiny, G.
1977
Ice-ray: a note on the generation of Chinese lattice designs. Environment and Planning B: Planning and Design
4, 89–98.

Stiny, G. & Gips, J.
1972
Shape grammars and the generative specification of painting and sculpture. In Proceedings of IFIP Congress 1971, 1972. North Holland Publishing Co.

Stiny, G. & Mitchell, W. J.
1978
The Palladian grammar. Environment and Planning B
5, 5–18.

Swantner, A. & Campbell, M. I.
2012
Topological and parametric optimization of gear trains. Engineering Optimization
44, 1351–1368.

Vale, C. A. W. & Shea, K.
2003
A machine learning-based approach to accelerating computational design synthesis. In International Conference on Engineering Design (ICED), Stockholm, Sweden.