General Constraints

The previously-described constraints are typically (but not always) handled directly by the underlying optimization algorithms. Gurobi includes an additional set of higher-level constraints, which we collectively refer to as general constraints, that require special handling. We think of these as belonging to two types: simple constraints and function constraints

Simple general constraints are a modeling convenience. They allow you to state fairly simple relationships between variables (min, max, absolute value, logical OR, etc.). Techniques for translating these constraints into lower-level modeling objects (typically using auxiliary binary variables and linear or SOS constraints) are well known and can be found in optimization modeling textbooks. By automating these translations and removing the need for the modeler to perform them, the hope is that these simple general constraints will allow you to write more readable and more maintainable models.

Function constraints allow you to state much more complex relationships between variables; you can require that $y =
f(x)$ , where $x$ and $y$ are Gurobi decision variables and $f()$ is chosen from a predefined list of nonlinear functions. The common theme among these functions is that there is no simple way to restate the associated constraints using the primitive objects (like integer variables and linear constraints) that a standard MIP solver wants to work with. Alternate algorithms are required, and the resulting models are typically much more difficult to solve than models that do not contain these constraints.

Simple General Constraints

Gurobi supports the following simple general constraints, each with its own syntax and semantics:

MAX constraint: The constraint $$r = \max\{x_1,\ldots,x_k,c\}$$ states that the resultant variable should be equal to the maximum of the operand variables $$x_1,\ldots,x_k$$ and the constant . For example, a solution would be feasible for the constraint $$r = \max\{x_1,x_2,x_3,1.7\}$$ because is indeed the maximum of , , , and .
MIN constraint: Similar to a MAX constraint, the constraint $$r = \min\{x_1,\ldots,x_k,c\}$$ states that the resultant variable should be equal to the minimum of the operand variables $$x_1,\ldots,x_k$$ and the constant .
ABS constraint: The constraint $$r = \mbox{abs}\{x\}$$ states that the resultant variable should be equal to the absolute value of the operand variable . For example, a solution would be feasible for the constraint $$r = \mbox{abs}\{x\}$$ .
AND constraint: The constraint $$r = \mbox{and}\{x_1,\ldots,x_k\}$$ states that the binary resultant variable should be if and only if all of the binary operand variables $$x_1,\ldots,x_k$$ are equal to . For example, a solution would be feasible for the constraint $$r = \mbox{and}\{x_1,x_2,x_3\}$$ . Note that any involved variables that are not already binary are converted to binary.
OR constraint: Similar to an AND constraint, the constraint $$r = \mbox{or}\{x_1,\ldots,x_k\}$$ states that the binary resultant variable should be if and only if at least one of the binary operand variables $$x_1,\ldots,x_k$$ is equal to . Note that any involved variables that are not already binary are converted to binary.
NORM constraint: The constraint $$r = \mbox{norm}\{x_1,\ldots,x_k\}$$ states that the resultant variable should be equal to the vector norm of the operand variables $$x_1,\ldots,x_k$$ . A few options are available: the 0-norm, 1-norm, 2-norm, and infinity-norm.
INDICATOR constraints: An indicator constraint $$y = f \rightarrow a^Tx \leq b$$ states that if the binary indicator variable is equal to in a given solution, where $$f \in \{0,1\}$$ , then the linear constraint $$a^Tx \leq b$$ has to be satisfied. On the other hand, if $$y \neq f$$ (i.e., ) then the linear constraint may be violated. Note that the sense of the linear constraint can also be or $$\geq$$ ; refer to this earlier section for a more detailed description of linear constraints. Note also that declaring an INDICATOR constraint implicitly declares the indicator variable to be of binary type.
Piecewise-linear constraints: A piecewise-linear constraint states that the point must lie on the piecewise-linear function defined by a set of points . Refer to the description of piecewise-linear objectives for details of how piecewise-linear functions are defined.

Note that adding any of these constraints to an otherwise continuous model will transform it into a MIP

