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 Start date set up for the base simulation on the analysis screen is displayed but cannot be edited here.
The End date set up for the base simulation on the analysis screen is displayed but cannot be edited here.
The maximum number of generations to be used will determine the time and computing resources required to complete the analysis. The value entered here will usually reflect the size and complexity of the analysis. Typical values are in the range 50-500 depending on size of the problem, the population size and whether a Pareto archive is used.
Tip 1: Setting the right number of Maximum generations is not a crucial setting provided you use a large number such as 100 or more.
Tip 2: When seeking accurate optimal outputs and hence using a large value for Maximum generations it can be worth experimenting with higher mutation rates to help avoid early convergence.
This option is used to decide when to stop the optimisation simulations. As the optimisation process progresses and most optimum solutions have been identified, less and less new optimal solutions will be found and there comes a point when it's time to stop. At the end of each generation, DesignBuilder checks whether any new optimal solutions were found in the most recent Generations for convergence generations. If so, the simulations continue, otherwise the optimisation process is considered to be complete and results are displayed. It isn't generally possible to be sure that no new optimum solutions wouldn't be found if the optimisation process continued, but this setting offers a simple way to stop simulations once it seems that most have been identified.
The default is 5 generations. Enter a higher number to give you the best chance of finding all possible solutions, or enter a smaller number if you are less concerned about finding every possible optimum solution. Alternatively you can enter a very high number (e.g. same as Maximum generations) if you would like to control convergence manually by using the Stop button.
When using the JEA optimisation engine, this setting works in conjunction with the Max wall time and Max evaluations settings - whichever limit is reached first will cause the optimisation to stop.
Each generation will include at least 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 or where some variables have many options.
Tip: Initial population size will typically be between 10 and 50 depending on the size of the analysis. For 3 design variables with say 10 options each then choose an initial population size of between 10 and 20. For 10 variables, each with 10 options then choose a value between 20 and 50. Like other settings on this dialog the best values to use for fastest and most reliable convergence will come from experience. In the meantime a value of 20 will work well for most typical applications.
Note: All simulations for a generation must complete before the next generation is started so if you have many parallel cores at your disposal and the time taken to run the simulations is the main bottleneck in calculations (as opposed to IDF generation) then a higher number here can be helpful.
Note: There is no way to control the exact number of iterations that will be run since the optimiser controls the population size of each generation.
This option allows you to control the way that constrained optimisation result sets are displayed but does not affect the optimisation process itself. It is only available when one or more constraints are applied. The options are:
The Apply constraints to Pareto front selection can be changed during the simulation.
It is important to understand the cause of any errors that occur during an optimisation. The Pause on errors option, when checked, causes a message to be displayed and the optimisation is paused. For example if there is an overlap in heating and cooling setpoint temperatures, in configurations where the heating setpoint is higher than the cooling setpoint the following error message is displayed:
This sort of error does not cause a problem for the overall optimisation study. 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.
Once you are clear about the cause of any errors you will normally want to stop seeing reports and allow the optimisation to continue. To do this simply uncheck the Pause on errors check box. Simulations with errors are displayed in red in the grid as shown below.
Common causes of errors are:
Normally, if DesignBuilder is unable to access the requested Simulation Server, it will ask you whether you would like to Abort, Retry or Ignore the missing server. Selecting Abort cancels the whole analysis. Selecting Retry or Ignore instructs the software to keep trying. The latter option would be selected if the server became temporarily unavailable, perhaps due to a network error or because the server was down for a while.
However, if you are running a long analysis and you don't want to be prompted in this way due to a temporary glitch in the availability of your simulation server then you can check this option. This is similar to pre-selecting the retry or ignore options in advance.
Select the engine to use from the options:
The options for Open Beagle and JEA are different and are therefore explained in their respective sections below.
Options for Open Beagle
The options below are available when the Open Beagle optimisation engine is selected.
Check this option if the optimisation is to include a Pareto archive to feed previously identified "best so far" solutions into the population to encourage exploration around previously identified Pareto optimal designs. This option can help the solution to progress more quickly. On the other hand it can also lead to early convergence so some experimentation may be required to find the best setting for each new analysis.
Maximum population size
When using a Pareto archive, the population size (i.e. the number of iterations per generation) can grow as the optimisation progresses and more optimum solutions are added to the archive. In this case the Maximum population size defines an upper limit on the population size of each generation. This value should be higher than the Initial population size. The default maximum population size is 50 which typically works well with the default Initial population size of 20.
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 5 and 10. An encoding length of 10 for a float gives 1024 equally spaced samples within the specified range of the design variable. In most cases a value of 6 (the default) will be adequate giving 64 samples.
The interval size is calculated as (objective max value - objective min value) / (2n - 1).
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) chance that the new solution will be created by crossover, and 33% (0.5/1.5) chance it will be created by mutation. The default value is 1.0. Typical range is 0.6-1.0
It is important to avoid "premature convergence" where the optimisation settles on a Pareto front which is incomplete or inaccurate. The Individual mutation probability helps to maintain diversity in the population to ensure that the parameter space is fully explored which in turn helps to avoid premature convergence and missing the full set of optimal solutions.
Low values of Individual mutation probability (e.g. 0.2) can help to avoid wasting time exploring non-optimal parts of the parameter space which leads to fast convergence; however the results may not be as accurate as when using higher values. DesignBuilder uses a balanced default of 0.5.
See also Crossover rate.
Check this option if you wish to override the default value of bitwise mutation probability. The default 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.5 and the minimum is 0.01.
Bitwise mutation probability
If you choose to override the automatic calculation then the value can be entered here.
Options for JEA
The options below are available when the JEA optimisation engine is selected.
The number of solutions to be evaluated in each iteration. More design variables requires larger population size in general. The choice is also influenced by the number of processor cores you have for running these simulations.
The number of solutions to be included in each generation is likely to increase as the Pareto archive builds up. This is the maximum number of solutions to be included in any one generation.
Crossover is a genetic operator used to combine the genetic information of two parents to generate new offspring. It is one way to stochastically generate new solutions from an existing population, and analogous to the crossover that happens during sexual reproduction in biology. JEA uses a "hybrid integer" crossover method. The crossover rate defines how often the new solutions are created by merging features of existing solutions. A high value of 1.0 is normally used.
This setting defines how often random changes are applied to new solutions. A lower value is preferred for fast convergence and to avoid the algorithm behaving like a random trial and error. On the other hand it is important to avoid "premature convergence" where the optimisation settles on a Pareto front which is incomplete or inaccurate. Mutation helps to maintain diversity in the population to ensure that the parameter space is fully explored which in turn helps to avoid premature convergence and missing the full set of optimal solutions.
Low values of mutation rate (e.g. 0.2) can be used to avoid wasting time exploring non-optimal parts of the parameter space which leads to fast convergence; however the results may not be as accurate as when using higher values. DesignBuilder uses a balanced default of 0.4.
Tournament selection involves running several "tournaments" among a few individuals chosen at random from the population. The winner of each tournament (the one with the best fitness) is selected for crossover. With larger tournament sizes, weak individuals have a smaller chance to be selected, because, if a weak individual is selected to be in a tournament, there is a higher probability that a stronger individual is also in that tournament. In other words, the larger the tournament size, the harder the algorithm pushes towards the desired objectives. A tournament size of 1 is equivalent to random selection. A tournament size of 2 is normally a good balance.
This setting controls the level of the push for feasibility, i.e. meeting any constraints applied. It controls the ranking bias between Pareto ranking and constraint infeasibility scores. A value of zero means solutions with lower infeasibility score is better, regardless of the Pareto ranking result.
Enter the maximum number of iterations you want the optimisation to run for. If the optimisations are still running after the number of iterations entered here they will be considered to be completed. This limit works in conjunction with the Generations for convergence and Max wall time settings - whichever limit is reached first will cause the optimisation to stop. If you don't want optimisations to be limited by number of iterations then you should enter a large number here such as 50,000.
Enter the time limit in hours for the optimisation to run. If the optimisations are still running after the duration entered here they will be considered to be completed. This limit works in conjunction with the Generations for convergence and Max evaluations settings - whichever limit is reached first will cause the optimisation to stop. If you don't want optimisations to be limited by time then you should enter a large number here, such as 240 (10 days).
Normally results for each simulation are held within the Simulation Manager system only for as long as required and are deleted once the key results have been loaded into DesignBuilder. However, if you require results for each simulation to be retained within the Simulation Manager system then check this checkbox.
An important and often overlooked consideration is the impact of the time taken by DesignBuilder to generate the IDF input file for each design. The longer this is relative to simulation time the greater the model generation bottleneck and the less useful the large number of parallel simulations. On the other hand, the larger and more complex the model and the more detailed the simulations (nat vent, detailed HVAC, more time steps etc) the more time is taken in simulation and relatively less in IDF generation. For an extremely large/complex model, all IDF inputs will have been generated before the first results are in and the large number of parallel simulations will speed progress. For a smaller model, the IDF generation bottleneck is often more significant and first simulation results will be in before the 3rd or 4th IDF input has been generated and in this case the multiple cores will not be needed. This is often the case for simple single zone models. To test and understand this watch the Simulation Manager while the optimisation takes place. You will see new jobs being submitted, queued and simulated.
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.