You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/src/multi-networks.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -41,7 +41,7 @@ PowerModels.ismultinetwork(pm3)
41
41
```
42
42
will result in an error. Moreover, `instantiate_model()` (see )
43
43
44
-
Because this is a common pattern of usage, we provide corresponding calls to `run_mn_opf` (which behaves analogously to `run_opf`, but for multinetwork data).
44
+
Because this is a common pattern of usage, we provide corresponding calls to `solve_mn_opf` (which behaves analogously to `solve_opf`, but for multinetwork data).
Copy file name to clipboardExpand all lines: docs/src/network-data.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -160,19 +160,19 @@ PowerModels.print_summary(network_data) # mixed units form
160
160
Another useful helper function is `update_data`, which takes two network data dictionaries and updates the values in the first dictionary with the values from the second dictionary. This is particularly helpful when applying sparse updates to network data. A good example is using the solution of one computation to update the data in preparation for a second computation, like so,
A variety of helper functions are available for processing the topology of the network. For example, `connected_components` will compute the collections of buses that are connected by branches (i.e. the network's islands). By default PowerModels will attempt to solve all of the network components simultaneously. The `select_largest_component` function can be used to only consider the largest component in the network. Finally the `propagate_topology_status!` can be used to explicitly deactivate components that are implicitly inactive due to the status of other components (e.g. deactivating branches based on the status of their connecting buses), like so,
172
172
```
173
173
data = PowerModels.parse_file("matpower/case3.m")
174
174
PowerModels.propagate_topology_status!(data)
175
-
opf_result = run_ac_opf(data, Ipopt.Optimizer)
175
+
opf_result = solve_ac_opf(data, Ipopt.Optimizer)
176
176
```
177
177
The `test/data/matpower/case7_tplgy.m` case provides an example of the kind of component status deductions that can be made. The `simplify_network!`, `propagate_topology_status!` and `deactivate_isolated_components!` functions can be helpful in diagnosing network models that do not converge or have an infeasible solution.
The run commands in PowerModels return detailed results data in the form of a dictionary. Results dictionaries from either Matpower `.m` or PTI `.raw` files will be identical in format. This dictionary can be saved for further processing as follows,
28
28
29
29
```julia
30
-
result =run_ac_opf("matpower/case3.m", Ipopt.Optimizer)
30
+
result =solve_ac_opf("matpower/case3.m", Ipopt.Optimizer)
31
31
```
32
32
33
33
For example, the algorithm's runtime and final objective value can be accessed with,
@@ -49,17 +49,17 @@ The `print_summary(result["solution"])` function can be used show an table-like
49
49
50
50
## Accessing Different Formulations
51
51
52
-
The function `run_ac_opf` and `run_dc_opf` are shorthands for a more general formulation-independent OPF execution, `run_opf`.
53
-
For example, `run_ac_opf` is equivalent to,
52
+
The function `solve_ac_opf` and `solve_dc_opf` are shorthands for a more general formulation-independent OPF execution, `solve_opf`.
where "ACPPowerModel" indicates an AC formulation in polar coordinates. This more generic `run_opf()` allows one to solve an OPF problem with any power network formulation implemented in PowerModels. For example, an SOC Optimal Power Flow can be run with,
59
+
where "ACPPowerModel" indicates an AC formulation in polar coordinates. This more generic `solve_opf()` allows one to solve an OPF problem with any power network formulation implemented in PowerModels. For example, an SOC Optimal Power Flow can be run with,
Network data parsed from PTI `.raw` files supports data extensions, i.e. data fields that are within the PSS(R)E specification, but not used by PowerModels for calculation. This can be achieved by
@@ -93,7 +93,7 @@ This network data can be modified in the same way as the previous Matpower `.m`
93
93
94
94
The flow AC and DC branch results are written to the result by default. The following can be used to inspect the flow results:
95
95
```julia
96
-
result =run_opf("matpower/case3_dc.m", ACPPowerModel, Ipopt.Optimizer)
96
+
result =solve_opf("matpower/case3_dc.m", ACPPowerModel, Ipopt.Optimizer)
97
97
result["solution"]["dcline"]["1"]
98
98
result["solution"]["branch"]["2"]
99
99
```
@@ -106,7 +106,7 @@ loss_dc = Dict(name => data["pt"]+data["pf"] for (name, data) in result["soluti
106
106
107
107
108
108
## Building PowerModels from Network Data Dictionaries
109
-
The following example demonstrates how to break a `run_opf` call into separate model building and solving steps. This allows inspection of the JuMP model created by PowerModels for the AC-OPF problem,
109
+
The following example demonstrates how to break a `solve_opf` call into separate model building and solving steps. This allows inspection of the JuMP model created by PowerModels for the AC-OPF problem,
Copy file name to clipboardExpand all lines: docs/src/utilities.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,7 +7,7 @@ This section provides an overview of the some of the utility functions that are
7
7
To improve the quality of the convex relaxations available in PowerModels and also to obtain tightened bounds on the voltage-magnitude and phase-angle difference variables, an optimization-based bound-tightening algorithm is made available as a function in PowerModels.
8
8
9
9
```@docs
10
-
run_obbt_opf!
10
+
solve_obbt_opf!
11
11
```
12
12
13
13
@@ -16,6 +16,6 @@ run_obbt_opf!
16
16
The following functions are meta-algorithms for solving OPF problems where line flow limit constraints are added iteratively to exploit the property that the majority of line flows constraints will be inactive in the optimal solution.
0 commit comments