As stated above, each general constraint has an equivalent MIP formulation that consists of linear and SOS constraints, and possibly auxiliary variables. Thus, you could always model such constraints yourself without using a Gurobi general constraint. For example, the MAX constraint $$r = \max\{x_1,\ldots,x_k,c\}$$ can be modeled as follows:

$$\begin{array}{rcll} r & = & x_j + s_j & \mbox{ for all } j = 1,\ldots,k \ r &... ...ots,k+1 \ z_j & \in & \{0,1\} & \mbox{ for all } j = 1,\ldots,k+1 \end{array}$$

The first two constraints state that $$r \geq \max\{x_1,\ldots,x_k,c\}$$ , i.e., that the resultant variable $r$

must be at least as large as each of the operand variables $x_j$

and the constant $c$

. This could be modeled using inequalities, but the explicit slack variables play an important role in the constraints that follow.

The next two constraints enforce $$r \leq \max\{x_1,\ldots,x_k,c\}$$ , which ensures that $r$ is equal to the MAX expression. Enforcing this side of the equality is actually a lot more complicated. We need to introduce binary auxiliary variables $$z_j \in \{0,1\}$$ , and SOS1 constraints to required that at most one of the two variables $s_j$ and $z_j$ can be non-zero, which models the implication $$z_j = 1 \rightarrow s_j = 0$$ . Due to the third constraint, one will be equal to $1$ and thus at least one will be zero. Hence, $r = x_j$ for at least one $j$ due to the first constraint, or $r = c$ due to the second constraint.

Tolerances play a role in general constraints, although as you might expect, the exact role depends on the constraint type. As a general rule, violations in the resultant will be smaller than the feasibility tolerance, and integrality violations in integer resultants will also satisfy the integrality tolerance.

By most measures, general constraints are just a means of concisely capturing relationships between variables while removing the burden of creating an equivalent MIP formulation. However, general constraints have another potential advantage: Gurobi might be able to simplify the MIP formulation if it can prove during presolve that the simplified version suffices for the correctness of the model. For this reason, Gurobi might be able to produce a smaller or tighter representation of the general constraint than you would get from the most general formulation. For example, it might be the case that $$r \leq \max\{x_1,\ldots,x_k,c\}$$ is already implied by the other constraints in the model, so that a simple set of inequalities

$$\begin{array}{rcll} r & \geq & x_j \;\;\mbox{ for all } j = 1,\ldots,k \ r & \geq & c \end{array}$$

to describe $$r \geq \max\{x_1,\ldots,x_k,c\}$$ suffices to model the relevant part of the MAX constraint.

Norm Constraint

The norm constraint introduces a few complications that are important to be aware of. As mentioned above, this constraint allows you to set one variable equal to the norm of a vector of variables. A few norms are available. The L1 norm is equal to the sum of the absolute values of the operand variables. The L-infinity norm is equal to the maximum absolute value of any operand. The L2 norm is equal to the square root of the sum of the squares of the operands. The L0 norm counts the number of non-zero values among the operands.

Regarding the L2 norm, one obvious complication comes from the fact that enforcing it requires a quadratic constraint. If your model only ever bounds the result from above (e.g., $$r=\vert\vert x\vert\vert<=1$$ ), then the resulting constraint will be convex. If your model was otherwise convex, the resulting model will be a (convex) QCP. However, if you try to bound the result from below (e.g., $$r=\vert\vert x\vert\vert>=y$$ ), adding the L2 norm constraint will lead to a non-convex QCP model, which will typically be significantly harder to solve.

Regarding the L0 norm, note that results obtained with this constraint can be counter-intuitive. This is a consequence of the fact that for nearly any feasible solution with a variable at exactly 0, you can add a small value into that variable while still satisfying all associated constraints to tolerances. The net result is that a lower bound on the L0 norm is often satisfied by “cheating” - by setting enough variables to values that are slightly different from zero. We strongly recommend that you only bound the result from above. That is, you should avoid using the resultant in situations where the model incentivizes a larger value. This would include situations where the objective coefficient is negative, as well as situations where a larger value for the variable could help to satisfy a constraint (e.g., a greater-than constraint where the resultant appears with a positive coefficient).

