gurobipy 12.0.3__cp310-cp310-win_amd64.whl → 13.0.0b1__cp310-cp310-win_amd64.whl

gurobipy/_paramdetails.py

@@ -318,7 +318,7 @@ param_details = {
         }
     },
     "ConcurrentSettings": {
-        "description": "This command-line only parameter allows you to specify a comma-\nseparated list of .prm files that are used to set parameters for the\ndifferent instances in a concurrent MIP run.\n\nTo give an example, you could create two \".prm\" files with the\nfollowing contents\u2026\n\ns0.prm:\n\n   MIPFocus 0\n\ns1.prm:\n\n   MIPFocus 1\n\nIssuing the command \"gurobi_cl ConcurrentSettings=s0.prm,s1.prm\nmodel.mps\" would invoke the concurrent MIP solver, using parameter\nsetting MIPFocus=0 in one of the two concurrent solves and MIPFocus=1\nin the other.\n\nNote that if you want to run concurrent MIP on multiple machines, you\nmust also set the ConcurrentJobs parameter. The command for running\ndistributed concurrent optimization using the two example parameter\nfiles on two machines would be\n\n   > gurobi_cl ConcurrentJobs=2 ConcurrentSettings=s0.prm,s1.prm model.mps\n\nNote:\n\n  Command-line only (\"gurobi_cl\"). See Concurrent environments for the\n  equivalent feature in the Gurobi APIs.",
+        "description": "This command-line only parameter allows you to specify a comma-\nseparated list of .prm files that are used to set parameters for the\ndifferent instances in a concurrent MIP run.\n\nTo give an example, you could create two \".prm\" files with the\nfollowing contents\u2026\n\ns0.prm:\n\n   MIPFocus 0\n\ns1.prm:\n\n   MIPFocus 1\n\nIssuing the command \"gurobi_cl ConcurrentSettings=s0.prm,s1.prm\nmodel.mps\" would invoke the concurrent MIP solver, using parameter\nsetting MIPFocus=0 in one of the two concurrent solves and MIPFocus=1\nin the other. It is also possible to provide one parameter file with\nseveral parameter settings, refer to PRM Format for more details.\n\nNote that if you want to run concurrent MIP on multiple machines, you\nmust also set the ConcurrentJobs parameter. The command for running\ndistributed concurrent optimization using the two example parameter\nfiles on two machines would be\n\n   > gurobi_cl ConcurrentJobs=2 ConcurrentSettings=s0.prm,s1.prm model.mps\n\nNote:\n\n  Command-line only (\"gurobi_cl\"). See Concurrent environments for the\n  equivalent feature in the Gurobi APIs.",
         "name": "ConcurrentSettings",
         "values": {
             "default": "",
@@ -336,7 +336,7 @@ param_details = {
         }
     },
     "Crossover": {
-        "description": "Determines the crossover strategy used to transform the interior\nsolution produced by barrier into a basic solution (note that\ncrossover is not available for QP or QCP models). Crossover consists\nof three phases: (i) a *primal push* phase, where primal variables are\npushed to bounds, (ii) a *dual push* phase, where dual variables are\npushed to bounds, and (iii) a *cleanup* phase, where simplex is used\nto remove any primal or dual infeasibilities that remain after the\npush phases are complete. The order of the first two phases and the\nalgorithm used for the third phase are both controlled by the\nCrossover parameter:\n\n+---------------------+----------------+-----------------+-------------+\n| **Parameter value** | **First push** | **Second push** | **Cleanup** |\n|=====================|================|=================|=============|\n| 0                   | Disabled       | Disabled        | Disabled    |\n+---------------------+----------------+-----------------+-------------+\n| 1                   | Dual           | Primal          | Primal      |\n+---------------------+----------------+-----------------+-------------+\n| 2                   | Dual           | Primal          | Dual        |\n+---------------------+----------------+-----------------+-------------+\n| 3                   | Primal         | Dual            | Primal      |\n+---------------------+----------------+-----------------+-------------+\n| 4                   | Primal         | Dual            | Dual        |\n+---------------------+----------------+-----------------+-------------+\n\nThe default value of -1 chooses the strategy automatically. Use value\n0 to disable crossover; this setting returns the interior solution\ncomputed by barrier. Since an interior solution is typically less\naccurate than a basic solution after crossover, disabling crossover\nmay sometimes result in barrier performing more iterations to improve\nthe returned interior solution.\n\nNote:\n\n  Barrier only",
+        "description": "Determines the crossover strategy used to transform the interior\nsolution produced by barrier or PDHG into a basic solution (note that\ncrossover is not available for QP or QCP models). Crossover consists\nof three phases: (i) a *primal push* phase, where primal variables are\npushed to bounds, (ii) a *dual push* phase, where dual variables are\npushed to bounds, and (iii) a *cleanup* phase, where simplex is used\nto remove any primal or dual infeasibilities that remain after the\npush phases are complete. The order of the first two phases and the\nalgorithm used for the third phase are both controlled by the\nCrossover parameter:\n\n+---------------------+----------------+-----------------+-------------+\n| **Parameter value** | **First push** | **Second push** | **Cleanup** |\n|=====================|================|=================|=============|\n| 0                   | Disabled       | Disabled        | Disabled    |\n+---------------------+----------------+-----------------+-------------+\n| 1                   | Dual           | Primal          | Primal      |\n+---------------------+----------------+-----------------+-------------+\n| 2                   | Dual           | Primal          | Dual        |\n+---------------------+----------------+-----------------+-------------+\n| 3                   | Primal         | Dual            | Primal      |\n+---------------------+----------------+-----------------+-------------+\n| 4                   | Primal         | Dual            | Dual        |\n+---------------------+----------------+-----------------+-------------+\n\nThe default value of -1 chooses the strategy automatically. Use value\n0 to disable crossover; this setting returns the interior solution\ncomputed by barrier or PDHG. Since an interior solution is typically\nless accurate than a basic solution after crossover, disabling\ncrossover may sometimes result in barrier or PDHG performing more\niterations to improve the returned interior solution.\n\nNote:\n\n  Barrier and PDHG only",
         "name": "Crossover",
         "values": {
             "default": -1,
@@ -346,7 +346,7 @@ param_details = {
         }
     },
     "CrossoverBasis": {
-        "description": "Determines the initial basis construction strategy for crossover. A\nvalue of 0 chooses an initial basis quickly. A value of 1 can take\nmuch longer, but often produces a more numerically stable start basis.\nThe default value of -1 makes an automatic choice.\n\nNote:\n\n  Barrier only",
+        "description": "Determines the initial basis construction strategy for crossover. A\nvalue of 0 chooses an initial basis quickly. A value of 1 can take\nmuch longer, but often produces a more numerically stable start basis.\nThe default value of -1 makes an automatic choice.\n\nNote:\n\n  Barrier and PDHG only",
         "name": "CrossoverBasis",
         "values": {
             "default": -1,
@@ -475,6 +475,16 @@ param_details = {
             "type": "double"
         }
     },
+    "FixVarsInIndicators": {
+        "description": "Controls how Gurobi deals with indicator constraints when creating the\nfixed model (e.g. \"GRBconverttofixed\" and \"GRBfixmodel\" in C, or\n\"Model.convertToFixed\" and \"Model.fixed\" in Python).\n\nIf set to 0 (the default), then an indicator constraint is discarded\nif its premise is false (i.e., if the associated binary indicator\nvariable is fixed to a value that does not satisfy the premise\ncondition) in the solution or MIP start that is associated to the\nfixed model. On the other hand, if the premise of the indicator is\ntrue, then the implied linear constraint is added as a regular linear\nconstraint to the fixed model.\n\nLet\u2019s consider the case where FixVarsInIndicators is set to 0. If\nthere is an indicator constraint\n\nz = 0 \\rightarrow ax \\leq b\n\nin the model and variable z has value 1 in the solution for which the\nfixed model is created, then the indicator constraint is not active\nand it is therefore discarded from the fixed model. If the indicator\nvariable z has value 0, then the indicator is active and the linear\nconstraint ax \\leq b is added to the fixed model.\n\nIf the FixVarsInIndicators parameter is set to 1, then all variables\n(including continuous variables) in the indicator constraint are fixed\nto their solution value, independent of whether the indicator is\nactive or not in the associated solution.\n\nNote:\n\n  Only affects mixed integer programming (MIP) models",
+        "name": "FixVarsInIndicators",
+        "values": {
+            "default": 0,
+            "maximum": 1,
+            "minimum": 0,
+            "type": "int"
+        }
+    },
     "FlowCoverCuts": {
         "description": "Controls flow cover cut generation. Use 0 to disable these cuts, 1 for\nmoderate cut generation, or 2 for aggressive cut generation. The\ndefault -1 value chooses automatically. Overrides the Cuts parameter.\n\nNote:\n\n  Only affects mixed integer programming (MIP) models",
         "name": "FlowCoverCuts",
@@ -636,7 +646,7 @@ param_details = {
         }
     },
     "ImproveStartTime": {
-        "description": "The MIP solver can change parameter settings in the middle of the\nsearch in order to adopt a strategy that gives up on moving the best\nbound and instead devotes all of its effort towards finding better\nfeasible solutions. This parameter allows you to specify the time when\nthe MIP solver switches to a solution improvement strategy. For\nexample, setting this parameter to 10 will cause the MIP solver to\nswitch strategies 10 seconds after starting the optimization.\n\nNote:\n\n  Only affects mixed integer programming (MIP) models",
+        "description": "The MIP solver can change parameter settings in the middle of the\nsearch in order to adopt a strategy that gives up on moving the best\nbound and instead devotes all of its effort towards finding better\nfeasible solutions. This parameter allows you to specify the time (in\nseconds) when the MIP solver switches to a solution improvement\nstrategy. For example, setting this parameter to 10 will cause the MIP\nsolver to switch strategies 10 seconds after starting the\noptimization.\n\nNote:\n\n  Only affects mixed integer programming (MIP) models",
         "name": "ImproveStartTime",
         "values": {
             "default": 1e+100,
@@ -645,6 +655,16 @@ param_details = {
             "type": "double"
         }
     },
+    "ImproveStartWork": {
+        "description": "The MIP solver can change parameter settings in the middle of the\nsearch in order to adopt a strategy that gives up on moving the best\nbound and instead devotes all of its effort towards finding better\nfeasible solutions. This parameter allows you to specify the work (in\nwork units) when the MIP solver switches to a solution improvement\nstrategy. For example, setting this parameter to 10 will cause the MIP\nsolver to switch strategies 10 work units after starting the\noptimization.\n\nNote:\n\n  Only affects mixed integer programming (MIP) models",
+        "name": "ImproveStartWork",
+        "values": {
+            "default": 1e+100,
+            "maximum": 1e+100,
+            "minimum": 0.0,
+            "type": "double"
+        }
+    },
     "InfProofCuts": {
         "description": "Controls infeasibility proof cut generation. Use 0 to disable these\ncuts, 1 for moderate cut generation, or 2 for aggressive cut\ngeneration. The default -1 value chooses automatically. Overrides the\nCuts parameter.\n\nNote:\n\n  Only affects mixed integer programming (MIP) models",
         "name": "InfProofCuts",
@@ -665,6 +685,16 @@ param_details = {
             "type": "int"
         }
     },
+    "InheritParams": {
+        "description": "Indicates whether parameters from a main environment should be\ninherited when working with Concurrent Environments or Multiobjective\nEnvironments. If set to 1, parameters are inherited from the main\nenvironment: if their value has not been set in the supporting\nenvironment, their value in the main environment is considered. If set\nto 0, parameters are not inherited: only parameters defined on the\nsupporting environment are used. The default value of -1 is equivalent\nto 0, i.e., parameters are not inherited. This parameter can be set\neither on the main environment or on the supporting environment. If it\nis set on both, its value in the supporting environment overrules the\nvalue in the main environment.\n\nWhen using the command line parameters MultiObjSettings or\nConcurrentSettings, set this parameter to 1 if you want to provide\nadditional parameters valid for all objectives or concurrent settings,\nrespectively.",
+        "name": "InheritParams",
+        "values": {
+            "default": -1,
+            "maximum": 1,
+            "minimum": -1,
+            "type": "int"
+        }
+    },
     "InputFile": {
         "description": "Specifies the name of a file that will be read before beginning a\ncommand-line optimization run. This parameter can be used to input a\nMIP start (a \".mst\" or \".sol\" file), MIP hints (a \".hnt\" file), a\nsimplex basis (a \".bas\" file), Gurobi attributes (a \".attr\" file), or\na set of parameter settings (a \".prm\" file) from the Gurobi command\nline. The suffix may optionally be followed by \".zip\", \".gz\", \".bz2\",\n\".7z\" or \".xz\" if the input files are compressed.\n\nNote:\n\n  Command-line only (\"gurobi_cl\"), can be used multiple times\n\nFor examples of how to use this parameter, refer to the Reading Input\nFiles section.",
         "name": "InputFile",
@@ -722,12 +752,12 @@ param_details = {
         }
     },
     "LPWarmStart": {
-        "description": "Controls whether and how Gurobi uses warm start information for an LP\noptimization. The non default setting of 2 is particularly useful for\ncommunicating advanced start information while retaining the\nperformance benefits of presolve. A warm start can consist of any\ncombination of basis statuses, a primal start vector, or a dual start\nvector. It is specified using the attributes VBasis and CBasis or\nPStart and DStart on the original model.\n\nAs a general rule, setting this parameter to 0 ignores any start\ninformation and solves the model from scratch. Setting it to 1 (the\ndefault) uses the provided warm start information to solve the\noriginal, unpresolved problem, regardless of whether presolve is\nenabled. Setting it to 2 uses the start information to solve the\npresolved problem, assuming that presolve is enabled. This involves\nmapping the solution of the original problem into an equivalent (or\nsometimes nearly equivalent) crushed solution of the presolved\nproblem. If presolve is disabled, then setting 2 still prioritizes\nstart vectors, while setting 1 prioritizes basis statuses. Taken\ntogether, the LPWarmStart parameter setting, the LP algorithm\nspecified by Gurobi\u2019s Method parameter, and the available advanced\nstart information determine whether Gurobi will use basis statuses\nonly, basis statuses augmented with information from start vectors, or\na basis obtained by applying the crossover method to the provided\nprimal and dual start vectors to jump start the optimization.\n\nWhen Gurobi\u2019s Method parameter requests the barrier solver, primal and\ndual start vectors are prioritized over basis statuses (but only if\nyou provide both). These start vectors are fed to the crossover\nprocedure. This is the same crossover that is used to compute a basic\nsolution from the interior solution produced by the core barrier\nalgorithm, but in this case crossover is started from arbitrary start\nvectors. If you set the LPWarmStart parameter to 1, crossover will be\ninvoked on the original model using the provided vectors. Any provided\nbasis information will not be used in this case. If you set\nLPWarmStart to 2, crossover will be invoked on the presolved model\nusing crushed start vectors. If you set the parameter to 2 and provide\na basis but no start vectors, the basis will be used to compute the\ncorresponding primal and dual solutions on the original model. Those\nsolutions will then be crushed and used as primal and dual start\nvectors for the crossover, which will then construct a basis for the\npresolved model. Note that for all of these settings and start\ncombinations, no barrier algorithm iterations are performed.\n\nThe simplex algorithms provide more warm-starting options. With a\nparameter value of 1, simplex will start from a provided basis, if\navailable. Otherwise, it uses a provided start vector to refine the\ncrash basis it computes. Primal simplex will use PStart and dual\nsimplex will use DStart in this refinement process.\n\nWith a value of 2, simplex will use the crushed start vector on the\npresolved model (PStart for primal simplex, DStart for dual) to refine\nthe crash basis. This is true regardless of whether the start is\nderived from start vectors or a starting basis from the original\nmodel.  The difference is that if you provide an advanced basis, the\nbasis will be used to compute the corresponding primal and dual\nsolutions on the original model from which the primal or dual start on\nthe presolved model will be derived.\n\nNote:\n\n  Only affects linear programming (LP) models",
+        "description": "Controls whether and how Gurobi uses warm start information for an LP\noptimization. A warm start can consist of any combination of basis\nstatuses, a primal start vector, or a dual start vector. It is\nspecified using the attributes VBasis and CBasis or PStart and DStart\non the original model.\n\nSetting this parameter to 2 is particularly useful for communicating\nadvanced start information while retaining the performance benefits of\npresolve. The default value of -1 is equivalent to 1 for all Method\nchoices except for PDHG, for which it is equivalent to 2.\n\nAs a general rule, setting this parameter to 0 ignores any start\ninformation and solves the model from scratch. Setting it to 1 (the\ndefault) uses the provided warm start information to solve the\noriginal, unpresolved problem, regardless of whether presolve is\nenabled. Setting it to 2 uses the start information to solve the\npresolved problem, assuming that presolve is enabled. This involves\nmapping the solution of the original problem into an equivalent (or\nsometimes nearly equivalent) crushed solution of the presolved\nproblem. If presolve is disabled, then setting 2 still prioritizes\nstart vectors, while setting 1 prioritizes basis statuses. Taken\ntogether, the LPWarmStart parameter setting, the LP algorithm\nspecified by Gurobi\u2019s Method parameter, and the available advanced\nstart information determine whether Gurobi will use basis statuses\nonly, basis statuses augmented with information from start vectors, or\na basis obtained by applying the crossover method to the provided\nprimal and dual start vectors to jump start the optimization.\n\nWhen Gurobi\u2019s Method parameter requests the barrier solver, primal and\ndual start vectors are prioritized over basis statuses (but only if\nyou provide both). These start vectors are fed to the crossover\nprocedure. This is the same crossover that is used to compute a basic\nsolution from the interior solution produced by the core barrier\nalgorithm, but in this case crossover is started from arbitrary start\nvectors. If you set the LPWarmStart parameter to 1, crossover will be\ninvoked on the original model using the provided vectors. Any provided\nbasis information will not be used in this case. If you set\nLPWarmStart to 2, crossover will be invoked on the presolved model\nusing crushed start vectors. If you set the parameter to 2 and provide\na basis but no start vectors, the basis will be used to compute the\ncorresponding primal and dual solutions on the original model. Those\nsolutions will then be crushed and used as primal and dual start\nvectors for the crossover, which will then construct a basis for the\npresolved model. Note that for all of these settings and start\ncombinations, no barrier algorithm iterations are performed.\n\nWhen the Method parameter selects PDHG, primal and dual start vectors\nare used to warm start PDHG iterations directly before proceeding to\ncrossover if it is enabled. If a warm start basis is provided, it will\nbe used to construct start vectors for the PDHG solve. If both a basis\nand vectors are given, vectors are prioritised over basis statuses. If\nyou set LPWarmStart to 1, start vectors will be used to warm-start\nPDHG on the original model. Otherwise, if presolve is enabled, start\nvectors will be crushed and used to warm-start PDHG on the presolved\nmodel.\n\nThe simplex algorithms provide more warm-starting options. With a\nparameter value of 1, simplex will start from a provided basis, if\navailable. Otherwise, it uses a provided start vector to refine the\ncrash basis it computes. Primal simplex will use PStart and dual\nsimplex will use DStart in this refinement process.\n\nWith a value of 2, simplex will use the crushed start vector on the\npresolved model (PStart for primal simplex, DStart for dual) to refine\nthe crash basis. This is true regardless of whether the start is\nderived from start vectors or a starting basis from the original\nmodel.  The difference is that if you provide an advanced basis, the\nbasis will be used to compute the corresponding primal and dual\nsolutions on the original model from which the primal or dual start on\nthe presolved model will be derived.\n\nNote:\n\n  Only affects linear programming (LP) models",
         "name": "LPWarmStart",
         "values": {
-            "default": 1,
+            "default": -1,
             "maximum": 2,
-            "minimum": 0,
+            "minimum": -1,
             "type": "int"
         }
     },
@@ -849,6 +879,16 @@ param_details = {
             "type": "double"
         }
     },
+    "MasterKnapsackCuts": {
+        "description": "Controls the generation of cuts derived from the master knapsack\npolytope. Use 0 to disable these cuts, 1 for moderate cut generation,\nor 2 for aggressive cut generation. The default -1 value chooses\nautomatically. Overrides the Cuts parameter.",
+        "name": "MasterKnapsackCuts",
+        "values": {
+            "default": -1,
+            "maximum": 2,
+            "minimum": -1,
+            "type": "int"
+        }
+    },
     "MemLimit": {
         "description": "Limits the total amount of memory (in GB, i.e., 10^9 bytes) available\nto Gurobi. If more is needed, Gurobi will fail with an OUT_OF_MEMORY\nerror.\n\nNote that it is not possible to retrieve solution information after an\nerror termination. Thus, the behavior of this parameter is different\nfrom that of other termination criteria like SoftMemLimit, TimeLimit,\nor NodeLimit, where the solver will terminate with a Status Code and\nsolution information will still be available.\n\nOne advantage of using this parameter rather than the similar\nSoftMemLimit is that MemLimit is checked after every memory\nallocation, so Gurobi will terminate at precisely the point where the\nlimit is exceeded.\n\nNote that allocated memory is tracked across all models within a\nGurobi environment. If you create multiple models in one environment,\nthese additional models will count towards overall memory consumption.\n\nMemory usage is also tracked across all threads. One consequence of\nthis is that termination may be non-deterministic for multi-threaded\nruns.",
         "name": "MemLimit",
@@ -860,11 +900,11 @@ param_details = {
         }
     },
     "Method": {
-        "description": "Algorithm used to solve continuous models or the initial root\nrelaxation of a MIP model. Options are:\n\n* -1=automatic,\n\n* 0=primal simplex,\n\n* 1=dual simplex,\n\n* 2=barrier,\n\n* 3=concurrent,\n\n* 4=deterministic concurrent, and\n\n* 5=deterministic concurrent simplex (deprecated; see\n  ConcurrentMethod).\n\nAvailable settings and default behaviour depend on the model type or\nthe type of the initial root relaxation. In the current release, the\ndefault Automatic (\"Method=-1\") setting will typically choose non-\ndeterministic concurrent (\"Method=3\") for an LP, barrier (\"Method=2\")\nfor a QP or QCP, and dual (\"Method=1\") for the MIP root relaxation. If\nthe size of the MIP root relaxation is large, then it will often\nselect deterministic concurrent (\"Method=4\") or deterministic\nconcurrent simplex (\"Method=5\").\n\nConcurrent methods aren\u2019t available for QP and QCP. Only the simplex\nand barrier algorithms are available for continuous QP models. If you\nselect barrier (\"Method=2\") to solve the root of an MIQP model, then\nyou need to also select barrier for the node relaxations (i.e. set\nNodeMethod=2).  Only barrier is available for continuous QCP models.\nHowever if you choose LP relaxations for solving MIQCP, you can also\nselect the simplex algorithms (\"Method=0\" or \"Method=1\").\n\nConcurrent optimizers run multiple solvers on multiple threads\nsimultaneously and choose the one that finishes first. The solvers\nthat are run concurrently can be controlled with the ConcurrentMethod\nparameter. The deterministic options (\"Method=4\" and \"Method=5\") give\nthe exact same result each time, while the non-deterministic option\n(\"Method=3\") is often faster but can produce different optimal bases\nwhen run multiple times.\n\nThe default setting is rarely significantly slower than the best\npossible setting, so you generally won\u2019t see a big gain from changing\nthis parameter. There are classes of models where one particular\nalgorithm is consistently fastest, though, so you may want to\nexperiment with different options when confronted with a particularly\ndifficult model.\n\nNote that if memory is tight on an LP model, you should consider using\nthe dual simplex method (\"Method=1\"). The concurrent optimizer, which\nis typically chosen when using the default setting, consumes a lot\nmore memory than dual simplex alone.\n\nIn multiobjective LP optimization:\n\n* The first objective is solved using LP defaults. It can be set by\n  the user using the \"Method\" parameter.\n\n* Subsequent objectives are solved by default using primal simplex to\n  allow for warm starting. The algorithm used here can be controlled\n  using MultiObjMethod.",
+        "description": "Algorithm used to solve continuous models or the initial root\nrelaxation of a MIP model. Options are:\n\n* -1=automatic,\n\n* 0=primal simplex,\n\n* 1=dual simplex,\n\n* 2=barrier,\n\n* 3=concurrent,\n\n* 4=deterministic concurrent,\n\n* 5=deterministic concurrent simplex (deprecated; see\n  ConcurrentMethod), and\n\n* 6=PDHG (Primal-Dual Hybrid Gradient).\n\nAvailable settings and default behaviour depend on the model type or\nthe type of the initial root relaxation. In the current release, the\ndefault Automatic (\"Method=-1\") setting will typically choose non-\ndeterministic concurrent (\"Method=3\") for an LP, barrier (\"Method=2\")\nfor a QP or QCP, and dual (\"Method=1\") for the MIP root relaxation. If\nthe size of the MIP root relaxation is large, then it will often\nselect deterministic concurrent (\"Method=4\") or deterministic\nconcurrent simplex (\"Method=5\").\n\nConcurrent methods aren\u2019t available for QP and QCP. Only the simplex\nand barrier algorithms are available for continuous QP models. If you\nselect barrier (\"Method=2\") to solve the root of an MIQP model, then\nyou need to also select barrier for the node relaxations (i.e. set\nNodeMethod=2).  Only barrier is available for continuous QCP models.\nHowever if you choose LP relaxations for solving MIQCP, you can also\nselect the simplex algorithms (\"Method=0\" or \"Method=1\").\n\nConcurrent optimizers run multiple solvers on multiple threads\nsimultaneously and choose the one that finishes first. The solvers\nthat are run concurrently can be controlled with the ConcurrentMethod\nparameter. The deterministic options (\"Method=4\" and \"Method=5\") give\nthe exact same result each time, while the non-deterministic option\n(\"Method=3\") is often faster but can produce different optimal bases\nwhen run multiple times.\n\nThe default setting is rarely significantly slower than the best\npossible setting, so you generally won\u2019t see a big gain from changing\nthis parameter. There are classes of models where one particular\nalgorithm is consistently fastest, though, so you may want to\nexperiment with different options when confronted with a particularly\ndifficult model.\n\nNote that if memory is tight on an LP model, you should consider using\nthe dual simplex method (\"Method=1\"). The concurrent optimizer, which\nis typically chosen when using the default setting, consumes a lot\nmore memory than dual simplex alone.\n\nIn multiobjective LP optimization:\n\n* The first objective is solved using LP defaults. It can be set by\n  the user using the \"Method\" parameter.\n\n* Subsequent objectives are solved by default using primal simplex to\n  allow for warm starting. The algorithm used here can be controlled\n  using MultiObjMethod.",
         "name": "Method",
         "values": {
             "default": -1,
-            "maximum": 5,
+            "maximum": 6,
             "minimum": -1,
             "type": "int"
         }
@@ -920,20 +960,60 @@ param_details = {
         }
     },
     "MultiObjSettings": {
-        "description": "This command-line only parameter allows you to specify a comma-\nseparated list of .prm files that are used to set parameters for the\ndifferent solves in a multi-objective model.\n\nIn the case of \"grbtune\", the same settings are applied to all the\nmodels.\n\nTo give an example, you could create two \".prm\" files with the\nfollowing contents\u2026\n\nvb0.prm:\n\n   VarBranch 0\n\nvb1.prm:\n\n   VarBranch 1\n\nIssuing the command \"gurobi_cl MultiObjSettings=vb0.prm,vb1.prm\nmodel.mps\" would use different branching strategies when solving for\nthe two objectives of the multi-objective model.\n\nNote:\n\n  Command-line only (\"gurobi_cl\" and \"grbtune\")\n\nNote:\n\n  Only affects multi-objective models",
+        "description": "This command-line only parameter allows you to specify a comma-\nseparated list of .prm files that are used to set parameters for the\ndifferent solves in a multi-objective model. It is also possible to\nprovide one parameter file with several parameter settings, refer to\nPRM Format for more details.\n\nIn the case of \"grbtune\", the same settings are applied to all the\nmodels.\n\nTo give an example, you could create two \".prm\" files with the\nfollowing contents\u2026\n\nvb0.prm:\n\n   VarBranch 0\n\nvb1.prm:\n\n   VarBranch 1\n\nIssuing the command \"gurobi_cl MultiObjSettings=vb0.prm,vb1.prm\nmodel.mps\" would use different branching strategies when solving for\nthe two objectives of the multi-objective model.\n\nNote:\n\n  Command-line only (\"gurobi_cl\" and \"grbtune\")\n\nNote:\n\n  Only affects multi-objective models",
         "name": "MultiObjSettings",
         "values": {
             "default": "",
             "type": "string"
         }
     },
+    "NLBarCFeasTol": {
+        "description": "Important:\n\n  We consider this feature a *preview* in this release. This means\n  that it is fully supported and expected to work correctly, but it\n  will likely undergo significant changes in subsequent Gurobi\n  technical or major releases, potentially including breaking changes\n  in API, behavior and packaging.\n\nFor the NL barrier algorithm, the complementarity error must be\nsmaller than NLBarCFeasTol in order for a model to be declared locally\noptimal.\n\nNote:\n\n  Only affects the NL barrier algorithm",
+        "name": "NLBarCFeasTol",
+        "values": {
+            "default": 1e-08,
+            "maximum": 0.1,
+            "minimum": 1e-12,
+            "type": "double"
+        }
+    },
+    "NLBarDFeasTol": {
+        "description": "Important:\n\n  We consider this feature a *preview* in this release. This means\n  that it is fully supported and expected to work correctly, but it\n  will likely undergo significant changes in subsequent Gurobi\n  technical or major releases, potentially including breaking changes\n  in API, behavior and packaging.\n\nFor the NL barrier algorithm, the dual feasibility error must be\nsmaller than NLBarDFeasTol in order for a model to be declared locally\noptimal.\n\nNote:\n\n  Only affects the NL barrier algorithm",
+        "name": "NLBarDFeasTol",
+        "values": {
+            "default": 1e-06,
+            "maximum": 0.1,
+            "minimum": 1e-12,
+            "type": "double"
+        }
+    },
+    "NLBarIterLimit": {
+        "description": "Important:\n\n  We consider this feature a *preview* in this release. This means\n  that it is fully supported and expected to work correctly, but it\n  will likely undergo significant changes in subsequent Gurobi\n  technical or major releases, potentially including breaking changes\n  in API, behavior and packaging.\n\nLimits the number of barrier NL iterations performed.\n\nOptimization returns with an ITERATION_LIMIT status if the limit is\nexceeded.\n\nThis parameter is callback settable. It can be changed from within a\ncallback when the \"where\" value is \"PRESOLVED\", \"SIMPLEX\", \"MIP\",\n\"MIPSOL\", \"MIPNODE\", \"BARRIER\", or \"MULTIOBJ\" (see the Callback Codes\nsection for more information). How to do that for the different APIs\nis illustrated here. In case of a remote server, the change of a\nparameter from within a callback may not be taken into account\nimmediately.\n\nNote:\n\n  Only affects the NL barrier algorithm",
+        "name": "NLBarIterLimit",
+        "values": {
+            "default": 1000,
+            "maximum": 2000000000,
+            "minimum": 0,
+            "type": "int"
+        }
+    },
+    "NLBarPFeasTol": {
+        "description": "Important:\n\n  We consider this feature a *preview* in this release. This means\n  that it is fully supported and expected to work correctly, but it\n  will likely undergo significant changes in subsequent Gurobi\n  technical or major releases, potentially including breaking changes\n  in API, behavior and packaging.\n\nFor the NL barrier algorithm, the primal feasibility error must be\nsmaller than NLBarPFeasTol in order for a model to be declared locally\noptimal.\n\nNote:\n\n  Only affects the NL barrier algorithm",
+        "name": "NLBarPFeasTol",
+        "values": {
+            "default": 1e-06,
+            "maximum": 0.1,
+            "minimum": 1e-12,
+            "type": "double"
+        }
+    },
     "NLPHeur": {
-        "description": "The NLP heuristic uses a non-linear barrier solver to find feasible\nsolutions to non-convex quadratic models. It can often find solutions\nmuch more quickly than the alternative, but in some cases it can\nconsume significant runtime without producing a solution. By default,\nthe heuristic is enabled (1). Use 0 to disable the heuristic.\n\nNote:\n\n  Only affects models with nonconvex quadratic expressions in the\n  objective or constraints",
+        "description": "The NLP heuristic uses a non-linear barrier solver to find feasible\nsolutions to nonconvex quadratic and nonlinear models during a global\noptimization solve. It often helps to find solutions quicker, but in\nsome cases it can consume significant runtime without producing a\nsolution. A value of 0 disables the heuristic completely, while larger\nvalues call the heuristic more and more aggressively during the\noptimization process. The default -1 value chooses automatically.\n\n   Note:\n\n     Only affects models with nonconvex quadratic or nonlinear\n     expressions in the objective or constraints",
         "name": "NLPHeur",
         "values": {
-            "default": 1,
-            "maximum": 1,
-            "minimum": 0,
+            "default": -1,
+            "maximum": 3,
+            "minimum": -1,
             "type": "int"
         }
     },
@@ -957,6 +1037,16 @@ param_details = {
             "type": "int"
         }
     },
+    "NoRelHeurSolutions": {
+        "description": "Limits the number of solutions found by the NoRel heuristic. This\nheuristic searches for high-quality feasible solutions. It can be\nquite useful on models where the root relaxation is particularly\nexpensive.\n\nNote:\n\n  Only affects mixed integer programming (MIP) models",
+        "name": "NoRelHeurSolutions",
+        "values": {
+            "default": 0,
+            "maximum": 2000000000,
+            "minimum": 0,
+            "type": "int"
+        }
+    },
     "NoRelHeurTime": {
         "description": "Limits the amount of time (in seconds) spent in the NoRel heuristic.\nThis heuristic searches for high-quality feasible solutions before\nsolving the root relaxation. It can be quite useful on models where\nthe root relaxation is particularly expensive.\n\nNote that this parameter will introduce non-determinism - different\nruns may take different paths. Use the NoRelHeurWork parameter for\ndeterministic results.\n\nNote:\n\n  Only affects mixed integer programming (MIP) models",
         "name": "NoRelHeurTime",
@@ -1066,7 +1156,7 @@ param_details = {
         }
     },
     "ObjScale": {
-        "description": "When positive, divides the model objective by the specified value to\navoid numerical issues that may result from very large or very small\nobjective coefficients. The default value of 0 decides on the scaling\nautomatically. A value less than zero uses the maximum coefficient to\nthe specified power as the scaling (so \"ObjScale=-0.5\" would scale by\nthe square root of the largest objective coefficient).\n\nNote that objective scaling can lead to large dual violations on the\noriginal, unscaled objective when the optimality tolerance with the\nscaled objective is barely satisfied, so it should be used sparingly.\nNote also that scaling will be more effective when all objective\ncoefficients are of similar orders of magnitude, as opposed to\nobjectives with a wide range of coefficients. In the latter case,\nconsider using the Multiple Objectives feature instead.",
+        "description": "When positive, divides the model objective by the specified value to\navoid numerical issues that may result from very large or very small\nobjective coefficients. The default value of 0 decides on the scaling\nautomatically. A value less than zero uses the maximum coefficient to\nthe specified power as the scaling, e.g., ObjScale=-1 would divide by\nthe largest objective coefficient, while ObjScale=-0.5 would divide by\nthe square root of that coefficient.\n\nNote that objective scaling can lead to large dual violations on the\noriginal, unscaled objective when the optimality tolerance with the\nscaled objective is barely satisfied, so it should be used sparingly.\nNote also that scaling will be more effective when all objective\ncoefficients are of similar orders of magnitude, as opposed to\nobjectives with a wide range of coefficients. In the latter case,\nconsider using the Multiple Objectives feature instead.",
         "name": "ObjScale",
         "values": {
             "default": 0.0,
@@ -1075,6 +1165,16 @@ param_details = {
             "type": "double"
         }
     },
+    "OptimalityTarget": {
+        "description": "Important:\n\n  We consider this feature a *preview* in this release. This means\n  that it is fully supported and expected to work correctly, but it\n  will likely undergo significant changes in subsequent Gurobi\n  technical or major releases, potentially including breaking changes\n  in API, behavior and packaging.\n\nSpecifies the optimality target for nonlinear continuous problems\n(NLP), including nonconvex QP and QCP models.  Available options are\nAutomatic (-1), Global Optimum (0), and Local Optimum (1). Currently,\nthe automatic choice always selects the search for a global optimum\n(0).\n\nFor Option 0, the linearized outer-approximation branch-and-bound\napproach seeks a feasible point with the best possible objective value\nand provides an optimality gap.\n\nFor Option 1, the nonlinear (NL) barrier algorithm seeks a local\noptimum, i.e., a feasible point that has the best possible objective\nvalue among the feasible points within a local neighborhood. This\nalternative typically converges faster and is able to handle larger\ninstances than a global search, but it does not provide an optimality\ngap.\n\nUpon success, the NL barrier algorithm concludes with status\nLOCALLY_OPTIMAL. If it terminates with LOCALLY_INFEASIBLE, the method\nfound a point that is an infeasible local minimizer of the constraint\nviolation.\n\nNote that the search for a local optimum can only be selected if the\nmodel has no discrete variables or SOS constraints, and does not\ninclude nondifferentiable functions, such as PWL functions, Max-,\nMin-, Abs-operators, or the 1- or Infinity-norm.\n\nThe V13 preview version of the NL barrier algorithm does not yet\nsupport all solution and quality attributes.  In particular, the\noptimal values of dual variables and some quality attributes (such as\nscaled violations) are not yet available.\n\nNote:\n\n  Only affects continuous nonlinear nonconvex QP, QCP, or NLP models",
+        "name": "OptimalityTarget",
+        "values": {
+            "default": -1,
+            "maximum": 1,
+            "minimum": -1,
+            "type": "int"
+        }
+    },
     "OptimalityTol": {
         "description": "For the simplex algorithm and crossover, reduced costs must all be\nsmaller than OptimalityTol in the improving direction in order for a\nmodel to be declared optimal.",
         "name": "OptimalityTol",
@@ -1095,6 +1195,56 @@ param_details = {
             "type": "int"
         }
     },
+    "PDHGAbsTol": {
+        "description": "The PDHG algorithm will terminate if both of the following conditions\nare satisfied:\n\n1. The relative difference between the primal and dual objective\n   values is less than PDHGConvTol, and\n\n2. The primal and dual solution values meet the specified feasibility\n   tolerance. This is satisfied if either:\n\n   1. the absolute residuals of all primal and dual equations are\n      below PDHGAbsTol; or\n\n   2. the relative residuals of all primal and dual equations are\n      below PDHGRelTol.\n\nYou can set PDHGAbsTol to loosen or tighten the second termination\ncriterion. Note though that relative tolerances typically lead to\nearlier termination than absolute tolerances. If you wish to terminate\nPDHG based solely on absolute tolerances, you should set PDHGRelTol to\nzero (0).\n\nThe first criterion is controlled by PDHGConvTol.\n\nNote:\n\n  PDHG only",
+        "name": "PDHGAbsTol",
+        "values": {
+            "default": 1e-06,
+            "maximum": 0.01,
+            "minimum": 1e-09,
+            "type": "double"
+        }
+    },
+    "PDHGConvTol": {
+        "description": "The PDHG algorithm will terminate if both of the following conditions\nare satisfied:\n\n1. The relative difference between the primal and dual objective\n   values is less than PDHGConvTol, and\n\n2. The primal and dual solution values meet the specified feasibility\n   tolerance. This is satisfied if either:\n\n   1. the absolute residuals of all primal and dual equations are\n      below PDHGAbsTol; or\n\n   2. the relative residuals of all primal and dual equations are\n      below PDHGRelTol.\n\nYou can set PDHGConvTol to loosen or tighten the first termination\ncriterion.\n\nThe second criterion is controlled by PDHGAbsTol and PDHGRelTol.\n\nNote:\n\n  PDHG only",
+        "name": "PDHGConvTol",
+        "values": {
+            "default": 1e-06,
+            "maximum": 1.0,
+            "minimum": 0.0,
+            "type": "double"
+        }
+    },
+    "PDHGGPU": {
+        "description": "By default, the PDHG algorithm runs on the CPU. You can set this\nparameter to 1 to have PDHG run on the GPU instead, if your Gurobi\nbuild has GPU support and your system has compatible hardware. Note\nthat you must additionally set the Method parameter to\n\"GRB_METHOD_PDHG\" (6) to enable PDHG.\n\nNote:\n\n  PDHG only",
+        "name": "PDHGGPU",
+        "values": {
+            "default": 0,
+            "maximum": 1,
+            "minimum": 0,
+            "type": "int"
+        }
+    },
+    "PDHGIterLimit": {
+        "description": "Limits the number of PDHG iterations performed.\n\nThe PDHG algorithm will terminate if this limit is exceeded. If\ncrossover is enabled, it will start from the final PDHG iterate. If\ncrossover is disabled, optimization will return with an\nITERATION_LIMIT status.\n\nNote:\n\n  PDHG only",
+        "name": "PDHGIterLimit",
+        "values": {
+            "default": 1e+100,
+            "maximum": 1e+100,
+            "minimum": 0.0,
+            "type": "double"
+        }
+    },
+    "PDHGRelTol": {
+        "description": "The PDHG algorithm will terminate if both of the following conditions\nare satisfied:\n\n1. The relative difference between the primal and dual objective\n   values is less than PDHGConvTol, and\n\n2. The primal and dual solution values meet the specified feasibility\n   tolerance. This is satisfied if either:\n\n   1. the absolute residuals of all primal and dual equations are\n      below PDHGAbsTol; or\n\n   2. the relative residuals of all primal and dual equations are\n      below PDHGRelTol.\n\nYou can set PDHGRelTol to loosen or tighten the second termination\ncriterion.\n\nIf you set PDHGRelTol to the special value zero (0), then only the\nabsolute feasibility tolerances are considered. Specifically, primal\nand dual solutions are considered feasible only if the residuals of\nall primal and dual equations are below PDHGAbsTol.\n\nThe first criterion is controlled by PDHGConvTol.\n\nNote:\n\n  PDHG only",
+        "name": "PDHGRelTol",
+        "values": {
+            "default": 1e-06,
+            "maximum": 1e+100,
+            "minimum": 0.0,
+            "type": "double"
+        }
+    },
     "PSDCuts": {
         "description": "Controls PSD cut generation. Use 0 to disable these cuts, 1 for\nmoderate cut generation, or 2 for aggressive cut generation. The\ndefault -1 value chooses automatically. Overrides the Cuts parameter.\n\nNote:\n\n  Only affects models with nonconvex quadratic expressions in the\n  objective or constraints",
         "name": "PSDCuts",
@@ -1336,7 +1486,7 @@ param_details = {
         }
     },
     "RINS": {
-        "description": "Frequency of the RINS heuristic. Default value (-1) chooses\nautomatically. A value of 0 shuts off RINS. A positive value \"n\"\napplies RINS at every \"n-th\" node of the MIP search tree.\n\nIncreasing the frequency of the RINS heuristic shifts the focus of the\nMIP search away from proving optimality, and towards finding good\nfeasible solutions. We recommend that you try MIPFocus,\nImproveStartGap, or ImproveStartTime before experimenting with this\nparameter.\n\nNote:\n\n  Only affects mixed integer programming (MIP) models",
+        "description": "Frequency of the RINS heuristic. Default value (-1) chooses\nautomatically. A value of 0 shuts off RINS. A positive value \"n\"\napplies RINS at every \"n-th\" node of the MIP search tree.\n\nIncreasing the frequency of the RINS heuristic shifts the focus of the\nMIP search away from proving optimality, and towards finding good\nfeasible solutions. We recommend that you try MIPFocus,\nImproveStartGap, ImproveStartTime, ImproveStartWork, or\nImproveStartNodes before experimenting with this parameter.\n\nNote:\n\n  Only affects mixed integer programming (MIP) models",
         "name": "RINS",
         "values": {
             "default": -1,
@@ -1490,7 +1640,7 @@ param_details = {
         }
     },
     "SolutionNumber": {
-        "description": "When querying attribute Xn, ObjNVal, or PoolObjVal to retrieve an\nalternate MIP solution, this parameter determines which alternate\nsolution is retrieved. The value of this parameter should be less than\nthe value of the SolCount attribute.\n\nNote:\n\n  Only affects mixed integer programming (MIP) models",
+        "description": "When querying attribute PoolNX, ObjNVal, PoolNObjVal or any of the\nsolution pool quality attributes (e.g., PoolNMaxVio) to retrieve\ninformation about an alternate MIP solution, this parameter determines\nfor which alternate solution the data are retrieved. The value of this\nparameter should be less than the value of the SolCount attribute.\n\nNote:\n\n  Only affects mixed integer programming (MIP) models",
         "name": "SolutionNumber",
         "values": {
             "default": 0,
@@ -1529,6 +1679,26 @@ param_details = {
             "type": "int"
         }
     },
+    "StartTimeLimit": {
+        "description": "This parameter limits the total time (in seconds) spent on completing\na partial MIP start.\n\nNote that this parameter will introduce non-determinism - different\nruns may take different paths. Use the StartWorkLimit parameter for\ndeterministic results.\n\nNote:\n\n  Only affects mixed integer programming (MIP) models",
+        "name": "StartTimeLimit",
+        "values": {
+            "default": 1e+100,
+            "maximum": 1e+100,
+            "minimum": 0.0,
+            "type": "double"
+        }
+    },
+    "StartWorkLimit": {
+        "description": "This parameter limits the total work (in work units) spent on\ncompleting a partial MIP start.\n\nIn contrast to the StartTimeLimit, work limits are deterministic. This\nmeans that on the same hardware and with the same parameter and\nattribute settings, a work limit will stop the optimization of a given\nmodel at the exact same point every time. One work unit corresponds\nvery roughly to one second on a single thread, but this greatly\ndepends on the hardware on which Gurobi is running and the model that\nis being solved.\n\nNote:\n\n  Only affects mixed integer programming (MIP) models",
+        "name": "StartWorkLimit",
+        "values": {
+            "default": 1e+100,
+            "maximum": 1e+100,
+            "minimum": 0.0,
+            "type": "double"
+        }
+    },
     "StrongCGCuts": {
         "description": "Controls Strong Chv\u00e1tal-Gomory (Strong-CG) cut generation. Use 0 to\ndisable these cuts, 1 for moderate cut generation, or 2 for aggressive\ncut generation. The default -1 value chooses automatically. Overrides\nthe Cuts parameter.\n\nNote:\n\n  Only affects mixed integer programming (MIP) models",
         "name": "StrongCGCuts",
@@ -1590,12 +1760,12 @@ param_details = {
         }
     },
     "Threads": {
-        "description": "Controls the number of threads to apply to parallel algorithms\n(concurrent LP, parallel barrier, parallel MIP, etc.). The default\nvalue of 0 is an automatic setting. It will generally use as many\nthreads as there are virtual processors. The number of virtual\nprocessors may exceed the number of cores due to hyperthreading or\nother similar hardware features.\n\nWhile you will generally get the best performance by using all\navailable cores in your machine, there are a few exceptions. One is of\ncourse when you are sharing a machine with other jobs. In this case,\nyou should select a thread count that doesn\u2019t oversubscribe the\nmachine.\n\nWe have also found that certain classes of MIP models benefit from\nreducing the thread count, often all the way down to one thread.\nStarting multiple threads introduces contention for machine resources.\nFor classes of models where the first solution found by the MIP solver\nis almost always optimal, and that solution isn\u2019t found at the root,\nit is often better to allow a single thread to explore the search tree\nuncontested.\n\nAnother situation where reducing the thread count can be helpful is\nwhen memory is tight. Each thread can consume a significant amount of\nmemory.\n\nWe\u2019ve made the pragmatic choice to impose a soft limit of 32 threads\nfor the automatic setting (0). If your machine has more, and you find\nthat using more increases performance, you should feel free to set the\nparameter to a larger value.",
+        "description": "Controls the number of threads to apply to parallel algorithms\n(concurrent LP, parallel barrier, parallel MIP, etc.). The default\nvalue of 0 is an automatic setting. It will generally use as many\nthreads as there are virtual processors. The number of virtual\nprocessors may exceed the number of cores due to hyperthreading or\nother similar hardware features.\n\nWhile you will generally get the best performance by using all\navailable cores in your machine, there are a few exceptions. One is of\ncourse when you are sharing a machine with other jobs. In this case,\nyou should select a thread count that doesn\u2019t oversubscribe the\nmachine.\n\nWe have also found that certain classes of MIP models benefit from\nreducing the thread count, often all the way down to one thread.\nStarting multiple threads introduces contention for machine resources.\nFor classes of models where the first solution found by the MIP solver\nis almost always optimal, and that solution isn\u2019t found at the root,\nit is often better to allow a single thread to explore the search tree\nuncontested.\n\nAnother situation where reducing the thread count can be helpful is\nwhen memory is tight. Each thread can consume a significant amount of\nmemory.\n\nWe\u2019ve made the pragmatic choice to impose a soft limit of 32 threads\nfor the automatic setting (0), because usually, Gurobi\u2019s algorithms do\nnot benefit from higher thread counts. Actually, higher thread counts\nmay even hurt performance, because this will often saturate the memory\nsystem.  If your machine has more virtual processors, and you find\nthat using more threads increases performance, you should feel free to\nset the parameter to a larger value. Alternatively, you can use the\nvalue -1 to indicate that Gurobi should use all available virtual\nprocessors, even if the machine has more than 32.",
         "name": "Threads",
         "values": {
             "default": 0,
             "maximum": 1024,
-            "minimum": 0,
+            "minimum": -1,
             "type": "int"
         }
     },
@@ -1618,7 +1788,7 @@ param_details = {
         }
     },
     "TuneBaseSettings": {
-        "description": "A list of parameter files (e.g., \"base1.prm,base2.prm\") that define\nsettings that should be tried first during the tuning process, in the\norder they are given. Default parameter settings will also be tried,\nbut after the settings provided in these files. You can include an\nempty parameter file in the list if you would like default settings to\nbe tried earlier.\n\nNote:\n\n  Command-line only (\"grbtune\")",
+        "description": "A list of parameter files (e.g., \"base1.prm,base2.prm\") that define\nsettings that should be tried first during the tuning process, in the\norder they are given. Default parameter settings will also be tried,\nbut after the settings provided in these files. You can include an\nempty parameter file in the list if you would like default settings to\nbe tried earlier. It is also possible to provide one parameter file\nwith several parameter settings, refer to PRM Format for more details.\n\nNote:\n\n  Command-line only (\"grbtune\")",
         "name": "TuneBaseSettings",
         "values": {
             "default": "",
@@ -1655,6 +1825,14 @@ param_details = {
             "type": "int"
         }
     },
+    "TuneIgnoreSettings": {
+        "description": "A list of parameter files (e.g., \"ignore1.prm,ignore2.prm\") that\ndefine settings that should be ignored during the tuning process. When\na parameter setting is ignored, the tuning algorithm will not try that\nparticular combination of parameters and values. It may still try\ncombinations of parameters that are a subset or a superset of the\nspecified values. You can include an empty parameter file in the list\nif you would like default settings to be ignored. It is also possible\nto provide one parameter file with several parameter settings, refer\nto PRM Format for more details.\n\nNote:\n\n  Command-line only (\"grbtune\")",
+        "name": "TuneIgnoreSettings",
+        "values": {
+            "default": "",
+            "type": "string"
+        }
+    },
     "TuneJobs": {
         "description": "Enables distributed parallel tuning, which can significantly increase\nthe performance of the tuning tool. A value of \"n\" causes the tuning\ntool to use a static set of up to \"n\" workers in parallel. Such\nworkers are kept for the whole tuning run. Note that this parameter\ncan be combined with TuneDynamicJobs to get a static set of workers\nand a dynamic set of workers for distributed tuning. You can use the\nWorkerPool parameter to provide a distributed worker cluster.\n\nNote that distributed tuning is most effective when the worker\nmachines have similar performance. Distributed tuning doesn\u2019t attempt\nto normalize performance by server, so it can incorrectly attribute a\nboost in performance to a parameter change when the associated setting\nis tried on a worker that is significantly faster than the others.",
         "name": "TuneJobs",
@@ -1724,10 +1902,10 @@ param_details = {
         }
     },
     "TuneTimeLimit": {
-        "description": "Limits total tuning runtime (in seconds). The default setting chooses\na time limit automatically.",
+        "description": "Limits total tuning runtime (in seconds). The default value is 86400\nseconds, i.e., 24 hours.",
         "name": "TuneTimeLimit",
         "values": {
-            "default": 1e+100,
+            "default": 86400.0,
             "maximum": 1e+100,
             "minimum": 0.0,
             "type": "double"

gurobipy/_statusconst.py

@@ -26,20 +26,22 @@ class StatusConstClass(object):
   def __setattr__(self, name, value):
     raise AttributeError("Gurobi status constants are not modifiable")
 
-  LOADED          = 1
-  OPTIMAL         = 2
-  INFEASIBLE      = 3
-  INF_OR_UNBD     = 4
-  UNBOUNDED       = 5
-  CUTOFF          = 6
-  ITERATION_LIMIT = 7
-  NODE_LIMIT      = 8
-  TIME_LIMIT      = 9
-  SOLUTION_LIMIT  = 10
-  INTERRUPTED     = 11
-  NUMERIC         = 12
-  SUBOPTIMAL      = 13
-  INPROGRESS      = 14
-  USER_OBJ_LIMIT  = 15
-  WORK_LIMIT      = 16
-  MEM_LIMIT       = 17
+  LOADED             = 1
+  OPTIMAL            = 2
+  INFEASIBLE         = 3
+  INF_OR_UNBD        = 4
+  UNBOUNDED          = 5
+  CUTOFF             = 6
+  ITERATION_LIMIT    = 7
+  NODE_LIMIT         = 8
+  TIME_LIMIT         = 9
+  SOLUTION_LIMIT     = 10
+  INTERRUPTED        = 11
+  NUMERIC            = 12
+  SUBOPTIMAL         = 13
+  INPROGRESS         = 14
+  USER_OBJ_LIMIT     = 15
+  WORK_LIMIT         = 16
+  MEM_LIMIT          = 17
+  LOCALLY_OPTIMAL    = 18
+  LOCALLY_INFEASIBLE = 19

gurobipy/gurobi.lic

@@ -1,6 +1,6 @@
 # Gurobi pip license
 TYPE=PIP
-VERSION=12
-EXPIRATION=2026-11-23
-KEY=1DGU05AF
-CKEY=1DGU05AF
+VERSION=13
+EXPIRATION=2027-11-29
+KEY=GXEBJOVG
+CKEY=GXEBJOVG

gurobipy/nlfunc.py

@@ -28,5 +28,7 @@ from gurobipy._helpers import (
     log2,
     log10,
     logistic,
+    signpow,
     square,
+    tanh,
 )

gurobipy/nlfunc.pyi

@@ -1,4 +1,4 @@
-from typing import overload
+from typing import overload, Union
 
 from gurobipy import NLExpr, MNLExpr, _NLExprLike, _MNLExprLike
 
@@ -39,6 +39,14 @@ def logistic(expr: _NLExprLike) -> NLExpr: ...
 @overload
 def logistic(expr: _MNLExprLike) -> MNLExpr: ...
 @overload
+def tanh(expr: _NLExprLike) -> NLExpr: ...
+@overload
+def tanh(expr: _MNLExprLike) -> MNLExpr: ...
+@overload
+def signpow(expr: _NLExprLike, exponent: Union[int, float]) -> NLExpr: ...
+@overload
+def signpow(expr: _MNLExprLike, exponent: Union[int, float]) -> MNLExpr: ...
+@overload
 def square(expr: _NLExprLike) -> NLExpr: ...
 @overload
 def square(expr: _MNLExprLike) -> MNLExpr: ...

{gurobipy-12.0.3.dist-info → gurobipy-13.0.0b1.dist-info}/METADATA

@@ -1,6 +1,6 @@
-Metadata-Version: 2.1
+Metadata-Version: 2.4
 Name: gurobipy
-Version: 12.0.3
+Version: 13.0.0b1
 Summary: Python interface to Gurobi
 Home-page: https://www.gurobi.com
 Author: Gurobi Optimization, LLC
@@ -11,19 +11,31 @@ Platform: Windows
 Platform: Linux
 Platform: macOS
 Classifier: Programming Language :: Python :: 3
-Classifier: Programming Language :: Python :: 3.9
 Classifier: Programming Language :: Python :: 3.10
 Classifier: Programming Language :: Python :: 3.11
 Classifier: Programming Language :: Python :: 3.12
 Classifier: Programming Language :: Python :: 3.13
 Classifier: Operating System :: OS Independent
 Classifier: Programming Language :: Python :: Implementation :: CPython
-Requires-Python: >=3.9
+Requires-Python: >=3.10
 Description-Content-Type: text/markdown
 License-File: LICENSE.txt
 Provides-Extra: matrixapi
 Requires-Dist: numpy; extra == "matrixapi"
 Requires-Dist: scipy; extra == "matrixapi"
+Dynamic: author
+Dynamic: classifier
+Dynamic: description
+Dynamic: description-content-type
+Dynamic: home-page
+Dynamic: keywords
+Dynamic: license
+Dynamic: license-file
+Dynamic: platform
+Dynamic: project-url
+Dynamic: provides-extra
+Dynamic: requires-python
+Dynamic: summary
 
 ![Python versions](https://img.shields.io/pypi/pyversions/gurobipy.svg)
 ![PyPI - Downloads](https://img.shields.io/pypi/dm/gurobipy)
@@ -114,7 +126,7 @@ DELETE ANY COPIES OF THE PRODUCT YOU MAY HAVE.  TERMS AND CONDITIONS
 1.	DEFINITIONS
 
 1.1.	 "Product" means the limited, evaluation version of Gurobi
-Optimizer Version 12.0.0 or higher in the form of object code
+Optimizer Version 13.0.0 or higher in the form of object code
 libraries, including all upgrades, new releases, modifications,
 enhancements, adaptations, copies and translations thereof. "You" and
 "Your" mean the individual who is installing, accessing or using the