To start an optimisation analysis go to the Simulation screen and click on the Optimisation tab. Calculations are updated using the Update toolbar icon in the usual way. The data on the Optimisation Calculation Dialog is used to provide options to control the optimisation analysis as well as outputs to help you to understand the progress being made as the calculations continue.
Note: It is necessary to run the base simulation with monthly/annual outputs before opening the optimisation tab. The optimisation simulations will all be run using the base calculation and model options.
The genetic algorithms (GA) used by DesignBuilder require a number of options to control the way that the solutions evolve.
Enter a description for the calculation. This text will be used to identify the results on the graph and any other related outputs.
The maximum number of generations to be used will determine the time/computing resources required to complete the analysis. The value entered here will usually reflect the complexity of the analysis. The default value for maximum generations is 200 and typical values are in the range 50-500. You can of course set a larger number at the beginning, and then manually terminate the search process when sufficient good solutions have been found.
Each generation will include at most this number of designs. The bigger the population size, the more different solutions may exist within the same generation. Larger population sizes may be required for problems containing 5 or more design variables. The default maximum population size is 15.
This option allows you to only display feasible solutions on the Pareto Front. Solutions failing one or constraint requirement are not included on the Pareto Front. This option applies to the graphic display of the Pareto Front only and does not affect the solution itself. The option can be changed during the simulation.
Checking this option shows on feasible solutions and hides all other solutions failing one or more constraint requirement.
The number of bits used to define each float (numeric) design variable value. The number of options this gives rise to can be calculated as 2n, where n is the encoding length. This value should normally be between 6 and 14. An encoding length of 10 for a float gives 1024 equally spaced samples within the specified range of the design variable. This in most cases will be adequate.
The number of bits used to define each list design variable value. The maximum number of options that this option can accommodate can be calculated as 2n,where n is the encoding length. For example a value of 6 allows up to 26 = 64 items per list. If you have less than 64 items in each variable list then a value of 6 should be a good choice here.
The “Tournament operator” is used in this implementation of Genetic Algorithm for selecting better solutions from the current generation. Tournament size means the size of a random sample taken in the current generation. From this random sample, the best solution will be selected for “reproduction”. Default value is 2.
This rate is in fact a relative probability (compared to individual mutation probability) of a new solution being created by crossover. For example, if the crossover rate is 1.0 and individual mutation probability is 0.5, there are 67% (1.0/1.5) of chance the new solution will be created by crossover, and 33% (0.5/1.5) of chance it will be created by mutation.The default value is 0.9. Typical range is 0.6-1.0
Check this option if you wish to override the default value of bitwise mutation probability. The defaults value is 1/nbits where nbits is the total of the number of bits in the chromosome calculated by summing the number of bits for each variable. For numeric variables the number of bits is the Encoding length for floats and for list variables the number of bits is the Encoding length for lists. The maximum default value is 0.1 and the minimum is 0.01.
If you choose to override the automatic calculation then the value can be entered here.
See crossover rate. Default is 1.0.
The lower and upper constraint margins are used as part of the constraint handling method used by DesignBuilder, which is based on a generic penalty function approach. During a constrained optimisation each design alternative is tested against any constraints applied and a penalty is generated based on whether the design is feasible or not, i.e. whether it meets constraint requirements. If the function value is within the feasible range then no penalty is applied and conversely if it is outside the feasible range then a penalty is applied. There is a margin between the feasible and the unfeasible regions where a linearly ramped penalty is applied. The upper and lower margins set on the Calculation options dialog are used to define these regions as shown on the graph below.
Some designs are considered invalid. For example in a controls analysis it is not normally allowed for heating setpoint temperature to be higher than cooling setpoint temperature. If a particular design variant has an invalid configuration then it is assigned a penalty using the maximum objective score (assuming objectives are being minimised). This applies evolutionary pressure to discourage similar invalid design variants from appearing in future generations.
When 2 objective functions are defined, the trade off for the range of design variables considered is displayed graphically on the scatter graph. The Pareto optimal solutions are displayed in red, current generation are shown in blue and previous generations are shown in dark grey.
When a single objective is used the graphical output shows the evolution of the objective function for each iteration. Because there is no trade off with single objective optimisation, only the single most optimal solution is highlighted in green in the grid.