Function Constraints

Gurobi supports the following function constraints, each with somewhat different syntax and semantics ( $x$ and $y$ below are Gurobi decision variables, and other terms are constants provided as input when the constraint is added to the model):

Polynomial: $$y = p_0 x^n + p_1 x^{n-1} + ... + p_n x + p_{n+1}$$
Natural exponential: or
Exponential: , where is the base for the exponential function
Natural logarithm: $$y = \log_e(x)$$ or $$y = \ln(x)$$
Logarithm: $$y = \log_a(x)$$ , where is the base for the logarithmic function
Logistic: $$y = \frac{1}{1 + exp(-x)}$$ or $$y = \frac{1}{1 + e^{-x}}$$
Power: , where $$x \geq 0$$ for any and for
Sine: $$y = \sin(x)$$
Cosine: $$y = \cos(x)$$
Tangent: $$y = \tan(x)$$

As noted earlier, there is no good way to restate these nonlinear constraints so that a standard MIP solver can handle them efficiently and accurately. The most effective approaches to solving such problems involve replacing the constraints with piecewise-linear approximations. Gurobi provides two different mechanisms for doing so:

A static piecewise-linear approximation, where the nonlinear function is approximated once, before the MIP solution process begins. That model can then be solved using the standard MIP solver, but the accuracy of the approximation will of course depend heavily on the number of pieces used. For some nonlinear functions, the number of pieces required to achieve the desired accuracy may be lead to excessive solution times.
A dynamic piecewise-linear approximation, using outer approximation and spatial branch-and-bound. In this approach, the MIP solver is extended to compute an approximation in the neighborhood of the current relaxation solution at each node of the branch-and-bound search. The solver can compute very accurate solutions using this approach, but having the model change at each node in the branch-and-bound tree greatly complicates the search, which can lead to much less efficient tree exploration.

The most effective approach will depend on your model and your accuracy goals. That's why we provide both options.

Function Constraints with Static Piecewise-Linear Approximation

As noted earlier, the first option for managing function constraints is to perform a static piecewise-linear approximation, yielding a MIP model that can be handed to the standard MIP solver. Gurobi will take this approach for any function where the FuncNonlinear attribute is set to 0 (or that attribute is set to -1 and the global FuncNonlinear parameter is set to 0).

With this approach to handling non-linearity, you face a fundamental cost-versus-accuracy tradeoff: adding more pieces produces smaller approximation errors, but also increases the cost of solving the problem. The tradeoff can be complex. Gurobi provides a set of three attributes that help to navigate this tradeoff: FuncPieces, FuncPieceLength, FuncPieceError. They are used as follows:

If you would like to choose the number of pieces to use for the approximation, set the FuncPieces attribute to the desired value. All pieces will have equal width. This approach allows you to control the size of the approximation.
If you would like to choose the width of each piece, set the FuncPieces attribute to a special value of 1 and set the FuncPieceLength attribute equal to the desired width of each piece. This approach provides some control over both the size and the error of the approximation. While this may appear to be a minor variation of the first option, note that presolve may tighten the domain of , often substantially, which can make it difficult to predict the relationship between the width of each piece and the number of pieces.
If you would like to set the maximum error you are willing to tolerate in the approximation, set the FuncPieces attribute to a special value of -1 and set the FuncPieceError attribute equal to the maximum absolute approximation you are willing to tolerate. Gurobi will choose pieces, typically of different sizes, to achieve that error bound. Note that the number of pieces required may be quite large if you set a tight error tolerance. You can control the maximum relative error rather than the absolute error by setting the FuncPieces attribute to -2 instead of -1.

These are attributes on the general constraints, so you can choose different values for each individual constraint.

