–1–
MOVI 1.0
SOFTWARE PACKAGE
USER’S MANUAL
HEAD OF THE PROJECT:
PROFESSOR R.B.STATNIKOV
AUTHORS:
J.B.MATUSOV
A.R.STATNIKOV
R.B.STATNIKOV
I.V. YANUSHKEVICH
MOSCOW 2001
–2–
ABSTRACT
The MOVI 1.0 (Multicriteria Optimization and Vector Identification) software
package was designed to apply the Parameter Space Investigation (PSI) Method to
engineering problems. Using MOVI 1.0, one can utilize the entire potential of the PSI
method without assistance. MOVI 1.0 enables the user to employ a mathematical
model developed according to the simple rules described in the User's Manual.
Thus, MOVI 1.0 can be configured for solving various engineering optimization
problems, including the investigation of mechanical systems described in terms of
the finite element method in particular.
MOVI 1.0 allows up to 51 design variables in the problems. By an additional
agreement between the authors of MOVI 1.0 and the user, the latter can be supplied
with an LP sequences code that allows the dimension of the design variable vectors
to be increased to 350.
The "Educational" version limits the number of design variables to eight. The
number of criteria to be optimized is limited only by the computer's processing
power. The number of criteria reached many dozens when we solved real problems.
The MOVI 1.0 installation set includes a CD with installation software and a
User's Manual.
MOVI 1.0 is a very simple and user-friendly program. An extensive Help
system covers all menu items and available options and, along with information on
program operation, provides information on the PSI method. The User's Manual
contains a detailed description of how to use the software, as well as theoretical
fundamentals of the PSI method. The MOVI 1.0 software package combines
theoretical knowledge with a practical user's manual, thus representing a unique and
unprecedented tool for researchers.
MOVI 1.0 was built using the Delphi 5 visual programming environment and
InterBase 6.0 SQL Server.
–3–
CONTENTS
ABSTRACT _______________________________________________________________ 2
CONTENTS_______________________________________________________________ 3
1. THE PARAMETER SPACE INVESTIGATION METHOD: A NEW APPROACH
TO SOLVING OPTIMIZATION PROBLEMS IN ENGINEERING________________ 7
2. NOTATION AND DEFINITIONS __________________________________________ 8
3. STATEMENT AND SOLUTION OF MULTICRITERIA OPTIMIZATION
PROBLEMS ______________________________________________________________ 9
3.1. SOME FEATURES OF THE ENGINEERING OPTIMIZATION PROBLEMS _______________ 9
3.2. FORMULATION OF MULTICRITERIA OPTIMIZATION PROBLEMS _________________ 10
3.3. SYSTEMATIC SEARCH IN MULTIDIMENSIONAL DOMAINS USING UNIFORMLY
DISTRIBUTED SEQUENCES ___________________________________________________ 11
3.4. THE PARAMETER SPACE INVESTIGATION METHOD IS A TOOL FOR FORMULATING AND
SOLVING ENGINEERING OPTIMIZATION PROBLEMS ______________________________ 12
3.5. PROBLEMS OF VECTOR IDENTIFICATION AND OPERATIONAL DEVELOPMENT OF
PROTOTYPES______________________________________________________________ 17
3.6. THE REQUIRED NUMBER OF TRIALS _______________________________________ 17
4. GENERAL DESCRIPTION OF THE MOVI 1.0 SOFTWARE PACKAGE _______ 19
4.1. UNIT I: ENTERING NEW DATA ____________________________________________ 20
4.1.1. PURPOSE ____________________________________________________________ 20
4.1.2. DESCRIPTION _________________________________________________________ 20
4.2. UNIT II: PROBING THE PARAMETER SPACE __________________________________ 21
4.2.1. PURPOSE ____________________________________________________________ 21
4.2.2. DESCRIPTION _________________________________________________________ 21
4.3. UNIT III: CHECK FOR THE FULFILLMENT OF FUNCTIONAL CONSTRAINTS _________ 21
4.3.1. PURPOSE ____________________________________________________________ 21
4.3.2. DESCRIPTION _________________________________________________________ 21
4.4. UNIT IV: EVALUATION OF CRITERIA _______________________________________ 22
4.4.1. PURPOSE ____________________________________________________________ 22
4.4.2. DESCRIPTION _________________________________________________________ 23
4.5. UNIT V: COMPILING THE TEST TABLE ______________________________________ 23
4.5.1. PURPOSE ____________________________________________________________ 23
–4–
4.5.2. DESCRIPTION _________________________________________________________ 23
4.6. UNIT VI: DEFINITION OF CRITERIA CONSTRAINTS. GENERATION OF A FEASIBLE SET 23
4.6.1. PURPOSE ____________________________________________________________ 23
4.6.2. DESCRIPTION _________________________________________________________ 24
4.6.2.1. Dialogue 1 _________________________________________________________ 24
4.6.2.2. Dialogue 2 _________________________________________________________ 24
4.6.2.3. Dialogue 3 _________________________________________________________ 25
4.6.3. TRUNCATED TEST TABLES _______________________________________________ 26
4.6.4. CHOICE OF THE ALGORITHM _____________________________________________ 26
4.6.5. TABLE OF CRITERIA FAILURES ____________________________________________ 27
4.6.6. ANALYSIS OF THE FEASIBLE SET __________________________________________ 27
4.7. UNIT VII: GENERATION OF THE PARETO OPTIMAL SET ________________________ 28
4.7.1. PURPOSE ____________________________________________________________ 28
4.7.2. DESCRIPTION _________________________________________________________ 28
4.8. UNIT VIII: ANALYZING THE RESULTS. CONSTRUCTING TABLES OF RESULTS,
HISTOGRAMS, AND GRAPHS __________________________________________________ 28
4.8.1. PURPOSE ____________________________________________________________ 28
4.8.2. DESCRIPTION _________________________________________________________ 28
4.9. UNIT IX: DETERMINING THE BEST SOLUTION ________________________________ 29
4.9.1. PURPOSE ____________________________________________________________ 29
4.9.2. DESCRIPTION _________________________________________________________ 30
5. EXAMPLE_____________________________________________________________ 31
6. SYSTEM REQUIREMENTS _____________________________________________ 36
7. CONTENTS OF THE DISTRIBUTION PACKAGE __________________________ 36
8. INSTALLING THE MOVI 1.0 SOFTWARE PACKAGE AND GETTING
STARTED _______________________________________________________________ 37
8.1. INSTALLING THE MOVI 1.0 SOFTWARE PACKAGE ____________________________ 37
8.2. ADDING THE “OSCILLATOR” AND “OSCILLATOR 1” TEST PROBLEMS _____________ 37
8.2.1. ADDING THE “OSCILLATOR” PROBLEM _____________________________________ 37
8.2.2. ADDING THE “OSCILLATOR 1” PROBLEM ____________________________________ 38
8.3. HOW TO START THE MOVI 1.0 PROGRAM __________________________________ 38
8.4. UNINSTALLATION ______________________________________________________ 38
9. INTERFACE LIBRARY DEVELOPMENT MANUAL _______________________ 39
9.1. PURPOSE OF THE INTERFACE LIBRARY: PRELIMINARY INFORMATION ____________ 39
9.2. INTERFACE LIBRARY DEVELOPMENT_______________________________________ 39
9.3. INTERFACE LIBRARY EXAMPLE ___________________________________________ 41
–5–
10. DATABASE MANAGER USER'S MANUAL _______________________________ 44
10.1. PURPOSE ____________________________________________________________ 44
10.2. STARTING THE PROGRAM AND DESCRIPTION OF THE INTERFACE _______________ 44
10.3. EDITING THE PROBLEM NAME, FOLDER, AND INTERFACE LIBRARY _____________ 44
10.4. DATABASE INTEGRITY CHECK ___________________________________________ 45
10.5. ADDING AND DELETING A PROBLEM ______________________________________ 46
11. MOVI 1.0 OPERATION ________________________________________________ 48
11.1. MAIN MENU ITEM DATA INPUT ________________________________________ 49
11.1.1. EMBEDDED MENU ITEM NEW TASK _____________________________________ 49
11.1.1.1. DESIGN VARIABLES Page __________________________________________ 51
11.1.1.2. FUNCTIONAL CONSTRAINTS Page __________________________________ 52
11.1.1.3. CRITERIA Page ___________________________________________________ 53
11.1.2. EMBEDDED MENU ITEM LOAD TASK ____________________________________ 53
11.1.3. EMBEDDED MENU ITEM EDIT TASK _____________________________________ 54
11.2. MAIN MENU ITEM CHECK OF PRIMARY CONSTRAINTS _________________ 54
11.3. MAIN MENU ITEM TEST TABLES _______________________________________ 55
11.3.1. EMBEDDED MENU ITEM TEST TABLE I ___________________________________ 56
11.3.2. EMBEDDED MENU ITEM TEST TABLE II __________________________________ 61
11.4. MAIN MENU ITEM TABLES _____________________________________________ 64
11.4.1. EMBEDDED MENU ITEM TABLE OF FUNCTIONAL FAILURES _______________ 64
11.4.2. EMBEDDED MENU ITEM TABLE OF CRITERIA FAILURES __________________ 65
11.4.3. EMBEDDED MENU ITEM TABLE OF CRITERIA ____________________________ 66
11.4.4. EMBEDDED MENU ITEM TABLE OF DESIGNS _____________________________ 67
11.5. MAIN MENU ITEM HISTOGRAMS AND GRAPHS _________________________ 68
11.5.1. EMBEDDED MENU ITEM HISTOGRAMS __________________________________ 68
11.5.2. EMBEDDED MENU ITEM GRAPHS _______________________________________ 68
11.5.3. SAVING GRAPHS _____________________________________________________ 74
11.6. MAIN MENU ITEM PERFORM ONE TEST ________________________________ 74
11.7. MAIN MENU ITEM COMBINE SOLUTIONS _______________________________ 76
11.8. MAIN MENU ITEM SERVICE ____________________________________________ 77
11.9. PRINTING REPORTS ____________________________________________________ 78
12. EXERCISES __________________________________________________________ 80
12.1. EXERCISE A. CONSTRUCTION OF A FULL TEST TABLE (TEST TABLE I). DIALOGUES
WITH THE COMPUTER. TRUNCATED TEST TABLE. TABLE OF CRITERIA FAILURES _______ 82
12.1.1. EXAMPLE 1. _________________________________________________________ 88
12.1.2. EXAMPLE 2. EXTENSION OF THE TRUNCATED TABLE __________________________ 89
12.2. EXERCISE В. TRUNCATED TEST TABLE. TABLE OF FUNCTIONAL FAILURES. TEST
TABLE II ________________________________________________________________ 91
12.2.1. TABLE OF FUNCTIONAL FAILURES ________________________________________ 91
12.2.2. TEST TABLE II _____________________________________________________ 93
12.3. EXERCISE С. ANALYSIS OF TABLES OF CRITERIA AND DESIGN VARIABLES.
HISTOGRAMS. GRAPHS OF CRITERIA VERSUS DESIGN VARIABLES __________________ 96
12.3.1. ANALYSIS OF THE TABLE OF CRITERIA _____________________________________ 97
–6–
12.3.2. ANALYSIS OF THE TABLE OF DESIGN VARIABLES. _____________________________ 97
12.3.3. HISTOGRAMS ________________________________________________________ 98
12.3.4. CRITERION VERSUS DESIGN VARIABLE I GRAPHS ______________________ 99
12.3.5. CRITERION VERSUS DESIGN VARIABLE II GRAPHS ____________________ 102
12.4. EXERCISE D. CONSTRUCTION OF THE COMBINED FEASIBLE AND PARETO OPTIMAL
SETS. THE MENU ITEM COMBINE SOLUTIONS _______________________________ 103
12.4.1. CASE А ___________________________________________________________ 103
12.4.2. CASE В____________________________________________________________ 105
APPENDIX A. EXAMPLES OF POINTS OF THE LP SEQUENCE _____________ 108
APPENDIX B. PROBLEM FILES __________________________________________ 109
B.1. STRUCTURE OF THE PROBLEM’S DATABASE ________________________________ 109
B.2. CFG TABLE__________________________________________________________ 110
B.3. PRM TABLE _________________________________________________________ 111
B.4. FUNCS TABLE _______________________________________________________ 112
B.5. CRITS TABLE ________________________________________________________ 112
B.6. FR TABLE ___________________________________________________________ 112
B.7. СR TABLE ___________________________________________________________ 113
B.8. FIRSTCRBOUND TABLE ______________________________________________ 113
B.9. CRITTAB TABLE _____________________________________________________ 114
B.10. CUTTED TABLE ____________________________________________________ 114
B.11. TMPTAB TABLE ____________________________________________________ 114
B.12. FPRM AND PAR TABLES ______________________________________________ 115
B.13. DISKR TABLE ______________________________________________________ 115
B.14. OTHER TYPES OF FILES THAT CAN BE GENERATED ________________________ 115
REFERENCES __________________________________________________________ 116
–7–
1. THE PARAMETER SPACE INVESTIGATION METHOD: A
NEW APPROACH TO SOLVING OPTIMIZATION PROBLEMS
IN ENGINEERING
1. Engineering optimization problems, including design problems, are
essentially multicriteria ones. The designer of a machine, a mechanism, or a
structure encounters a lot of contradictory performance criteria, such as material
demand, strength, expected life, vibration and noise levels, power demand,
productivity, efficiency, dimensions, and economic factors. The nature of these
problems is such that improving some of the criteria leads, as a rule, to the
deterioration of others.
In general, it is impossible to reduce multicriteria problems to single-criterion
ones.
The experience gained in solving engineering optimization and optimal design
problems shows that the expert cannot state a problem correctly. Unfortunately, the
known optimization techniques are only of slender assistance.
2. For the correct statement and solution of engineering optimization problems
a unique method called PARAMETER SPACE INVESTIGATION (PSI method) has
been developed and widely integrated into various fields of industry, science, and
technology.
The PSI method takes into account the features of problems from the class
under consideration and allows one to obtain optimal solutions for any number of
performance criteria.
3. In solving practical problems, it is very important to determine if the
mathematical model adequately represents a real object. Herein lies the essence of
a new approach, i.e., vector identification.
There also exists a broad and important class of problems related to the
operational development of prototypes of various objects such as machines,
mechanisms, and structures. The solution of these problems includes vector
identification and multicriteria optimization and is based on the PSI method.
4. The MOVI 1.0 software package implements the PSI method and allows
one to solve the above problems. Through a simple interface, MOVI 1.0 can be
configured by the user to solve different engineering optimization problems, including
the study of mechanical objects described in terms of the finite element method .
The number of performance criteria that can be optimized is virtually
unlimited.
5. The PSI method has become one of the major tools for selecting optimal
design variables in many areas of industry (e.g., the automotive, machine tool,
aircraft, and shipbuilding industries) and has proved to be highly efficient in all
applications, without exception [1, 2, 4, 5, 7,11].
–8–
2. NOTATION AND DEFINITIONS
jth design variable:
j, j = 1, r
Design variable vector:
 = (1,..., r)
jth design-variable constraint:
j*  j  j**
vth performance criterion:
v(), v = 1, k
Vector of performance criteria:
 = (1, ..., k)
vth criterion constraint:
v()  v**, v = 1, k
lth functional relationship:
fl(), l = 1,t
lth functional constraint:
Cl*  fl()  Cl**
feasible set (the set of feasible design variables)
D
feasible solution set in the criteria space:
(D)
Pareto optimal set in the design variable space:
P
Pareto optimal set in the criteria space:
(P)
Parallelepiped:
 = {j: j*  j  j**, j = 1, r }
The performance criterion is the object characteristic to be minimized
(maximized).
The functional relationship is the object characteristic whose values should be
within a certain predetermined range [Cl*; Cl**].
The feasible set is the set of vectors meeting design variable, functional, and
criteria constraints.
The Pareto optimal set is the domain of vectors in the feasible set that cannot
be simultaneously improved over all performance criteria (if one criterion is
improved, another criterion will certainly deteriorate).
–9–
3. STATEMENT AND SOLUTION OF MULTICRITERIA
OPTIMIZATION PROBLEMS
3.1. Some Features of the Engineering Optimization Problems
Let us start by considering the specifics of the problems to be solved. In doing
so, we will draw on the experience we accumulated while solving numerous
engineering optimization problems, including design problems. There are a number
of specific features inherent in the class of the problems under consideration that
predetermine both their formulation and the approaches to solving them.
The problems to be considered possess the following major specific features:
(1) They are essentially multicriteria problems. As a rule, attempts are made
to reduce multicriteria problems to single criterion ones. For example, the
productivity of a machine is undoubtedly an important indicator. However, should
one always try to maximize it? In addition, the single-criterion formulation of a
problem ignores questions of paramount significance such as the following: What is
the cost of maximum productivity? How does it affect the other performance criteria?
Why is this criterion more preferable than the others?
Numerous attempts to construct a generalized criterion in the form of a
combination of particular criteria proved to be fruitless.
By cramming a realistic multicriteria problem into the Procrustean bed of a
single-criterion one, one replaces it, in effect, with a different problem having little or
nothing in common with the initial one. Clearly, one should always try to take all the
major performance criteria into account simultaneously.
(2) Determination of the feasible solution set is one of the fundamental points
arising in the analysis of engineering problems. The construction of this set is a
major step in formulating and solving the problem.
(3) Formulating and solving a problem comprise a single process. We are
accustomed to processes where the designer first formulates a problem and then a
computer is employed to solve it. However, in the case under consideration this
approach is inadequate, since it is only on rare occasions that a problem may be
formulated prior to solving it. The feasible set may be determined only in the process
of solving the problem. Therefore, the problems are formulated and solved in the
interactive mode.
(4) As a rule, mathematical models are complicated systems of equations
(including differential equations) which may be linear and nonlinear, deterministic
and stochastic, and have distributed and lumped parameters.
(5) The design variables are usually continuous. The feasible solution domain
may be disconnected, and its volume may be several orders of magnitude smaller
than the domain within which the optimal solution is sought.
(6) Both the feasible and the Pareto optimal sets can be multiply connected
and nonconvex. Commonly, there is a lack of information about the smoothness of
the goal functions; as a rule, they are nonlinear continuous functions, which,
– 10 –
however, may be nondifferentiable. There are almost always many constraints of
various kinds, and the number of design variables and criteria reaches many dozens.
(7) The designer does not often encounter serious difficulties in analyzing the
feasible and Pareto optimal sets or in choosing the most preferable solution. A
sufficiently well defined system of preferences exists. In addition, these sets contain
a small number of elements.
3.2. Formulation of Multicriteria Optimization Problems
The formulation discussed below and the means for implementing it may be
used to solve the majority of engineering optimization problems [1–10].
Let us consider a mechanical, biological, social, or other object whose
operation is described by a system of equations (differential, algebraic, etc.) or
whose performance criteria may be calculated in a straightforward manner. We
assume that the system depends on r design variables 1, ..., r representing a point
 = ( 1 , ...,  r ) of an r-dimensional space. Usually,  appears in the abovementioned equations.
In general, when designing a machine, one has to take design variable,
functional, and criteria constraints into account.
Design variable constraints are given by
j*  j  j**, j = 1, r .
(1)
In the case of mechanical systems, j represents the stiffness coefficients,
moments of inertia, masses, damping coefficients, geometrical dimensions, etc.
Functional constraints can be written as
Cl*  fl()  Cl**, l = 1,t ,
(2)
where the functional relationships fl() may be either functionals that depend on the
integral curves of the above-mentioned differential equations or just functions of 
that do not depend on any equations. The constants Cl* and Cl** describe the feasible
limits for characteristic quantities (e.g., allowable stresses in structural elements, the
track gauge, etc.).
We have a number of performance criteria, such as productivity, material
consumption, efficiency, etc. All other things being the same, it is desirable that
these criteria, denoted by v(), v = 1, k , have extremal values.
Clearly, constraints (1) single out a parallelepiped  in the r-dimensional
design variable space. In turn, constraints (2) single out a certain subset G in ,
whose volume may be assumed to be positive without loss of generality.
In order to avoid situations where, in the designer's opinion, the values of
some criteria are unacceptable, we introduce criteria constraints:
v()  v**, v = 1, k ,
(3)
where v** is the worst, but still acceptable, value of the criterion v() (the choice of
v** is discussed in Section 3.4).
– 11 –
The criteria constraints differ from the functional constraints in that the former
are determined while solving a problem and, as a rule, are repeatedly revised. Unlike
Cl* and Cl**, reasonable values of v** cannot be chosen before the problem is
solved.
Constraints (1)–(3) single out the feasible set D, i.e., the set of design
solutions i that satisfy the constraints such that D  G  .
If functions fl() and v() are continuous in , then the sets G and D are
closed.
Let us formulate one of the basic problems of multicriteria optimization. It is
necessary to find a set P  D for which
 P   min    ,
 D
(4)
where v() = (1(), ...,k()) is the criteria vector and P is the Pareto optimal set.
We mean that ()<() if for all v = 1,...,k, v()  v() and at least for one
v0{1,...,k}, v0() < v0().
When solving the problem, one has to determine the design variable vector
P, which is the most preferable of the vectors belonging to set P. However, if
not all performance criteria can be formalized, then the optimal solution should be
sought over the entire set D.
0 
Let us give an alternative definition of the Pareto optimal set.
Definition. A point D, is called a Pareto optimal point if there exists no
point D, such that v() v () for all v = 1,...,k, and v0() < v0(0) for at least
one v0{1,...,k}. A set P  D is called Pareto optimal if it consists of Pareto optimal
points.
The Pareto optimal set plays an important role in vector optimization
problems, because (1) it can be analyzed more easily than the feasible solution set
and (2) the optimal vector always belongs to the Pareto optimal set, irrespective of
the system of preferences used by the designer for comparing vectors belonging to
the feasible solution set. The importance of this set is determined to a great extent
by the well-known theorem formulated in [4].
If the feasible solution set D is closed and the criteria v() are continuous,
then the Pareto optimal set is nonempty.
Therefore, when solving a multicriteria optimization problem, one always has
to find the set of Pareto optimal solutions.
3.3. Systematic Search in Multidimensional Domains Using
Uniformly Distributed Sequences
The features of the problems under consideration make it necessary to
represent vectors  by points of sequences of uniformly distributed design variables
[1, 2, 4–7,11]. We briefly consider this issue below.
The following situation is typical of many applied problems. There exists a
multidimensional domain where a function (or a system of functions) whose values
– 12 –
may be calculated at certain points is considered. Suppose we wish to get some
information about the function's behavior within the domain/subdomain. Then, in the
absence of any additional information about the function, it is natural to wish that the
points where it is calculated would be uniformly distributed within the domain.
To satisfy this condition, we use LP sequences. These sequences are among
the best ones with regard to uniformity.
3.4. The Parameter Space Investigation Method is a Tool for
Formulating and Solving Engineering Optimization Problems
In Section 3.2 we formulated the problem of multicriteria optimization and
defined the feasible solution set D, which is constructed using the values of  ,  =
1,, k and some other constraints. Now we proceed by describing the Parameter
Space Investigation method, which allows correct determination of   and, hence,
of the feasible solutions as well.
The Parameter Space Investigation method involves the following three
stages (see Figure 3.1).
Stage 1. Compilation of test tables with the help of a computer.
First, one chooses N trial points 1,...,N satisfying relation (2). Suppose that
~
the designer can a priori indicate the constraints   to be imposed on the criteria
~
~
 ( ),   1,..., k  ;   is the value of the  th criterion for which the values     
