Skip to content

Commit

Permalink
update docs
Browse files Browse the repository at this point in the history
  • Loading branch information
mcosovic committed Oct 16, 2024
1 parent 6678648 commit 629eb71
Show file tree
Hide file tree
Showing 7 changed files with 19 additions and 47 deletions.
15 changes: 1 addition & 14 deletions docs/src/manual/acStateEstimation.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,20 +20,7 @@ After obtaining the AC state estimation solution, JuliaGrid offers post-processi
* [`power!`](@ref power!(::PowerSystem, ::ACPowerFlow)),
* [`current!`](@ref current!(::PowerSystem, ::AC)).

Furthermore, there are specialized functions dedicated to calculating specific types of powers related to particular buses and branches:
* [`injectionPower`](@ref injectionPower(::PowerSystem, ::AC)),
* [`supplyPower`](@ref supplyPower(::PowerSystem, ::ACPowerFlow)),
* [`shuntPower`](@ref shuntPower(::PowerSystem, ::AC)),
* [`fromPower`](@ref fromPower(::PowerSystem, ::AC)),
* [`toPower`](@ref toPower(::PowerSystem, ::AC)),
* [`seriesPower`](@ref seriesPower(::PowerSystem, ::AC)),
* [`chargingPower`](@ref chargingPower(::PowerSystem, ::AC)),

Likewise, there are specialized functions dedicated to calculating specific types of currents related to particular buses or branches:
* [`injectionCurrent`](@ref injectionCurrent(::PowerSystem, ::AC)),
* [`fromCurrent`](@ref fromCurrent(::PowerSystem, ::AC)),
* [`toCurrent`](@ref toCurrent(::PowerSystem, ::AC)),
* [`seriesCurrent`](@ref seriesCurrent(::PowerSystem, ::AC)).
Additionally, specialized functions are available for calculating specific types of [powers](@ref ACPowerAnalysisAPI) or [currents](@ref ACCurrentAnalysisAPI) for individual buses or branches.

---