The other relevant attribute is FuncPieceRatio, which controls whether the approximation is an underestimate of the function (0.0), an overestimate (1.0), or somewhere in between (any value strictly between 0.0 and 1.0). You can also choose the special value of -1, which will choose points that are on the original function.

Consider the following simple example:

$\scalebox{1.0}{\includegraphics[width=2.5in]{graphics/func}}$

The goal is to find an approximation of the polynomial $y=x^2$

. We've set FuncPieces to $1$

and FuncPieceLength to $1.0$

, so we're performing an approximation with fixed-width pieces of width 1.0. The domain of $x$

, so the approximation has two pieces. The figure shows 6 points: $$P_{u1}(0,0), P_{u2}(1,1), P_{u3}(2,4)$$ , and $$P_{l1}(0,-0.25), P_{l2}(1, 0.75), P_{l3}(2,3.75)$$ . If FuncPieceRatio is set to $0.0$

, the approximation would be built from the points below the function ( $$P_{l1}, P_{l2}$$ , and $$P_{l3}$$ ). Similarly, if it is set to $1.0$

, the approximation would be built from the points above the function ( $$P_{u1}, P_{u2}$$ , and $$P_{u3}$$ ). A value of $0.6$

would use weighted combinations of the points: $0.6$

times $$P_{ui}$$ plus $0.4$

times $$P_{li}$$ . In this case, the line segments would be built from the points $(0, -0.1), (1,
0.9)$

, and

. If FuncPieceRatio is set to $-1$

, meaning that the approximation would be built from points that are on the original function, in this case the upper points ( $$P_{u1}, P_{u2}$$ , and $$P_{u3}$$ ) fit the bill. This will always be the case for a convex function.

Recall that you can set FuncPieces to $-1$ to control the maximum absolute error. In this case, choosing a FuncPieceError value of $0.25$ would give the piecewise approximation shown in the figure, since the distance between the upper and lower curves is always . A smaller error value would of course lead to more pieces. We should add that piece widths will typically be non-uniform when limiting the maximum approximation error. The approximation algorithms we use try to limit the number of pieces needed to meet the error targets, which often requires more refinement in some portions of the domain than in others.

Note that the approximations are guaranteed to be under- and over-estimates in all cases except for polynomials of degree greater than 5. Finding the roots of higher-degree polynomials, which would be required to guarantee this property, is quite difficult.

If you wish to experiment with different approaches to approximating a set of functions, it is often convenient to be able to change the approach for all functions at once. We provide a set of parameters with the same names as the attributes to make this easier: FuncPieces, FuncPieceLength, FuncPieceError, and FuncPieceRatio. If you set the FuncPieces attribute on a function constraint to $0$ , then the approximation approach for that constraint will be determined by the parameter settings instead.

For some of the supported functions, modest $x$ values can lead to enormous $y$ values (and vice-versa). This can cause numerical issues when solving the resulting piecewise-linear MIP model. To avoid such issues, we limit the range of any or that participates in a function constraint to [-1e+6, 1e+6]. The parameter FuncMaxVal allows you to change these limits, but we recommend that you proceed with caution.

We should point out we handle violations and tolerances differently for PWL approximations, which can sometimes lead to unexpected results. For one, the feasibility tolerance for function constraints is specified in FuncPieceError rather than through the standard feasibility tolerance. We also interpret violations differently. The violation of a function constraint is computed as the Euclidian distance from the solution to the nearest point on the function. Computing this distance exactly can be quite involved for some functions, so we actually compute an over-estimate in some cases. The net result is that the reported violations may be larger than you expect.