~
are known to be unacceptable. The constraints   , if any, should be imposed
~
successively. First, one should calculate 1 ( i ) . If the inequality 1 ( i )  1** is
satisfied, then we proceed to the calculation of the criterion  2 ( i ) , and so on. The
vectors  i violating this inequality are discarded. Finally, only the vectors  i
~
satisfying all constraints ci* , ci** , and   will remain. Then for each of the k  criteria a
 
 
test table1 is compiled so that the values of   1 ,,  N
increasing order, i.e.,
 
 
 
  i1    i2      iN ,
  1,, k , k   k ,
are arranged in
(5)
where i1, i2 ,...,iN are the numbers of trials.
The remaining criteria  ( ),   k   1,...,k , should be calculated only for the
vectors satisfying all the inequalities of (5). By analogy with the criteria
 ( ),   1,..., k , test tables are constructed for the criteria  ( ),   k   1,...,k . Taken
together, the k tables form a complete test table.
1
This is sometimes called an ordered test table. In an unordered table the columns are formed from
the values of  ( i ), i  1,..., N ,   1,..., k.
– 13 –
Figure 3.1. Flow chart of the algorithm
Stage 2. Selection of criteria constraints.
This stage implies the intervention of the designer. When successively
analyzing inequalities (5), the designer specifies the criteria constraints   . It should
be noted that the method described earlier is in practice convenient for the designer.
Actually, the designer has to consider one criterion at a time and specify the
– 14 –
respective constraint. The designer should not “balance” by reducing one criterion at
the expense of the others. He/she analyzes one test table and imposes a criterion
constraint. Then he/she proceeds to the next table, and so on. Note that revision of
the criteria constraints within the limit of the test tables that have been constructed
does not lead to any difficulties for the designer.
All   should be the maximum values of the criteria (), which guarantee
an acceptable operating level of the object. If the selected values of   are not a
maximum, then many interesting solutions may be lost, since some of the criteria are
contradictory. Note that when solving practical problems, the designer often cannot
determine the maximum values.

As a rule, the designer may set   equal to a criterion value    whose
feasibility is beyond doubt.
Stage 3. Verification of the solvability of problem (4) with the help of a computer.
Let us fix a criterion, say,   1   , and consider the corresponding table (see
(5)), and let S1 be the number of values in the table satisfying the selected criterion
constraint:
 
 
  i1   1 
iS1

1

 1  .
(6)
One should choose the criterion   1 for which S1 is minimum among the
analogous numbers calculated for each of the criteria  .
Then criterion  2 is selected by analogy with   1 , and the values of
  in the test table are considered. Let the table contain S  S
values such that      , 1 j  S . Similar procedures are carried out for
 
 2  i1 ,  ,  2 
iS1
2
2
ij

2
1
2
each of the criteria. Then if at least one point can be found for which all inequalities
(3) are valid simultaneously, the set D defined by inequalities (1)(3) is then
nonempty and problem (4) is solvable. Otherwise D   , and one should return to
Stage 2 and ask the designer to make certain concessions in the specification of
  . However, if the concessions are highly undesirable, then one may return to
Stage 1 and increase the number of points in order to repeat Stages 2 and 3 using
extended test tables.
The procedure is continued until D proves to be nonempty and the designer
finds the solutions obtained to be acceptable. Otherwise, the designer can attempt to
improve these solutions by returning to Stage 1 and/or Stage 2. The Pareto optimal
set P is then constructed in accordance with the definition presented in Section 3.2.
This is done by removing the feasible points that can be improved with respect to all
criteria simultaneously.
Let us describe the procedure for constructing the maximum feasible set. If
the selected values of **     are not maximal, then one cannot be sure that the
values of    from the interval          are feasible. In this case, one
~

has to construct the feasible solution set D under the constraints   =    and the
– 15 –
~
corresponding Pareto optimal set P. Further, the set D is constructed under the
~
~
constraints    = 1,...,k, as well as the corresponding Pareto optimal set P . Let us
compare (P) and  P  . If the vectors belonging to  P  do not substantially
~
~

improve the value of the vectors from (P), then one may set   =    .
Otherwise, if the improvement is significant, then the values of the criteria constraints
~
may be set equal to   . In this case, one has to verify that the optimal solutions
thus obtained are feasible. If the designer is unable to do this, then the criteria
constraints are set equal to their previous values,   =    . This scheme can be


~
used for all possible values of    and   .
Remark. The PSI method makes it possible to solve problems in parallel,
using several computers simultaneously rather than only one. On the first computer,
we can make the calculations for the trial points with numbers from 1 to some N1,
and on the second computer, from N1+1 to some N2 > N1 +1, and so on. Then the
results of all these calculations are collected in a single test table.
Solving Practical Problems
The algorithm presented above ensures the construction of the maximum
feasible set D by executing all procedures involved in this algorithm. However, when
solving a specific problem, the designer can obtain a quite acceptable solution
without constructing this set. In this case, he/she will have to execute only some of
~  and
the procedures. It is also unnecessary in this case to construct the sets D
 
~
 P
and compare the set D with P . Example problems presented in this
book confirm this observation. In these examples, it turns out that relatively few
dialogues with the computer for different criteria constraints ** ,  1, k are sufficient
to obtain desirable solutions. The analysis of these solutions almost always indicated
that it was advisable to correct the constraints in the input statement of the problem.
This correction made it possible to find interesting new solutions.
Thus, the PSI method has proved to be a very convenient and effective tool
for the designer, primarily because this method can be directly used to state
and solve the problem in an interactive mode.
Fast Algorithm for Constructing the Feasible Solution Set
Consider the fast procedure for constructing test tables (see Figure 3.2).
~
First of all, we carry out N trials, calculate Φ1 ( i ), for i  1, N , determine  1** and
 1** by analyzing the test table, and then determine the number of feasible solutions
