[TASK] Improved seeding for optimization algorithm #2537
Description
Issue Description
Is your feature request related to a problem? Please describe.
The optimization process can be accelerated with the option of providing a starting seed compared to starting with a truly random population of initial solutions. In the latter case, the first many iterations of the optimizer are often spent narrowing the search of the input space to the general vicinity of the global minimum. If a relatively optimal solution is provided as an initial seed, this initial search of the input space is naturally skipped. This approach is most impactful for highly constrained optimization problems, and is least effective when a poor initial seed is given (either poorly performing or close to a local minimum).
There are two common approaches to employing a user-provided initial seed. 1) the seed is duplicated until the population size is reached, or 2) the seed is added and the rest of the population is filled with random solutions. Both of these lead to a very poor initial search of the input space and no acceleration is accomplished.
Describe the solution you'd like
RAVEN should support a sampling method that takes a user-provided initial seed or seeds and fills the rest of the population with perturbed variations. To ensure that the randomly perturbed variations on the seed fall within a reasonable area around the provided seed(s), the minimum Euclidean distance of each new solution from the initial seed(s) should be constrained.
Describe alternatives you've considered
For sampling variables with a non-numerical or discrete distribution, the Euclidean distance is not a meaningful metric. In this case, another common metric for population diversity can be used and likewise constrained, such as the Hamming distance or Cayley distance.
For Change Control Board: Issue Review
This review should occur before any development is performed as a response to this issue.
- 1. Is it tagged with a type: defect or task?
- 2. Is it tagged with a priority: critical, normal or minor?
- 3. If it will impact requirements or requirements tests, is it tagged with requirements?
- 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
- 5. Is a rationale provided? (Such as explaining why the improvement is needed or why current code is wrong.)
For Change Control Board: Issue Closure
This review should occur when the issue is imminently going to be closed.
- 1. If the issue is a defect, is the defect fixed?
- 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
- 3. If the issue can impact users, has an email to the users group been written (the email should specify if the defect impacts stable or master)?
- 4. If the issue is a defect, does it impact the latest release branch? If yes, is there any issue tagged with release (create if needed)?
- 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?