Another possible source of unexpected results comes from the fact that solutions that satisfy the original nonlinear function may not satisfy the piecewise-linear approximation of that function. This may lead to sub-optimal solutions or even conclusions of infeasibility. Consider a simple example with two constraints: $y = 2x-1$ and $y=x^2$ . Clearly $(x, y) = (1, 1)$ is a feasible solution, but a piecewise-linear approximation could introduce breakpoints at $x=0.9$ and $x=1.1$ . The resulting approximation gives a $y$ value of $1.01$ at $x=1$ , which is sufficiently far from the actual function value that Gurobi will not consider that a valid solution and declare the model infeasible, since there are no other solutions to the constraints. Reducing the maximum approximation error (by setting FuncPieces to -1 and FuncPieceError to a much smaller value) would help, but this isn't always the best way to address the problem, since tighter error tolerances can substantially increase the number of pieces in the approximation and thus the cost. We recommend the following approach when you encounter unexpected results. For inequalities, you should ask for an approximation that always overestimates or underestimates the function (depending on the sense of the constraint), to ensure that your approximation will always satisfy the constraint. The FuncPieceRatio parameter allows you to do this. For equalities, if you have a sense of where your solution is likely to lie, one option for managing the size of the approximation is to introduce additional variables to capture your function in different ranges, and then perform approximations with different levels of accuracy on these different pieces.

While users could perform piecewise-linear approximations themselves, there are several advantages to asking Gurobi to do it instead. First, Gurobi can often reduce the domains of variables, by using bound strengthening in presolve, or by exploiting repetition in periodic functions like sine or cosine. Smaller domains means fewer pieces to achieve the same accuracy. Gurobi also provides many options to make experimentation easier (for error control, piece length, etc.). These options can be quite difficult to implement and maintain.

Function Constraints With Dynamic Piecewise-Linear Approximation

The alternative for managing function constraints is a more dynamic approach, using spatial branching and outer approximation. Gurobi will take this approach for any function where the FuncNonlinear attribute is set to 1 (or that attribute is set to -1 and the global FuncNonlinear parameter is set to 1).

Solving a model with (nonconvex) nonlinear constraints to global optimality is well known to be a hard task. The idea behind spatial branching is to divide the overall solution space into portions, and to compute valid primal and dual bounds for each portion. Such bounds are obtained by computing a linear approximation to the feasible space for each region (a so-called outer approximation) that contains all feasible solutions for the original nonlinear constraints in that region. Bounds for a region can often be tightened by spatial branching, where the domain of a variable (integer or continuous) is split, allowing hopefully tighter outer approximations to be computed for the resulting feasible subregions. Bounds for the original model can be obtained by combining the bounds from the leafs of the resulting branch-and-bound tree. This process continues until the desired optimality gap (MIPGap) is achieved.

Valid primal bounds come from feasible solutions found during the search. They can be found using various heuristics, or they may come from solutions to the current node relaxation that happen to satisfy the nonlinear and integrality constraints (relaxation solutions will always satisfy linear and bound constraints because these are still present in the relaxation). Valid dual bounds are found by solving an LP over a polyhedron that contains all feasible solutions to the original linear and nonlinear constraints in that region (the outer approximation).

Currently, Gurobi only directly supports the univariate nonlinear functions listed in the Function Constraints section. More complex functions must be disaggregated into a cascade of supported univariate functions. For example, the nonlinear equality constraint

$$x_3 = 100000 \cdot \frac{x_1}{x_1 + 1000 \cdot x_2} $$

can be disaggregated into

$$\begin{array}{ll} z_1 = & x_1 + 1000 \cdot x_2 \ z_2 = & z_1^{-1} \ x_3 = & 100000 \cdot x_1 \cdot z_2. \end{array}$$

Such disaggregation is standard practice for most global non-linear solvers (but it is typically performend behind the scenes).

While the disaggregated reformulation is mathematically equivalent to the original model, we should note that the presence of large coefficients in the expression can lead to larger violations of the original constraints than you might expect, due to the accumulation of violations of the disaggregated constraints.

Suppose we are using the default feasibility tolerance of $$10^{-6}$$ and Gurobi produces the following solution for the disaggregated model:

$$\begin{array}{ll} x_1 = & 1 \ x_2 = & 1 \ z_1 = & 1001.000001 \ z_2 = & 0.001000000998003 \ x_3 = & 100.0000998003 \end{array}$$