~
satisfying the criterion constraint  1** , i. e., N D 1 , 1**  1** . Then we construct the
second test table. We calculate  2 ( i ) for i  1, N D1 and determine the number of
feasible solutions N D 2 satisfying the constraints 1** and  *2* . In a similar way, we
– 16 –
find N D 3 , N D 4 ,... , and so on. The number N D k found after the analysis of the last test
table is the final number of feasible solutions; i. e., N D k = N D .
Compared with the previous algorithm, this algorithm reduces the time
required to construct the feasible solution set . This reduction is especially substantial
for rigid criteria constraints and also in cases where the times required for calculating
different criteria are significantly different.
Compared with the complete test table (5), in the case in question,
determination of the criteria constraints ** ,   2, k may cause certain difficulties.
Moreover, revising the values of ** in order to increase them may need additional
tests.
Figure 3.2. Scheme of the fast algorithm
– 17 –
3.5. Problems of Vector Identification and Operational Development
of Prototypes
Here, we consider two other classes of engineering optimization problems
whose statement and solution are also based on the PSI method.
A. Vector Identification Problems [1, 2]. Let vC(), v = 1, m stand for the
characteristics (criteria) determined from the analysis of the mathematical model
describing a physical object;  = (1, ..., r) is the parameter vector of the model
being studied.
Let vE be an experimental value of the vth criterion measured directly on the
prototype.
We state the following problem: By comparing the experimental and
calculated data, estimate the correspondence between the mathematical model and
the physical object and identify the design variables of the mathematical model; i.e.,
one should find the parameter vectors i that meet conditions (1) and (2) and satisfy
the following inequality:
║vC(i) – vE║  v**, v = 1, k .
(7)
Here ║║ is the function that evaluates the proximity (adequacy) of the
physical object and its mathematical model; v**, v = 1, k stand for the criteria
constraints that are specified in the course of the dialogue between the designer and
a computer, based on an analysis of the test tables. Relationships (1), (2), and (7)
determine the domain D.
Restoring the mathematical model parameters in accordance with (1), (2), and
(7) determines the essence of the vector identification.
B. Problems of Operational Development (Improvement) of Machine
Prototypes [1, 2]. Operational development problems are treated in two stages.
During the first stage, the vector identification problem is solved. One of the main
results of this stage is the evaluation of the agreement between the mathematical
model and experimental data and construction of parameter domain D.
During the second stage, the feasible set D of the vectors satisfying
conditions (1)–(3) is constructed with regard for the performance criteria 1,..., k,
and the optimal design variables are found in this set in accordance with (4).
3.6. The Required Number of Trials
As was mentioned above, unlike other optimization methods, the PSI method
was devised not only to solve a problem, but also to help formulate it. Therefore, the
number of trials N needed to construct the feasible and Pareto optimal sets depends
to a great extent on how the problem is formulated.
It should also be noted that N depends on the class of functions subjected to
optimization, the number of design variables, the volume of the parallelepiped under
investigation, and the functional and criteria constraints. In turn, the number of
– 18 –
functions may reach many dozens, and they may be differentiable, nondifferentiable,
nonconvex, discrete, etc.
As a rule, the number of trials was determined on the basis of a nonformal
analysis of the results obtained. The significance of the problem under consideration,
the time available for obtaining the optimal solution, the quality of the mathematical
model, the accuracy with which the criteria had to be calculated, etc. were taken into
account.
The need for a large number of trials is predetermined by the following
considerations. Since engineering problems are, as a rule, ill-posed, one has to
correct the mathematical model, the initial boundaries of the design variable
variation, and the values of both the functional and criteria constraints. Usually, 70–
85% of the total number of trials are "spent" on formulating the optimization problem.
After all the constraints have been determined, the optimal solution can be obtained
by running a relatively small number of trials. Taking into account the significance of
the problems to be solved and the expected gain from the optimization, we usually
agree to several thousand trials.
This is especially true for batch and mass production of automobiles, machine
tools, gear trains, etc. These articles are manufactured in large quantities, and here
metal and fuel economy, as well as cost reduction, is of paramount significance. In
all these cases, the efficiency of multicriteria optimization may be rather high, and it
should be implemented with utmost care.
There are many problems in which the time required to calculate one solution
(calculation of the criterion vector for fixed design variables) sometimes reaches an
hour or more. In particular, this is the case for finite element models. As a rule, such
systems are not amenable to optimization. However, things change when these
problems are solved on several computers simultaneously with the help of the PSI
method. In this case, the time required to solve the problem is considerably reduced.
Experience accumulated in solving engineering problems shows that the time
spent on formulating and solving an optimization problem is fully compensated for by
the results.
Let us draw some conclusions [1–10].
The PSI method allows you to:
-
determine design variable, functional, and criteria constraints;
-
determine the influence of the design variables on the criteria;
-
reveal dependent and contradictory criteria, etc.
However, the construction of the feasible and Pareto optimal sets of solutions
is the most important result.
– 19 –
4. GENERAL DESCRIPTION OF THE MOVI 1.0 SOFTWARE
PACKAGE
The MOVI 1.0 software package is designed for correct formulation and
solution of multicriteria optimization and vector identification problems.
The MOVI 1.0 system operates in the interactive mode. The system is shown
schematically in the flowchart in Figure 4.1. Each of the given units is described
below.
Figure 4.1
– 20 –
4.1. Unit I: Entering New Data
4.1.1. Purpose
To run the software package, a number of data must be entered. These are
the bounds of the design variables, the number of design variables, the number of
criteria, the number and bounds of functional constraints, the number of tests, etc. A
complete list of the input data will be given below.
4.1.2. Description
The Bounds of Design Variables. Lower, j*, and upper, j**, bounds of
variation must be introduced for each of the design variables j. The range of the
design variable j, j = 1,r , should be such that the mathematical model describing
the object being studied allows all performance criteria to be computed with the
required accuracy.
One of the forms for specifying the bounds of the design variables implies the
presence of a prototype1, i.e., a certain feasible vector of design variables jp, j = 1,r .
If this is the case, the bounds can be specified by taking the prototype into account.
For example, the magnitude of each of the prototype design variables can be taken
as the midpoint of the respective variation range.
The Number of Design Variables. This number must not exceed 51 when the
LP sequences generator is used.
The Number of Criteria. The choice of the number of criteria is of basic
importance for optimizing design variables in an engineering problem. The set of
criteria should be chosen so as to allow all the basic characteristics of the object to
be taken into consideration. The more criteria that are introduced, the more
completely the optimum variant will depict the basic abilities of the object being
designed. The PSI method allows virtually any number of criteria to be taken into
account.
The Number of Functional Constraints. Each functional relationship fl()
should meet certain constraints. These may be of two kinds: unilateral, f l ()  cl** or
cl*  f l (), and bilateral, cl*  f l ()  cl**. For this reason, the number of constraints
is determined by both the kind of constraints and the total number of functional
relationships.
The Bounds of Functional Constraints. The bounds cl*(*) are introduced for
each f l (). If, before solving the problem, the designer finds it difficult to assign the
exact magnitudes of these bounds for some f l (), it is advisable to formally
consider f l () as an additional criterion. Such a function fl() is called a pseudocriterion. Unit VI is used to compute the bounds for constraints on f l () (see Figure
4.1). In cases where this consideration is undesirable, units III through V are used to
perform the determination and possible correction of these bounds .
1
In particular, the design variables of an existing object may play the role of the prototype.
– 21 –
The Number of Tests. It is necessary to indicate the number of sets of the
design variables for which the performance criteria must be computed. Usually, this
number is assigned in stages, since it is impossible to determine at once how many
tests are needed to solve the problem (see Section 3.6). At the first stage, as a rule,
a number of the form N1 = 2 n1 is specified, where n1 = 510. ( n may sometimes be
greater). At the second stage, we specify N2 = N1 + 2 n2 , n2 = 510; similarly, at the
kth stage, Nk = Nk-1 + 2 nk . Here ni, i = 1, k , is dependent on both the time required to
compute the functional relationships and performance criteria and the time the
designer has to tackle the problem. Note that it is not necessary to specify the
number of tests of type 2 n for LP sequences. The maximum number of trials for
LP sequences is equal to 2 20 .
4.2. Unit II: Probing the Parameter Space
4.2.1. Purpose
The coordinates of vectors of design variables are computed for each of the
specified numbers of tests N. These N vectors allow one to perform uniform
observation of the entire area of design variables in the best way.
4.2.2. Description
Using the matrix of numerators we calculate the values of the coordinates of
the vectors  i  ( 1i ,...,  ri ) . Here, 1  i  N  220, r  51,  i are the points of the
uniformly distributed LP sequence1.
4.3. Unit III: Check for the Fulfillment of Functional Constraints
4.3.1. Purpose
The values of functional relationships fl() are calculated for each vector
, i = 1, N . Next, checks are made to see whether these values satisfy the imposed
constraints. This is necessary in order to make further computations of performance
criteria only for those i which satisfy the functional constraints.
i
4.3.2. Description
The vector i , i = 1, N (its number and values of the coordinates) is passed to
the next unit of the program if and only if it satisfies all functional constraints.
Correction of Functional Constraints Only those solutions that satisfy all
functional constraints enter the test table. Designs that fail to satisfy these
constraints enter the table of functional failures. An analysis of the table of functional
1
To check unit II for proper operation, Appendix A contains coordinates of five 50dimensional points of an LP sequence that belong to the unit cube K 50 . The numbers of these points
are 5, 82, 347, 754, and 998. The values of the first five coordinates are given in the first rows, the
second rows contain the sixth through tenth coordinates, and so on.
– 22 –
failures allows one to understand how the functional constraints ”work“ and, if
necessary, to correct them. The designer can proceed as follows when relaxing
functional constraints. First, he/she identifies all functional constraints that can be
relaxed and then, using the table of functional failures, defines a new (relaxed) value
of the functional constraint and enters this change in the table.
Remark. The optimization algorithm implies that, first, a set of solutions i
satisfying the functional constraints is constructed, and then the values of all v(i)
are computed for these i. However, in order to save time in optimization
computations, it is frequently advisable to carry out these steps in another order.
Consider the following situations:
1. Suppose the time required to calculate the functional relationships for
fixed design variables is less than or equal to the corresponding time for
the performance criteria. In this case, the operation of unit III directly
follows the operation of unit II.
2. If the time required to compute the functional relationships is greater than
the time for calculating the criteria, then the operation of unit II is followed
by the operation of units IV, V, and VI, and then unit III is engaged.
3. A mixed situation is also possible, e.g., when one part of the functional
relationships corresponds to condition 1, while the other part satisfies
condition 2. In this case, the constraints of the first kind are checked just
after unit II, while the others are checked after units IV, V, and VI.
4. Consider the situation where one portion of the functional relations and
performance criteria (“fast” functions) can be calculated rapidly, while the
other portion (“slow” functions) requires a significant amount of calculation
time. In this case, we can suggest two ways to organize the computations
reasonably for optimization. Prior to implementing either of these ways,
the functional relations should be declared as pseudo-criteria.
First approach. We compile the test table, taking into account only “fast”
functions (criteria and functional relations), and determine the criteria
constraints using these functions. Then we construct a test table, the first
portion of which consists of the “fast” functions with the constraints
determined, and the other portion comprises all remaining functions. After
this, the problem is solved in the usual way.
Second approach. The so-called fast algorithm is used. In this case also,
one should first calculate the “fast” functions in the test table and then the
“slow” functions.
4.4. Unit IV: Evaluation of Criteria
4.4.1. Purpose
Either after unit III or just after unit II, the performance criteria v(i), v = 1, k ,
are calculated for each of the vectors i by using the corresponding mathematical
model.
– 23 –
4.4.2. Description
In order to carry out this stage, one has to have software module(s), which
implement(s) the user’s problem. This makes it possible to compute (by using a
mathematical model) performance criteria and, perhaps, functional relationships,
provided these can be computed by means of the same mathematical model as the
performance criteria.
In the course of varying the design variables and computing the functional
relationships and criteria, the mathematical model may turn out to be unstable. In
this event, it is necessary to correct the model and/or the bounds of the design
variable ranges. This is described in unit VIII of the software package manual.
4.5. Unit V: Compiling the Test Table
4.5.1. Purpose
In many problems, the performance criteria may assume values that are
unacceptable from the designer's standpoint. To eliminate these values from further
consideration, the performance criteria are subject to constraints. This facilitates the
analysis of the results, since the number of solutions to be investigated is reduced.
To determine the criteria constraints and construct a feasible set of solutions, an
ordered test table is compiled.
4.5.2. Description
An example of an ordered test table is presented in Section 12. As mentioned
above, it may happen that one can find few or no solutions in the test table. In this
case, we advise the designer to do the following:
1. Weaken the functional constraints as much as possible and compile the
corresponding test table.
2. If item 1 does not lead to a desirable result, then increase the number of trials.
If this does not lead to desirable results, then try to change the ranges of the
design variables (Unit VIII).
In this unit, an unordered test table, which can be obtained by reference to
unit VIII, is also generated.
4.6. Unit VI: Definition of Criteria Constraints. Generation of a
Feasible Set
4.6.1. Purpose
It is required to construct the feasible set D by determining the criteria
constraints in the proper way. This unit checks the design variables i presented in
the test table for their feasibility. The designer can obtain the values of the design
variables and criteria corresponding to the feasible vectors by going to unit VIII.
– 24 –
4.6.2. Description
The criteria constraints are determined as follows. In each column of the
ordered test table, the designer marks the criterion value whose feasibility is
unquestionable. In doing so, it is desirable that this value be the maximum of all
feasible values of the criterion in question. This condition is necessary in order not to
lose solutions that are fairly good with regard to all the criteria, in case of
contradictory criteria1 are present. (In some of the criteria, these solutions may not
correspond to the best values). However, since it is not easy to indicate the
maximum feasible value of each criterion on the first attempt, the designer usually
does this during of a dialogue with the computer. This is described in more detail in
Section 3.
Let the test table be obtained. Consider the procedure for specifying criteria
constraints.
Step 1. Assign 1** and determine the number of the vectors satisfying this
constraint.
Step 2. Assign 2** and determine the number of the vectors satisfying 1**
and 2**.
After specifying n**, it may turn out that there are either no, or few vectors
satisfying all 1** ,..., n**. In this case, an attempt should be made to weaken
criterion constraint n** (and perhaps some v, v < n).
A fragment of the ordered test table for a 4-criteria problem is shown in Table
4.1. Consider an example of determining D that takes into account all of the steps
mentioned above.
4.6.2.1. Dialogue 1
Step 1. Assign 1** = 3.00. The number 14 appears at the bottom of the
column corresponding to 1. This indicates the number of vectors satisfying this
criterion constraint.
Step 2. Assign 2** = 48.4. Conditions 1** = 3.00 and 2** = 48.4 are satisfied
by three vectors with numbers 59, 22, and 4; the number 3 appearing at the bottom
of the column is related to 2.
Step 3. Assign 3** = 164.5. A 0 appears at the bottom of the column. This
means that there is no vector satisfying the conditions 1** = 3.00, 2** = 48.4, and
3** = 164.5. These three criteria constraints are marked in Table 4.1 by a thick line.
It is clear that D =  and there is no sense in assigning 4**.
4.6.2.2. Dialogue2 2
Step 1. 1** = 3.00.
Step 2. 2** = 53.1. These constraints have already been satisfied by five
vectors whose numbers are 59, 22, 4, 17, and 1.
Step 3. 3** = 164.5. Two vectors (1 and 17) have satisfied the indicated
criteria constraints.
1
As some of the criteria decrease, others increase.
The latter results are not given in Table 4.1.
2
– 25 –
Step 4. 4** = 0.178. We have D = .
4.6.2.3. Dialogue 3
Step 1. 1** = 3.00.
Step 2. 2** = 53.1.
Step 3. 3** = 175.2. Three vectors (1,17, and 59) satisfy the three indicated
constraints.
Step 4. 4** = 0.178. Only one solution (vector 59) is feasible.
Thus, after Dialogue 1 has been completed, we have the numbers 14 (the
column for 1), 3 (the column for 2), and 0 (the column for 3) at the bottom of the
table. After Dialogues 2 and 3, we have (14, 5, 2, 0) and (14, 5, 3, 1), respectively.
Table 4.1
i
1(i)
4
1.62
17
1.68
9
1.75
47
1.84
126
1.97
54
2.03
7
2.18
22
2.43
14
2.60
49
2.72
1
2.86
59
2.92
106
2.94
97
3.00
84
3.18
37
3.27
42
3.36
94
3.42
76
3.52
14
i
59
42
13
22
51
76
83
100
4
2
8
17
1
60
10
80
20
26
47
3
2(i)
44.2
44.5
44.8
45.1
45.3
46.2
46.8
47.4
48.3
48.4
48.7
49.2
49.7
51.3
52.4
53.1
55.4
56.1
57.3
i
10
2
1
80
100
13
17
8
20
23
59
48
16
4
117
99
120
77
87
0
3(i)
149.2
150.3
153.7
158.4
160.2
163.4
164.5
168.7
170.3
174.7
175.2
177.3
181.4
181.9
182.3
184.2
185.7
186.6
187.3
i
16
99
112
6
59
100
1
20
65
47
80
9
17
126
4
50
22
128
77
0
4(i)
0.153
0.164
0.168
0.172
0.178
0.181
0.184
0.187
0.192
0.194
0.198
0.205
0.212
0.219
0.221
0.223
0.238
0.241
0.246
After each of the dialogues, the designer analyzes the results obtained and
compares them with those of the previous dialogues. When specifying some criteria
constraints, the designer is guided by the significance of the criteria, the accuracy of
their computation, and other reasons. The feasible set may be empty due to an
improper specification of criteria, functional, and design variable constraints. All
these factors should be controlled in order to determine the set D correctly.
There may be the cases where, despite various possible dialogues, the
feasible set remains empty. In this event, the number of tests N should be increased.
If the statement of a problem corresponds to the physical nature of the system being
– 26 –
studied, one can always find the design variable vector satisfying all constraints,
provided N is sufficiently large.
The analysis of such situations is always not formal. After concluding this
analysis, the designer can see what he/she can give up in favor of searching for a
good solution. In problems with many functional and criteria constraints, it is of
utmost importance not to lose any solutions that may be of interest. Note that the
number of such solutions is usually very small, but their significance is rather high.
4.6.3. Truncated Test Tables
Suppose that we have performed N tests and constructed the test table.
Analysis of this table helps the designer understand how the values of the design
criteria can change. Let the designer have determined the criterion constraints
~
** , **  ** and the feasible solution on the basis of the test table, as well as
other information, including the design requirements. However, he/she may consider
it necessary to continue testing. Let N  1, ..., N1 be the numbers of the additional
tests. As a rule, the number of feasible designs is much less (sometimes by a factor
of several thousand) than the number of tests N. Therefore, it is very important for
the designer that the new test table constructed after N tests contain only useful
information in a convenient form, specifically, the feasible solutions. For this reason,
when performing tests with numbers N  1, ..., N1 , we will require that the test table
contain only the solutions (designs) satisfying the constraints ** identified
previously. To make this, we will organize the test table in the following way. We
select a vector  i and calculate 1 ( i ) . If the value 1 ( i ) satisfies the first criterion
constraint, we calculate  2 ( i ) . If the second criterion constraint is also satisfied, we
calculate the third, fourth, and other criteria consecutively. If it happens that some
criterion  j does not satisfy the criterion constraint for the design  i , then this
design is rejected. Otherwise, it is entered in the test table. We refer to these tables
as truncated tables: they contain only feasible solutions. It is fairly convenient for the
designer to work with such a table. Also, the construction of truncated test tables is
advisable if the number of tests is large and the random access memory of the
computer is not powerful enough to construct full tables.
4.6.4. Choice of the Algorithm
First of all, we recall that we are dealing with ill-posed problems. In particular,
it is common in multicriteria design that the designer almost never has complete
information about adequate constraints to be imposed on the design variables,
functional relations, and performance criteria. The designer obtains this important
information, which indicates whether it is advisable to correct the constraints so as to
construct feasible and Pareto optimal designs, from an analysis of the test tables.
The more comprehensive this information (with the other things being the same), the
greater the confidence the designer has in successfully solving the problem.
Frequently, this confidence has to be paid for by time spent on carrying out the
necessary number of tests. The designer makes the final decision on continuing or
terminating these tests only after analyzing the results obtained. To a considerable
extent, this decision depends on the physical nature of the problem, the time that the
designer has to solve it, the importance of the problem (the more important the
– 27 –
problem, the more the time that can be spent on solving it), etc. We emphasize once
again that the decision-making process is not formal. That is why we mentioned
previously that the statement and solution of multicriteria design problems is a single
process in which the designer participates rather nonformally.
We have described two algorithms for solving engineering optimization
problems. We will now indicate three approaches to use these algorithms . The first
approach involves the construction of the full test table. The second approach
requires the construction of the full table and then the construction of truncated
tables. The third approach implies the use of the fast algorithm. Roughly speaking,
one can say that the first approach is able to provide more information about the
feasible solution set, the third approach reduces computation time, and the second
approach occupies an intermediate position. It is difficult to say in advance which of
the algorithms will be better for constructing the optimal design. To obtain an answer
to this question, we recommend carrying out a preliminary analysis of the problem.
For example, one can evaluate the results obtained after a relatively small number of
tests and try to estimate the effect expected from the optimization. Nonformal
analysis of the results can enable one to estimate which of the algorithms may be
most effective. In all three approaches, after the feasible set is constructed, the
Pareto optimal set of solutions is defined and the most preferable design is
determined on the basis of an analysis of the Pareto optimal set.
4.6.5. Table of criteria failures
For certain specified criteria constraints, it can happen that not all of the
solutions of interest appear in the feasible set. An attempt can be made to improve
this set by relaxing the constraints somewhat and finding additional solutions that
may be of interest to the designer. For example, these can be solutions that provide
“good” values for major performance criteria but are somewhat worse in terms of
less important criteria. After obtaining and analyzing such solutions, the designer
may agree to include them in the feasible set. To make this, he/she should refer to
the table of criteria failures. Let us assume we have constructed the truncated test
table. The vectors of design variables that fail to satisfy at least one of the
constraints ** ,  1, k  1 appear in the table of criteria failures. Analysis of this table
allows one to compare the values of the criteria for these vectors with the criteria
constraints and assess the possibility of relaxing these constraints. The vectors
(solutions) satisfying all constraints enter the truncated table. The structure of the
table of criteria failures is described in Section 11.4.2.
4.6.6. Analysis of the Feasible Set
Let a few feasible vectors be found, and/or assume that the designer wishes
to improve the values of the obtained performance criteria.
1. Let us assume, that designer has enough time to tackle the problem. Then,
in order to determine whether the found set D is final, several stages are required to
compute Nk (see unit I). (In many cases, there may from two to five such additional
iterations). If the values of the criteria at a certain stage do not differ significantly
compared with the previous stage, then the process of forming the feasible set is
completed.
– 28 –
In addition, the designer can modify the feasible set by correcting the design
variable, functional, and criteria constraints.
To correct the feasible set, the designer may also go to unit VIII and use the
design variable distribution histograms given in the unit. Analysis of these histograms
may lead to changes in the design variable constraints and even in the feasible set
itself.
2. Let us assume, that the designer has little time to tackle the problem. In this
case, the designer may change the values of the criteria constraints in order to make
an attempt to form a new feasible set.
4.7. Unit VII: Generation of the Pareto optimal Set
4.7.1. Purpose
The importance of this set is due to the fact that the most preferable or
optimal solution always belongs to it. The Pareto optimal set is easier to analyze
than the feasible set, since the former is no larger (and is often smaller) than the
latter. Note that the MOVI 1.0 software package does not have a separate item for
constructing the Pareto optimal set. Nevertheless, here we consider the construction
of the Pareto optimal set separately, in view of the importance of this stage for
determining optimal designs.
4.7.2. Description
In this unit, the program eliminates all vectors that can be improved
simultaneously with respect to all criteria from the feasible set. The remaining
vectors will be Pareto optimal. The designer can determine the numbers of these
vectors, their components, and the respective values of the performance criteria by
going to unit VIII of the software package. To this end, the tables of Pareto optimal
solutions (including both the design variables and criteria) are constructed.
4.8. Unit VIII: Analyzing the Results. Constructing Tables of
Results, Histograms, and Graphs
4.8.1. Purpose
This unit provides additional information about the distribution of the design
variables within their ranges, as well as the dependence of the criteria on design
variables, and gives a graphic presentation of the results. This information helps the
designer correct the design variable constraints and the mathematical model.
4.8.2. Description
Visualization of the Process of Investigating Criteria and Parameter Spaces
This process is rather important, since it helps the designer go deep into the
essence of the engineering problem and correct the mathematical model,
constraints, etc.
– 29 –
When specifying the bounds i*(*), it is often useful to analyze how v depends
on j. The analysis reveals the expedience (or inexpedience) of changing these
bounds.
Suppose that after performing N tests we have obtained Фv(), i =1,…,N. Let
us assume we are interested in the dependence of the vth criterion on the jth design
variable, i.e., in the function Фv( We fix all design variables determined previously,
apart from the jth one. Let us calculate some values of the jth design variable and
the values Фv(j), i =1,…,N. In this case, we can confine ourselves to a relatively
small number of tests, for example, N=16, 32. By repeating this procedure for
various sets of design variables, we obtain graphs giving sufficient information about
the dependence of the vth criterion on the jth design variable. Examples of these
graphs are presented in Section 12.
Design Variable Distribution Histograms
One of the features of engineering optimization problems is the difficulty in
specifying proper bounds for design variable ranges because of the presence of
performance and criteria constraints. The analysis of the histograms is aimed at
correcting the initial parallelepiped of design variables  and constructing new
parallelepipeds that contain solutions of practical interest.
For the vectors from feasible set D, histograms are plotted that show the
distribution of the vector coordinates over the ranges of the corresponding design
variables. Each of the ranges is divided into ten equal segments.
A numerical example illustrating the construction and analysis of histograms
is given in Section 12.
Remark. In this unit the designer can obtain all of the above-mentioned types
of tables. These are the ordered and unordered test tables, the tables of feasible and
Pareto optimal solutions and their design variables, and the tables of functional and
criteria failures and their design variables. Let us dwell on the description of
unordered test tables. The numbers of the tests are arranged in ascending order in
the first column. The values of the criteria are given in the subsequent columns.
Thus, for the ith test registered in the table, the values 1(i), ..., k(i) are given in
the corresponding row.
Unordered tables may be used in debugging the program at the stage of
preliminary computations.
4.9. Unit IX: Determining the Best Solution
4.9.1. Purpose
After analyzing the table of Pareto optimal solutions, the designer needs to
select the best one. In doing this, he/she takes into account the importance of the
criteria, analyzes how a loss in one of the criteria is balanced by a gain in another
criterion, and so on. If the designer comprehends the physical content of the problem
well enough, the choice of the optimal solution usually causes no difficulty.
– 30 –
4.9.2. Description
Assume that the designer has chosen the best variant and is able to continue
solving the problem.
The designer can try to improve this variant by increasing the number of tests
and correcting the constraints.
Remark. When the MOVI 1.0 package is used for vector identification (see
Section 3.5), the description of its operation coincides with the one given here, with
slight differences. When solving identification problems, one should not apply unit VII
(forming the Pareto optimal set). In these problems, the identification is carried out
with respect to proximity or adequacy criteria. Correction of the feasible range of
design variables is almost always necessary.
– 31 –
5. EXAMPLE
The vibratory system shown in Figure 5.1 consists of two identical masses m1
= m2 = m connected by springs whose stiffness coefficients are k1 = k2= k and k0 [1,
46]. Such a system depends on three design variables k, k0, and m. Suppose the
design variables lie within the following specified limits:
k*  k  k**, k0* k0  k0**, m* m  m**.
(1)
The system can perform free harmonic vibrations with two natural frequencies
1 and 2. We will suppose that 0 < 1< 2.The formulas for calculating the natural
frequencies are quite simple:
1 
k  2k 0
k
, 2 
.
m
m
(2)
Such dynamic systems are considered in many textbooks on the theory of
vibrations.
In designing a vibratory system, one has to choose the natural frequencies in
such a way as to avoid undesirable resonance phenomena.
If the designer wishes to decrease 2, then he/she may introduce the criterion
1 
k  2k 0
m
and assume that the smaller the value of 1, the more perfect the system is.
Figure 5.1. Vibratory system
(3)
– 32 –
Suppose that along with decreasing frequency 2 the designer wishes to
decrease the mass of the system 2m. Then he may introduce another criterion
2 = m
(4)
and assume that the smaller the value of 2, the better the system is.
Let us consider the criteria plane shown in Figure 5.2.
To each set of design variables (k, k0, m) there corresponds a pair of numbers
Ф1 and Ф2 calculated from formulas (3) and (4) and, hence, a point on the criteria
plane. The same formulas allow one to find the set of points (Ф 1, Ф2) on the criteria
plane, which are calculated with the design variables (k, k0, m) varying within the
limits (1). The set is shown in Figure 5.2. Consider the lower left-hand boundary of
the set formed by a segment of the hyperbola
Ф1Ф2 = k*+2k0*.
(5)
It can be readily shown that points lying outside the hyperbola cannot
correspond to the best solution.
To prove this statement, we choose a point B (see Figure 5.2). By drawing a
vertical and a horizontal line through the point, we get points B' and B belonging to
the hyperbola. Since the abscissas of the points B' and B coincide (i.e., the values of
Ф1 at these points are equal) and the ordinate of B' is less than the ordinate of B (i.e.,
the value of Ф2 corresponding to B' is smaller), the system corresponding to point B'
is undoubtedly better than the one corresponding to point B.
Similarly, the system corresponding to point B" (as well as to all points (except
B) belonging to the curvilinear triangle B'BB") may be shown to be undoubtedly
better than the system corresponding to point B.
Hence, the best solutions should be sought among the systems
corresponding to points belonging to a segment of the hyperbola (Eq. (5).This
segment, shown in Figure 5.2 by a thick line, represents the Pareto optimal set.
Figure 5.2. Criteria plane
– 33 –
Figure 5.3. Feasible solution set Ф(D) in the criteria plane
Let constraints 1** and  *2* be specified. In Figure 5.3, the set of points
meeting these constraints is shaded. The set of design variables (k, k0, m) satisfying
conditions (1) is a parallelepiped П in the three-dimensional design variable space
(see Figure 5.4). The set of points lying within parallelepiped П and corresponding to
curve (5) can readily be found. In fact, from Eqs (3), (4), and (5) it follows that k
+2k0= k*+2k0*, and since k  k* and k0  k0* in П, we have k = k* and k0= k0*.
Hence, the desired set of points is determined by the conditions
k = k*, k0 = k0*, m*  m  m**
and represents an edge of parallelepiped П (see the thick line in Figure 5.4).
Naturally, the point (k = k*, k0 = k0*, m = m**) lies on the edge.
Let us continue by finding the set of points in П corresponding to the shaded
region in Figure 5.3.
From Eqs. (3) and (4) and inequalities 1  1** and  2   *2* it follows that
m   *2* , k+2k0  1**  m.
Together with (1), these equations define the portion of parallelepiped П that is the
feasible solution set of points D (see Figure 5.5). Let k, k0, and m vary within the
limits 2  k  6, 1  k0  4, 2  m  5, and let us do the necessary calculations. In
Table 5.1, a fragment of an unordered test table is given, representing the first 32
trials. After 32 trials, criteria constraints 1** and  *2* proved to be equal to 2.76 and
3.6, respectively.
– 34 –
Figure 5.4. Pareto optimal set P in the design variable space
Figure 5.5. Feasible solution set D in the design variable space
– 35 –
Table 5.1
i
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Ф1(i)
2.5714
3.4545
2.0
1.7838
2.32
2.0
5.3684
2.4308
3.4634
1.3247
3.434
2.2553
2.6197
4.1714
2.2034
2.2718
Ф2(i)
3.5
2.75
4.75
4.625
3.125
3.875
2.375
4.0625
2.5625
4.8125
3.3125
2.9375
4.4375
2.1875
3.6875
3.2188
i
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Ф1(i)
1.3377
2.7595
2.9764
1.5478
5.0448
2.5468
3.5385
1.5862
4.0206
2.562
3.8082
3.7412
2.1504
1.8899
2.3312
1.8199
Ф2(i)
4.7188
2.4688
3.9688
3.5938
2.0938
4.3438
2.8438
4.5313
3.0313
3.7813
2.2813
2.6563
4.1563
3.4063
4.9063
4.8594
Seven vectors were found in the feasible set D. Four of these vectors (α12,
and α30) were Pareto optimal. We then performed three more series of trials
with N=64, 128, and 256. Fairly acceptable results were obtained already for N=64.
The test results for N=128 and N=256 are shown in Figures 5.6a and 5.6b,
respectively.
α18,
α20,
 
Figure 5.6. Points   i in the criteria plane
– 36 –
6. SYSTEM REQUIREMENTS
The minimum system software and hardware requirements for normal
operation of the MOVI 1.0 package are:
1. Microsoft Windows 9x or Me, NT 4.0 with Service Pack 3 or later, or
Windows 2000.
2. SQL server InterBase 6.0 or later installed. Both InterBase Server and
InterBase Client should be installed on the same computer (the InterBase
6.0 setup program propose this by default).
3. PII 300 or faster processor.
4. Minimum 32MB RAM (64MB or more is recommended).
5. VGA or better graphics adapter. Windows display resolution should be set
to 800x600 or higher.
6. 60 MB free space on the hard drive for the software package plus at least
20MB for the data (depends on the complexity of the problem).
Remark. The minimum requirements indicated above are sufficient for
operating MOVI 1.0. However, a faster processor and more RAM will ensure faster
operation of MOVI 1.0 and allow a larger Test Table to be processed in a reasonable
time. Assuming that the number of tests is large enough, procedures such as
criterion change and construction of feasible and Pareto sets will take much longer
on slower computers than on faster ones.
7. CONTENTS OF THE DISTRIBUTION PACKAGE
The MOVI 1.0 Distribution Package includes:

One CD with MOVI 1.0 installation software and test examples ”Oscillator“
and ”Oscillator 1“.

User's Manual.
– 37 –
8. INSTALLING THE MOVI 1.0 SOFTWARE PACKAGE AND
GETTING STARTED
8.1. Installing the MOVI 1.0 Software Package
Please keep in mind, that you must first install InterBase 6.0 SQL Server.
The MOVI 1.0 installation set consists of one CD. To install the package,
insert the CD into the CD drive and run SETUP.EXE from the SETUP directory.
During the installation, the program will ask for the necessary information. Installation
can be canceled at any time by clicking the CANCEL button.
Step-by-step installation:
1. Insert the CD into the CD drive. The setup program will start automatically.
If it does not start, run SETUP.EXE manually by entering the string
”X:\setup\setup.exe“ (here X: is the CD drive letter) in the Windows RUN
dialogue window and clicking the OK button.
2. In the first window that appears, click NEXT.
3. In the next window, please read the license agreement. Click YES if you
agree; otherwise click NO.
4. If you selected YES, the next window appears. Enter your name and
company in the appropriate fields, and then click NEXT.
5. In the next window, you are requested to enter the directory name where
you want to install MOVI 1.0 (referred to as ”<MOVI 1.0 installation
directory>” from now on). You can leave the default setting, ”Program
Files\PSIOpt Lab\Movi 1.0”. Then click NEXT.
6. In the next window, enter the folder name for the Windows PROGRAMS
menu where the MOVI 1.0 program shortcuts will be added. Then click
NEXT.
7. In the next window, verify the data you entered. Click NEXT to confirm.
8. The installation program starts copying files. After the installation has been
successfully completed, the final window appears. Click FINISH to
conclude the installation.
8.2. Adding the “Oscillator” and “Oscillator 1” Test Problems
The MOVI 1.0 software package includes the “Oscillator” and “Oscillator 1”
example problems discussed in detail in Section 12 of the User's Manual. After the
package has been installed, the example problems are located in the directories
“<MOV 1.0 installation directory>\Problems\Oscillator” and “<MOVI 1.0 installation
directory>\Problems\Oscillator1”, respectively (each problem is in two files: base.gdb
and oscil.dll). To add an example problem to MOVI 1.0, use the Database Manager
utility included in the MOVI 1.0 distribution package.
8.2.1. Adding the “Oscillator” Problem
1. Start the Database Manager utility included in the MOVI 1.0 distribution
package.
– 38 –
2. Click the
button on the tool panel of the main window.
3. In the ADD PROBLEM window that then appears, enter the following
information:
a) Type “Oscillator“ in the PROBLEM NAME field.
b) In the PROBLEM FOLDER field, enter “<MOVI 1.0 installation
directory>\Problems\Oscillator“ or click the button to the right of this field
and select this path in the standard dialogue window.
c) In the INTERFACE LIBRARY field, enter “<MOVI 1.0 installation
directory>\Problems\Oscillator\oscil.dll” or click the button to the right of
this field and select this file in the standard dialogue window
(IMPORTANT! If the file “oscil.dll” cannot be found in this folder,
change the Windows settings to allow the display of system and
hidden files).
4. Click OK.
Now the “Oscillator” problem appears in the problem tree in the left panel of
Database Manager’s main window. The problem also now appears in the problem
list that is displayed when the LOAD PROBLEM item is selected in the MOVI 1.0
menu.
8.2.2. Adding the “Oscillator 1” Problem
“Oscillator 1” is added in the same way as “Oscillator”, except that in the
PROBLEM NAME field one should enter “Oscillator 1”, and in the PROBLEM
FOLDER and INTERFACE LIBRARY fields one should enter “<MOVI 1.0 installation
directory>\Problems\Oscillator1” and “<MOVI 1.0 installation directory>\ Problems\
Oscillator1\oscil.dll”, respectively.
8.3. How to Start the MOVI 1.0 Program
To start the MOVI 1.0 package program, select an appropriate shortcut in the
MOVI 1.0 installation folder (by default this is the “MOVI 1.0” folder in the Windows
PROGRAMS menu).
IMPORTANT! In order to use MOVI 1.0, both the InterBase Server and
InterBase Client parts of InterBase 6.0 SQL Server must be installed on the user's
computer. The InterBase 6.0 SQL Server is included in the educational version
of the MOVI 1.0 distribution package.
8.4. Uninstallation
To uninstall MOVI 1.0, select ADD/REMOVE PROGRAMS in the Windows
Control Panel. In the window that then appears, select “MOVI 1.0” and click
REMOVE.
– 39 –
9. INTERFACE LIBRARY DEVELOPMENT MANUAL
9.1. Purpose of the Interface Library: Preliminary Information
MOVI 1.0 is designed to solve object optimization problems by means of the
user's mathematical models. For this purpose, the following data exchange must be
organized between MOVI 1.0 and the mathematical model (Figure 9.1):
1. transfer of input data (design variable vectors) generated by MOVI 1.0 to the
user's model;
2. transfer of data processed by the user's model (values of criteria and
functional relations) back to MOVI 1.0.
Figure. 9.1. Data exchange between MOVI 1.0 and the user's model
From the input design variable vector, the user’s model calculates the
necessary values of criteria or functional relations and sends the result back to MOVI
1.0 in a suitable fixed format. In the MOVI 1.0 software package, this interaction is
provided by means of an Interface Library, which is a Dynamically Linked Library
(.dll-file) created according to certain rules. The Interface Library must involve
procedures for calculating criteria and functional relations. It is the basic element that
distinguishes one optimization problem from another, since it contains the
mathematical model of the problem under consideration. MOVI 1.0 performs all
calculations (except for the construction of the feasible and Pareto optimal sets) by
means of the Interface Library. Therefore, the performance of MOVI 1.0 when
processing a certain problem depends on the quality of the Interface Library code
written for this problem.
9.2. Interface Library Development
When developing the Interface Library, the programmer should be guided by
the following requirements1:
A. The library must contain an initialization function Init with the following
format:
function Init(var NPar: Word; var NFun:Word; var NCrit:Word;
var S:PChar):Integer; stdcall;
1
Here and after we will give all the examples using Object Pascal language
– 40 –
The function Init takes three WORD type variables and a pointer to a
string type variable as parameters.
The function returns the following values:
- NPar – the number of design variables in the problem;
- NFun – the number of functional relations;
- NCrit – the number of criteria;
- S – a string containing identifiers of the functions used to calculate
criteria and functional relations in the same format as they are
declared in the Interface Library. Identifiers of functions used to
calculate functional relations are listed first. Identifiers are divided
by commas“, ”, and the string ends with a semicolon“;”.
For example, if the following functions are declared in the Interface
Library:
//Functions to calculate functional dependencies:
function f1(Alpha:TAPar):Real; stdcall;
function f2(Alpha:TAPar):Real; stdcall;
function f3(Alpha:TAPar):Real; stdcall;
//Functions to calculate criteria:
function c1(Alpha:TAPar):Real; stdcall;
function c2(Alpha:TAPar):Real; stdcall;
function c3(Alpha:TAPar):Real; stdcall;
function c4(Alpha:TAPar):Real; stdcall;
then string S is
'f1,f2,f3,c1,c2,c3,c4;'
B. Functions used to calculate criteria and functional relations take a DOUBLE
type dynamic array of design variables and return a DOUBLE type value.
The size of the array depends on the number of design variables. The number
of an array element corresponds to the number of the corresponding design variable
declared in the problem setup. The zero element is not used. When setting up a
problem, it is important to add parameters strictly in accordance with the Interface
Library.
For example, if the Interface Library describes the function for calculating a
sum of masses in the following way:
type
TAPar = array of Double;
function f1(Alpha:TAPar):Double; stdcall;
begin
f1 := Alpha[3]+Alpha[4]; //m1+m2
end;
then in the problem setup, the design variables must be listed in the following order:
1.
2.
3.
4.
5.
. . .
. . .
m1
m2
. . ., etc.
C. The Interface Library exports Init and all functions used to calculate criteria.
– 41 –
9.3. Interface Library Example
Here is the listing of Interface Library for the "Oscillator" example problem
discussed in Section 12. The library was developed in Delphi 5.
Examples of interface libraries written in Delphi 5 and Microsoft Visual C++
can be found in the Examples folder on the CD or in the MOVI 1.0 installation folder.
library oscil; //Library name
uses // modules used by the Library
SysUtils,
Classes;
{$R *.RES}//compiler directive
const //constants used
p = 2000;
om = 30;
type
//type declaration for the design variable vector array
//(dynamic array)
TAPar = array of Real;
function Init(var NPar: Word; var NFun:Word; var NCrit:Word;
var S:PChar):Integer; stdcall;
//required function. Initializes the Library
begin
NPar := 5;
NFun := 3;
NCrit:= 4;
s := 'f1,f2,f3,c1,c2,c3,c4;';
Result := 0;
end;
function f1(Alpha:TAPar):Real; stdcall;
//first functional relation - M1+M2
begin
Result := Alpha[3]+Alpha[4];
end;
function f2(Alpha:TAPar):Real; stdcall;
//second functional relation – p1
begin
Result := sqrt(Alpha[1]/Alpha[3]); //sqrt(k1/m1)
end;
function f3(Alpha:TAPar):Real; stdcall;
//third functional relation – p2
begin
Result := sqrt(Alpha[2]/Alpha[4]);//sqrt(k2/m2)
end;
function c1(Alpha:TAPar):Real; stdcall;
//first criterion – X1d
var
– 42 –
K1, K2, M1, M2, C
: real;
P1, P2, X1D, X1ST, X1DST
: real;
DT, BETA, GAMA, MU
: real;
begin
//define design variables
K1 := Alpha[1];
K2 := Alpha[2];
M1 := Alpha[3];
M2 := Alpha[4];
C := Alpha[5];
//calculations
P1 := sqrt(K1/M1);
P2 := sqrt(K2/M2);
X1ST := P/K1*1000.0;
DT
:= P2/P1;
BETA := M2/M1;
GAMA := OM/P1;
MU
:= C/(2.0*M2*P1);
X1DST:= (4.0*Sqr(MU*GAMA)+Sqr(Sqr(GAMA)-Sqr(DT)))/
(4.0*Sqr(MU*GAMA)*Sqr((1+BETA)*Sqr(GAMA)-1.0)+
Sqr(BETA*Sqr(DT*GAMA)-(Sqr(GAMA)-1.0)*
(Sqr(GAMA)-Sqr(DT))));
X1DST := SQRT(X1DST);
X1D := X1DST*X1ST;
Result := X1D;
end;
function c2(Alpha:TAPar):Real; stdcall;
//second criterion – m = m1+m2
begin
Result := Alpha[3]+Alpha[4];
end;
function c3(Alpha:TAPar):Real; stdcall;
//third criterion – X1d/X1st
var
K1, K2, M1, M2, C
: real;
P1, P2, X1DST
: real;
DT, BETA, GAMA, MU
: real;
begin
//define design variables
K1 := Alpha[1];
K2 := Alpha[2];
M1 := Alpha[3];
M2 := Alpha[4];
C := Alpha[5];
//calculations
P1 := sqrt(K1/M1);
P2 := sqrt(K2/M2);
DT
:= P2/P1;
BETA := M2/M1;
GAMA := OM/P1;
MU
:= C/(2.0*M2*P1);
X1DST:= (4.0*Sqr(MU*GAMA)+Sqr(Sqr(GAMA)-Sqr(DT)))/
(4.0*Sqr(MU*GAMA)*Sqr((1+BETA)*Sqr(GAMA)-1.0)+
– 43 –
Sqr(BETA*Sqr(DT*GAMA)-(Sqr(GAMA)-1.0)*
(Sqr(GAMA)-Sqr(DT))));
X1DST := SQRT(X1DST);
Result := X1DST;
end;
function c4(Alpha:TAPar):Real; stdcall;
//fourth criterion – w/p1
begin
Result := OM/(sqrt(Alpha[1]/Alpha[3]));
end;
exports //list of exported functions
Init,
f1,f2,f3,
c1,c2,c3,c4;
begin
end.
– 44 –
10. DATABASE MANAGER USER'S MANUAL
10.1. Purpose
Database Manager is a part of the MOVI 1.0 distribution package and is
designed to restore damaged problems and to link problems calculated on another
computer. By means of Database Manager, one can change some problem status
parameters while keeping the already calculated data intact.
10.2. Starting the Program and Description of the Interface
To start Database Manager, go to the PROGRAMS menu item of the
Windows START menu, and in the "MOVI 1.0 Software Package" folder select the
“Database Manager” shortcut. The “MOVI 1.0 Software Package” folder appears
after the MOVI 1.0 package is installed on your computer.
After the program is started, Database Manager's main window appears
(Figure 10.1). The left panel shows a problem tree—a list of problems linked to MOVI
1.0. Note that the tree is initially folded. To unfold it, click “+” to the left of the “MOVI
Databases” title, or double click this title.
The right (information) panel displays problem status variables (problem
folder, interface library, etc.) This information appears in the panel when a problem is
selected in the left panel. By default, only information on the problem name, problem
folder, and interface library is available. To display all data, click
. This button will
stay pressed until clicked again. If it is pressed, all data will be displayed in the right
panel when the user moves along the problem tree. This will take more time than
moving when the button is not pressed and only the first three data elements are
displayed.
10.3. Editing the Problem Name, Folder, and Interface Library
When a problem is selected in the left panel, the problem name, folder, and
interface library can be changed. These changes do not require recalculation of the
problem.
To change the name of the problem, double-click PROBLEM NAME. A
dialogue window appears (Figure 10.2). Enter the new name. To confirm the change
click OK; to cancel, click CANCEL.
To change the problem folder or interface library, double-click the respective
string. A dialogue window appears. Enter the new values or click the button to the
right of the edit field, and select the required problem folder or interface library file.
IMPORTANT! Please be very careful when making such changes. If you
are not sure that the new folder contains a database file or that the new
interface library corresponds to the problem being considered, cancel the
operation. A mistake can lead to MOVI 1.0 operation failure.
– 45 –
Figure 10.1
Figure 10.2
10.4. Database Integrity Check
If a system malfunction or power failure occurs when the user is working with
the Test Table or other similar cases, the calculated results can be lost. In such
cases, one may try to restore the calculated results. To do this, select the problem in
which the malfunction occurred in the left panel. Then click the
button (problem
check) on the tool bar. The Database Integrity Report window will appear (Figure
10.3). This window displays a three-column table. The first cell in each row shows
the name of the value being checked, the second shows the true value, and the third
shows the value stored in the database after the malfunction. The latter value may
possibly be erroneous.
– 46 –
Figure 10.3
The icons next to the values in the first column represent the status of the
checked element. The meanings of the icons are explained in Table 10.1.
Table 10.1
Icon
Status of the checked value
The database value corresponds to the calculated value. No need to
change.
The database value is probably not correct. In this case, one should decide
if the value in the third column is correct. If it is not correct, double-click the
name of the checked value. A dialogue window will appear. In this window,
enter or choose the correct value. Be careful when making changes,
since entering wrong values can lead to incorrect operation.
The value is incorrect and must be changed for correct operation. Doubleclick the name of the checked value. The value will be corrected
automatically and the icon will change to .
Close the windows after all changes have been made. In 90% of all cases,
such problems can be restored. The remaining 10% consist of problems that were
damaged by mistakes during restoration when the fields marked
were filled with
incorrect values.
Remark. When restoring a problem that malfunctioned after the work with the
full table, indicate which table you worked with (full table – Table I, or quick algorithm
– Table II), regardless of the values in the second and third columns.
10.5. Adding and Deleting a Problem
To add a problem calculated by another instance of MOVI 1.0 (which can be
installed either on another computer or on the same computer in another folder), do
the following:
1. Copy all files from the problem folder on the computer that was used for the
calculations to a new folder on the computer with the MOVI 1.0 package to
which the problem will be added.
– 47 –
2. Start Database Manager, and click the
button on the tool bar or press the
INS key. A dialogue window will appear (Figure 10.4). Fill all fields in this
window: enter the problem name in the NAME field, the path to the problem
files in the PROBLEM FOLDER field, and the full interface library name (with
path) in the INTERFACE LIBRARY field.
When all fields are filled, click OK to add the problem to MOVI 1.0, or click
CANCEL to cancel the operation.
The added problem will appear in the problem list in the left panel.
To delete a problem, select it in the left panel and click
on the tool bar or
press the DEL key.
Figure 10.4
– 48 –
11. MOVI 1.0 OPERATION
The MOVI 1.0 software package is controlled by means of menus. The
items in the main menu are represented by buttons arranged in the left portion of
the screen and are repeated in the Main Menu
In the right-hand portion of the screen, the name of the task, the number of
design variables (design parameters), functional relations and performance
criteria, as well as the total number of tests and the number of vectors (designs)
in the test table and in the feasible set, are displayed (see Figure 11.1). Some
items end with ellipses (…), indicating that an embedded menu will appear during
execution of the corresponding item.
To switch between control elements (buttons or edit fields), use either the
mouse or keys.
Press TAB to move to the next field and SHIFT+TAB to return to the
previous field.
The envelope of MOVI 1.0 has a system of context-dependent messages
(prompts). To call a prompt, press the F1 key.
The structure and intended use of the files formed during the operation of
the MOVI 1.0 software package are explained in Appendix B.
Figure 11.1
– 49 –
11.1. Main Menu Item DATA INPUT
DATA INPUT allows one to create a new task or to edit an available task
and link it to MOVI 1.0. This item is implemented first. It has an embedded menu.
11.1.1. Embedded Menu Item NEW TASK
NEW TASK is used to create a new task. Before the user can start
working with a new task, a dialogue window will appear requiring confirmation
that the work with the current task has been completed.
When NEW TASK is selected, a dialogue window with one page will
appear (see Figure 11.2). This page informs the user about the name of the task
the location of the task folder and the interface module, as well as the parameters
of the interface module.
The name of the new task to be created should be entered in the TASK
NAME field. This information allows the user to see what task is currently loaded.
Entering the task name is mandatory.
The path to the place on the disk where the working files of the task will be
located is indicated in the TASK FOLDER field. By default, this folder is
organized as “<PATH TO SOFTWARE MOVI 1.0>\PROBLEMS\<TASK NAME>”,
but the user can change it as desired. If this folder does not exist, it will be
created automatically. One can also create the folder by using the button located
to the right of the edit field. In this case, a standard dialogue window for folder
selection will appear.
In the INTERFACE LIBRARY field, the path to the interface library is
indicated. One can also use the button to the right of the input field to select a
library in the standard dialogue window for loading files. The library file will be
displayed if Windows is tuned to display system and auxiliary files1.
.
Figure 11.2
1
You can adjust the Windows settings using “Explorer” menu
– 50 –
To continue operating, press the ATTACH LIBRARY button. The library
file will be copied to the task folder and linked to the package. In case of failure,
an error message will appear. Otherwise, the parameters of the interface module
will be displayed in the panel at the bottom of the window and the DESIGN
VARIABLES, FUNCTIONAL CONSTRAINTS, and CRITERIA pages will be
accessible for entering the input data of the task (see Figure 11.3).
Figure 11.3
– 51 –
11.1.1.1. DESIGN VARIABLES Page
The DESIGN VARIABLES page is intended for entering information about
the design variables (see Figure 11.4). The list of design variables is displayed in
the table.
To enter a design variable, fill in the edit fields at the bottom of the page.
The name of the design variable should be entered in the NAME field, and the
boundaries of the range of this variable are entered in the LOWER BOUND and
UPPER BOUND fields. By default, all design variables are treated as continuous.
If the design variable is discrete, it is necessary to put a checkmark in the
DISCRETE field. This will activate the LIST OF VALUES button. Pressing this
button will open the DISCRETE VALUES OF DESIGN VARIABLE window (see
Figure 11.5). The values that the design variable is allowed to assume should be
entered in the edit field. All values that have been entered are displayed in the
right-hand portion of the window. Edit this list using the buttons
(to add data),
(to delete data), and
(to correct data). After the design variables have
been entered, close this window or press OK to return to the DESIGN
VARIABLES page. Then press the ADD button. The added variable will appear in
the table.
Figure 11.4
Figure 11.5
– 52 –
In order to edit a previously entered design variable, it is necessary to
highlight it in the table, then use the fields at the bottom of the page. To accept
the change, press the CHANGE button. To delete the design variable, highlight it
in the table and press the DELETE button.
IMPORTANT: The number of design variables that are introduced
must not exceed the limiting value declared in the interface module. If the
user tries to add design variables beyond this value, a warning message
will appear.
11.1.1.2. FUNCTIONAL CONSTRAINTS Page
The FUNCTIONAL CONSTRAINTS page is intended for entering data on
functional constraints (see Figure 11.6). The list of values entered is displayed in
the table. The edit fields at the bottom of the page allow the user to enter or
change the data.
Use the NAME field to enter the name of the functional constraint, for
example, f 1( m 1+ m 2).
The FUNCTION NAME field presents a drop-down list of the names of the
functions declared in the interface module. The functional relation will be
calculated in accordance with the function selected from this list.
The COMPARISON field presents a drop-down list of various comparison
operations. Use this field to select the type of constraint for the specified
functional relation, for example,  .
Use the CONSTRAINT field to enter the constraint imposed on the
functional relation, for example, 1100.
The information entered as shown above corresponds to the inequality
f 1  1100 .
If some functional relation is subject to a two-sided constraint, for example,
*
cn  f n  cn** , then this functional relation should be entered twice, first with the
constraint cn*  f n and then with the constraint cn**  f n .
The procedure for editing this page is quite similar to that of the DESIGN
VARIABLES page.
Figure 11.6
– 53 –
11.1.1.3. CRITERIA Page
The CRITERIA page is intended for entering data about the performance
criteria (see Figure 11.7). To edit this page, use the fields at the bottom of the
page. The procedure for editing this page is quite similar to that of the previous
two pages.
Use the NAME field to enter or change the name of the performance
criterion.
The FUNCTION NAME field presents a drop-down list of the names of the
functions declared in the interface module.
Use the MIN/MAX field to select an extremalization operation. If MIN is
selected, the values of the criterion (or pseudo-criterion) in the test table will be
arranged in increasing order, i.e., from smaller to larger. If MAX is selected, the
values of this criterion (or pseudo-criterion) will be arranged in decreasing order.
If the function in question is interpreted as a pseudo-criterion, put a
checkmark in the PSEUDO-CRITERION field. By default, all functions are
interpreted as criteria.
If there are primary constraints imposed on the performance criteria, put a
checkmark in the PRIMARY CONSTRAINTS field and enter the corresponding
constraint in this field.
11.1.2. Embedded Menu Item LOAD TASK
A window with the list of tasks appears. Use the cursor to select one of
these tasks and to link it to the MOVI 1.0 package. This item also allows the user
to delete any task from the list (see Figure 11.8).
Figure 11.7
– 54 –
Figure 11.8
11.1.3. Embedded Menu Item EDIT TASK
A window similar to that of the EDIT TASK item appears.
The DESIGN VARIABLES, FUNCTIONAL CONSTRAINTS, and
CRITERIA pages are similar in all respects to the pages with the same names in
the item NEW TASK. These pages are edited in the manner described in Section
11.1.1.
Remark. On the TASK page, the user can attach a new interface library
and change the name of the task. Changing the name of the task preserves the
results calculated previously. If a new interface library is attached, the task has to
be recalculated. Changing the task folder is not allowed.
On the three abovementioned pages, DESIGN VARIABLES,
FUNCTIONAL CONSTRAINTS, and CRITERIA, there are colored fields.
Changing data in these fields requires all calculations of the task to be redone.
For example, on the DESIGN VARIABLES page, there are three colored fields:
LOWER BOUND, UPPER BOUND, and DISCRETE. Suppose that we performed
some optimization computations and then discovered that in the process of
stating the problem, the value of the lower bound for some design variable on the
DESIGN VARIABLES page was specified incorrectly. In this case, we make an
appropriate correction in the LOWER BOUND field and press the CHANGE
button. Then the message “This change will require recalculation of the task. Are
you sure that you wish to make this change?” will appear. Pressing the OK button
deletes the results of the previous calculations, and the user will have to solve
the problem again. Pressing the NO button preserves the previous results. In the
latter case, the user can also solve the problem again, if necessary.
11.2. Main Menu Item CHECK OF PRIMARY CONSTRAINTS
Use this item to check the functional constraints, as well as the primary
criteria constraints (if any). The execution of this item is mandatory.
Selection of this item opens a window in which two fields should be used
to enter the numbers of tests, for example, from 1 to 512 (see Figure 11.9). In
– 55 –
addition, this window presents the current information on the results of checking
the primary constraints.
When LP sequences are used, it is desirable that the number of tests be
equal to 2 n . If one then chooses to continue testing to the number N, one should
enter this number in the second field. If it is impossible to guarantee N  2n , N
may be specified as an arbitrary integer.
11.3. Main Menu Item TEST TABLES
Use this item to calculate the performance criteria, generate the test
tables, determine the criteria constraints, and construct the feasible and Pareto
optimal sets (see Figure 11.1). The execution of this item is mandatory. The item
TEST TABLES must be executed after the item CHECK OF PRIMARY
CONSTRAINTS. TEST TABLES has an embedded menu with two items: TEST
TABLE I and TEST TABLE II. The second item utilizes the so-called fast
algorithm, which allows one to save time when solving the optimization problem.
However, selection of TEST TABLE II may complicate the determination and
correction of the criteria constraints  *2* ,...,  *i * ,... , compared with TEST TABLE I.
Figure 11.9
– 56 –
11.3.1. Embedded Menu Item TEST TABLE I
When this item is selected, the FULL ORDERED TEST TABLE window
opens (see Figure 11.10). We use the following notation: N is the number of tests
performed, N1 is the number of design variable vectors that are entered the test
table, and ND is the number of design variable vectors in the feasible set. If
N1  ND immediately after construction of the test table, this means that the
cursor does not stand on the last row in some columns. To set the cursor on the
last row, press the
button and then press the ND button. For each criterion,
two columns are reserved for entering the numbers of the design variable vectors
and the respective values of the criterion. If some criterion is to be minimized, the
values of this criterion are arranged in increasing order. If a criterion is to be
maximized, its values are arranged in decreasing order. The minimum and
maximum values of each criterion are presented in the first rows of the table. For
brevity, in what follows, we use the terms design variable vector, design, and
solution as synonyms.
As a rule, some values of the criteria are unfeasible. Therefore, it is
necessary to introduce criteria constraints. The criteria constraints are imposed
as follows. Using the cursor, the designer marks in each column a value of the
respective criterion whose feasibility he/she does not doubt. If this criterion is to
be minimized, it is desirable that the selected value be the maximum of all
feasible values (In the case of maximization, this value should be a minimum.)
This is necessary in order not to lose fairly good solutions if there are competing
(contradictory) criteria. The criteria constraints are marked with color in the table.
Above each column, the number of the respective criterion, its maximum and
minimum values, and the number of designs satisfying all criteria constraints
(from the first to the current one), ND, are presented.
Suppose that we consecutively determined j criteria constraints
 ,..., *i * ,..., *j* ,... and then decided to revise the constraint  *i * . This may affect
