Info iconThis preview shows pages 1–2. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: 25.2 Architecture 441 25.1.3 Separation of Concerns An optimization system consists not only of the optimization algorithms themselves. It needs interfaces to simulators. If it is distributed, there must be a communication subsystem. Even if the optimization system is not distributed, we will most likely make use of parallelism since the processors inside of nowadays off-the-shelf PCs already offer supportive hyper-threading or dual-core technology [570, 1891]. If Sigoa is utilized by multiple other software systems which transfer optimization tasks to it, security issues arise. These aspects are orthogonal to the mathematical task of optimizing and should therefore be specified at different places and clearly be separated from the pure algorithms. Best practice commands to already consider such aspects in the earliest software design phase of every project and thus, also in the Sigoa library. 25.1.4 Support for Pluggable Simulations and Introspection In most real-world scenarios, simulations are needed to evaluate the objective values of the solution candidates. If we use the framework for multiple problem domains, we will need to exchange these simulations or even want to rely on external modules. In some cases, the value of an objective function is an aggregate of everything what happened during the simulation. Therefore, they need a clear insight into what is going. Since we separate the objective functions from the simulations by clearly specified interfaces (as discussed in Section 25.1.3 ), these interfaces need to provide this required functionality of introspection. In the use case of evolving a distributed algorithm, we can visualize the combination with the separation of concerns and introspective simulations: Besides working correctly, a distributed algorithm should use as few messages as possible or at least has stable demands considering the bandwidth on the communication channel. We therefore could write an objective function which inspects the number of messages underway in the simulation and computes a long-term average and variance. The simulation itself then does not need to be aware of that; it simple has to offer the functionality of counting the messages currently in transmission. The catch is that we can now replace the objective function by another one that maybe puts the pressure a little bit differently, leading to better results, without modifying the simulation. On the other hand, we can also use different simulation models – for example one where transmission errors can occur and one where this is not the case – without touching the objective function. 25.1.5 Distribution utilities As already said, there are many applications where the simulations are very complicated and therefore, our architecture should allow us to distribute the arising workload to a network of many computers. The optimization process then can run significantly faster because many optimization techniques (especially evolutionary algorithms) are very suitable for parallel...
View Full Document

This document was uploaded on 08/10/2011.

Page1 / 20


This preview shows document pages 1 - 2. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online