As one can see, this solution is indeed feasible within the tolerance for the disaggregated model. However,

$$100000 \cdot \frac{1}{1 + 1000 \cdot 1} = 99.9000999001 \neq 100.0000998003 = x_3. $$

The 100000 coefficient magnifies the error in the intermediate result, leading to a violation of almost $0.1$

on the original model, which is much larger than the specified feasibility tolerance.

This example illustrates that a solution that is feasible for the disaggregated model may not necessarily be feasible for the aggregated (original) model. Clearly, the above example is an extreme case, but this issue can definitely arise in other situations. This makes scaling and tight coefficient ranges extremely important when formulating and solving nonlinear models.

Cookie	Duration	Description
_biz_flagsA	1 year	A Cloudflare cookie set to record users’ settings as well as for authentication and analytics.
_biz_pendingA	1 year	A Cloudflare cookie set to record users’ settings as well as for authentication and analytics.
_biz_sid	30 minutes	This cookie is set by Bizible, to store the user's session id.
ARRAffinity	session	ARRAffinity cookie is set by Azure app service, and allows the service to choose the right instance established by a user to deliver subsequent requests made by that user.
ARRAffinitySameSite	session	This cookie is set by Windows Azure cloud, and is used for load balancing to make sure the visitor page requests are routed to the same server in any browsing session.
BIGipServersj02web-nginx-app_https	session	NGINX cookie
cookielawinfo-checkbox-advertisement	1 year	Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category .
cookielawinfo-checkbox-analytics	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional	11 months	The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
CookieLawInfoConsent	1 year	Records the default button state of the corresponding category & the status of CCPA. It works only in coordination with the primary cookie.
elementor	never	This cookie is used by the website's WordPress theme. It allows the website owner to implement or change the website's content in real-time.
JSESSIONID	session	New Relic uses this cookie to store a session identifier so that New Relic can monitor session counts for an application.
viewed_cookie_policy	11 months	The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.

Cookie	Duration	Description
__cf_bm	30 minutes	This cookie, set by Cloudflare, is used to support Cloudflare Bot Management.
_biz_nA	1 year	Bizible sets this cookie to remember users’ settings as well as for authentication and analytics.
_biz_uid	1 year	This cookie is set by Bizible, to store user id on the current domain.
_hjAbsoluteSessionInProgress	30 minutes	Hotjar sets this cookie to detect a user's first pageview session, which is a True/False flag set by the cookie.
_mkto_trk	2 years	This cookie is set by Marketo. This allows a website to track visitor behavior on the sites on which the cookie is installed and to link a visitor to the recipient of an email marketing campaign, to measure campaign effectiveness. Tracking is performed anonymously until a user self-identifies by submitting a form.
bcookie	1 year	LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie	1 year	LinkedIn sets this cookie to store performed actions on the website.
doc_langsBB	1 year	Documentation system cookie
doc_version	1 year	Documentation system cookie
lang	session	LinkedIn sets this cookie to remember a user's language setting.
lidc	1 day	LinkedIn sets the lidc cookie to facilitate data center selection.
UserMatchHistory	1 month	LinkedIn sets this cookie for LinkedIn Ads ID syncing.
whova_client_id	10 years	Event agenda system cookie