the number of feasible solutions in the columns lying to the right of the column
with number i. In order for the program to recalculate the number of feasible
solutions, after changing  *i * , one should press the ND button or the ENTER key
or move the cursor to a column lying to the right of the column with number i.
**
1
Assume that in the ith column of the test table we have several close
values of the corresponding criterion and that all these values are feasible. If the
criteria constraints are to be determined with these values, it is necessary to set
the cursor on the last (worst) value.
After determining all criteria constraints, one can construct the feasible set
(the set of feasible solutions). Pressing the RESULT button opens the FEASIBLE
AND PARETO OPTIMAL SOLUTIONS window (see Figure 11.11). This window
is divided into four panels. The first panel presents the total number of tests, the
number of tests that entered the table, the number of feasible solutions, and the
number of Pareto optimal solutions. The second panel contains information about
all criteria constraints. The third and fourth panels present the total number and
individual numbers of the feasible and Pareto optimal solutions, respectively.
– 57 –
Figure 11.10
Figure 11.11
– 58 –
To display information about the criteria constraints, one can also press
the CONSTRAINTS button in the FULL ORDERED TEST TABLE window. To
select a criterion, use the keys that move the cursor left and right or use the
and
buttons. To increase the number of tests, press the CONTINUE
TESTING button. To construct a complete test table, it is recommended that the
number of tests in the table with up to 20 criteria not exceed approximately
4000.
Construction of the truncated test table. If the test table contains a
large number of solutions and the number of criteria is also large, this table may
prove to be rather complicated to work with. These difficulties are aggravated if
the solution of the design problem requires tens of thousands of tests to be
performed. If one removes from this table all solutions that do not satisfy the
criteria constraints, its length will substantially decrease. The user can obtain
such a table by pressing the TRUNCATED TABLE button after determining the
feasible set (see Figure 11.10). When the TRUNCATED TABLE button is
pressed, the CONSTRUCTION OF TRUNCATED TABLE window opens (see
Figure 11.12). This window displays the total number of tests performed – N, the
number of solutions in the truncated table – N2, and the number of solutions in
the feasible set – ND. In addition, it presents the list of criteria and indicates the
type of each criterion (criterion or pseudo-criterion), the type of extremalization
(minimization or maximization), and the values of the criteria constraints. To
generate the truncated table, press the YES button (see Figure 11.13). Then the
user can continue testing, if necessary. After that, the user should set the cursor
on the last place in all columns of the truncated table by pressing the
button
or using the cursor control keys. Then press the ND button. The user can also
revise the criteria constraints in the truncated table.
Figure 11.12
– 59 –
It will be helpful to note a number of specific features of working with the
truncated test table.
(i) It may happen that in the ith column of the full or truncated table, the values
 i  p  and  i  m  satisfying the inequality  i  p    i  m  follow one
