+ * where `var1.value`, `var2.value` and `var3.value` are the unknown values.
+ *
+ * If a constraint is not shared, the sum is replaced by a max.
+ * For example, a third non-shared constraint `cons3` and the associated elements `elem5` and `elem6` could write as:
+ *
+ * max( var1.weight * var1.value * elem5.value , var3.weight * var3.value * elem6.value ) <= cons3.bound
+ *
+ * This is usefull for the sharing of resources for various models.
+ * For instance, for the network model, each link is associated to a constraint and each communication to a variable.
+ *
+ * Implementation details
+ *
+ * For implementation reasons, we are interested in distinguishing variables that actually participate to the
+ * computation of constraints, and those who are part of the equations but are stuck to zero.
+ * We call enabled variables, those which var.weight is strictly positive. Zero-weight variables are called disabled
+ * variables.
+ * Unfortunately this concept of enabled/disabled variables intersects with active/inactive variable.
+ * Semantically, the intent is similar, but the conditions under which a variable is active is slightly more strict
+ * than the conditions for it to be enabled.
+ * A variable is active only if its var.value is non-zero (and, by construction, its var.weight is non-zero).
+ * In general, variables remain disabled after their creation, which often models an initialization phase (e.g. first
+ * packet propagating in the network). Then, it is enabled by the corresponding model. Afterwards, the max-min solver
+ * (lmm_solve()) activates it when appropriate. It is possible that the variable is again disabled, e.g. to model the
+ * pausing of an action.
+ *
+ * Concurrency limit and maximum
+ *
+ * We call concurrency, the number of variables that can be enabled at any time for each constraint.
+ * From a model perspective, this "concurrency" often represents the number of actions that actually compete for one
+ * constraint.
+ * The LMM solver is able to limit the concurrency for each constraint, and to monitor its maximum value.
+ *
+ * One may want to limit the concurrency of constraints for essentially three reasons:
+ * - Keep LMM system in a size that can be solved (it does not react very well with tens of thousands of variables per
+ * constraint)
+ * - Stay within parameters where the fluid model is accurate enough.
+ * - Model serialization effects
+ *
+ * The concurrency limit can also be set to a negative value to disable concurrency limit. This can improve performance
+ * slightly.
+ *
+ * Overall, each constraint contains three fields related to concurrency:
+ * - concurrency_limit which is the limit enforced by the solver
+ * - concurrency_current which is the current concurrency
+ * - concurrency_maximum which is the observed maximum concurrency
+ *
+ * Variables also have one field related to concurrency: concurrency_share.
+ * In effect, in some cases, one variable is involved multiple times (i.e. two elements) in a constraint.
+ * For example, cross-traffic is modeled using 2 elements per constraint.
+ * concurrency_share formally corresponds to the maximum number of elements that associate the variable and any given
+ * constraint.