- 上一篇：噪音工程齿轮模型英文文献和中文翻译
- 下一篇：使用基因算法来减少齿轮振动英文文献和中文翻译
architectures. An example is the integrated circuit design application of Cohoon et al. (1991), where each subpopulation (environment) is allowed to evolve independently for a number of generations (an epoch), after which a ‘natural catastrophe’ causes genetic material to move between subpopulations, followed by another epoch Automated optimal design of a two-stage helical gear reducer 431
of isolated evolution, etc. Multiple epochs separated by catastrophes can be seen in single population implementations too—see, as an example, the GA of Hamada et al. (2001), where the catastrophe is represented by a steep increase in mutation rates.
Indeed, a single-population, multi-epoch framework defines the structure of our proposed search strategy too. We depart, however, from the previously mentioned heuristics in the way we control the evolution of the population within each of two distinct types of epoch (or phase). In the first, the population is only subjected to the selective (evolutionary) pressure of the constraints. The epoch concludes when a sufficient number of feasible inpiduals has been
generated—this is one of the run-time parameters of the heuristic. Typically this threshold value is set to around 40% of the population—clearly, this value controls the balance between feasibility and persity. The next epoch then sees most of the control of the selective pressure relinquished to the objective function itself; at this stage, the algorithm works like a standard GA, which penalises constraint violations in the conventional manner. Upon registering a drop in the feasibility percentage of the population below a certain threshold value, the algorithm reverts once more to the constraint-led mode of operation for the next epoch and so it proceeds until some termination condition is met (typically,
the objective value of the fittest inpidual reaches a pre-set threshold).
As noted before, this novel constraint-handling mechanism
is the result of our efforts to solve a problem subject to a very high number of constraints. We shall review the constraints of our reducer design problem shortly, but first let us consider the ‘genotype’, or the set of design variables, that defines the two-stage reducer.
3 The ‘genotype’ of the two-stage reducer
The class of reducers we are considering here (see Fig. 1 for an example) is highly standardised, both in terms of the design of their gearings and bearings and in terms of their layout. The set of 18 design variables that define the reducer unequivocally (see Table 1) reflects this, with standardisation imposing discrete value sets on most of them.
Nevertheless, the resulting design space is still vast. Assuming a discretisation of the few continuous variables into 25 steps, we could obtain a number of possible reducer designs of the order 4 × 1026 (it is notoriously hard to gain an intuitive ‘feel’ for such numbers, but it is worth considering that this is comparable to the number of atoms in about eight kilograms of C-12!).
Two conclusions can be drawn from here. Firstly, it is clear that, although the computational cost of evaluating the objective function and the constraints for a given design is
Fig. 1 Sketch of the two-stage reducer
quite low (less than a second per design), an exhaustive (full factorial) search of the design space is not feasible. Secondly, of all the search heuristics one could consider using instead, population-based evolutionary algorithms appear to be the most suitable, reinforcing the observation we made earlier regarding the popularity of such approaches in the transmission design literature.
4 A highly constrained design space
This is probably a good time to turn our attention to the constraints of our design problem, which, as hinted earlier, constitute the key challenge of this class of problems in general and of optimizing the structural elements of the reducer shown in Fig. 1 in particular. As it will become apparent, they are all of the inequality type, mostly involving geometrical or structural considerations. There are a total of 77 constraints, which we have organized into 24 groups (e.g., the same type of constraint applied to all four gears constitutes one group, though it is actually implemented as four