another. Suppose we wish to introduce as a primary criterion constraint a
value  *i * that does not occur in the ith column but must satisfy the condition
 
 
 i  p   *i *   i  m (or it may be greater than the last value in this column).
In this case, we set the cursor on the value  i  p  in the table and press the
TRUNCATED TABLE button. The CONSTRUCTION OF TRUNCATED TABLE
window will appear. In the VALUE column, we click the row corresponding to
this criterion constraint. Then a menu with three items, UPPER VALUE,
LOWER VALUE, and NEW VALUE, appears (see Figure 11.14). In this menu,
we select NEW VALUE. The CONSTRAINT VALUE edit field will appear. We
enter the value  i in this field and press the
button. The value  i will be
automatically entered in the VALUE column. We press the YES button to
construct the truncated table (see Figure 11.14) and then continue testing.
(ii) Suppose the user wishes to sharpen the constraints on some criteria, leaving
the others unchanged. In this case, he/she should set the cursor on the values
of the criteria that he/she wishes to treat as new constraints. For the other
criteria, the cursor should be set on the last place.
Then, press the TRUNCATED TABLE button. A window will appear in
which the user should click the row corresponding to the criterion constraint
that is not subject to change. To preserve the value of this constraint, the user
should select the item LOWER VALUE in the embedded menu that appears
(see Figure 11.14). If we choose to sharpen a criterion constraint in the
truncated table, then by default the value indicated by the cursor is treated as
this criterion constraint. This corresponds to the UPPER VALUE item of the
embedded menu.
When the number of tests is increased without changing the criteria
constraints, pressing the TRUNCATED TABLE button is unnecessary.
(iii) Let testing be continued in the truncated table. (This condition is not
necessary.) Let the feasible set have been constructed and let the user
choose to relax the constraints on some criteria. To do this, press the
EXTEND button. The EXTENSION OF TRUNCATION TABLE window will
appear on the screen (see Figure 11.15).
To relax a constraint value by which the table has been truncated, doubleclick this value. Then replace this constraint value by a less restrictive one and
press the ACCEPT CONSTRAINTS button. The criterion vectors satisfying the
new (relaxed) constraints will be included in the truncated test table.
– 60 –
Figure 11.13
Figure 11.14
Figure 11.15
– 61 –
One can also define a new constraint value by analyzing the full test table
from which the user has chosen to proceed to the truncated table. To return to
the full test table, press the RETURN button. This table will have preserved
the values of the criteria constraints by which the table was truncated. Note
that this table will contain feasible designs corresponding to new tests
performed with the truncated table. In addition, it will contain new designs that
satisfy not only the last criterion constraint, but others as well.
After returning to the full table and correcting constraints, the user can
construct a new truncated table with the relaxed constraints by pressing the
TRUNCATED TABLE button.
If the analysis of the full table does not allow one to define the relaxed
constraints or the results obtained are unacceptable, one should refer to the
table of criteria failures (see Section 11.4.2).
(iv) Sometimes it may not be necessary to impose constraints on some criteria
when working with the truncated table. In this case, set the cursor on the last
row in the columns corresponding to these criteria in the full test table. Then
press the TRUNCATED TABLE button, and in the window that appears, click
the value of the criterion that should not be constrained (see Figure 11.14). In
the embedded menu that appears, select LOWER VALUE. Then construct a
new truncated table.
One should also proceed in a similar way when the full table is constructed
with primary constraints imposed on some criteria. To truncate this table
without changing the primary constraints, use the TRUNCATED TABLE
button. In the window that appears, click the value of the criterion for which the
primary constraint should not be changed. An embedded menu will appear.
From the three items in this menu, select LOWER VALUE. Then construct the
truncated table
11.3.2. Embedded Menu Item TEST TABLE II
When this item is selected, the TEST TABLE: FAST ALGORITHM
window appears on the screen. Initially, this table has one column corresponding
to the first criterion (see Figure 11.16). In this table, N is the number of tests, N1
is the number of solutions that entered the first column, and ND is the number of
feasible solutions.
~
Denote by ** the value of the th criterion that must not be exceeded in
~
any case. (If some of the values ** are known before solving the problem, these
values should be entered as primary constraints using the item DATA INPUT,
see Section 11.1) After obtaining the table for the first criterion, the user should
~
enter the constraint on this criterion,  1** (see Section 11.1.1.3). Entering this
constraint is desirable but not mandatory if, for example, the user fails to define
~
~
the value of  1** . To remove the designs that do not satisfy the constraint  1**
from the table, use the
button. Then, by analyzing the values in the table for
~
the first criterion, the user enters the criterion constraint  1** . For the designs
satisfying this constraint, the criterion  2 is calculated. The values of this
criterion appear in the second table on the display screen. One should work with
~
this table as with the table for the first criterion, entering constraints  *2* and  *2* .
– 62 –
Figure 11.16
For designs satisfying the constraints 1** and  *2* , the criterion  3 is
calculated, and so on. After performing these operations with all criteria, we will
obtain the test table (see Figure 11.17). We can proceed from this table to the
truncation test table, which has the same structure as that of the item TEST
TABLE I.
If the user is not satisfied with the solutions obtained, we recommend the
following strategy:
1. Let the analysis of the table show that the criterion constraint imposed on a
criterion  m , m  k (or on several criteria) is inappropriate. Then it is
necessary to change this constraint. To do this, the user should return to the
table for this criterion, change the constraint, and press the ENTER key or the
ND button. If the considered column does not contain a value that could be
taken as a new criterion constraint, set the cursor on the nearest value less
than the desirable constraint. Then press the TRUNCATED TABLE button.
The CONSTRUCTION OF THE TRUNCATED TABLE window will appear in
which one should click the row corresponding to the constraint being
considered. A menu will open. Select the item NEW VALUE in this menu and
then enter the desirable value of the criterion constraint in the edit field. After
that, for the designs satisfying this new constraint, the values of the criterion
 m 1 will be calculated and the constraint *m*1 will be checked. For the
designs satisfying this constraint, the values of  m  2 will be calculated, and
so on. One can continue testing if necessary.
– 63 –
Figure 11.17
2. If the analysis of the table does not allow one to identify the constraints that
lead to the unsatisfactory result, it is necessary to relax the criteria constraints
consecutively, beginning with the last constraint  *k* . If relaxing  *k* does not
improve the result,  *k*1 should be relaxed. Then, for the designs satisfying this
constraint, the values of the criterion k are calculated. If this also does not
improve the result, this procedure should be repeated with the criterion  k  2 ,
and so on to 1 . Note, however, that the sequence suggested for revising
(relaxing) the criteria constraints is not the only possible one for improving the
designs.
3. Let the truncated table have been constructed and suppose one wishes to
relax some of the criteria constraints. In this case, one should press the
RETURN button to return to the analysis of TEST TABLE II.
IMPORTANT NOTE:
You have already constructed the test table and determined the sets
of feasible solutions and Pareto optimal solutions.
You have analyzed the results obtained (see also Sections 11.4.3 and
11.4.4) and defined the solution that is most acceptable to you. Thus, you
can consider the problem to have been solved.
In what follows, we will speak about various approaches to
improving this solution.
– 64 –
11.4. Main Menu Item TABLES
This item can be executed only after the item TEST TABLES. The item
TABLES has an embedded menu with four items: TABLE OF FUNCTIONAL
FAIULURES, TABLE OF CRITERIA FAILURES, TABLE OF CRITERIA, and
TABLE OF DESIGNS.
11.4.1. Embedded Menu Item TABLE OF FUNCTIONAL FAILURES
Only those solutions that satisfy all functional constraints enter the test
table. Designs that fail to satisfy these constraints enter the table of functional
failures. An analysis of the table of functional failures allows one to understand
how the functional constraints “work” and, if necessary, to correct them. The table
of functional failures has two fields on the top panel: the left-hand NAME field and
the right-hand CONSTRAINT field. The table itself lies below this panel (see
Figure 11.18). This table contains information about all the design variable
vectors that do not satisfy the functional constraints. Between the top and bottom
panels, information about the vectors that failed to satisfy functional constraints is
presented. This information includes the total number of tests conducted, the
total number of functional failures, and the number of functional failures for each
functional constraint c j . Use the NAME field to select the functional relation to
be analyzed. For example, let the jth functional relation be selected. Then the
corresponding functional constraint c j will appear in the right-hand CONSTRAINT
field, and the list of numbers of the designs that failed to satisfy this constraint will
appear in the second column of the table. If the constraint has the form
f j ( i )  c j , these numbers are arranged in decreasing order of the value f j (see
the first column). For a constraint of the form f j ( i )  c j , these numbers are
arranged in increasing order of f j .
The information obtained allows the designer to estimate the values
assumed by the design variable vectors that do not satisfy the jth functional
constraint and to find out whether it is possible to change this constraint so that
as many designs as possible will satisfy it.
Figure 11.18
– 65 –
To do this, the designer selects the functional relation f j in the NAME
field. Then, using the table, the designer determines the values assumed by the
function f j and estimates to what extent he/she can change the corresponding
value c j so that a number of designs will meet this constraint. Next, he/she
introduces a new (relaxed) value c j in the CONSTRAINT field and gives the
command to change the functional constraint. The designs that meet this new
constraint will then be tested to find out if they satisfy all subsequent constraints,
if any. The designs that satisfy all functional constraints enter the test table. (If we
are dealing with the truncated table, these designs may enter either the truncated
table or the table of criteria failures.) Taking into account a possible shortage of
computer time for calculating the functional relations, it is advisable to relax the
functional constraints, beginning with the last one, c p . Then, if necessary and
possible, the constraint c p 1 can be relaxed, and so on.
When relaxing functional constraints, the designer can also proceed as
follows. First, he/she identifies all functional relations on which the constraints
can be relaxed and then, using the table of functional failures, defines a new
(relaxed) value of the functional constraint and enters this change in the table.
Using the table of functional failures, the designer obtains all the
information required to correct the functional constraints. The analysis of the
table of functional failures does not cause any difficulties.
11.4.2. Embedded Menu Item TABLE OF CRITERIA FAILURES
This item can be used for relaxing criteria constraints in order to improve
the results obtained previously. Let a number of tests have been performed when
working with the truncated table and let the necessity of relaxing some of the
constraints have arisen. To define the values of the new (relaxed) constraints,
use the RETURN or EXTEND button. If the designer is not quite satisfied with the
results, he/she can try to improve them by using the table of criteria failures. The
table of criteria failures contains design variable vectors that failed to satisfy the
constraints  ** ,  1, k  1 .
The table of criteria failures can also be used after primary constraints for
some criteria have been entered in the DATA INPUT menu item and the full test
table has been constructed. Let the analysis of the table of criteria failures have
revealed the necessity of relaxing a primary constraint (except for the constraint
on the last criterion). This relaxation can be implemented by performing the
operations described below. If it is necessary to relax the primary constraint on
the last criterion, one should truncate the full test table and then press the
RETURN button. Then, after analyzing the truncated table, one can change this
constraint. Note that the tests that satisfy all criteria constraints, except for the
constraint on the last criterion, will enter the full test table.
When the item TABLE OF CRITERIA CONSTRAINTS is chosen, a
window opens (see Figure 11.19). This window has a CRITERION field with a
drop-down list of criteria (or pseudo-criteria). When one of these criteria is
chosen, the value of the criterion constraint that has been defined by using the
RETURN or EXTEND button automatically appears in the CONSTRAINT edit
field. The window informs the user about the total number of criteria failures and
the number of designs that failed to satisfy each of the criteria constraints.
– 66 –
Figure 11.19
In the bottom portion of the window, the numbers of the designs that failed
to satisfy the selected criterion constraint, as well as the values of the
corresponding criterion for these designs, are indicated. By analyzing the values
of this criterion and comparing them with the corresponding constraint, the user
can determine whether he agrees with this constraint or some change is still
possible. In the first case, press the CHANGE button. In the second case, enter a
new constraint value in the CONSTRAINT field and then press the CHANGE
button. The designs that satisfy the new criterion constraint will be tested to find
out whether they satisfy the subsequent constraints. The designs that satisfy all
constraints will enter the truncated test table. An operation similar to the one
described in this section should be performed for all criteria on which the user
has chosen to relax the constraints.
Let the truncated test table have been constructed in accordance with the
item TEST TABLE II and let the tests be continued.
Let the criteria constraints  *j* and  *i * , j < i  k  1 , have been relaxed in
the truncated test table. For some problems, updating the test table after
relaxing the constraint on the criterion  j in the table of criteria failures may
require considerable time, which the designer may not have. On the other hand,
it can happen that he/she is satisfied with the results of relaxing the constraint on
the criterion  i . In this case, the designer may decide against relaxing the
constraint on the criterion  j in the table of criteria failures. If acceptable results
have been obtained after relaxing constraints in the truncated table, whereas
relaxing constraints in the table of criteria failures requires an unacceptable
amount of computer time, the designer may decide not to go to the table of
criteria failures. One should also take all these considerations into account when
relaxing the functional constraints in the table of functional failures.
11.4.3. Embedded Menu Item TABLE OF CRITERIA
This item allows one to obtain information about the values of the criteria
vectors belonging to the feasible set or the Pareto optimal set. When this item is
chosen, the TABLE OF CRITERIA window will appear. After FEASIBLE SET or
PARETO OPTIMAL SET is selected in the drop-down list, the numbers of the
– 67 –
solutions belonging to the respective sets and the corresponding values of the
performance criteria appear in the table of criteria (see Figure 11.20). By
checking or unchecking the SHOW PSEUDO-CRITERIA check box, one can add
to or remove from the screen the columns with pseudo-criteria.
11.4.4. Embedded Menu Item TABLE OF DESIGNS
When the item TABLE OF DESIGNS is selected the DESIGN VARIABLE
VALUES window opens (see Figure 11.21). This window has three input fields.
The third field has a drop-down list with three items: FEASIBLE SET, PARETO
OPTIMAL SET, and BY NUMBERS. By selecting the first or the second item, one
can obtain information about feasible or Pareto optimal designs, respectively.
Using BY NUMBERS, one can display the components of an arbitrary sequence
of consecutively numbered design variable vectors on the screen. To do this,
select BY NUMBERS in the drop-down list. Then, enter the number of the first
vector whose components should be displayed in the first field, and the number
of the last vector in the second field.
Figure 11.20
Figure 11.21
– 68 –
11.5. Main Menu Item HISTOGRAMS AND GRAPHS
After solving an optimization problem, questions very often arise as to
whether it is possible to improve the solutions obtained, perhaps by correcting
the primary constraints imposed on the design variables, and how to determine
these improved solutions. We will indicate two possibilities for improving the
solutions. The first possibility implies no change in the design variable
constraints. The other possibility requires the construction of a new
parallelepiped for the design variables. The new parallelepiped is constructed on
the basis of an analysis of histograms and graphs.
This item can be selected after executing the item TEST TABLES, when
the feasible set and the Pareto optimal set have been constructed. The item
HISTOGRAMS AND GRAPHS has an embedded menu consisting of two items:
HISTOGRAMS and GRAPHS.
11.5.1. Embedded Menu Item HISTOGRAMS
When this item is selected, the HISTOGRAMS: FEASIBLE SET window
appears (see Figure 11.22). Select a desirable design variable in the DESIGN
VARIABLE field. The histograms of the feasible solutions will appear in the
*
**
window. The interval [ j ; j ] is divided into ten identical subintervals. Above
each subinterval, the number of feasible designs entering this subinterval is
indicated. To show the arrangement of Pareto optimal designs on a histogram,
check the SHOW PARETO OPTIMAL DESIGNS check box. The percentage of
designs entering the corresponding interval is indicated in the right-hand portion
of the screen. The panel at the bottom indicates the number of the interval, its
boundaries [  *ji ; *ji* ] , the number of feasible and Pareto optimal design variable
vectors in this interval, and the numbers of these vectors. The number of a
Pareto optimal vector is labeled by the letter P. Analysis of the histograms
reveals how the feasible designs are distributed. This information may prove to
be helpful when correcting the ranges of the design variables in order to improve
the results of optimization.
11.5.2. Embedded Menu Item GRAPHS
This item has an embedded menu with two items: CRITERION VERSUS
DESIGN VARIABLE I and CRITERION VERSUS DESIGN VARIABLE II.
First consider the item CRITERION VERSUS DESIGN VARIABLE I.
After analysis of the test table, let preference be given to the design variable
vector
 i . Let us fix all components of this vector, apart from one,  ij , and find
out how the functions 1 ,...,  k (or some of them) change as the component
 ij varies on the original interval [  *j ; *j* ] .
– 69 –
Figure 11.22
To do this, we construct the appropriate graphs. If good solutions lie near
the boundaries  *j or  *j* or the graph shows that some criteria tend to improve
as the design variable approaches the boundaries of the design variable
constraints, it is of interest to investigate the behavior of the criteria beyond these
boundaries. In this case, one should define new boundaries  *j   *j or  *j*   *j* ,
where  *j * is the value of the change in the boundary  *j * , and perform tests in
the new parallelepiped. If these variations of the boundaries improve the
solutions obtained previously, this fact is of interest to the designer. The analysis
of the results has a nonformal nature. The final decision regarding the
acceptance of the new design variable constraints depends on the values of the
performance criteria achieved by extending the design variable ranges.
When the item CRITERION VERSUS DESIGN VARIABLE I is selected,
the GRAPH OF CRITERION VERSUS DESIGN VARIABLE I window appears
(see Figure 11.23). This window has five fields. In the CRITERION and DESIGN
VARIABLE fields, one should select the desirable criterion and design variable.
To draw the graph, all design variables, apart from the design variable  ij
being investigated, should be fixed. Therefore, only the design variable to be
varied should be select in the DESIGN VARIABLE field.
– 70 –
Figure 11.23
This window also has two additional fields: TEST FROM and TO. In the
former field, one should set the number of the initial test (for example, 1) and in
the latter field, the total number of tests, N. (As a rule, the number N is taken to
be relatively small, for example, 32.) All performance criteria to be analyzed will
be calculated at N points of the range of the design variable  ij in order to
construct the corresponding graph.
Enter the number of the design variable vector to be investigated, i , in the
FIXED VECTOR field. For example, this could be one of the Pareto optimal
vectors identified previously. Press the DRAW button to draw the corresponding
graph in the window. The interval [  *j ; *j* ] is separated off on the X-axis, and the
values of the criterion are measured along the Y-axis. The graph shows feasible,
Pareto optimal, and unfeasible points. Different types of points are shown in
different colors. All points are connected by a curve (see Figure 11.23). To the
right of the FIXED VECTOR field, there is a button
; when this button is
pressed, the CORRECTION OF VALUE OF DESIGN VARIABLE VECTOR #
window appears (see Figure 11.24). This window informs the user about fixed
components of the design variable vector  i and indicates the variable
component that was previously defined in the DESIGN VARIABLE field.
Using CORRECTION OF VALUE OF DESIGN VARIABLE VECTOR #
window, one can change the values of the fixed design variables. Then, the
ACCEPT NEW VALUES button should be pressed. The graph corresponding to
the new values of the fixed design variables will appear on the screen.
In the top left-hand corner of the GRAPH OF CRITERION VERSUS
DESIGN VARIABLE I window, the number of tests N, the number of feasible
solutions ND, and the number of Pareto optimal solutions NP are displayed.
On the top panel of this window, there is a menu with the items GRAPH
and VIEW.
– 71 –
Figure 11.24
The item GRAPH has an embedded menu with the following items:
 PRINT
 OUTPUT IN A NEW WINDOW
 FIRST KIND CONSTRAINTS
 KIND CONSTRAINTS
 SAVE
 SAVE AS BITMAP
 OPEN
The item OUTPUT IN A NEW WINDOW is used for drawing graphs in a
separate window and representing several graphs on the same screen. When
this item is selected, the panel with graphs disappears from the screen and only
the panel for data input remains. By analogy with what has been described
above, one should (i) select a fixed vector, the component of this vector to be
varied, and the performance criterion; (ii) prescribe the number of tests; and (iii)
press the DRAW button. A graph will appear in a separate VECTOR # window.
This window can be moved to any place on the screen. Other graphs can also be
constructed. Thus, this item allows one to draw several graphs on a large screen
(see Figure 11.25). This provides the user with a more convenient means of
comparing and analyzing graphs. The VECTOR # window has an embedded
menu allowting one to construct two types of graphs. The first type of graphs take
into account both feasible and unfeasible (i.e., they failed to satisfy criteria and
functional constraints) solutions. The second type of graphs involve only feasible
and Pareto optimal solutions.
In the VECTOR # window, there are two menu items: GRAPH and VIEW.
The former item allows one to print graphs. The latter item has an embedded
menu with the following items: TABLE OF VALUES, FEASIBLE SOLUTIONS,
ALL SOLUTIONS, NAME, and LIST OF NAMES.
Before drawing a graph, one should mark the check box either in the item
CONSTRAINTS OF THE FIRST KIND or in the item CONSTRAINTS OF THE
SECOND KIND of the embedded menu. Constraints of the first kind cover
primary constraints and/or constraints introduced by the user in the full test table.
If, after constructing the truncated table, the user changes some constraints in
this table, the modified constraints will be constraints of the second kind.
– 72 –
Figure 11.25
When the menu item VIEW is chosen, a menu with the following items
appears in the GRAPH OF CRITERION VERSUS DESIGN VARIABLE I window:
 TABLE OF VALUES
 ALL SOLUTIONS
 FEASIBLE SOLUTIONS
 CALCULATE ALL CRITERIA