Expand Down
6 changes: 1 addition & 5 deletions docs/src/manual/dcStateEstimation.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,11 +20,7 @@ For more detailed information, users can refer to the [Observability Analysis](@
After obtaining the solution for DC state estimation, JuliaGrid offers a post-processing analysis function to compute active powers associated with buses and branches:
* [`power!`](@ref power!(::PowerSystem, ::DCStateEstimation)).

Additionally, there are specialized functions dedicated to calculating specific types of active powers related to particular buses or branches:
* [`injectionPower`](@ref injectionPower(::PowerSystem, ::DCStateEstimation)),
* [`supplyPower`](@ref supplyPower(::PowerSystem, ::DCStateEstimation)),
* [`fromPower`](@ref fromPower(::PowerSystem, ::DCStateEstimation)),
* [`toPower`](@ref toPower(::PowerSystem, ::DCStateEstimation)).
Additionally, specialized functions are available for calculating specific types of [powers](@ref DCPowerAnalysisAPI) for individual buses or branches.

---

Expand Down
18 changes: 9 additions & 9 deletions docs/src/manual/measurementModel.md
Original file line number Diff line number Diff line change
Expand Up @@ -309,7 +309,7 @@ In this context, one varmeter has been added to measure the reactive power injec
---

##### Customizing Input Units for Keywords
Just as we explained for the previous device, users have the flexibility to select units different from per-units. In this case, they can opt for volt-ampere reactive (VAr), as illustrated in the following example:
Just as we explained for the previous device, users have the flexibility to select units different from per-units. In this case, they can opt for megavolt-ampere reactive (MVAr), as illustrated in the following example:
```@example addVarmeterSI
using JuliaGrid # hide
@default(unit) # hide
Expand Down Expand Up @@ -526,7 +526,7 @@ JuliaGrid necessitates a unique label for each voltmeter, ammeter, wattmeter, va
In all the previous examples, with the exception of the last one, we relied on automatic labeling by omitting the `label` keyword. This allowed JuliaGrid to independently assign unique labels to measurement devices. In such cases, JuliaGrid utilizes a sequential set of increasing integers for labeling the devices. The [last example](@ref ChangeKeywordsMeasurementManual) demonstrates the user labeling approach.

!!! tip "Tip"
String labels improve readability, but in larger models, the overhead from using strings can become substantial. To reduce memory usage and the number of allocations, users can configure ordered dictionaries to accept and store integers as labels:
String labels improve readability, but in larger models, the overhead from using strings can become substantial. To reduce memory usage, users can configure ordered dictionaries to accept and store integers as labels:
```julia DCPowerFlowSolution
@labels(Integers)
```
Expand Down Expand Up @@ -629,7 +629,7 @@ To access the wattmeter labels, we can use the variable:
device.wattmeter.label
```

If we need to obtain labels in the same order as the wattmeter definitions sequence, we can use the following code:
If we need to obtain only labels, we can use the following code:
```@repl retrievingLabels
label = collect(keys(device.wattmeter.label))
```
Expand Down Expand Up @@ -665,7 +665,7 @@ This procedure is applicable to all measurement devices, including voltmeters, a

---

##### Load and Save Measurement Data
##### Loading and Saving Labels
When saving the measurements to an HDF5 file, the label type (strings or integers) will match the type chosen during system setup. Likewise, when loading data from an HDF5 file, the label type will be preserved as saved, regardless of what is set by the [`@labels`](@ref @labels) macro.


Expand Down Expand Up @@ -733,15 +733,15 @@ For wattmeters, varmeters, and PMUs added to all buses and branches, we rely on
Users have the option to employ an alternative method for adding groups of measurements, utilizing functions that add measurements individually. This approach may offer a more straightforward process. For example, to add wattmeters similarly to the procedure outlined above, we can employ the following:
```@example addDeviceGroups
Pᵢ = analysis.power.injection.active
for (label, index) in system.bus.label
addWattmeter!(system, device; bus = label, active = Pᵢ[index], variance = 1e-3)
for (label, idx) in system.bus.label
addWattmeter!(system, device; bus = label, active = Pᵢ[idx], variance = 1e-3)
end
Pᵢⱼ = analysis.power.from.active
Pⱼᵢ = analysis.power.to.active
for (label, index) in system.branch.label
addWattmeter!(system, device; from = label, active = Pᵢⱼ[index], status = 0)
addWattmeter!(system, device; to = label, active = Pⱼᵢ[index])
for (label, idx) in system.branch.label
addWattmeter!(system, device; from = label, active = Pᵢⱼ[idx], status = 0)
addWattmeter!(system, device; to = label, active = Pⱼᵢ[idx])
end
nothing # hide
```
Expand Down
19 changes: 3 additions & 16 deletions docs/src/manual/pmuStateEstimation.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,20 +18,7 @@ After obtaining the PMU state estimation solution, JuliaGrid offers post-process
* [`power!`](@ref power!(::PowerSystem, ::ACPowerFlow)),
* [`current!`](@ref current!(::PowerSystem, ::AC)).

Furthermore, there are specialized functions dedicated to calculating specific types of powers related to particular buses and branches:
* [`injectionPower`](@ref injectionPower(::PowerSystem, ::AC)),
* [`supplyPower`](@ref supplyPower(::PowerSystem, ::ACPowerFlow)),
* [`shuntPower`](@ref shuntPower(::PowerSystem, ::AC)),
* [`fromPower`](@ref fromPower(::PowerSystem, ::AC)),
* [`toPower`](@ref toPower(::PowerSystem, ::AC)),
* [`seriesPower`](@ref seriesPower(::PowerSystem, ::AC)),
* [`chargingPower`](@ref chargingPower(::PowerSystem, ::AC)),

Likewise, there are specialized functions dedicated to calculating specific types of currents related to particular buses or branches:
* [`injectionCurrent`](@ref injectionCurrent(::PowerSystem, ::AC)),
* [`fromCurrent`](@ref fromCurrent(::PowerSystem, ::AC)),
* [`toCurrent`](@ref toCurrent(::PowerSystem, ::AC)),
* [`seriesCurrent`](@ref seriesCurrent(::PowerSystem, ::AC)).
Additionally, specialized functions are available for calculating specific types of [powers](@ref ACPowerAnalysisAPI) or [currents](@ref ACCurrentAnalysisAPI) for individual buses or branches.

---

Expand Down Expand Up @@ -98,8 +85,8 @@ Utilizing PMU placement and AC power flow data, which serves as the source for m
device = measurement()
@pmu(label = "PMU ? (!)")
for (bus, k) in placement.bus
Vᵢ, θᵢ = analysis.voltage.magnitude[k], analysis.voltage.angle[k]
for (bus, idx) in placement.bus
Vᵢ, θᵢ = analysis.voltage.magnitude[idx], analysis.voltage.angle[idx]
addPmu!(system, device; bus = bus, magnitude = Vᵢ, angle = θᵢ)
end
for branch in keys(placement.from)
Expand Down
4 changes: 3 additions & 1 deletion docs/src/tutorials/acOptimalPowerFlow.md
Original file line number Diff line number Diff line change
Expand Up @@ -79,7 +79,9 @@ nothing # hide

Afterward, the AC optimal power flow model is created using the [`acOptimalPowerFlow`](@ref acOptimalPowerFlow) function:
```@example ACOptimalPowerFlow
analysis = acOptimalPowerFlow(system, Ipopt.Optimizer)
analysis = acOptimalPowerFlow(
system, Ipopt.Optimizer; active = "Pg", reactive = "Qg", magnitude = "V", angle = "θ"
)
nothing # hide
```

Expand Down
2 changes: 1 addition & 1 deletion docs/src/tutorials/acPowerFlow.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,7 @@ nothing #hide
To review, we can conceptualize the bus/branch model as the graph denoted by ``\mathcal{G} = (\mathcal{N}, \mathcal{E})``, where we have the set of buses ``\mathcal{N} = \{1, \dots, n\}``, and the set of branches ``\mathcal{E} \subseteq \mathcal{N} \times \mathcal{N}`` within the power system:
```@repl PowerFlowSolution
𝒩 = collect(keys(system.bus.label))
ℰ = [𝒩[system.branch.layout.from] 𝒩[system.branch.layout.to]]
ℰ = hcat([𝒩[system.branch.layout.from] 𝒩[system.branch.layout.to]])
```

---
Expand Down
2 changes: 1 addition & 1 deletion docs/src/tutorials/dcOptimalPowerFlow.md
Original file line number Diff line number Diff line change
Expand Up @@ -74,7 +74,7 @@ nothing # hide

Afterward, the DC optimal power flow model is created using the [`dcOptimalPowerFlow`](@ref dcOptimalPowerFlow) function:
```@example DCOptimalPowerFlow
analysis = dcOptimalPowerFlow(system, HiGHS.Optimizer)
analysis = dcOptimalPowerFlow(system, HiGHS.Optimizer; active = "Pg", angle = "θ")
nothing # hide
```

Expand Down

0 comments on commit 629eb71

Please sign in to comment.