diff --git a/docs/src/manual/acStateEstimation.md b/docs/src/manual/acStateEstimation.md
index c285eb94d..017fd7924 100644
--- a/docs/src/manual/acStateEstimation.md
+++ b/docs/src/manual/acStateEstimation.md
@@ -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.
 
 ---
 
diff --git a/docs/src/manual/dcStateEstimation.md b/docs/src/manual/dcStateEstimation.md
index 1d608cc2d..9ad0d4968 100644
--- a/docs/src/manual/dcStateEstimation.md
+++ b/docs/src/manual/dcStateEstimation.md
@@ -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.
 
 ---
 
diff --git a/docs/src/manual/measurementModel.md b/docs/src/manual/measurementModel.md
index 45a471c46..9e1b54a0e 100644
--- a/docs/src/manual/measurementModel.md
+++ b/docs/src/manual/measurementModel.md
@@ -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
@@ -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)
     ```
@@ -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))
 ```
@@ -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.
 
 
@@ -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
 ```
diff --git a/docs/src/manual/pmuStateEstimation.md b/docs/src/manual/pmuStateEstimation.md
index 45afd4f2f..d251167b2 100644
--- a/docs/src/manual/pmuStateEstimation.md
+++ b/docs/src/manual/pmuStateEstimation.md
@@ -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.
 
 ---
 
@@ -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)
diff --git a/docs/src/tutorials/acOptimalPowerFlow.md b/docs/src/tutorials/acOptimalPowerFlow.md
index 6b6a9388d..5159869ee 100644
--- a/docs/src/tutorials/acOptimalPowerFlow.md
+++ b/docs/src/tutorials/acOptimalPowerFlow.md
@@ -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
 ```
 
diff --git a/docs/src/tutorials/acPowerFlow.md b/docs/src/tutorials/acPowerFlow.md
index 58c6d13d5..8ff5b88a3 100644
--- a/docs/src/tutorials/acPowerFlow.md
+++ b/docs/src/tutorials/acPowerFlow.md
@@ -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]])
 ```
 
 ---
diff --git a/docs/src/tutorials/dcOptimalPowerFlow.md b/docs/src/tutorials/dcOptimalPowerFlow.md
index ad91a6d9e..60b775071 100644
--- a/docs/src/tutorials/dcOptimalPowerFlow.md
+++ b/docs/src/tutorials/dcOptimalPowerFlow.md
@@ -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
 ```