When the item TABLE OF VALUES is selected, a TABLE OF VALUES
window opens, displaying the values of the criteria to be improved (a prototype),
as well as the criteria constraints (see Figure 11.26).
In the bottom portion of the window, there is a table on the basis of which
the graph has been constructed. This table has N rows and a number of
columns. The first column contains the numbers of the design variable vectors j.
The values of the variable component of the design variable vector,  i j , j  1, N ,
are arranged in increasing order in the second column. Consider a row of this
table. To the vector number j indicated in the first column, there corresponds a
value of the design variable  i j , j  1, N in the second column. This value is
followed by a list of the values of the performance criteria from 1 to  k . These
values have been defined for the given value of  i j , with the other design
variables being fixed.
In the left column, there are the letters P, C, D, and F, as well as numbers
identifying design variable vectors. The letter P identifies Pareto optimal
solutions; D, feasible solutions; C, solutions that failed to satisfy criteria
constraints; and F, solutions that failed to satisfy functional constraints.
Consider the item CALCULATE ALL CRITERIA. Let the feasible and
Pareto optimal solutions have been determined previously. To draw the graphs
 ( j ) , press the DRAW button. However, it may happen that the designer
wishes to analyze only one of the graphs  ( j ) without calculating the values
of the other criteria. To that end, it is necessary to remove the marker in the item
CALCULATE ALL CRITERIA and press the DRAW button. In this case, the
record NP=0 appears informing the user that Pareto optimal solutions have not
been calculated.
– 73 –
Figure 11.26
Now consider the item CRITERION VERSUS DESIGN VARIABLE II.
When this item is selected, the GRAPH OF CRITERION VERSUS DESIGN
VARIABLE II window opens. The main menu of this window has the item GRAPH
with an embedded menu containing the following items:




PRINT
SAVE
SAVE AS BITMAP
OPEN
The panel at the top of the window contains information about the total
number of tests N, the number of tests that entered the test table N1, the number
of feasible solutions ND, and the number of Pareto optimal solutions NP. (These
data are obtained from the full test table. If the truncated test table has been
constructed, then these data are automatically taken from the full table that could
be constructed by pressing the RETURN button.) This window has two edit fields:
CRITERION and DESIGN VARIABLE. The desired graph will be constructed
after pressing the DRAW button. The points corresponding to the numbers N1,
ND, and NP are marked on this graph.
These graphs are related only to the embedded menu item TEST TABLE
I. Let N1 design variable vectors have entered the test table after N tests. The
graphs CRITERION VERSUS DESIGN VARIABLE II are formed by the
projections of the points (   i  , 1, 2 , , , r ),   1, k , i  1, N 1 onto the plane
   j ,   1, k , j  1, r (see Figure11.27).
By analyzing the graphs and the corresponding tables, the designer can (i)
estimate the influence of the design variables on the criteria, (ii) compare the
values of the performance criteria of the design (prototype) to be improved with
the results obtained by investigating graphs and histograms, and (iii) judge
whether it is advisable to correct the original parallelepiped and to perform
additional tests in the updated parallelepiped to improve the results of
optimization.
– 74 –
Figure 11.27
11.5.3. Saving Graphs
When one selects the item GRAPH in the GRAPH OF CRITERION
VERSUS DESIGN VARIABLE I or GRAPH OF CRITERION VERSUS DESIGN
VARIABLE II window, an embedded menu appears. This embedded menu has
the items SAVE, SAVE AS BITMAP, and OPEN.
The item SAVE allows one to save a graph in a format accepted by the
MOVI 1.0 software package. When this item is selected, a standard dialogue
window for saving graphs opens. The graph will be saved in the task folder with
the extension .ch1 for the GRAPH OF CRITERION VERSUS DESIGN
VARIABLE I window and with the extension .ch2 for the GRAPH OF CRITERION
VERSUS DESIGN VARIABLE II window.
The item SAVE AS BITMAP allows one to save a graph as a picture in
BMP format. To open a graph saved in such a file, one can use the facilities of
the operating system, for example, PAINT or EXPLORER.
This item is also present in the HISTOGRAM menu of the HISTOGRAMS:
FEASIBLE SET window.
The item OPEN allows one to open a graph previously saved by using the
item SAVE.
11.6. Main Menu Item PERFORM ONE TEST
This item is used to perform a single test. It may be useful either when
debugging a program or if it is necessary to calculate the vector of performance
criteria for a given design variable vector (a prototype). It is advisable to
implement this item after constructing the feasible set.
When this item is selected, the PERFORM ONE TEST window opens (see
Figure 11.28). In the NUMBER OF VECTOR field, enter the number of the design
– 75 –
variable vector for which calculation of the criteria is required. Next, press the
TEST button. Information will appear about the values of the design variables,
functional relations, and criteria for the given vector. If this vector did not enter
the test table, a message appears informing the user about the functional
constraints violated by this vector. Pressing the
button opens the
CORRECTION OF THE VALUES OF VECTOR # (see Figure 11.29). Using this
window, the designer can change some components (design variables) of the
selected vector in order to try to improve the values of the performance criteria.
The designer can also change all components of some design variable vector,
calculate the criteria for this new vector, and compare the results with those
obtained previously. This can be done after the corresponding values of the new
design variables have appeared in this window. After that, first press the
ACCEPT NEW VALUES button and then the TEST button in the PERFORM
ONE TEST window. The values of the criteria and design variables will then
appear in this window.
Figure 11.28
Figure 11.29
– 76 –
11.7. Main Menu Item COMBINE SOLUTIONS
This item may be helpful in the following two cases:
 If solving the problem on one computer takes an unacceptably long time. The
MOVI 1.0 software package allows one to solve a problem on several
computers simultaneously, thereby considerably reducing the time required to
find the solution. In this case, the source problem (task) is divided into
subproblems, each with its own name and its own test interval [ N1k ; N 2k ] ,
where k is the number identifying the computer. Different subproblems are
solved on different computers.
 If the range of the design variables is separated into several parallelepipeds
and it is not reasonable to combine them into one parallelepiped because of
the large volume. In this case, one could solve a separate optimization
problem for each parallelepiped.
In both of these cases, it is necessary to combine feasible solutions of
each of the subproblems and construct a single Pareto optimal set. The item
COMBINE SOLUTIONS can be implemented only after constructing the
corresponding feasible sets for each subproblem. Press the COMBINE
SOLUTIONS button on the panel of the main menu. The COMBINATION OF
SOLUTIONS window will open (see Figure 11.30). On the ATTACHED TASKS
panel, indicate the names of the tasks (problems) whose results are to be
combined with those of the problem already available. To make this, press the
ADD button. The SELECTION OF PROBLEM window with the list of available
optimization problems will appear. Select the necessary problems. The lists of
feasible design variable vectors for each of these problems will appear in the top
right-hand portion of the COMBINATION OF SOLUTIONS window. If one then
presses the
button (Figure 11.30), the combined Pareto optimal solutions will
be shown in the bottom portion of the window. The number of each vector of
criteria is followed by the number of the subproblem to which this vector belongs.
The numbers of the subproblems are given in parentheses. To display the values
of these criteria and design variables, press the
button (see Figure 11.30).
The VALUES OF VECTORS OF COMBINED PARETO OPTIMAL SET window
will open. In the field with the drop-down list, select any of the design variable
and criteria vectors. The numbers and the values of these vectors will appear in
the bottom portion of the window (see Figure 11.31).
To attach a problem solved on another computer, use the Database
Manager program integrated into the MOVI 1.0 software package. For more
details of this operation, see Section 10.
– 77 –
Figure 11.30
Figure 11.31
11.8. Main Menu Item SERVICE
The SERVICE menu item is not present as a button (see Figure 11.1). It
serves the following purposes: clearing database and database optimization. It
contains the items CLEAR RESULTS and DATABASE OPTIMIZATION of an
embedded menu. The item CLEAR THE TASK allows one to delete the results
obtained previously.
The DATABASE OPTIMIZATION menu item performs database optimization,
intended to speed up the database processing, which improves MOVI's
performance.
After performing a large number of tests, constructing truncated tables,
returning to full tables, and clearing the problem, the database becomes very
fragmented; it becomes very large, thus increasing the time required to access its
elements. This slows down procedures such as opening tables of tests, returns,
continuation of tests, and many others.
In order to avoid performance degradation, it is advisable to run database
optimization after constructing truncated tables, returning to full tables, and clearing
the problem.
– 78 –
11.9. Printing Reports
Using the MOVI 1.0 software package, one can create the following reports:
1.
2.
3.
4.
5.
6.
Test tables
Feasible and Pareto optimal solutions
Design variable vectors
Criteria vectors
The data of the prototype and constraints the values of the criteria
Table of the values of the criteria for the graph CRITERION VERSUS
DESIGN VARIABLE I
7. Combination of solutions
8. The values of the vectors of the combined Pareto optimal set
9. Graphs and histograms
All reports are limited to print only four columns at one time. A report on the
full and truncated test tables is printed from the FULL ORDERED TEST TABLE and
TRUNCATED TABLE windows. In the panels of these windows, there is the button
. When this button is pressed, a window appears (see Figure 11.32) in which one
can select the criteria information for printing. In this window, press the
button to open the preview window or the
button to print out the report.
The report “Feasible and Pareto optimal solutions” is printed from the
FEASIBLE SOLUTIONS window. This window appears when the RESULT button on
the panel of the test tables is pressed. The FEASIBLE SOLUTIONS window has the
button
. When this button is pressed, the preview window appears, from which
this report can be printed out.
The reports “Design variable vectors” and “Vectors of criteria” are called from
the VIEW OF DESIGN VARIABLE VECTORS and TABLE OF CRITERIA windows.
When the
button is pressed, a window appears (Figure 11.32) in which one can
select criteria or design variable information for printing. It is important to note that
these reports are created in accordance with the current information on the screen.
For example, if one is analyzing Pareto optimal solutions, then the report will be
created for these solutions.
Figure 11.32
– 79 –
To obtain the report “The data of the prototype and constraints” and the table
“The values of the criteria” for the CRITERION VERSUS DESIGN VARIABLE I
graph, one should proceed as follows. Construct the graph in the GRAPH OF
CRITERION VERSUS DESIGN VARIABLE I window and then press the VIEW
button. An embedded menu will appear in which one should select the item TABLE
OF VALUES. In the window that appears, press the
button in the DATA OF THE
PROTOTYPE AND CONSTRAINTS panel. The preview window for the
corresponding report will appear. When the
button on the VALUES OF
CRITERIA panel is pressed, a window opens (Figure 11.32) in which one can select
the desired criteria information for printing.
The report “Combination of solutions” is called from the COMBINATION OF
SOLUTIONS window by pressing the
window.
The report “The values of the vectors of the combined Pareto optimal set” is
called from the window of the same name by pressing the
button. The PRINT OF
COMBINED PARETO OPTIMAL SET window will appear. In this window, one
should select criteria or design variables, depending on what is currently being
analyzed for printing.
The reports outlined above have the preview option. If the user does not open
the selection window, the preview window opens automatically. Otherwise, the
preview mode can be called by pressing the corresponding button in the selection
window.
To print graphs and histograms, select the appropriate item in the GRAPH or
HISTOGRAM menu. The graphs will be printed from the screen in the “without
landscape” format preview.
– 80 –
12. EXERCISES
In this Section, we pursue two goals. First, we want to demonstrate the
potential of the MOVI 1.0 software package. Second, by using a very simple
example, we want to show some details of the analysis the designer performs when
solving an engineering optimization problem.
We invite the reader to become acquainted with a number of simple exercises
and perform some of them on his/her own. These exercises involve the construction
of test tables, operating with the truncated table, construction of histograms and
graphs, solving a problem on several computers, and implementing other
possibilities of the software package.
The exercises given below are based on the following example problem.
Example. Multicriteria optimization of design variables of a vibratory system.
Consider the two-mass dynamical system shown in Figure 12.1. The system
consists of two bodies with masses М1 and М2. Mass М1 is attached to a fixed base
by a spring with stiffness coefficient К1. A spring-and-dashpot element with stiffness
coefficient К2 and damping coefficient С is located between masses М1 and М2. The
harmonic force P  cos (t ) acts upon mass М1. The amplitude and frequency of the
exciting force are identified as Р = 2000 (N) and  = 30 (s-1).
Figure 12.1
The motion of this system is governed by the equations



М1 X 1 + С ( X 1  X 2 )+ К1 X 1 + К2 ( X 1  X 2 ) = P  cos (t )



(1)
М2 X 2 + C ( X 2  X 1 ) + К2 ( X 2  X 1 ) = 0
We treat the parameters К1, К2, М1, М2, and C as the design variables to be
determined; i.e.,
1 = К1, 2 = К2, 3 = М1, 4 = М2, 5 = С.
The design variable constraints are prescribed as the parallelepiped П defined
by the inequalities
– 81 –
1.1106  1  2.0 106 (N/m);
4.0104  2  5.0104 (N/m);
950  3  1050 (kg);
(2)
30  4 70 (kg);
80  5 120 (Ns/m).
There are three functional constraints (on the total mass and on the partial
frequencies):
f1 ( )  3   4  1100.0 (kg);
33.0  f 2 ( )  p1 
27.0  f 3 ( )  p 2 
1
1
 3  42.0s ;
2
(3)
1
 4  32.0s .
The upper limits imposed on the functions f 2   and f 3   are not rigid and
can be changed within some range. For this reason, the functional relations f 2  
and f 3   are interpreted as pseudo-criteria 1 and  2 .
The system is to be optimized with respect to the following four performance
criteria:
Ф3 = Х1 (mm) – vibration amplitude of the first mass;
Ф4 = М1 + М2 (kg) – metal consumption of the system;
Ф5 = Х1 /Х1st and Ф6 = /р1 – dimensionless dynamical characteristics of the
system, where Х1st is the static displacement of mass М1 under the action of the
force Р. Thus, we have three rigid lower functional constraints and the vector of
criteria   (1 ,  2 ,  3 ,  4 ,  5 ,  6 ) , on the basis of which test tables will be
constructed below.
Various modifications of the example problem outlined above will be given
below as the OSCILLATOR and OSCILLATOR 1 problems.
It is reasonable to divide all the exercises into two groups corresponding to
two stages in the solution of the optimization problem. The first stage involves the
construction and analysis of test tables. This is the basic stage. The second stage
involves the construction of histograms and graphs and is aimed at helping the
designer improve the solutions determined during the first stage by means of
correcting the original statement of the problem. The exercises presented below are
virtually independent of one another. They have the character of a tutorial and are
aimed at preparing the reader to solve real optimization problems in engineering.
– 82 –
12.1. Exercise A. Construction of a full test table (TEST TABLE I).
Dialogues with the computer. Truncated test table. Table of criteria
failures
Load the OSCILLATOR problem. Enter the main menu item CHECK OF
PRIMARY CONSTRAINTS. The CHECK OF PRIMARY CONSTRAINTS window will
appear. Indicate the number of tests, for example, 128, in the right-hand edit field.
Press the START button.
Then enter the main menu item TEST TABLES. In the embedded menu,
select the item TEST TABLE I. A window with the test table will appear. In the top
left-hand corner, information appears indicating that after 128 tests (N=128), 99
solutions entered the table (N1=99). The remaining 29 solutions failed to satisfy the
functional constraints. Since the cursor stands on the last places in the test table, all
solutions are feasible; i.e., ND=99.
Consider the process of determining the criteria constraints. Let us work with
the criterion 1 . The first four rows of this table correspond to criterion 1, the
number of feasible solutions (ND), min 1 , and maх 1 after N=128, respectively
(see Figure 12.2).
For ND=99, we have min 1 = 33.233 (corresponds to vector 64) and max 1 =
45.6091 (corresponds to vector 63). Since the criterion 1 is to be minimized, all
vectors in the table 1 are arranged in increasing order (deterioration) of this
criterion. The best design is 64; the worst one is 63.
After analyzing table 1 , we impose the criterion constraint, for example,
 = Ф1(30) = 39.072. This constraint corresponds to ND=46; i.e., 46 designs have
**
1
satisfied the constraint  1** (see Figure 12.2). Use the
button or the keyboard to
proceed to the second table, 2. We perform investigations similar to those carried
out for 1 and determine  *2* = Ф2(114) = 32.975. We set the cursor on solution
number 114. Then ND=28 appears at the top of the table 2, indicating that 28
solutions simultaneously satisfy the criteria constraints 1** and  *2* (see Figure
12.2). In a similar way, we determine  *3* = Ф3(98) = 5.024 ( 1** ,  *2* , and  *3* are
simultaneously satisfied by 20 solutions),  *4* =Ф4(104) = 1080.468 ( 1** ,  *2* ,  *3* , and
 *4* are simultaneously satisfied by 17 solutions; see Figure 12.2),  *5* = Ф5(113) =
2.10478 ( 1** ,  *2* ,  *3* ,  *4* , and  *5* are simultaneously satisfied by 12 solutions), and
 *6* = Ф6(124) = 0.8176.
Thus, after the first dialogue with the computer, we have determined the
criteria constraints
1**  1 (30)  39.072 ;
*4*   4 (104) 1080.468;
*2*   2 (114)  32.975 ; *5*   5 (113)  2.1048;
   3 (98)  5.024 ;
**
3
   6 (124)  0.8176.
**
6
(4)
– 83 –
Figure 12.2
Then press the ND button or the ENTER key. In the top left-hand corner,
ND=4 will be indicated, implying that four solutions have satisfied all criteria
constraints. Press the RESULT button. The FEASIBLE SOLUTIONS window will
appear with the results of the investigations; the feasible solutions (86, 38, 26, and 2)
and Pareto optimal solutions (86, 38, and 26) are indicated (see Figure 12.3).
To analyze the results obtained above, enter the main menu and select the
item TABLES and then select the items TABLE OF DESIGNS and TABLE OF
CRITERIA in the embedded menu.
In the TABLE OF CRITERIA window, select FEASIBLE SET or PARETO
OPTIMAL SET in the drop-down list. The numbers of solutions 2, 26, 38, and 86 will
appear in the table of feasible solutions with the corresponding values of the
performance criteria (see Figure 12.4). The Pareto optimal solutions are shown in
Figure 12.5. Suppose, for example, that preference is given to solution 38.
In the TABLE OF DESIGNS table, the values of the feasible and Pareto
optimal design variable vectors are presented. The minimum and maximum values,
min  j and max  j , are indicated for each design variable. By comparing the original
boundaries of the ranges of the design variables with the maximum and minimum
values attained by these variables, one can assess the “effectiveness” of the
functional and criteria constraints. This information is important for possible
correction of the parameters of the original parallelepiped.
– 84 –
Figure 12.3
Figure 12.4
– 85 –
Figure 12.5
Dialogues with the computer. During the investigations, it is possible to
conduct dialogues with the computer and to revise criteria constraints in order to find
better solutions.
Previously, the criteria constraints of (4) were imposed. Now we choose to
revise them. To make this, we enter the main menu and select the item TEST
TABLE I. The FULL ORDERED TEST TABLE window will appear. As a result of the
second dialogue with the computer, we determine the new criteria constraints
1**  1 (78)  38.57 ;
*4*   4 (94) 1085.78;
*2*   2 (60)  33.833;
*5*   5 (56)  1.90537;
(5)
   3 (124)  6.9794;    6 (28)  0.8213.
**
3
**
6
These constraints define five feasible solutions: 38, 26, 2, 108, and 82.
Solutions 26, 38, and 108 are Pareto optimal (see Figure 12.6). We now have to
compare these results with the previous ones and analyze them. As a result, we give
preference to solution 108.
Suppose that we choose to continue testing with the new constraints. There
may be various reasons for this. For example, it may happen that 128 tests took little
time and we wish to improve the results obtained previously. To make this, we press
the CONTINUE TESTING button. We construct the test table for N=256 and press
the RESULT button. The number of feasible solutions increases to nine. Compared
with the case of 128 tests, solutions 186, 150, 242, and 226 have been added. The
Pareto optimal set now contains three solutions: 108, 186, and 242. One should
analyze these results to make further decisions.
Remark. A comment concerning the choice of the number of tests is
appropriate here. Since we have aimed at acquainting the reader with the basic
facilities of the MOVI 1.0 software rather than with a thorough analysis of the
problem, we choose to confine ourselves to the number of tests ranging from 128 to
512. It takes less than one minute to conduct these tests.
– 86 –
Figure 12.6
Proceeding from the full table to the truncated table. The convenience of
operating with truncated tables has been discussed previously (see Section 11.3.1).
To construct the truncated table, press the TRUNCATED TABLE button in the FULL
ORDERED TEST TABLE window. The CONSTRUCTION OF TRUNCATED TABLE
window will appear. Press the YES button. The TRUNCATED TABLE N1 window will
appear, with nine solutions in it (see Figure 12.7). These nine feasible solutions
entered the truncated table from the full table. Only solutions satisfying all criteria
constraints enter the truncated table. Suppose we choose to continue testing in the
truncated table from test 257 to test 512. In the TRUNCATED TABLE N1 window (9
VECTORS ENTERED), press the CONTINUE TESTING button. The TRUNCATED
TEST TABLE N1 window (19 VECTORS ENTERED) will appear informing us that
ND=19. Four of the feasible solutions (108, 186, 242, and 342) are Pareto optimal
(see Figure 12.8). After analyzing these solutions, one should decide either to
accept the results obtained or to continue the computations. In the latter case, the
criteria constraints can be revised again.
– 87 –
Figure 12.7
Figure 12.8
– 88 –
Consider two examples to illustrate the revision of criteria constraints in the
truncated tables.
12.1.1. Example 1.
Suppose that we wish to sharpen criteria constraints 1** ,  *2* ,  *3* , and  *5*
compared with the constraints of (5), leaving constraints  *4* and  *6* unchanged. In
this table, we set the cursor on the corresponding values of criteria constraints
1** ,  *2* ,  *3* and  *5* that we wish to revise:
 1**   1 (242)  37.9187;
 *2*   2 (26)  28.9635;
 *3*   3 (466)  2.6895 ;
 *5*   5 (410)  1.8297.
