Service overview
Single and multi-objective, metaheuristic, Bayesian and topology optimisation; decision models. This service is part of that division and is scoped individually around what you need to learn, decide or publish.
Genetic algorithms are search methods inspired by natural selection. A population of candidate designs is evaluated, the better ones are selected, combined and slightly mutated to produce the next generation, and the process repeats. Because they use only objective values and not gradients, they cope with discontinuities, discrete choices and noisy objectives that stop gradient-based methods.
That flexibility has a price: many evaluations, several parameters to tune and no guarantee of optimality. Genetic algorithms are best seen as robust general-purpose heuristics for problems that are hard for other approaches, such as layout, scheduling and mixed-variable design. Used with attention to encoding, constraint handling and repeated runs, they can be effective. Used by default, they are often an expensive way to solve problems that simpler methods solve better.
If you plan to publish the outcome, see manuscript & publication support, for example computational & simulation manuscripts or original research article writing.
What this service covers
Problems this service can address
- Premature convergence to poor solutions
- Algorithm parameters chosen without justification
- Results that cannot be reproduced due to randomness
Methods and analytical approaches
- Encoding, selection, crossover and mutation design
- Parameter tuning and repeated-run statistics
- Constraint-handling strategies
- Comparison with alternative algorithms
Applications
- Layout and scheduling problems
- Parameter identification
- Design optimisation with discrete choices
Relevant engineering disciplines
Scope, inputs and deliverables
Scope of work
- Data audit and definition of the prediction or decision task
- Model development with structure-aware validation and baselines
- Evaluation, error analysis and uncertainty reporting
- Documentation sufficient for others to reproduce the work
- Feasibility check on: problem definition and evaluation function
Typical inputs required from you
- Problem definition and evaluation function
- Variable types and ranges
- Computational budget
Deliverables
- Algorithm configuration and statistics over repeated runs
- Convergence plots
- Best solutions with sensitivity notes
Highly specialised requests are first checked for feasibility from this information. Please do not send confidential data through the public form; describe it first and agree secure transfer afterwards.
Project workflow and method
- 01Enquiry and requirement assessment
- 02Technical scoping and proposal
- 03Execution
- 04Quality review and delivery, with an agreed round of revisions
Read the full project workflow.
In depth: how the work is done
Encoding and problem representation
How a design is encoded as a chromosome shapes the search. Binary, integer, real-valued and permutation encodings suit different problems, for instance permutations for ordering and scheduling. Good encodings make feasible designs easy to represent and keep related designs close together so that crossover and mutation produce meaningful variations. Poor encodings create many infeasible offspring or destroy good building blocks.
Selection, crossover and mutation
Selection pressure determines how strongly better individuals are favoured. Too much leads to premature convergence on a mediocre solution; too little makes the search slow. Crossover recombines parents, with operators that suit the encoding, while mutation maintains diversity and explores new regions. Elitism preserves the best solutions. Rates and operators interact, and we choose them in light of the problem and test their influence.
Parameter tuning and repeated-run statistics
Because the algorithm is stochastic, a single run proves little. We perform multiple independent runs with different random seeds, report distributions of the best objective, the number of evaluations to reach target quality and the success rate. Parameter tuning uses designed experiments or tuning frameworks rather than ad hoc trial and error. Statistical tests compare configurations and algorithms so that claims of improvement are supported.
Constraint handling
Constraints can be handled by penalty functions, repair operators, feasibility-first selection rules or specialised encodings that guarantee feasibility. Penalty weights strongly influence behaviour and need care. Where feasible regions are small, techniques that maintain feasibility during search are more efficient. We document the strategy and its sensitivity because constraint handling often matters more than the other algorithmic choices.
Comparison with alternative algorithms
Claims that a genetic algorithm is suitable should be supported by comparison with alternatives such as local search, simulated annealing, particle swarm or gradient-based methods with multiple starts, on the same evaluation budget. For problems amenable to mathematical programming, exact methods may find provable optima faster. We state when the alternative is better and when the genetic algorithm's flexibility is worth its cost.
Reporting a genetic algorithm study so it can be reproduced
Reproducible reporting lists the encoding, population size, selection scheme, crossover and mutation operators with their rates, elitism, termination criteria, constraint handling and the random-number generator and seed policy. It also states how many independent runs were made and how the best, mean and spread of results are reported. Convergence plots across runs, not only the best run, show whether the algorithm is reliable. These details allow others to repeat the study and compare their own algorithms fairly.
Choosing evaluation budgets fairly
Comparisons between optimisers should use the same number of function evaluations, not the same number of generations, because population sizes differ. When each evaluation is an expensive simulation, the budget is a central design constraint, and surrogate-assisted variants may be justified. Reporting the budget, run time and hardware lets readers judge whether differences between methods are practical.
Quality control and good practice
Quality-control approach
- Data are audited for quality, leakage and drift before modelling.
- Validation respects data structure (by specimen, machine or time) and includes simple baselines.
- Performance is reported with uncertainty and failure cases, not only headline scores.
- Model limits and the conditions under which it should not be trusted are documented.
Common pitfalls this service helps avoid
- Reporting one run. Results from a single random seed cannot support conclusions about an algorithm's performance.
- Premature convergence. High selection pressure or low diversity can trap the population in poor regions.
- Heavy penalties. Badly chosen penalty weights can make feasible regions unreachable or constraints ineffective.
- Neglecting alternatives. Simpler or exact methods may solve the problem better and faster.
What good reporting looks like
A genetic algorithm study states the problem and encoding, operators and parameter settings with the tuning procedure, constraint handling, the evaluation budget, convergence histories and results from repeated runs with statistics, comparison with alternative methods under equal budgets, the best solutions found and their verification, and limitations. It makes clear that the method is heuristic and does not claim global optimality.
An illustrative scenario
Hypothetical example written for explanation. It is not a client case, a result or a testimonial.
Imagine a researcher laying out equipment in a plant to minimise piping length subject to spacing and safety constraints. A permutation-based genetic algorithm is run thirty times with different seeds, and the distribution of final costs shows that most runs reach similar layouts. Comparison with simulated annealing on the same budget shows comparable results, with a slightly lower variance for the genetic algorithm. The report presents both and notes that the constraint-handling method strongly affected the number of feasible layouts found.
Questions to settle before you begin
- How should my design be encoded?
- How many evaluations can I afford?
- How will I handle constraints?
- Which alternative algorithm should I compare against?
- How many independent runs will support my conclusions?
Key terms
- Chromosome
- The encoded representation of a candidate solution.
- Crossover
- An operation combining parts of two parents to create offspring.
- Mutation
- A random modification of a solution to maintain diversity.
- Elitism
- Carrying the best solutions unchanged into the next generation.
- Premature convergence
- Loss of diversity before good regions are found.
Working together on Engineering Optimisation & Decision Science projects
Optimisation engagements begin with formulation: objectives, decision variables, constraints and the model or experiment used to evaluate designs. Much of the value is created at this stage, because poorly posed problems give unusable optima. We ask for the evaluation model or data, bounds on variables, constraints and any manufacturing or operational limits. Algorithms are chosen to suit evaluation cost and problem structure, and results are checked against independent evaluations and robustness tests. Reports present trade-offs rather than a single answer where objectives conflict, and they state assumptions behind the model that an optimiser could exploit.
Frequently asked questions
Is a genetic algorithm always the right choice?
No. For smooth problems, gradient-based methods are often far more efficient. We recommend the method on technical merit.
Is a genetic algorithm the right choice for my problem?
It may be if the problem is discontinuous, discrete or multimodal. A comparison with simpler methods will indicate whether it is justified.
How many evaluations does it need?
Typically thousands or more. Surrogates can reduce the cost when evaluation is expensive.
Can you tune the parameters for me?
Yes. Tuning with a systematic procedure and repeated runs is part of the service.
Can you provide the code?
Implementation details can be provided so the work is reproducible. The language and library will be agreed.
How is this service scoped and priced?
After your enquiry we review what you need, ask for missing information and send a written scope and quotation. Price depends on complexity, deliverables and timeline. See the project workflow.