 Algorithmique Numérique Distribuée Public GIT Repository
1 /* Copyright (c) 2004-2017. The SimGrid Team. All rights reserved.          */
3 /* This program is free software; you can redistribute it and/or modify it
4  * under the terms of the license (GNU LGPL) which comes with this package. */
6 #ifndef SURF_MAXMIN_HPP
7 #define SURF_MAXMIN_HPP
9 #include "src/internal_config.h"
10 #include "surf/surf.hpp"
11 #include "xbt/asserts.h"
12 #include "xbt/misc.h"
13 #include <cmath>
16  * @details
17  * A linear maxmin solver to resolve inequations systems.
18  *
19  * Most SimGrid model rely on a "fluid/steady-state" modeling that simulate the sharing of resources between actions at
20  * relatively coarse-grain.  Such sharing is generally done by solving a set of linear inequations. Let's take an
21  * example and assume we have the variables \f$x_1\f$, \f$x_2\f$, \f$x_3\f$, and \f$x_4\f$ . Let's say that \f$x_1\f$
22  * and \f$x_2\f$ correspond to activities running and the same CPU \f$A\f$ whose capacity is \f$C_A\f$. In such a
23  * case, we need to enforce:
24  *
25  *   \f[ x_1 + x_2 \leq C_A \f]
26  *
27  * Likewise, if \f$x_3\f$ (resp. \f$x_4\f$) corresponds to a network flow \f$F_3\f$ (resp. \f$F_4\f$) that goes through
28  * a set of links \f$L_1\f$ and \f$L_2\f$ (resp. \f$L_2\f$ and \f$L_3\f$), then we need to enforce:
29  *
30  *   \f[ x_3  \leq C_{L_1} \f]
31  *   \f[ x_3 + x_4 \leq C_{L_2} \f]
32  *   \f[ x_4 \leq C_{L_3} \f]
33  *
34  * One could set every variable to 0 to make sure the constraints are satisfied but this would obviously not be very
35  * realistic. A possible objective is to try to maximize the minimum of the \f$x_i\f$ . This ensures that all the
36  * \f$x_i\f$ are positive and "as large as possible".
37  *
38  * This is called *max-min fairness* and is the most commonly used objective in SimGrid. Another possibility is to
39  * maximize \f$\sum_if(x_i)\f$, where \f$f\f$ is a strictly increasing concave function.
40  *
41  * Constraint:
42  *  - bound (set)
43  *  - shared (set)
44  *  - usage (computed)
45  *
46  * Variable:
47  *  - weight (set)
48  *  - bound (set)
49  *  - value (computed)
50  *
51  * Element:
52  *  - value (set)
53  *
54  * A possible system could be:
55  * - three variables: var1, var2, var3
56  * - two constraints: cons1, cons2
57  * - four elements linking:
58  *  - elem1 linking var1 and cons1
59  *  - elem2 linking var2 and cons1
60  *  - elem3 linking var2 and cons2
61  *  - elem4 linking var3 and cons2
62  *
63  * And the corresponding inequations will be:
64  *
65  *     var1.value <= var1.bound
66  *     var2.value <= var2.bound
67  *     var3.value <= var3.bound
68  *     var1.weight * var1.value * elem1.value + var2.weight * var2.value * elem2.value <= cons1.bound
69  *     var2.weight * var2.value * elem3.value + var3.weight * var3.value * elem4.value <= cons2.bound
70  *
71  * where var1.value, var2.value and var3.value are the unknown values.
72  *
73  * If a constraint is not shared, the sum is replaced by a max.
74  * For example, a third non-shared constraint cons3 and the associated elements elem5 and elem6 could write as:
75  *
76  *     max( var1.weight * var1.value * elem5.value  ,  var3.weight * var3.value * elem6.value ) <= cons3.bound
77  *
78  * This is usefull for the sharing of resources for various models.
79  * For instance, for the network model, each link is associated to a constraint and each communication to a variable.
80  *
81  * Implementation details
82  *
83  * For implementation reasons, we are interested in distinguishing variables that actually participate to the
84  * computation of constraints, and those who are part of the equations but are stuck to zero.
85  * We call enabled variables, those which var.weight is strictly positive. Zero-weight variables are called disabled
86  * variables.
87  * Unfortunately this concept of enabled/disabled variables intersects with active/inactive variable.
88  * Semantically, the intent is similar, but the conditions under which a variable is active is slightly more strict
89  * than the conditions for it to be enabled.
90  * A variable is active only if its var.value is non-zero (and, by construction, its var.weight is non-zero).
91  * In general, variables remain disabled after their creation, which often models an initialization phase (e.g. first
92  * packet propagating in the network). Then, it is enabled by the corresponding model. Afterwards, the max-min solver
93  * (lmm_solve()) activates it when appropriate. It is possible that the variable is again disabled, e.g. to model the
94  * pausing of an action.
95  *
96  * Concurrency limit and maximum
97  *
98  * We call concurrency, the number of variables that can be enabled at any time for each constraint.
99  * From a model perspective, this "concurrency" often represents the number of actions that actually compete for one
100  * constraint.
101  * The LMM solver is able to limit the concurrency for each constraint, and to monitor its maximum value.
102  *
103  * One may want to limit the concurrency of constraints for essentially three reasons:
104  *  - Keep LMM system in a size that can be solved (it does not react very well with tens of thousands of variables per
105  *    constraint)
106  *  - Stay within parameters where the fluid model is accurate enough.
107  *  - Model serialization effects
108  *
109  * The concurrency limit can also be set to a negative value to disable concurrency limit. This can improve performance
110  * slightly.
111  *
112  * Overall, each constraint contains three fields related to concurrency:
113  *  - concurrency_limit which is the limit enforced by the solver
114  *  - concurrency_current which is the current concurrency
115  *  - concurrency_maximum which is the observed maximum concurrency
116  *
117  * Variables also have one field related to concurrency: concurrency_share.
118  * In effect, in some cases, one variable is involved multiple times (i.e. two elements) in a constraint.
119  * For example, cross-traffic is modeled using 2 elements per constraint.
120  * concurrency_share formally corresponds to the maximum number of elements that associate the variable and any given
121  * constraint.
122  */
124 /** @{ @ingroup SURF_lmm */
126 /**
127  * @brief Solve the lmm system
128  * @param sys The lmm system to solve
129  */
130 XBT_PUBLIC(void) lmm_solve(lmm_system_t sys);
132 XBT_PUBLIC(void) lagrange_solve(lmm_system_t sys);
133 XBT_PUBLIC(void) bottleneck_solve(lmm_system_t sys);
135 /** Default functions associated to the chosen protocol. When using the lagrangian approach. */
137 XBT_PUBLIC(void)
138 lmm_set_default_protocol_function(double (*func_f)(lmm_variable_t var, double x),
139                                   double (*func_fp)(lmm_variable_t var, double x),
140                                   double (*func_fpi)(lmm_variable_t var, double x));
142 XBT_PUBLIC(double) func_reno_f(lmm_variable_t var, double x);
143 XBT_PUBLIC(double) func_reno_fp(lmm_variable_t var, double x);
144 XBT_PUBLIC(double) func_reno_fpi(lmm_variable_t var, double x);
146 XBT_PUBLIC(double) func_reno2_f(lmm_variable_t var, double x);
147 XBT_PUBLIC(double) func_reno2_fp(lmm_variable_t var, double x);
148 XBT_PUBLIC(double) func_reno2_fpi(lmm_variable_t var, double x);
150 XBT_PUBLIC(double) func_vegas_f(lmm_variable_t var, double x);
151 XBT_PUBLIC(double) func_vegas_fp(lmm_variable_t var, double x);
152 XBT_PUBLIC(double) func_vegas_fpi(lmm_variable_t var, double x);
154 /** @} */
156 #endif