(6)
In the columns corresponding to  4 and  6 , the cursor must stand on the
bottom row. Press the CALCULATION OF ND button. We obtain four feasible
solutions, 314, 326, 26, and 2, all of them Pareto optimal. Press the TRUNCATED
TABLE button. The CONSTRUCTION OF TRUNCATED TABLE window will appear
with new values of 1** ,  *2* ,  *3* , and  *5* . At the same time, it is necessary to take
into account the values of  *4*   4 (94)  1085.78 and  *6*   6 (28)  0.8213 . To do
so, we click on the values  *4* and  *6* and select the item LOWER VALUE in the
menu that appears (see Figure 12.9). Then we press the YES button and construct
the truncated table, which contains the four solutions indicated above. The
TRUNCATED TABLE N2 (4 VECTORS ENTERED) window will appear (see Figure
12.10).
Figure 12.9
– 89 –
Figure 12.10
12.1.2. Example 2. Extension of the truncated table
Suppose that 128 tests have been conducted in the parallelepiped Π (N=128),
the full test table has been constructed, and the criteria constraints have been
determined as follows:
1**  1 (24)  33.83807; *4*   4 (3)  1065;
*2*   2 (8)  34.08467;
*5*   5 (8)  14.101;
   3 (8)  24.39053;
   6 (8)  0.8905.
**
3
(7)
**
6
The feasible set contains only one solution: number 8.
We construct the truncated test table and then press the CONTINUE
TESTING button. In the button CHECK OF PRIMARY CONSTRAINTS button, we
mark the tests from number 129 to number 256. The number of feasible solutions
does not increase.
Now extend this table. To extend the table, we leave the values of
constraints 1** ,  *3* , and  *5* unchanged (coinciding with those of (7)) and increase
the other constraints, i.e.,  *2* ,  *4* , and  *6* , to obtain
 1**   1 (24)  33.83807;  *4*  1096.4063;
 *2*  40.1701;
 *5*   5 (8)  14.101;
 *3*   3 (8)  24.39053 ;
(8)
 *6*  0.902713.
Press the EXTEND button. The EXTENSION OF TRUNCATED TABLE
window will appear. Increase the values  *2* ,  *4* , and  *6* in accordance with (8);
see Figure 12.11. Press the ACCEPT CONSTRAINTS button. Six feasible solutions,
64, 128, 48, 8, 16, and 24, will appear (see Figure 12.12). Solutions 16, 24, 48, and
128 are Pareto optimal.
– 90 –
Figure 12.11
Figure 12.12
Note that we could also obtain these six solutions in another way. Particularly,
after conducting 256 tests in the truncated table, we press the RETURN button to
obtain the full test table. Then it is necessary to set the cursor in accordance with the
constraints
of
(8),
where
**
**
**
 2   2 (127)  40.1701;  4   4 (76)  1096.4063; 6   6 (64)  0.902713 , and obtain
the six desired solutions.
We can now try to extend the truncated table by changing constraints
 ,  in the table of criteria failures. Enter the item TABLES from the main menu
and then the item TABLE OF CRITERIA FAILURES from the embedded menu.
Select  *2* in the drop-down list. A message will appear, informing us that there is
only one solution, 176, in the table of criteria failures with respect to  *2* . Press the
**
2
**
4
– 91 –
CHANGE button (see Figure 12.13). The ACCEPT NEW CONSTRAINT? window
will appear. Press the OK button. The message 1 VECTOR ENTERED THE TEST
TABLE will appear. This is vector number 176. If necessary, we can now proceed to
constraint  *4* . Press the CHANGE button. Due to the increase in  *4* , solution
number 208 also appears in the truncated test table.
12.2. Exercise В. Truncated test table. Table of functional failures.
TEST TABLE II
12.2.1. Table of functional failures
In order for a solution to enter the test table, this solution must satisfy all
functional constraints. However, it may happen that because of the imposition of
erroneous functional constraints, the test table turns out to be empty or contains too
few solutions. In this case, enter TABLE OF FUNCTIONAL FAILURES and analyze
the results. It is important to understand how various functional constraints work and
find out whether it is possible to relax some of them. If corrections are made to
functional constraints, information will appear about the solutions that satisfied the
modified (relaxed) functional constraints and entered the test table.
Suppose that in the OSCILLATOR problem we have imposed the rigid
functional constraints f1  1100, f 2  33, f 3  40 . The constraints on the design
variables are presented at the beginning of this Section. We indicate the number of
tests, 128, in the CHECK OF PRIMARY CONSTRAINTS window. After 128 tests
have been conducted, a message appears, informing us that that only one solution
entered the test table. Hence, the other 127 candidate solutions failed to satisfy the
functional constraints. We analyze the test table consisting of only one solution
(number 127). Since the number of solutions that entered the test table is
unreasonably small, we choose to analyze the work of the functional constraints. To
make this, we select the item TABLES in the main menu and call the item TABLE OF
FUNCTIONAL FAILURES in the embedded menu.
The program informs us that 5 solutions failed to satisfy the first functional
constraints, 1 solution failed to satisfy the second functional constraint, and 121
solutions failed to satisfy the third functional constraint (see Figure 12.14). Analysis
of the values of the third functional relation, i.e., those of f3, allows us to relax the
corresponding functional constraint by replacing f3  40 with f3  27. To make this
change, we point to the number 27 in the CONSTRAINT edit field in the TABLE OF
FUNCTIONAL FAILURES window and press the CHANGE button. Then the
message “98 VECTORS ENTERED THE TEST TABLE” will appear. Press the OK
button. Information will appear showing that 5, 1, and 23 solutions failed to satisfy
the first, second, and third functional constraints, respectively (see Figure 12.15).
After this, we analyze the new test table and construct the feasible and Pareto
optimal sets. Finally, we agree to the constraint f3  27.
After 128 tests, 29 vectors appeared in the table of functional failures. Five
vectors (53, 31, 46, 4, and 32) failed to satisfy the first functional constraint, 1
vector (number 80) did not meet the second functional constraint, and 23 vectors did
not satisfy the third functional constraint. Analysis of the functional relation f1 shows
the following results:
f1 (53)  1116.53; f1 (31)  1108.125; f1 (46)  1103.4375; f1 (4)  1102.5 ; f1 (32)  1102.1875 .
– 92 –
Figure 12.13
Figure 12.14
Figure 12.15
Some of the design variable vectors that failed to satisfy the functional
constraint f1  1100 violate this constraint only “a little bit” (see Figure 12.16). For
this reason, we choose to increase the constraint on f1 from 1100 to 1104. Of the five
vectors that failed to satisfy the previous constraint, three vectors (4, 32, and 46)
now meet the new constraint. To fix the new constraint, we write the number 1104 in
the CONSTRAINT edit field and press the CHANGE button. The message “0
VECTORS ENTERED THE TEST TABLE” will appear. Hence, these three vectors
failed to satisfy subsequent functional constraints. Press the OK button. A message
will appear indicating that vectors 31 and 53, for which f1  1104 , remain in the table
of functional failures for f1.
– 93 –
Figure 12.16
We now proceed to an analysis of the functional constraints for f2. Two
vectors, 32 and 80, violate this constraint. (Vector 32 was in the table of functional
failures for f1 until we relaxed the constraint on this relation.) We have f2(80) =
32.9907 and f2(32) = 32.646. The initial constraint was imposed on the function f2 as
f 2  33 . After analyzing the table of functional failures for f2, we choose to relax the
functional constraint on this function by a very small amount by changing this
constraint to f 2  32.99 . The message “1 VECTOR ENTERED THE TABLE” will
appear. This is vector 80. Note that after relaxing the functional constraint on f1 to
f1  1104, vector 32 did not satisfy the constraint on f2, and vectors 4 and 64 failed to
meet the third functional constraint.
12.2.2. TEST TABLE II
Let the parallelepiped П be specified. The functional constraints and the
performance criteria are presented at the beginning of this Section. As before,
consider the OSCILLATOR problem. The number of tests conducted is N=512.
1. Determination of  1** . Enter the item TEST TABLES from the main menu
and then the item TEST TABLE II from the embedded menu. The TEST TABLE:
FAST ALGORITHM window will appear on the screen (see Figure 12.17). In the top
left-hand corner, information showing that the total number of tests conducted is N=
512 and that the number of solutions that satisfied the functional constraints is N1=
395 is presented. These are the solutions for which the criterion Ф 1, was calculated
~
(see Figure 12.17). Set the cursor on **1  1 (446)  39.92 ; i.e., all solutions
~
satisfying the inequality 1  **1 are unfeasible. Press the
button (DELETE
BELOW) to delete everything that lies below the cursor. In the column Ф 1, the
message ND=215 will appear indicating that 180 vectors (395 – 215 = 180)
~
satisfying the inequality 1  **1 have been deleted. Define 1**  1 (154)  36.97 . In
the column Ф1, the message ND=118 will appear showing the number of solutions
that satisfied the first criterion constraint 1** . Then proceed to the calculation of Ф2.
– 94 –
Figure 12.17
~
2. Determination of  *2* . Define *2*   2 (116)  35.88 . Press the
button.
After this, 98 vectors remain in the table. Define    2 (8)  34.08 . Criteria
**
2
constraints 1** and  **
2 are met by 86 vectors (see Figure 12.18).
~
3. Determination of  **
Define **3  3 (204)  9.1715 . After this, 66
3 .
vectors remain in the table. Define  *3*   3 (24)  6.68 . Sixty vectors satisfy criteria
**
constraints 1** ,  **
2 , and  3 (see Figure 12.19).
~ **
4. Determination of  **
4 . We do not specify the value of  4 . We set
**
 *4*   4 (412)  1072.38 . In this case, 41 vectors satisfy constraints 1** ,  **
2 , 3 ,
and  **
4 (see Figure 12.19).
~ **
5. Determination of  **
5 . We set 5  5 (412)  1.88 . After this, 19 solutions
remain in the table. Define  *5*   5 (132)  1.7515 . In this case, 14 solutions satisfy
**
**
**
criteria constraints 1** ,  **
2 ,  3 ,  4 , and  5 (see Figure 12.19).
~
6. Determination of  *6* . We do not specify the value of **6 . Set
 *6*   6 (34)  0.8281 (see Figure 12.19). Five solutions satisfy all criteria
constraints. Four of these solutions are Pareto optimal (see Figure 12.20). When the
RESULT button is pressed, the numbers of these solutions are displayed.
– 95 –
Figure 12.18
Figure 12.19
– 96 –
Figure 12.20
In the course of further analysis, by analogy with TEST TABLE I, one can
construct truncated tables, perform the operations described above with the tables of
functional and criteria failures, and construct histograms and graphs.
12.3. Exercise С. Analysis of tables of criteria and design variables.
Histograms. Graphs of criteria versus design variables
Analysis of tables, histograms, and graphs is very important for the choice of
the final solution. We will illustrate some basic points of this analysis below.
Let 256 tests have been performed in the parallelepiped Π (OSCILLATOR
problem).
Suppose that we have constructed the full test table and defined the criteria
constraints
 1**   1 (130)  37.281;
 *4*   4 (237) 1089.6;
 *2*   2 (52)  31.8784 ;  *5*   5 (135)  2.2711;
   3 (97)  4.2193;
**
3
   6 (16)  0.88899.
**
6
(9)
– 97 –
Press the CALCULATION OF ND button. The message ND=19 will appear.
Press the RESULT button. The FEASIBLE SOLUTIONS window will open, in which
the numbers of 19 solutions are shown. Seven of these solutions are Pareto optimal.
Next, turn to the item TABLES in the main menu and then to the items TABLE
OF DESIGNS and TABLE OF CRITERIA of the embedded menu.
12.3.1. Analysis of the table of criteria
Prior to the analysis, enter the item TABLES from the main menu and then the
item TABLE OF CRITERIA from the embedded menu. In the drop-down list, indicate
the feasible or Pareto optimal solutions. The minimum and maximum values for each
criterion are indicated at the beginning of the table. For example, from the table of
Pareto optimal solutions, it follows that the minimum of the mass (criterion  4 ) is
equal to 1010.54 and the maximum is equal to 1072.03. The minimum corresponds
to design variable vector 216 and the maximum to vector 82 (see Figure 12.21).
Analysis of these tables allows one to select the most suitable solution. For example,
we can choose vector 216, which provides the minimum for the criterion  4 .
12.3.2. Analysis of the table of design variables.
Enter the item TABLES from the main menu and then the item TABLE OF
DESIGNS from the embedded menu. The DESIGN VARIABLE VALUES window will
appear. In the drop-down list in this window, indicate the feasible or Pareto optimal
solutions (see Figure 12.22).
Information about the minimum and maximum feasible values of the design
variable j is given at the beginning of the table. For example, from the table of
feasible solutions, it follows that min1=1.1316106 (corresponds to vector 144) and
max1=1.37106 (corresponds to vector 178). Hence, 1 ranges in the interval
[1.1316106, 1.37106].
Figure 12.21
– 98 –
12.3.3. Histograms
Enter the item HISTOGRAMS AND GRAPHS from the main menu. Then
enter the item HISTOGRAMS from the embedded menu. The HISTOGRAMS:
FEASIBLE SET window will appear. Indicate the design variable К1 in the drop-down
list. One can see that all 19 feasible solutions lie near the left end of the initial
interval [1.1106, 2106]; see Figure 12.23. The panel at the bottom of the window
shows the feasible and Pareto optimal solutions that enter each of the ten intervals.
For example, the first interval [1.1106, 1.19106] contains four solutions, specifically,
feasible vectors 240, 144, 104 and Pareto optimal vector 200 (Р).
To visualize the Pareto optimal solutions, check the appropriate check box.
We have mentioned that since all solutions feasible with respect to the first design
variable lie near the left end of the interval [ 1* ; 1**] , it makes sense to continue
investigating the problem, if possible, with a new value of the quantity  1* satisfying
the inequality 1* <1.1106. Let us agree to  1* = 0.85106. For 1** , we adopt (with
some margin) 1** =1.5106. Thus we have constructed the new interval [0.85106,
1.5106] for further investigation. The other histograms can be investigated in a
similar manner.
Figure 12.22
– 99 –
Figure 12.23
After the design variable constraints are changed, a new problem arises. We
will refer to this problem as OSCILLATOR I. When solving this problem, it is
necessary to keep the functional and criteria constraints (9) unchanged. One should
perform new tests, construct the test table, and determine new feasible and Pareto
optimal sets. After that, one can combine the previous feasible set (constructed for
the OSCILLATOR problem) with the new feasible set (for the OSCILLATOR I
problem), identify Pareto optimal solutions in the combined feasible set, and analyze
these solutions (see below).
12.3.4. CRITERION VERSUS DESIGN VARIABLE I Graphs
Analysis of these graphs allows one to correct the domain boundary of the
design variables and to improve the solution obtained previously.
Earlier, we gave preference to vector 216. Let us try to find a better solution.
To make this, select the item HISTOGRAMS AND GRAPHS in the main menu. After
that, enter the embedded menu item GRAPHS and then the embedded menu item
CRITERION VERSUS DESIGN VARIABLE I. The GRAPH OF CRITERION
VERSUS DESIGN VARIABLE I window will appear.
Analysis of vector 216. We will analyze the influence of each component of
this vector (with the other components being fixed) on all criteria. In the GRAPH OF
CRITERION VERSUS DESIGN VARIABLE I window, in the TESTS FROM … TO… ,
edit fields we indicate the numbers of the tests, for example, from 1 to 32. In the
drop-down lists, we indicate, for example, the design variable 1= К1 and the
criterion  3 . Enter the number 216 in the FIXED VECTOR field. Press the DRAW
button. The graph  3 (К1) will appear (see Figure 12.24). After that, in the top lefthand corner, the messages N=32, ND=9, and NP=1 will appear. (We recall that the
– 100 –
Pareto optimal solutions are constructed only for criteria, i.e., for Ф3, Ф4, Ф5, and Ф6;
pseudo-criteria 1 and  2 are not taken into account.)
Select the menu item VIEW and then the item TABLE OF VALUES in the
embedded menu. A window will appear in which the values are presented for all
vectors of criteria corresponding to N=32 (see Figure 12.25). The VECTOR column
on the left presents the feasible solutions, (D)i; Pareto optimal vectors, (P)i; the
vectors that failed to satisfy the criteria constraints, (C)i; and the vectors that failed to
satisfy the functional constraints, (F)i. Here i is the number of the corresponding
vector.
Figure 12.24
Figure 12.25
– 101 –
The top panel presents information about the criteria constraints and the
values of the criteria for the design to be improved (the prototype). In the case in
question, vector 216 plays the role of the prototype. As one can see from the table,
minФ3 = 1.4618 corresponds to vector (С)31, and maxФ3 = 3.8528 to vector (D)32.
For the Pareto optimal vector, we have Ф3((Р)2) = 2.7549, whereas for the prototype
(vector 216), we have Ф3 = 3.3441. The graphs showing the criteria versus the
design variables represent the dependence of each criterion   on each design
variable j. On these graphs, the value of the criterion   for the prototype,  , is
marked with a triangle ▲ (see Figure 12.24); Pareto optimal and feasible vectors are
represented by points of different colors. The analysis of the table combined with the
analysis of the graphs allows one to assess the possibilities for improving the values
of the criteria compared with those of the prototype. It is apparent from the graphs
and tables related to the dependence of the criteria Ф 3, Ф5, and Ф6 on the design
variable К1 that all these criteria have been improved compared with the values
corresponding to vector 216. (Note that Ф1 and Ф2 are pseudo-criteria and Ф4 does
not depend on К1).
216
Along with the analysis of histograms, the analysis of these relations for 1 =
К1 implies that all feasible solutions lie in the interval [1.1106,1.325106]. Based on
reasoning similar to that presented above, we form a new range for the design
variable К1, i.e., the interval [0.85106; 1.5106]. Upon further analysis, it is advisable
to investigate the influence of the remaining design variables on all performance
criteria. Thus we obtain the following intervals: [850;1050] for m1, [40; 60] for m2, and
[70; 120] for C. The interval for К2, [4  10 4 ;5  10 4 ] , was kept unchanged.
To facilitate the comparison of several graphs on the same screen, the MOVI
1.0 software package allows one to display the graphs in a separate window. To
make this, select the GRAPH menu in the top left-hand corner of the GRAPH OF
CRITERION VERSUS DESIGN VARIABLE I window and then select the item
OUTPUT IN NEW WINDOW in the embedded menu. Then construct the graphs, for
example,  3 m1 ,  5 k 2 ,  5 m2  ; see Figure 12.26.
Figure 12.26
– 102 –
Analysis of the results. We have described some stages of the analysis of
the graphs above. Part of the results obtained from the analysis are gathered
together in Table 12.1
Table 12.1
Vectors
(Р)2
(Р)19
(Р)21
(Р)24
(Р)14
(Р)26
216
Ф3
2.75
2.08
3.32
2.88
2.54
3.31
3.34
Ф4
1010
1010
1007
1003
1004
1010
1010
Ф5
1.825
1.247
1.987
1.726
1.520
1.978
1.997
Ф6
0.806
0.848
0.847
0.848
0.848
0.848
0.848
Design variable
1=К1
2=К2
3= m1
4=m2
4=m2
5=С
-
Conclusions
1. Vector (Р)21 surpasses the prototype (vector 216) in all criteria.
2. Vectors (Р)2, (Р)24, and (Р)14 surpass vector 216 in three criteria; the values of
the fourth criterion for these vectors coincide with those of the prototype.
3. Vectors (Р)19 and (Р)26 should also be preferred to the original vector 216.
Sensitivity analysis of the performance criteria with respect to the design
variables shows that
The influence of К1 on the criteria Ф3, Ф5, and Ф6 is strong.
The influence of m1 on the criteria Ф3, Ф4, Ф5, and Ф6 is strong.
As m1 decreases, the values of all these criteria are improved.
The influence of С on the criteria Ф3 and Ф5 is strong. As С decreases, the
values of these criteria are improved.
- The influence of К2 on the criteria Ф3 and Ф5 has a complex nature.
- The influence of m2 on the criteria Ф3 and Ф5 is relatively weak.
Thus, first, we described the process for improving the prototype without
changing the constraints. Second, we showed that to perform a further analysis, it is
advisable to correct the design variable constraints and construct a new
parallelepiped. When imposing new constraints on the design variables, we took into
account a number of factors, including the character of the distribution of the feasible
and Pareto optimal solutions on the interval [ *j ; *j* ] and the tendency in the change
of the functions depending on the change of the design variables.
-
12.3.5. CRITERION VERSUS DESIGN VARIABLE II Graphs
These graphs are formed by the projections of the points (   i  , 1, 2 , , , r ),
  1, k , i  1, N1 onto the plane   j ,   1, k , j  1, r . At the beginning of the section
“Exercise C”, we described an experiment for constructing the feasible and Pareto
optimal sets under the criteria constraints of (9). From the graphs  4 ( 3 ) and
 6 (1 ) , one can observe that the value of  4 tends improve as
 3 decreases and
the value of  6 tends to improve as  1 increases (see Figures 12.27 and 12.28).
Analysis of these graphs can be helpful when correcting the initial constraints on the
design variables in order to search for the optimal solutions.
– 103 –
Figure 12.27
Figure 12.28
12.4. Exercise D. Construction of the combined feasible and Pareto
optimal sets. The menu item COMBINE SOLUTIONS
12.4.1. Case А
In many cases, analysis of the test tables leads us to conclude that correction
of the boundaries of the initial parallelepiped and construction of a new
parallelepiped are advisable. Suppose that the appropriate investigations have been
performed in the updated parallelepiped and that the corresponding feasible set has
been constructed. It is necessary to combine the feasible sets constructed in both
– 104 –
these parallelepipeds and indicate the Pareto optimal solutions in the combined
feasible set. The problems considered below have been solved with the use of TEST
TABLE I.
OSCILLATOR Problem. At the beginning of this Section, we defined the
parallelepiped (2), the vector of criteria, the functional relations, and the constraints
imposed on these relations (3). Let us perform 512 tests (N=512) and determine the
criteria constraints
 1**   1 (130)  37.281;
 *4*   4 (237) 1089.61;
 *2*   2 (52)  31.8785 ;
 *5*   5 (135)  2.2712;
   3 (97)  4.2194 ;
   6 (16)  0.88899.
