Run formatter

docs/src/explanation/system.md

@@ -19,12 +19,12 @@ retrieve all components of a certain `Type`.
 For example, the most common search function is [`get_components`](@ref), which
 takes a desired device `Type` (concrete or abstract) and retrieves all components in that
 category from the `System`. It also accepts filter functions for a more
-refined search. 
+refined search.
 
 Given the potential size of the return,
 `PowerSystems.jl` returns Julia iterators in order to avoid unnecessary memory allocations.
 The container is optimized for iteration over abstract or concrete component
-types as described by the [Type Structure](@ref type_structure). 
+types as described by the [Type Structure](@ref type_structure).
 
 ## [Accessing data stored in a component](@id dot_access)
 
@@ -36,4 +36,4 @@ access to this data using the "dot" access (e.g. `component.field`), however
 _this is actively discouraged_ for two reasons:
 
  1. We make no guarantees on the stability of component structure definitions. We will maintain version stability on the accessor methods.
- 2. Per-unit conversions are made in the return of data from the accessor functions. (see the [per-unit section](@ref per_unit) for more details)
+ 2. Per-unit conversions are made in the return of data from the accessor functions. (see the [per-unit section](@ref per_unit) for more details)

docs/src/how_to/serialize_data.md

@@ -35,6 +35,7 @@ Now write the system to JSON:
 ```@repl serialize_data
 to_json(sys, path)
 ```
+
 Notice in the `Info` statements that the serialization process stores 3 files:
 
  1. System data file (`*.json` file)
@@ -100,12 +101,12 @@ rm(folder; recursive = true); #hide
 ```
 
 !!! tip
-
+    
     PowerSystems generates UUIDs for the `System` and all components in order to have
     a way to uniquely identify objects. During deserialization it restores the same
     UUIDs.  If you will modify the `System` or components after deserialization then
     it is recommended that you set this flag to generate new UUIDs.
-
+    
     ```julia
     system2 = System(path; assign_new_uuids = true)
     ```

docs/src/index.md

@@ -76,6 +76,7 @@ framework.
 If you are new to `PowerSystems.jl`, here's how we suggest getting started:
 
  1. [Install](@ref install)
+
  2. Work through the introductory tutorial: [Create and Explore a Power `System`](@ref) to
     familiarize yourself with how `PowerSystems.jl` works
  3. Work through the other basic tutorials based on your interests

docs/src/tutorials/creating_system.md

@@ -157,7 +157,8 @@ withdraw power from the network.
 
     When you define components that aren't attached to a `System` yet, you must define
     all fields related to power (with units such as MW, MVA, MVAR, or MW/min) in
-    per-unit using the `base_power` of the component.
+    per-unit using the `base_power` of the component (with the exception of `base_power`
+    itself, which is in MVA).
 
 We'll start with defining a 10 MW [load](@ref PowerLoad) to `bus1`:
 

docs/src/tutorials/get_component_data.md

@@ -58,6 +58,7 @@ nothing #hide
 # copied over from the System
 
 ## Accessing components stored in the system
+
 <!-- 
 `PowerSystems.jl` implements a wide variety of methods to search for components to
 aid in the development of models. The code block shows an example of
@@ -69,7 +70,6 @@ type (concrete or abstract) and the system and it also accepts filter functions
 refined search. The container is optimized for iteration over abstract or concrete component
 types as described by the [Type Structure](@ref type_structure). Given the potential size of the return,
 `PowerSystems.jl` returns Julia iterators in order to avoid unnecessary memory allocations. -->
-
 ```@repl system
 using PowerSystems
 file_dir = joinpath(pkgdir(PowerSystems), "docs", "src", "tutorials", "tutorials_data")
@@ -103,7 +103,6 @@ _this is actively discouraged_ for two reasons:
 
  1. We make no guarantees on the stability of component structure definitions. We will maintain version stability on the accessor methods.
  2. Per-unit conversions are made in the return of data from the accessor functions. (see the [per-unit section](@ref per_unit) for more details) -->
-
 For example, the `my_thermal_gen.active_power_limits` parameter of a thermal generator should be accessed as follows:
 
 ```@repl system
@@ -122,4 +121,4 @@ show_components(system, ThermalStandard, Dict("has_time_series" => x -> has_time
 show_components(system, ThermalStandard, [:active_power, :reactive_power])
 ```
 
-# to do: add a link in the system that MD explanation to these examples
+# to do: add a link in the system that MD explanation to these examples