Cookie	Duration	Description
_an_uid	7 days	6Sense Cookie
_BUID	1 year	This cookie, set by Bizible, is a universal user id to identify the same user across multiple clients’ domains.
_ga	2 years	The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors.
_ga_*	1 year 1 month 4 days	Google Analytics sets this cookie to store and count page views.
_gat_UA-*	1 minute	Google Analytics sets this cookie for user behaviour tracking.
_gcl_au	3 months	Provided by Google Tag Manager to experiment advertisement efficiency of websites using their services.
_gd_session	4 hours	This cookie is used for collecting information on users visit to the website. It collects data such as total number of visits, average time spent on the website and the pages loaded.
_gd_visitor	2 years	This cookie is used for collecting information on the users visit such as number of visits, average time spent on the website and the pages loaded for displaying targeted ads.
_gid	1 day	Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously.
_hjFirstSeen	30 minutes	Hotjar sets this cookie to identify a new user’s first session. It stores the true/false value, indicating whether it was the first time Hotjar saw this user.
_hjIncludedInSessionSample_*	2 minutes	Hotjar cookie that is set to determine if a user is included in the data sampling defined by a site's daily session limit.
_hjRecordingEnabled	never	Hotjar sets this cookie when a Recording starts and is read when the recording module is initialized, to see if the user is already in a recording in a particular session.
_hjRecordingLastActivity	never	Hotjar sets this cookie when a user recording starts and when data is sent through the WebSocket.
_hjSession_*	30 minutes	Hotjar cookie that is set when a user first lands on a page with the Hotjar script. It is used to persist the Hotjar User ID, unique to that site on the browser. This ensures that behavior in subsequent visits to the same site will be attributed to the same user ID.
_hjSessionUser_*	1 year	Hotjar cookie that is set when a user first lands on a page with the Hotjar script. It is used to persist the Hotjar User ID, unique to that site on the browser. This ensures that behavior in subsequent visits to the same site will be attributed to the same user ID.
_hjTLDTest	session	To determine the most generic cookie path that has to be used instead of the page hostname, Hotjar sets the _hjTLDTest cookie to store different URL substring alternatives until it fails.
6suuid	2 years	6Sense Cookie
AnalyticsSyncHistory	1 month	LinkedIn cookie
BE_CLA3	1 year 1 month 4 days	BrightEdge sets this cookie to enable data aggregation, analysis and report creation to assess marketing effectiveness and provide solutions for SEO, SEM and website performance.
CONSENT	2 years	YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
dj	10 years	DemandJump cookie
djaimid.a28e	2 years	DemandJump cookiean
djaimses.a28e	30 minutes	DemandJump cookie
li_gc	5 months 27 days	LinkedIn Cookie
ln_or	1 day	LinkedIn Cookie
vuid	2 years	Vimeo installs this cookie to collect tracking information by setting a unique ID to embed videos to the website.

Cookie	Duration	Description
__adroll	1 year 1 month	This cookie is set by AdRoll to identify users across visits and devices. It is used by real-time bidding for advertisers to display relevant advertisements.
__adroll_fpc	1 year	AdRoll sets this cookie to target users with advertisements based on their browsing behaviour.
__adroll_shared	1 year 1 month	Adroll sets this cookie to collect information on users across different websites for relevant advertising.
__ar_v4	1 year	This cookie is set under the domain DoubleClick, to place ads that point to the website in Google search results and to track conversion rates for these ads.
_fbp	3 months	This cookie is set by Facebook to display advertisements when either on Facebook or on a digital platform powered by Facebook advertising, after visiting the website.
_te_	session	Adroll cookie
fr	3 months	Facebook sets this cookie to show relevant advertisements to users by tracking user behaviour across the web, on sites that have Facebook pixel or Facebook social plugin.
IDE	1 year 24 days	Google DoubleClick IDE cookies are used to store information about how the user uses the website to present them with relevant ads and according to the user profile.
li_sugr	3 months	LinkedIn sets this cookie to collect user behaviour data to optimise the website and make advertisements on the website more relevant.
test_cookie	15 minutes	The test_cookie is set by doubleclick.net and is used to determine if the user's browser supports cookies.
VISITOR_INFO1_LIVE	5 months 27 days	A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC	session	YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices	never	YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id	never	YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId	never	This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests	never	This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.

Documentation

General Constraints

Try Gurobi for Free

Evaluation License

Academic License

Cloud Trial

Search

RSS Feeds

News

Events

Resources

Jupyter Models

Case Studies

FAQs

Industries

Features