**
3
(10)
**
6
As a result, we obtain ND=40 and NP=13.
OSCILLATOR 1 Problem. After analyzing the test table, histograms, and
graphs for the OSCILLATOR problem, we define the new parallelepiped 1 as
1.1 10 6  k1  1.5 10 6 ; 42  m2  70 ;
3.5  10 4  k 2  5.5  10 4 ; 75  C  125 ; 900  m1  1100 .
(11)
In the OSCILLATOR 1 problem, we introduce the criteria constraints of (10)
as the primary ones. We perform 512 tests (N=512). As a result, we obtain the
feasible set, which contains by 81 vectors (ND=81), and the Pareto optimal set,
which contains 17 vectors (NP=17).
We can now combine the feasible solutions found for the OSCILLATOR and
OSCILLATOR 1 problems and determine Pareto optimal solutions in the combined
feasible set. To make this, select the item COMBINE SOLITIONS in the main menu.
The COMBINATION OF SOLUTIONS window will appear, in which the feasible
solutions for the OSCILLATOR 1 problem are presented. Then press the ADD
button. The SELECTION OF PROBLEM window will appear. In the case in question,
select the OSCILLATOR problem in this window and press the OK button. After that,
the feasible solutions of the OSCILLATOR problem will be added to the feasible
solutions of the OSCILLATOR 1 problem in the COMBINATION OF SOLUTIONS
window. Press the
button. In the bottom portion of the window, the list PARETO
OPTIMAL SOLUTIONS will appear indicating which of the problems, OSCILLATOR
or OSCILLATOR 1, each vector occurring in this list belongs to (see Figure 12.29). In
our case, we have 18 Pareto optimal solutions in the combined set.
Only one vector, 280(1), belongs to the OSCILLATOR problem. The other 17
vectors — 25(0), 36(0), 117(0), 130(0), 166(0), 168(0), 238(0), 242(0), 260(0),
280(0), 336(0), 369(0), 397(0), 419(0), 446(0), 490(0), and 502(0) — belong to the
OSCILLATOR 1 problem. The label (0) indicates the OSCILLATOR 1 problem, and
(1) corresponds to the OSCILLATOR problem.
Conclusion. Owing to the correction of the constraints on the design
variables in the OSCILLATOR 1 problem, we obtained many solutions that were
substantially better than the optimal solution for the OSCILLATOR problem. In the
combined set of Pareto optimal solutions, 17 of the 18 solutions belong to the
OSCILLATOR 1 problem.
– 105 –
Figure 12.29
12.4.2. Case В
It may happen that calculation of the vector of criteria for one test requires a
great deal of computer time and it is necessary to perform many tests. This is the
case, for example, for problems of design variable optimization in finite-element
models. A large number of tests may also be needed to solve other sorts of
problems in which the vector of the design variables has a considerable dimension.
The MOVI 1.0 software package allows one to solve such problems on
several computers simultaneously. For example, we can perform tests 1 to N on the
first computer, tests N+1 to 2N on the second computer, tests 2N+1 to 3N on the
third computer, and so on. After that, it is necessary to combine the feasible
solutions obtained on different computers and construct the combined Pareto optimal
set.
Suppose, for example, that we have to perform 1024 tests and have decided
to use two computers in order to reduce the computation time by a factor of two.
Proceeding in this way, we will perform 512 tests on each of the computers and then
combine the results of the computations. On the first computer, we will solve the
OSCILLATOR problem by performing tests 1–512. (The solution of this problem has
been described above.) On the second computer, we will solve the OSCILLATOR 1
problem by performing tests 513–1024.
OSCILLATOR Problem. After performing 512 tests, we obtain ND=40 and
NP=13.
OSCILLATOR 1 Problem. We perform tests 513–1024 in the parallelepiped
(2). In the EDIT TASK window, we enter the criteria constraints of (10) as primary
constraints. The functional constraints coincide with those of the OSCILLATOR
problem. We obtain ND=36 and NP=9.
We construct the combined feasible set for the OSCILLATOR and
OSCILLATOR 1 problems. This combined set contains 16 Pareto optimal solutions
(see Figure 12.30). Eight of the Pareto optimal solutions belong to the OSCILLATOR
problem and eight to the OSCILLATOR 1 problem. The Pareto optimal vectors have
the following numbers: 2(1), 108(1), 280(1), 288(1), 290(1), 388(1), 404(1), 476(1),
– 106 –
562(0), 642(0), 644(0), 714(0), 716(0), 732(0), 756(0), and 780(0). The labels (0) or
(1) following the numbers of the vectors indicate that the corresponding vector
belongs to the OSCILLATOR 1 or OSCILLATOR problems, respectively.
Using the facilities of the MOVI 1.0 software package, we can construct the
tables of design variables and criteria for these Pareto optimal solutions (see
Figures. 12.31 and 12.32).
Conclusion. The possibility of solving one problem simultaneously on several
computers provided by the MOVI 1.0 package is very important in many cases that
the designer may face in practice. Some of them have been considered above. In
these cases, using only one computer may turn out to be inefficient or even
unacceptable if solving the problem requires a great deal of computer time. The
MOVI 1.0 software package allows one to solve such problems.
Figure 12.30
Figure 12.31
– 107 –
Figure 12.32
– 108 –
APPENDIX A. EXAMPLES OF POINTS OF THE LP
SEQUENCE
Vector #5
6.250000E-001
6.250000E-001
1.250000E-001
8.750000E-001
1.250000E-001
1.250000E-001
1.250000E-001
3.750000E-001
3.750000E-001
6.250000E-001
Vector #82
2.890625E-001
7.265625E-001
3.515625E-001
3.203125E-001
3.906250E-002
1.328125E-001
3.984375E-001
1.015625E-001
9.140625E-001
7.265625E-001
Vector #347
8.535156E-001
5.410156E-001
2.929688E-002
8.964844E-001
3.496094E-001
7.128906E-001
5.175781E-001
3.691406E-001
8.183594E-001
1.269531E-001
Vector #754
3.095703E-001
8.740234E-001
2.587891E-001
5.595703E-001
5.302734E-001
2.822266E-001
9.404297E-001
2.832031E-002
3.134766E-001
9.462891E-001
Vector #998
4.052734E-001
9.082031E-002
3.427734E-001
3.154297E-001
6.728516E-001
4.560547E-001
7.900391E-001
2.958984E-001
7.646484E-001
8.779297E-001
1.250000E-001
8.750000E-001
3.750000E-001
3.750000E-001
8.750000E-001
6.250000E-001
6.250000E-001
1.250000E-001
1.250000E-001
8.750000E-001
3.750000E-001
8.750000E-001
3.750000E-001
1.250000E-001
8.750000E-001
8.750000E-001
6.250000E-001
6.250000E-001
1.250000E-001
8.750000E-001
3.750000E-001
3.750000E-001
6.250000E-001
6.250000E-001
6.250000E-001
8.750000E-001
1.250000E-001
8.750000E-001
3.750000E-001
3.750000E-001
1.250000E-001
1.250000E-001
8.750000E-001
6.250000E-001
3.750000E-001
3.750000E-001
3.750000E-001
8.750000E-001
3.750000E-001
1.250000E-001
8.828125E-001
3.828125E-001
9.609375E-001
1.796875E-001
9.296875E-001
2.343750E-002
1.171875E-001
2.578125E-001
5.703125E-001
8.671875E-001
6.796875E-001
8.671875E-001
2.343750E-002
2.109375E-001
9.765625E-001
4.296875E-001
7.890625E-001
2.265625E-001
8.515625E-001
8.203125E-001
6.015625E-001
4.140625E-001
2.265625E-001
1.171875E-001
2.734375E-001
5.390625E-001
3.828125E-001
8.828125E-001
4.609375E-001
6.796875E-001
7.578125E-001
7.031250E-002
3.671875E-001
3.203125E-001
1.015625E-001
3.906250E-002
1.796875E-001
3.671875E-001
5.234375E-001
7.109375E-001
7.226563E-002
7.832031E-001
1.972656E-001
7.441406E-001
3.417969E-001
2.714844E-001
3.925781E-001
2.324219E-001
4.003906E-001
4.277344E-001
4.628906E-001
7.441406E-001
9.199219E-001
1.933594E-001
9.628906E-001
3.457031E-001
7.324219E-001
3.222656E-001
4.550781E-001
8.007813E-002
5.683594E-001
3.105469E-001
6.035156E-001
2.636719E-001
2.480469E-001
3.378906E-001
3.769531E-001
4.882813E-002
2.832031E-001
9.667969E-001
1.660156E-001
6.835938E-002
1.660156E-001
7.636719E-001
6.972656E-001
6.445313E-002
3.964844E-001
9.785156E-001
5.488281E-001
6.855469E-001
6.933594E-002
6.181641E-001
3.232422E-001
3.935547E-001
2.490234E-001
7.822266E-001
5.634766E-001
3.310547E-001
6.376953E-001
6.689453E-001
6.298828E-001
5.175781E-002
3.720703E-001
5.869141E-001
6.162109E-001
5.732422E-001
5.068359E-001
6.474609E-001
7.998047E-001
6.416016E-001
3.447266E-001
2.832031E-002
8.955078E-001
2.158203E-001
1.220703E-001
6.337891E-001
8.544922E-001
9.697266E-001
6.337891E-001
8.232422E-001
2.451172E-001
2.763672E-001
9.169922E-001
2.470703E-001
8.300781E-002
6.083984E-001
8.486328E-001
1.396484E-001
6.748047E-001
1.650391E-001
7.236328E-001
3.623047E-001
1.806641E-001
5.478516E-001
6.181641E-001
5.771484E-001
5.732422E-001
2.705078E-001
1.240234E-001
1.904297E-001
7.568359E-001
3.349609E-001
4.199219E-002
2.255859E-001
4.111328E-001
9.228516E-001
2.822266E-001
2.080078E-001
1.650391E-001
4.199219E-002
3.583984E-001
5.419922E-001
8.037109E-001
5.732422E-001
6.826172E-001
9.638672E-001
5.009766E-001
4.951172E-001
1.435547E-001
9.501953E-001
7.431641E-001
5.175781E-002
7.119141E-001
4.638672E-001
7.099609E-001
3.613281E-002
1.669922E-001
7.470703E-001
1.181641E-001
6.083984E-001
– 109 –
APPENDIX B. PROBLEM FILES
When MOVI 1.0 is running, it generates files in the problem folder; these files
are then used to store calculated data and data entered by the user.
When a problem is set up, the following two files are always present in the
problem folder:
1. Interface Library (.dll file), which is copied to the problem folder automatically
if it was located in another place (see Section 9, “Interface Library
Development Manual”);
2. The problem database (file base.gdb), which contains all data calculated
during optimization and temporary data, as well as the description of the
design variables, functional constraints, and criteria defined during the
problem setup.
B.1. Structure of the Problem’s Database
To store problem data, MOVI 1.0 uses databases built upon the InterBase
server. All databases use the same structure (Figure B.1). The database file name is
base.gdb; the file is located in the directory “<MOVI 1.0 Installation
Directory>\BASE”.
Figure B.1 Structure of the problem’s database
– 110 –
When a new problem is being set up, the structure (empty database file) is
copied to the problem folder and filled up with data. MOVI 1.0 then uses this
database only while working on this problem.
The database tables are described in Table B.1.
Table B.1 Description of the Problem’s Database Tables
Table
Data
Data Type
Problem
status
variables
(number
of
tests
CFG
temporary data
performed, truncation number, etc.)
Description of the problem's design variables input data
(name, variation range, type (discrete or
continuous))
PRM
FUNCS
FR
CRITS
CR
FIRSTCRBOUN
D
CRITTAB
CUTTED
TMPTAB
FPRM
PAR
DISKR
PVALUES
Description of functional constraints
(name, function identifier, constraint)
Table of functional failures
Description of criteria (name, function
identifier, constraint, type)
Table of criteria failures
Initial values for criteria constraints
input data
Test table
Calculated criteria values not included in
the test table
Table of temporary criteria constraints
Table of the numbers of design variable
vectors included in the feasible set
Table of the numbers of design variable
vectors included in the Pareto optimal set
Table of discrete values of design
variables
Table of design variable values
results
results
temporary data
input data
temporary data
input data
temporary data
results
results
input data
unused
We chose to give information about the tables and fields of the database. This
information will be of interest for users who want to utilize software other than MOVI
1.0 to process the calculated data.
B.2. CFG Table
The CFG table stores problem status variables. It contains only one record.
This table is declared as follows:
CREATE TABLE CFG (
NUM INTEGER NOT NULL,
NPRMS INTEGER,
NPRMSDISKR INTEGER,
NFUNCS INTEGER,
NCRITBOUNDS INTEGER,
NCRITS INTEGER,
NTESTED INTEGER,
NSOLVED INTEGER,
NFEASIBLE INTEGER,
– 111 –
NCUT INTEGER,
PSTATE INTEGER,
NSOLVEDBEFORCUT INTEGER,
NPAR INTEGER,
NDOP INTEGER,
ALGTYPE INTEGER,
CURALG INTEGER,
SETKA4 INTEGER
)
The following table gives the meaning of each field:
Field Name
Meaning
NUM
Always equal to 1
NPRMS
Number of design variables
NFUNCS
Number of functional relations
NCRITS
Number of criteria
NTESTED
Number of tests performed
NSOLVED
Number of tests performed
NFEASIBLE
Number of vectors in the Test Table
NCUT
Equal to the truncation number if greater than 1; otherwise,
indicates the utilization of the test table
NPAR
Number of vectors in the Pareto optimal set
NDOP
Number of vectors in the feasible set
ALGTYPE
Type of algorithm used to calculate the full ordered test table:
1 – Test Table I
2 – Test Table II
CURALG
Indicates the type of table used last time. Takes the same values
as ALGTYPE
SETKA4
Not used
B.3. PRM Table
The PRM Table stores initial data on the problem's design variables. The
number of records is equal to the number of design variables. This table is declared
as follows:
CREATE TABLE PRM (
PRNUM INTEGER NOT NULL,
PRTOP DOUBLE PRECISION,
PRBOT DOUBLE PRECISION,
PRDISCR INTEGER,
PRNAME VARCHAR(100),
NDISKR INTEGER)
The following table gives the meaning of each field:
Field Name
Meaning
PRNUM
Number of the design variable
PRTOP
Upper bound of the design variable range
PRBOT
Lower bound of the design variable range
PRDISCR
Type of design variable:
0 – continuous
1 – discrete
PRNAME
Design variable name
NDISKR
Number of discrete values
– 112 –
B.4. FUNCS Table
The FUNCS Table stores initial data for functional constraints. The number of
records is equal to the number of functional constraints. This table is declared as
follows:
CREATE TABLE FUNCS (
FNUM INTEGER NOT NULL,
FFUNCNAME VARCHAR(100),
FCMODE VARCHAR(100),
FBOUND DOUBLE PRECISION,
FNAME VARCHAR(100)
)
The following table gives the meaning of each field:
Field Name
Meaning
FNUM
Number of the functional constraint
FFUNCNAME
Identifier of the function used to calculate the functional relation in
the Interface Library
FCMODE
Comparison operation
FBOUND
Constraint value
FNAME
Constraint name
B.5. CRITS Table
The CRITS Table stores initial data for criteria. The number of records is
equal to the number of criteria. This table is declared as follows:
CREATE TABLE CRITS (
CNUM INTEGER NOT NULL,
CFUNCNAME VARCHAR(100),
CMODE VARCHAR(100),
CPSEVDO INTEGER,
CNAME VARCHAR(100),
CHARD INTEGER,
CHARDV DOUBLE PRECISION
)
The following table gives the meaning of each field:
Field Name
Meaning
CNUM
Number of the criterion
CFUNCNAME
Identifier of the function used to calculate the criterion in the
Interface Library
CMODE
Extremalization type
CPSEVDO
Type of criterion (0 – criterion, 1 – pseudo-criterion)
CNAME
Criterion name
CHARDV
Criterion constraint
B.6. FR Table
The FR table stores information about functional failures. It includes vectors
that failed to satisfy the functional constraints (the CHECK OF PRIMARY
CONSTRAINTS item from the main menu and the CONTINUE TESTING button in
– 113 –
the window for processing test tables). The number of records depends on the
number of such vectors. This table is declared as follows:
CREATE TABLE FR (
NF INTEGER,
FCONT DOUBLE PRECISION,
PRM INTEGER NOT NULL
)
The following table gives the meaning of each field:
Field Name
NF
FCONT
PRM
Meaning
Number of the functional constraint from Table FUNCS violated
by vector RPM
Value of the function NF for vector PRM
Number of the test (number of the design variable vector)
B.7. СR Table
The CR table stores information about criteria failures. It includes vectors that
failed to satisfy criteria constraints during the check of the primary constraints
(CHECK OF PRIMARY CONSTRAINTS item from the main menu and the
CONTINUE TESTING button in the PROCESSING TEST TABLES window). The
number of records depends on the number of such vectors. This table is declared as
follows:
CREATE TABLE CR (
NC INTEGER,
CCONT DOUBLE PRECISION,
PRM INTEGER NOT NULL
)
The following table gives the meaning of each field:
Field Name
Meaning
NС
Number of the criterion from the CRITS table, the constraint on
which was violated by the vector RPM
СCONT
Value of the function NC for the vector PRM
PRM
Number of the test (number of the design variable vector)
B.8. FIRSTCRBOUND Table
The FIRSTCRBOUND table stores initial values of criteria constraints. The
fields are filled when the corresponding values are entered in the new problem setup
windows or modified when an existing problem is edited. The number of records is
equal to the number of criteria. This table is declared as follows:
CREATE TABLE FIRSTCRBOUND (
NC INTEGER NOT NULL,
CVALUE DOUBLE PRECISION
)
The following table gives the meaning of each field:
Field Name
Meaning
NC
The number of the criterion from the CRITS table
CVALUE
Value of the constraint
– 114 –
B.9. CRITTAB Table
The CRITTAB Table stores calculated criteria values from the Test Table. The
number of records in this table is equal to the product of the number of criteria
(NCRITS from the CFG table) and the number of design variable vectors included in
the Test Table (NFEASIBLЕ from the CFG table). This table is declared as follows:
CREATE TABLE CRITTAB (
NP INTEGER NOT NULL,
NC INTEGER NOT NULL,
CVALUE DOUBLE PRECISION
)
The following table gives the meaning of each field:
Field Name
NP
NC
CVALUE
Meaning
Number of the test (number of the design variable vector)
Number of the criterion
Value of criterion NC, calculated for design variable vector NP
B.10. CUTTED Table
The CUTTED Table stores calculated criteria values not included in the Test
Table. This table is declared as follows:
CREATE TABLE CUTTED (
NP INTEGER NOT NULL,
NC INTEGER NOT NULL,
CVALUE DOUBLE PRECISION
)
The meanings of the fields are similar to those of the CRITTAB table.
B.11. TMPTAB Table
The TMPTAB table stores temporary criteria constraints. The number of
records depends on the number of truncations. The table stores the values of criteria
constraints that are set in the Test Table when proceeding to truncated tables or
closing the Test Table window. This table is declared as follows:
CREATE TABLE TMPTAB (
NCUT INTEGER NOT NULL,
NC INTEGER NOT NULL,
NP INTEGER NOT NULL,
ND INTEGER NOT NULL,
CVALUE DOUBLE PRECISION
)
– 115 –
The following table gives the meaning of each field:
Field Name
Meaning
Truncation number. NCUT=1 corresponds to the positions of the
cursor in the full test table when proceeding to the truncated test
table, NCUT=2 corresponds to the positions of the cursor in the
first truncated table when proceeding to the next table, and so
forth. The last value of NCUT corresponds to the positions of the
cursor in the table the user last dealt with. The values are
assigned to the variable NCUT before closing the Test Table
window.
Number of the criterion
Number of the design variable vector on which the cursor was
positioned for criterion NC
Number of vectors satisfying the constraint imposed on criterion
NC
Value of criterion NC calculated for design variable vector NP
NCUT
NC
NP
ND
CVALUE
B.12. FPRM and PAR Tables
The FPRM and PAR tables store the results of the construction of the feasible
and Pareto optimal sets. Both tables contain only one field, NP, of type INTEGER,
which stores the number of the vector from the CRTITTAB table that was included in
the feasible (for the FPRM table) or Pareto optimal (for the PAR table) set.
B.13. DISKR Table
The DISKR table stores the values of discrete design variables entered during
the problem setup. This table is declared as follows:
CREATE TABLE DISKR (
NP INTEGER NOT NULL,
DVALUE DOUBLE PRECISION NOT NULL )
The following table gives the meaning of each field:
Field Name
Meaning
NP
Number of the design variable from the PRM table
DVALUE
Discrete value of design variable NP
B.14. Other Types of Files That Can Be Generated
-
-
-
MOVI 1.0 can also generate the following files:
*.ch1 – files generated when saving CRITERION VERSUS DESIGN
VARIABLE I graphs. These files can be opened by using the appropriate
menu item (see Section11).
*.ch2 – files generated when saving CRITERION VERSUS DESIGN
VARIABLE I graphs. These files can be opened by using the appropriate
menu item (see Section 11).
*.bmp – files generated when saving histograms (bar graphs) and charts
using the SAVE AS BITMAP menu item.
– 116 –
REFERENCES
1. Statnikov R.B. Multicriteria Design. Optimization and Identification.
Dordrecht/Boston/London: Kluwer Academic Publishers, 1999. 203 p.
2. Statnikov R.B., Matusov J.B. Multicriteria Optimization and Engineering. N.Y.:
Chapman and Hall, 1995. 236 p.
3. Statnikov R.B., Matusov J.B. Use of P-nets for the approximation of the
Edgeworth–Pareto set in multicriteria optimization // Journal of Optimization
Theory and Application. 1996. Vol. 91. # 3, pp. 543-560.
4. Sobol', I.M., and R.B. Statnikov. 1981. The Choice of Optimal Parameters in
Multicriteria Problems. Moscow: Nauka (in Russian).
5. Sobol', I.M., and R.B. Statnikov. 1982. The Best Solutions: Where They May
Be Found. Moscow: Znanie (in Russian).
6. Sobol', I.M., and R.B. Statnikov. 1977. Statement of Some Problems of
Computer Aided Optimal Design. Moscow: Keldysh Institute of Applied
Mathematics (in Russian).
7. Statnikov, R.B. and J.B. Matusov. 1989. Multicriteria Machine Design.
Moscow: Znanie (in Russian).
8. Dyer P.C., Fishburn P.C., Steuer R.E., Wallenius J., Zionts S. Multiple criteria
decision making. Multiattribute utility theory: the next ten years //Management
Science. 1992. Vol. 38. #5, pp. 645-654.
9. Stadler W., Dauer J.P. Multicriteria optimization in engineering: a tutorial and
survey //Structural Optimization: Status and Promise. Edited by M.P. Kamat,
Progress in Aeronautics and Astronautics, AIAA, Washington, DC. 1992. Vol.
150, pp. 543-566.
10. Steuer R.E., Sun M. The parameter space investigation method of multiple
objective nonlinear programming: a computational investigation //Operations
Research. 1995. Vol. 43. #4, pp. 641-648.
11. Statnikov R.B., Matusov I.B., and Statnikov A.R. Some major optimization
problems of mechanical engineering. Formulation and solution // Journal of
Machinery Manufacture and reliability. 2000. #2, pp.1-7.