+ * 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.