Update docs

0.4/.documenter-siteinfo.json

@@ -1 +1 @@
-{"documenter":{"julia_version":"1.10.3","generation_timestamp":"2024-05-09T13:50:05","documenter_version":"1.2.1"}}
+{"documenter":{"julia_version":"1.10.3","generation_timestamp":"2024-05-21T10:28:07","documenter_version":"1.2.1"}}

0.4/tutorials/customizing.jl

@@ -43,15 +43,13 @@ model = UnitCommitment.build_model(
 # First, we load a benchmark instance and solve it, as before.
 
 instance = UnitCommitment.read_benchmark("matpower/case14/2017-01-01");
-model = UnitCommitment.build_model(
+model =
-    instance=instance,
+    UnitCommitment.build_model(instance = instance, optimizer = HiGHS.Optimizer);
-    optimizer=HiGHS.Optimizer,
-);
 UnitCommitment.optimize!(model)
 
 # At this point, it is possible to obtain a reference to the decision variables by calling `model[:varname][index]`. For example, `model[:is_on]["g1",1]` returns a direct reference to the JuMP variable indicating whether generator named "g1" is on at time 1. For a complete list of decision variables available, and how are they indexed, see the [problem definition](../guides/problem.md).
 
-@show JuMP.value(model[:is_on]["g1",1])
+@show JuMP.value(model[:is_on]["g1", 1])
 
 # To access second-stage decisions, it is necessary to specify the scenario name. UnitCommitment.jl models deterministic instances as a particular case in which there is a single scenario named "s1", so we need to use this key.
 
@@ -62,33 +60,24 @@ UnitCommitment.optimize!(model)
 # When testing variations of the unit commitment problem, it is often necessary to modify the objective function, variables and constraints of the formulation. UnitCommitment.jl makes this process relatively easy. The first step is to construct the standard model using `UnitCommitment.build_model`:
 
 instance = UnitCommitment.read_benchmark("matpower/case14/2017-01-01");
-model = UnitCommitment.build_model(
+model =
-    instance=instance,
+    UnitCommitment.build_model(instance = instance, optimizer = HiGHS.Optimizer);
-    optimizer=HiGHS.Optimizer,
-);
 
 # Now, before calling `UnitCommitment.optimize`, we can make any desired changes to the formulation. In the previous section, we saw how to obtain a direct reference to the decision variables. It is possible to modify them by using standard JuMP methods. For example, to fix the commitment status of a particular generator, we can use `JuMP.fix`:
 
-JuMP.fix(model[:is_on]["g1",1], 1.0, force=true)
+JuMP.fix(model[:is_on]["g1", 1], 1.0, force = true)
 
 # To modify the cost coefficient of a particular variable, we can use `JuMP.set_objective_coefficient`:
 
-JuMP.set_objective_coefficient(
+JuMP.set_objective_coefficient(model, model[:switch_on]["g1", 1], 1000.0)
-    model,
-    model[:switch_on]["g1",1],
-    1000.0,
-)
 
 # It is also possible to make changes to the set of constraints. For example, we can add a custom constraint, using the `JuMP.@constraint` macro:
 
-@constraint(
+@constraint(model, model[:is_on]["g3", 1] + model[:is_on]["g4", 1] <= 1,);
-    model,
-    model[:is_on]["g3",1] + model[:is_on]["g4",1] <= 1,
-);
 
 # We can also remove an existing model constraint using `JuMP.delete`. See the [problem definition](../guides/problem.md) for a list of constraint names and indices.
 
-JuMP.delete(model, model[:eq_min_uptime]["g1",1])
+JuMP.delete(model, model[:eq_min_uptime]["g1", 1])
 
 # After we are done with all changes, we can call `UnitCommitment.optimize` and extract the optimal solution:
 
@@ -100,16 +89,13 @@ UnitCommitment.optimize!(model)
 # In this section we demonstrate how to add a new grid component to a particular bus in the network. This is useful, for example, when developing formulations for a new type of generator, energy storage, or any other grid device. We start by reading the instance data and buliding a standard model:
 
 instance = UnitCommitment.read_benchmark("matpower/case118/2017-02-01")
-model = UnitCommitment.build_model(
+model =
-    instance=instance,
+    UnitCommitment.build_model(instance = instance, optimizer = HiGHS.Optimizer);
-    optimizer=HiGHS.Optimizer,
-);
 
 # Next, we create decision variables for the new grid component. In this example, we assume that the new component can inject up to 10 MW of power at each time step, so we create new continuous variables $0 \leq x_t \leq 10$.
 
 T = instance.time
-@variable(model, x[1:T], lower_bound=0.0, upper_bound=10.0);
+@variable(model, x[1:T], lower_bound = 0.0, upper_bound = 10.0);
-
 
 # Next, we add the production costs to the objective function. In this example, we assume a generation cost of \$5/MW:
 

0.4/tutorials/da.json

@@ -0,0 +1,29 @@
+{
+    "Parameters": {
+        "Version": "0.4",
+        "Time horizon (h)": 2
+    },
+    "Buses": {
+        "b1": {
+            "Load (MW)": [200, 400]
+        }
+    },
+    "Generators": {
+        "g1": {
+            "Bus": "b1",
+            "Type": "Thermal",
+            "Production cost curve (MW)": [0, 200],
+            "Production cost curve ($)": [0, 1000],
+            "Initial status (h)": -24,
+            "Initial power (MW)": 0
+        },
+        "g2": {
+            "Bus": "b1",
+            "Type": "Thermal",
+            "Production cost curve (MW)": [0, 300],
+            "Production cost curve ($)": [0, 3000],
+            "Initial status (h)": -24,
+            "Initial power (MW)": 0
+        }
+    }
+}

0.4/tutorials/lmp.jl

@@ -0,0 +1,57 @@
+# # Locational Marginal Prices
+
+# Locational Marginal Prices (LMPs) refer to the cost of supplying electricity at specific locations of the network. LMPs are crucial for the operation of electricity markets and have many other applications, such as indicating what areas of the network may require additional generation or transmission capacity. UnitCommitment.jl implements two methods for calculating LMPS: Conventional LMPs and Approximated Extended LMPs (AELMPs). In this tutorial, we introduce each method and illustrate their usage.
+
+# ### Conventional LMPs
+
+# Conventional LMPs work by (1) solving the original SCUC problem, (2) fixing all binary variables to their optimal values, and (3) re-solving the resulting linear programming model. In this approach, the LMPs are defined as the values of the dual variables associated with the net injection constraints.
+
+# The first step to use this method is to load and optimize an instance, as explained in previous tutorials:
+
+using UnitCommitment
+using HiGHS
+
+instance = UnitCommitment.read_benchmark("matpower/case14/2017-01-01")
+model =
+    UnitCommitment.build_model(instance = instance, optimizer = HiGHS.Optimizer)
+UnitCommitment.optimize!(model)
+
+# Next, we call `UnitCommitment.compute_lmp`, as shown below. The function accepts three arguments -- a solved SCUC model, the LMP method, and a linear optimizer -- and it returns a dictionary mapping `(scenario_name, bus_name, time)` to the marginal price.
+
+lmp = UnitCommitment.compute_lmp(
+    model,
+    UnitCommitment.ConventionalLMP(),
+    optimizer = HiGHS.Optimizer,
+)
+
+# For example, the following code queries the LMP of bus `b1` in scenario `s1` at time 1:
+
+@show lmp["s1", "b1", 1]
+
+# ### Approximate Extended LMPs
+
+# Approximate Extended LMPs (AELMPs) are an alternative method to calculate locational marginal prices which attemps to minimize uplift payments. The method internally works by modifying the instance data in three ways: (1) it sets the minimum power output of each generator to zero, (2) it averages the start-up cost over the offer blocks for each generator, and (3) it relaxes all integrality constraints. To compute AELMPs, as shown in the example below, we call `compute_lmp` and provide `UnitCommitment.AELMP()` as the second argument.
+
+# This method has two configurable parameters: `allow_offline_participation` and `consider_startup_costs`. If `allow_offline_participation = true`, then offline generators are allowed to participate in the pricing. If instead `allow_offline_participation = false`, offline generators are not allowed and therefore are excluded from the system. A solved UC model is optional if offline participation is allowed, but is required if not allowed. The method forces offline participation to be allowed if the UC model supplied by the user is not solved. For the second field, If `consider_startup_costs = true`, then start-up costs are integrated and averaged over each unit production; otherwise the production costs stay the same. By default, both fields are set to `true`.
+
+# !!! warning
+
+#     This method is still under active research, and has several limitations. The implementation provided in the package is based on MISO Phase I only. It only supports fast start resources. More specifically, the minimum up/down time of all generators must be 1, the initial power of all generators must be 0, and the initial status of all generators must be negative. The method does not support time-varying start-up costs, and only currently works for deterministic instances. If offline participation is not allowed, AELMPs treats an asset to be  offline if it is never on throughout all time periods.
+
+instance = UnitCommitment.read_benchmark("test/aelmp_simple")
+
+model =
+    UnitCommitment.build_model(instance = instance, optimizer = HiGHS.Optimizer)
+
+UnitCommitment.optimize!(model)
+
+lmp = UnitCommitment.compute_lmp(
+    model,
+    UnitCommitment.AELMP(
+        allow_offline_participation = false,
+        consider_startup_costs = true,
+    ),
+    optimizer = HiGHS.Optimizer,
+)
+
+@show lmp["s1", "B1", 1]

0.4/tutorials/market.jl

@@ -0,0 +1,183 @@
+# # Market Clearing
+
+# In North America, electricity markets are structured around two primary types of markets: the day-ahead (DA) market and the real-time (RT) market. The DA market schedules electricity generation and consumption for the next day, based on forecasts and bids from electricity suppliers and consumers. The RT market, on the other hand, operates continuously throughout the day, addressing the discrepancies between the DA schedule and actual demand, typically every five minutes. UnitCommitment.jl is able to simulate the DA and RT market clearing process. Specifically, the package provides the function `UnitCommitment.solve_market` which performs the following steps:
+
+# 1. Solve the DA market problem.
+# 2. Extract commitment status of all generators.
+# 3. Solve a sequence of RT market problems, fixing the commitment status of each generator to the corresponding optimal solution of the DA problem.
+
+# To use this function, we need to prepare an instance file corresponding to the DA market problem and multiple instance files corresponding to the RT market problems. The number of required files depends on the time granularity and window. For example, suppose that the DA problem is solved at hourly granularity and has 24 time periods, whereas the RT problems are solved at 5-minute granularity and have a single time period. Then we would need to prepare one files for the DA problem and 288 files $\left(24 \times \frac{60}{5}\right)$ for the RT market problems.
+
+# ## A small example
+
+# For simplicity, in this tutorial we illustate the usage of `UnitCommitment.solve_market` with a very small example, in which the DA problem has only two time periods. We start by creating the DA instance file:
+
+da_contents = """
+{
+    "Parameters": {
+        "Version": "0.4",
+        "Time horizon (h)": 2
+    },
+    "Buses": {
+        "b1": {
+            "Load (MW)": [200, 400]
+        }
+    },
+    "Generators": {
+        "g1": {
+            "Bus": "b1",
+            "Type": "Thermal",
+            "Production cost curve (MW)": [0, 200],
+            "Production cost curve (\$)": [0, 1000],
+            "Initial status (h)": -24,
+            "Initial power (MW)": 0
+        },
+        "g2": {
+            "Bus": "b1",
+            "Type": "Thermal",
+            "Production cost curve (MW)": [0, 300],
+            "Production cost curve (\$)": [0, 3000],
+            "Initial status (h)": -24,
+            "Initial power (MW)": 0
+        }
+    }
+}
+""";
+
+open("da.json", "w") do file
+    return write(file, da_contents)
+end;
+
+# Next, we create eight single-period RT market problems, each one with a 15-minute time granularity:
+
+for i in 1:8
+    rt_contents = """
+    {
+        "Parameters": {
+            "Version": "0.4",
+            "Time horizon (min)": 15,
+            "Time step (min)": 15
+        },
+        "Buses": {
+            "b1": {
+                "Load (MW)": [$(150 + 50 * i)]
+            }
+        },
+        "Generators": {
+            "g1": {
+                "Bus": "b1",
+                "Type": "Thermal",
+                "Production cost curve (MW)": [0, 200],
+                "Production cost curve (\$)": [0, 1000],
+                "Initial status (h)": -24,
+                "Initial power (MW)": 0
+            },
+            "g2": {
+                "Bus": "b1",
+                "Type": "Thermal",
+                "Production cost curve (MW)": [0, 300],
+                "Production cost curve (\$)": [0, 3000],
+                "Initial status (h)": -24,
+                "Initial power (MW)": 0
+            }
+        }
+    }
+    """
+    open("rt_$i.json", "w") do file
+        return write(file, rt_contents)
+    end
+end
+
+# Finally, we call `UnitCommitment.solve_market`, providing as arguments (1) the path to the DA problem; (2) a list of paths to the RT problems; (3) the mixed-integer linear optimizer.
+
+using UnitCommitment
+using HiGHS
+
+solution = UnitCommitment.solve_market(
+    "da.json",
+    [
+        "rt_1.json",
+        "rt_2.json",
+        "rt_3.json",
+        "rt_4.json",
+        "rt_5.json",
+        "rt_6.json",
+        "rt_7.json",
+        "rt_8.json",
+    ],
+    optimizer = HiGHS.Optimizer,
+)
+
+# To retrieve the day-ahead market solution, we can query `solution["DA"]`:
+
+@show solution["DA"]
+
+# To query each real-time market solution, we can query `solution["RT"][i]`. Note that LMPs are automativally calculated.
+
+@show solution["RT"][1]
+
+# ## Customizing the model and LMPs
+
+# When using the `solve_market` function it is still possible to customize the problem formulation and the LMP calculation method. In the next example, we use a custom formulation and explicitly specify the LMP method through the `settings` keyword argument:
+
+UnitCommitment.solve_market(
+    "da.json",
+    [
+        "rt_1.json",
+        "rt_2.json",
+        "rt_3.json",
+        "rt_4.json",
+        "rt_5.json",
+        "rt_6.json",
+        "rt_7.json",
+        "rt_8.json",
+    ],
+    settings = UnitCommitment.MarketSettings(
+        lmp_method = UnitCommitment.ConventionalLMP(),
+        formulation = UnitCommitment.Formulation(
+            pwl_costs = UnitCommitment.KnuOstWat2018.PwlCosts(),
+            ramping = UnitCommitment.MorLatRam2013.Ramping(),
+            startup_costs = UnitCommitment.MorLatRam2013.StartupCosts(),
+            transmission = UnitCommitment.ShiftFactorsFormulation(
+                isf_cutoff = 0.008,
+                lodf_cutoff = 0.003,
+            ),
+        ),
+    ),
+    optimizer = HiGHS.Optimizer,
+)
+
+# It is also possible to add custom variables and constraints to either the DA or RT market problems, through the usage of `after_build_da` and `after_build_rt` callback functions. Similarly, the `after_optimize_da` and `after_optimize_rt` can be used to directly analyze the JuMP models, after they have been optimized:
+
+using JuMP
+
+function after_build_da(model, instance)
+    @constraint(model, model[:is_on]["g1", 1] <= model[:is_on]["g2", 1])
+end
+
+function after_optimize_da(solution, model, instance)
+    @show value(model[:is_on]["g1", 1])
+end
+
+UnitCommitment.solve_market(
+    "da.json",
+    [
+        "rt_1.json",
+        "rt_2.json",
+        "rt_3.json",
+        "rt_4.json",
+        "rt_5.json",
+        "rt_6.json",
+        "rt_7.json",
+        "rt_8.json",
+    ],
+    after_build_da = after_build_da,
+    after_optimize_da = after_optimize_da,
+    optimizer = HiGHS.Optimizer,
+)
+
+# ## Additional considerations
+
+# - UC.jl supports two-stage stochastic DA market problems. In this case, we need one file for each DA market scenario. All RT market problems must be deterministic.
+# - UC.jl also supports multi-period RT market problems. Assume, for example, that the DA market problem is an hourly problem with 24 time periods, whereas the RT market problem uses 5-minute granularity with 4 time periods. UC.jl assumes that the first RT file covers period `0:00` to `0:20`, the second covers `0:05` to `0:25` and so on. We therefore still need 288 RT market files. To avoid going beyond the 24-hour period covered by the DA market solution, however, the last few RT market problems must have only 3, 2, and 1 time periods, covering `23:45` to `24:00`, `23:50` to `24:00` and `23:55` to `24:00`, respectively.
+# - Some MILP solvers (such as Cbc) have issues handling linear programming problems, which are required for the RT market. In this case, a separate linear programming solver can be provided to `solve_market` using the `lp_optimizer` argument. For example, `solve_market(da_file, rt_files, optimizer=Cbc.Optimizer, lp_optimizer=Clp.Optimizer)`.

0.4/tutorials/rt_1.json

@@ -0,0 +1,30 @@
+{
+    "Parameters": {
+        "Version": "0.4",
+        "Time horizon (min)": 15,
+        "Time step (min)": 15
+    },
+    "Buses": {
+        "b1": {
+            "Load (MW)": [200]
+        }
+    },
+    "Generators": {
+        "g1": {
+            "Bus": "b1",
+            "Type": "Thermal",
+            "Production cost curve (MW)": [0, 200],
+            "Production cost curve ($)": [0, 1000],
+            "Initial status (h)": -24,
+            "Initial power (MW)": 0
+        },
+        "g2": {
+            "Bus": "b1",
+            "Type": "Thermal",
+            "Production cost curve (MW)": [0, 300],
+            "Production cost curve ($)": [0, 3000],
+            "Initial status (h)": -24,
+            "Initial power (MW)": 0
+        }
+    }
+}

0.4/tutorials/rt_2.json

@@ -0,0 +1,30 @@
+{
+    "Parameters": {
+        "Version": "0.4",
+        "Time horizon (min)": 15,
+        "Time step (min)": 15
+    },
+    "Buses": {
+        "b1": {
+            "Load (MW)": [250]
+        }
+    },
+    "Generators": {
+        "g1": {
+            "Bus": "b1",
+            "Type": "Thermal",
+            "Production cost curve (MW)": [0, 200],
+            "Production cost curve ($)": [0, 1000],
+            "Initial status (h)": -24,
+            "Initial power (MW)": 0
+        },
+        "g2": {
+            "Bus": "b1",
+            "Type": "Thermal",
+            "Production cost curve (MW)": [0, 300],
+            "Production cost curve ($)": [0, 3000],
+            "Initial status (h)": -24,
+            "Initial power (MW)": 0
+        }
+    }
+}

0.4/tutorials/rt_3.json

@@ -0,0 +1,30 @@
+{
+    "Parameters": {
+        "Version": "0.4",
+        "Time horizon (min)": 15,
+        "Time step (min)": 15
+    },
+    "Buses": {
+        "b1": {
+            "Load (MW)": [300]
+        }
+    },
+    "Generators": {
+        "g1": {
+            "Bus": "b1",
+            "Type": "Thermal",
+            "Production cost curve (MW)": [0, 200],
+            "Production cost curve ($)": [0, 1000],
+            "Initial status (h)": -24,
+            "Initial power (MW)": 0
+        },
+        "g2": {
+            "Bus": "b1",
+            "Type": "Thermal",
+            "Production cost curve (MW)": [0, 300],
+            "Production cost curve ($)": [0, 3000],
+            "Initial status (h)": -24,
+            "Initial power (MW)": 0
+        }
+    }
+}

0.4/tutorials/rt_4.json

@@ -0,0 +1,30 @@
+{
+    "Parameters": {
+        "Version": "0.4",
+        "Time horizon (min)": 15,
+        "Time step (min)": 15
+    },
+    "Buses": {
+        "b1": {
+            "Load (MW)": [350]
+        }
+    },
+    "Generators": {
+        "g1": {
+            "Bus": "b1",
+            "Type": "Thermal",
+            "Production cost curve (MW)": [0, 200],
+            "Production cost curve ($)": [0, 1000],
+            "Initial status (h)": -24,
+            "Initial power (MW)": 0
+        },
+        "g2": {
+            "Bus": "b1",
+            "Type": "Thermal",
+            "Production cost curve (MW)": [0, 300],
+            "Production cost curve ($)": [0, 3000],
+            "Initial status (h)": -24,
+            "Initial power (MW)": 0
+        }
+    }
+}

0.4/tutorials/rt_5.json

@@ -0,0 +1,30 @@
+{
+    "Parameters": {
+        "Version": "0.4",
+        "Time horizon (min)": 15,
+        "Time step (min)": 15
+    },
+    "Buses": {
+        "b1": {
+            "Load (MW)": [400]
+        }
+    },
+    "Generators": {
+        "g1": {
+            "Bus": "b1",
+            "Type": "Thermal",
+            "Production cost curve (MW)": [0, 200],
+            "Production cost curve ($)": [0, 1000],
+            "Initial status (h)": -24,
+            "Initial power (MW)": 0
+        },
+        "g2": {
+            "Bus": "b1",
+            "Type": "Thermal",
+            "Production cost curve (MW)": [0, 300],
+            "Production cost curve ($)": [0, 3000],
+            "Initial status (h)": -24,
+            "Initial power (MW)": 0
+        }
+    }
+}

0.4/tutorials/rt_6.json

@@ -0,0 +1,30 @@
+{
+    "Parameters": {
+        "Version": "0.4",
+        "Time horizon (min)": 15,
+        "Time step (min)": 15
+    },
+    "Buses": {
+        "b1": {
+            "Load (MW)": [450]
+        }
+    },
+    "Generators": {
+        "g1": {
+            "Bus": "b1",
+            "Type": "Thermal",
+            "Production cost curve (MW)": [0, 200],
+            "Production cost curve ($)": [0, 1000],
+            "Initial status (h)": -24,
+            "Initial power (MW)": 0
+        },
+        "g2": {
+            "Bus": "b1",
+            "Type": "Thermal",
+            "Production cost curve (MW)": [0, 300],
+            "Production cost curve ($)": [0, 3000],
+            "Initial status (h)": -24,
+            "Initial power (MW)": 0
+        }
+    }
+}

0.4/tutorials/rt_7.json

@@ -0,0 +1,30 @@
+{
+    "Parameters": {
+        "Version": "0.4",
+        "Time horizon (min)": 15,
+        "Time step (min)": 15
+    },
+    "Buses": {
+        "b1": {
+            "Load (MW)": [500]
+        }
+    },
+    "Generators": {
+        "g1": {
+            "Bus": "b1",
+            "Type": "Thermal",
+            "Production cost curve (MW)": [0, 200],
+            "Production cost curve ($)": [0, 1000],
+            "Initial status (h)": -24,
+            "Initial power (MW)": 0
+        },
+        "g2": {
+            "Bus": "b1",
+            "Type": "Thermal",
+            "Production cost curve (MW)": [0, 300],
+            "Production cost curve ($)": [0, 3000],
+            "Initial status (h)": -24,
+            "Initial power (MW)": 0
+        }
+    }
+}

0.4/tutorials/rt_8.json

@@ -0,0 +1,30 @@
+{
+    "Parameters": {
+        "Version": "0.4",
+        "Time horizon (min)": 15,
+        "Time step (min)": 15
+    },
+    "Buses": {
+        "b1": {
+            "Load (MW)": [550]
+        }
+    },
+    "Generators": {
+        "g1": {
+            "Bus": "b1",
+            "Type": "Thermal",
+            "Production cost curve (MW)": [0, 200],
+            "Production cost curve ($)": [0, 1000],
+            "Initial status (h)": -24,
+            "Initial power (MW)": 0
+        },
+        "g2": {
+            "Bus": "b1",
+            "Type": "Thermal",
+            "Production cost curve (MW)": [0, 300],
+            "Production cost curve ($)": [0, 3000],
+            "Initial status (h)": -24,
+            "Initial power (MW)": 0
+        }
+    }
+}

0.4/tutorials/usage.jl

@@ -8,7 +8,7 @@
 # pkg> add UnitCommitment@0.4
 # ```
 
-# To solve the optimization models, a mixed-integer linear programming (MILP) solver is also required. Please see the [JuMP installation guide](https://jump.dev/JuMP.jl/stable/installation/) for more instructions on installing a solver. Typical open-source choices are [HiGHS](https://github.com/jump-dev/HiGHS.jl), [Cbc](https://github.com/JuliaOpt/Cbc.jl) and [GLPK](https://github.com/JuliaOpt/GLPK.jl). In the instructions below, HiGHS will be used, but any other MILP solver listed in JuMP installation guide should also be compatible.
+# To solve the optimization models, a mixed-integer linear programming (MILP) solver is also required. Please see the [JuMP installation guide](https://jump.dev/JuMP.jl/stable/installation/) for more instructions on installing a solver. Typical open-source choices are [HiGHS](https://github.com/jump-dev/HiGHS.jl), [Cbc](https://github.com/JuliaOpt/Cbc.jl) and [GLPK](https://github.com/JuliaOpt/GLPK.jl). In the instructions below, HiGHS will be used, but any other MILP solver should also be compatible.
 
 # ## Solving a benchmark instance
 
@@ -17,16 +17,14 @@
 using HiGHS
 using UnitCommitment
 
-# Next, we use the function `read_benchmark` to read the instance.
+# Next, we use the function `UnitCommitment.read_benchmark` to read the instance.
 
 instance = UnitCommitment.read_benchmark("matpower/case14/2017-01-01");
 
 # Now that we have the instance loaded in memory, we build the JuMP optimization model using `UnitCommitment.build_model`:
 
-model = UnitCommitment.build_model(
+model =
-    instance=instance,
+    UnitCommitment.build_model(instance = instance, optimizer = HiGHS.Optimizer);
-    optimizer=HiGHS.Optimizer,
-);
 
 # Next, we run the optimization process, with `UnitCommitment.optimize!`:
 
@@ -44,7 +42,6 @@ solution = UnitCommitment.solution(model)
 
 UnitCommitment.write("solution.json", solution)
 
-
 # ## Solving a custom deterministic instance
 
 # In the previous example, we solved a benchmark instance provided by the package. To solve a custom instance, the first step is to create an input file describing the list of elements (generators, loads and transmission lines) in the network. See [Data Format](../guides/format.md) for a complete description of the data format UC.jl expects. To keep this tutorial self-contained, we will create the input JSON file using Julia; however, this step can also be done with a simple text editor. First, we define the contents of the file:
@@ -84,16 +81,14 @@ json_contents = """
 # Next, we write it to `example.json`.
 
 open("example.json", "w") do file
-    write(file, json_contents)
+    return write(file, json_contents)
 end;
 
 # Now that we have the input file, we can proceed as before, but using `UnitCommitment.read` instead of `UnitCommitment.read_benchmark`:
 
 instance = UnitCommitment.read("example.json");
-model = UnitCommitment.build_model(
+model =
-    instance=instance,
+    UnitCommitment.build_model(instance = instance, optimizer = HiGHS.Optimizer);
-    optimizer=HiGHS.Optimizer,
-);
 UnitCommitment.optimize!(model)
 
 # Finally, we extract and display the solution:
@@ -150,7 +145,7 @@ json_contents_s1 = """
 }
 """
 open("example_s1.json", "w") do file
-    write(file, json_contents_s1)
+    return write(file, json_contents_s1)
 end;
 
 # Next, we create `example_s2.json`, the second scenario file:
@@ -189,7 +184,7 @@ json_contents_s2 = """
 }
 """;
 open("example_s2.json", "w") do file
-    write(file, json_contents_s2)
+    return write(file, json_contents_s2)
 end;
 
 # Now that we have our two scenario files, we can read them using `UnitCommitment.read`. Note that, instead of a single file, we now provide a list.
@@ -203,10 +198,8 @@ instance = UnitCommitment.read(glob("example_s*.json"))
 
 # Finally, we build the model and optimize as before:
 
-model = UnitCommitment.build_model(
+model =
-    instance=instance,
+    UnitCommitment.build_model(instance = instance, optimizer = HiGHS.Optimizer);
-    optimizer=HiGHS.Optimizer,
-);
 UnitCommitment.optimize!(model)
 
 # The solution to stochastic instances follows a slightly different format, as shown below:

0.4/tutorials/utils.jl

@@ -33,7 +33,7 @@ json_contents = """
 }
 """;
 open("example_initial.json", "w") do file
-    write(file, json_contents)
+    return write(file, json_contents)
 end;
 
 # Next, we read the instance and generate the initial conditions (in-place):
@@ -43,10 +43,8 @@ UnitCommitment.generate_initial_conditions!(instance, HiGHS.Optimizer)
 
 # Finally, we optimize the resulting problem:
 
-model = UnitCommitment.build_model(
+model =
-    instance=instance,
+    UnitCommitment.build_model(instance = instance, optimizer = HiGHS.Optimizer)
-    optimizer=HiGHS.Optimizer,
-)
 UnitCommitment.optimize!(model)
 
 # !!! warning

index.html

@@ -1 +1 @@
-<meta http-equiv="Refresh" content="0; url='/UnitCommitment.jl/0.3'" />
+<meta http-equiv="Refresh" content="0; url='/UnitCommitment.jl/0.4'" />