Fix a few typos (#433)

* Update README.md

Fixed a typo.

* Update README.md

Fixed a typo.

* Update index.md

Fixed a few typos.

* Update installation.md

Add a missing period.

* Update quickguide.md

Fixed a few typos.

* Update external-data-formats.md

Fixed a typo.

* Update enums.md

Fixed a few typos.

* Update specifications.md

Added missing period.

* Update load-model.md

Fixed a few typos.

* Update load-model.md

Fixed a few typos.

* Update CHANGELOG.md

* Update CONTRIBUTING.md

* Update connections.md

* Update eng-data-model.md

* Update formulations.md

* Update style.md

* Update power-flow.md

CHANGELOG.md

@@ -118,7 +118,7 @@
 - Added missing `temperature` on pvsystem
 - Added `configuration=WYE` to voltage sources
 - Fixed bug in voltage angle variable start values
-- Fixed bug with case sensitve filenames by using `Glob.glob` with `Glob.FilenameMatch`
+- Fixed bug with case sensitive filenames by using `Glob.glob` with `Glob.FilenameMatch`
 - Fixed bug in `constraint_mc_switch_current_limit` where voltage variables being used were wrong
 - Moved all `import` statements to root `PowerModelsDistribution`
 - Fixed bug in `_calc_transformer_current_max_frto` where `sm_ub` should have been divided by `vmin`, NOT `vmax`
@@ -134,7 +134,7 @@
 - Added multinetwork versions of data model transformation functions using `apply_pmd!`
 - Added `propagate_network_topology!`, a helper function to propagate the status of buses to connected components
 - Updated Documentation on Storage data model
-- Added LPUBFDiag version of `constraint_mc_storage_thermal_limit` using PolyhedralRelaxations to relax the quadradic constraints
+- Added LPUBFDiag version of `constraint_mc_storage_thermal_limit` using PolyhedralRelaxations to relax the quadratic constraints
 - Fixed bug in reporting duals (typo in ampacity constraint functions) (#367)
 - Changed multiconductor storage model parsing from opendss to be single values (instead of creating some multiconductor values, making assumptions about split between phases)
 - Fixed `vm`, `va` variable starts in `ACRU` and `ACPU` forms

CONTRIBUTING.md

@@ -4,12 +4,12 @@ In this guide we aim to communicate the various code standards expected for Powe
 
 ## Documentation
 
-Documentation should be included for all new publically exported additions to the code base
+Documentation should be included for all new publicly exported additions to the code base
 
 - All new formulation should have their hierarchies be documented in `/docs/src/formulations.md`
 - All new formulations should be summarized in `/docs/src/formulation-details.md`
 - Additions to the `ENGINEERING` data model should be added to `/docs/src/eng-data-model.md`
-- All new constaints should have their mathematical form in their associated docstring
+- All new constraints should have their mathematical form in their associated docstring
 - The usage details for all new exported functions should be documented via an associated docstring, with the exception of constraint and variable creation functions, which should contain mathematical details in their docstring
 - _Summaries_ of the purpose of new _unexported_ functions should be documented via an associated docstring
 
@@ -27,7 +27,7 @@ Function additions should meeting the following criteria:
 
 - All functions should be clearly named, without abbreviations, and with underscores between words, _e.g._ `parse_file` or `constraint_bus_voltage_magnitude`; in Python this is known as [`lower_case_with_underscores`](https://legacy.python.org/dev/peps/pep-0008/#descriptive-naming-styles). The exception to the abbreviate rule is cases where abbreviations would be expected in the modeling of power systems.
 - All functions that are not prepended by an underscore `_` will be exported by default (_i.e._ when a user uses `using PowerModelsDistribution`). Public functions should have a detailed docstring instructing on usage
-- All functions that modify data in place should end with an exclamation point `!` and the function input that is being modified should be the first argument (or first arguments in the case where multiple inputs are being modified in place). The exceptions to this rule are constraint and variable creation functions (_i.e._ those functions related to JuMP model creation), which do not include the exclaimation point
+- All functions that modify data in place should end with an exclamation point `!` and the function input that is being modified should be the first argument (or first arguments in the case where multiple inputs are being modified in place). The exceptions to this rule are constraint and variable creation functions (_i.e._ those functions related to JuMP model creation), which do not include the exclamation point
 - All function arguments, including keyword arguments, should have their types specified.
 - Private functions, _i.e._ those intended to be for internal use only, should follow the same descriptive naming conventions as functions exported by default, and should always include docstrings to describe their purpose.
 - Functions should be separated by two blank lines
@@ -49,7 +49,7 @@ When specifying types, _i.e._ when specifying the type of a function argument, o
 
 ### Constants
 
-Whenever possible, `const` should be used to eliminate unnecesary re-evaluations of code, and every `const` should have a docstring, whether internal or public.
+Whenever possible, `const` should be used to eliminate unnecessary re-evaluations of code, and every `const` should have a docstring, whether internal or public.
 
 ### JuMP Variables and Constraints
 

docs/src/developer/style.md

@@ -8,7 +8,7 @@ Function additions should meeting the following criteria:
 
 - All functions should be clearly named, without abbreviations, and with underscores between words, _e.g._ `parse_file` or `constraint_bus_voltage_magnitude`; in Python this is known as [`lower_case_with_underscores`](https://legacy.python.org/dev/peps/pep-0008/#descriptive-naming-styles). The exception to the abbreviate rule is cases where abbreviations would be expected in the modeling of power systems.
 - All functions that are not prepended by an underscore `_` will be exported by default (_i.e._ when a user uses `using PowerModelsDistribution`). Public functions should have a detailed docstring instructing on usage
-- All functions that modify data in place should end with an exclamation point `!` and the function input that is being modified should be the first argument (or first arguments in the case where multiple inputs are being modified in place). The exceptions to this rule are constraint and variable creation functions (_i.e._ those functions related to JuMP model creation), which do not include the exclaimation point
+- All functions that modify data in place should end with an exclamation point `!` and the function input that is being modified should be the first argument (or first arguments in the case where multiple inputs are being modified in place). The exceptions to this rule are constraint and variable creation functions (_i.e._ those functions related to JuMP model creation), which do not include the exclamation point
 - All function arguments, including keyword arguments, should have their types specified.
 - Private functions, _i.e._ those intended to be for internal use only, should follow the same descriptive naming conventions as functions exported by default, and should always include docstrings to describe their purpose.
 - Functions should be separated by two blank lines
@@ -30,7 +30,7 @@ When specifying types, _i.e._ when specifying the type of a function argument, o
 
 ## Constants
 
-Whenever possible, `const` should be used to eliminate unnecesary re-evaluations of code, and every `const` should have a docstring, whether internal or public.
+Whenever possible, `const` should be used to eliminate unnecessary re-evaluations of code, and every `const` should have a docstring, whether internal or public.
 
 ## JuMP Variables and Constraints
 

docs/src/manual/connections.md

@@ -31,7 +31,7 @@ Edge objects connect two buses (except for generic `transformers`, which can con
 
 ### Lines
 
-A line can have a variable number of conductors, which is implied by the size of the fields `rs`, `xs`, `g_fr`, `b_fr`, `g_to` and `b_to`. The fields `f_connections` and `t_connections` should specify for each conductor, to which terminals it connects. The figure below illustrates this for a line with 2 conuctors,
+A line can have a variable number of conductors, which is implied by the size of the fields `rs`, `xs`, `g_fr`, `b_fr`, `g_to` and `b_to`. The fields `f_connections` and `t_connections` should specify for each conductor, to which terminals it connects. The figure below illustrates this for a line with 2 conductors,
 
 ![line connection example](../assets/line_connection_example.svg).
 

docs/src/manual/eng-data-model.md

@@ -30,7 +30,7 @@ Each edge or node component (_i.e._ all those that are not data objects or buses
 
 Parameter values on components are expected to be specified in SI units by default (where applicable) in the engineering data model. Relevant expected units are noted in the sections below. It is possible for the user to select universal scalar factors for power and voltages. For example, if `power_scalar_factor` and `voltage_scalar_factor` are their default values given below, where units is listed as watt or var, real units will be kW and kvar. Where units are listed as volt, real units will be kV (multiplied by `vm_nom`, where that value exists).
 
-The Used column describes the situtations where certain parameters are used. "always" indicates those values are used in all contexts, `opf`, `mld`, or any other problem name abbreviation indicate they are used in particular for those problems. "solution" indicates that those parameters are outputs from the solvers. "multinetwork" indicates these values are only used to build multinetwork problems.
+The Used column describes the situations where certain parameters are used. "always" indicates those values are used in all contexts, `opf`, `mld`, or any other problem name abbreviation indicate they are used in particular for those problems. "solution" indicates that those parameters are outputs from the solvers. "multinetwork" indicates these values are only used to build multinetwork problems.
 
 Those parameters that have a default may be omitted by the user from the data model, they will be populated by the specified default values.
 
@@ -400,7 +400,7 @@ A storage object is a flexible component that can represent a variety of energy
 | `sm_ub`                |           | `Real`             | watt    | opf          | Power rating,                                                                        |
 | `cm_ub`                |           | `Real`             | amp     | opf          | Current rating,                                                                      |
 | `charge_efficiency`    |           | `Real`             | percent | always       | charging efficiency (losses)                                                         |
-| `discharge_efficiency` |           | `Real`             | percent | always       | disharging efficiency (losses)                                                       |
+| `discharge_efficiency` |           | `Real`             | percent | always       | discharging efficiency (losses)                                                       |
 | `qs_ub`                |           | `Real`             |         | opf          | Maximum reactive power injection,                                                    |
 | `qs_lb`                |           | `Real`             |         | opf          | Minimum reactive power injection,                                                    |
 | `rs`                   |           | `Real`             | ohm     | always       | converter resistance                                                                 |
@@ -466,7 +466,7 @@ Transformer codes are easy ways to specify properties common to multiple transfo
 
 Time series objects are used to specify time series for _e.g._ load or generation forecasts.
 
-Some parameters for components specified in this document can support a time series by inserting a referece to a `time_series` object into the `time_series` dictionary inside a component under the relevant parameter name. For example, for a `load`, if `pd_nom` is supposed to be a time series, the user would specify `"time_series" => Dict("pd_nom" => time_series_id)` where `time_series_id` is the `id` of an object in `time_series`, and has type `Any`.
+Some parameters for components specified in this document can support a time series by inserting a reference to a `time_series` object into the `time_series` dictionary inside a component under the relevant parameter name. For example, for a `load`, if `pd_nom` is supposed to be a time series, the user would specify `"time_series" => Dict("pd_nom" => time_series_id)` where `time_series_id` is the `id` of an object in `time_series`, and has type `Any`.
 
 | Name      | Default | Type                         | Units | Used   | Description                                                                                                   |
 | --------- | ------- | ---------------------------- | ----- | ------ | ------------------------------------------------------------------------------------------------------------- |

docs/src/manual/formulations.md

@@ -51,7 +51,7 @@ The linear FBS and FOT formulations as described in:
 
 # Unbalanced Network Formulation Type Hierarchy
 
-PowerModelsDistribution has a rich model type hierarchy similiar to PowerModels. At the top of the type hierarchy we can distinguish between conic, active power only, and branch flow models:
+PowerModelsDistribution has a rich model type hierarchy similar to PowerModels. At the top of the type hierarchy we can distinguish between conic, active power only, and branch flow models:
 
 ```julia
 abstract type AbstractUnbalancedConicModel <: AbstractPowerModel end

docs/src/manual/power-flow.md

@@ -1,6 +1,6 @@
 # Power Flow Computations
 
-The typical goal of PowerModelsDistribution is to build a JuMP model that is used to solve ditribution power network optimization problems. The JuMP model abstraction enables PowerModelsDistribution to have state-of-the-art performance on a wide range of problem formulations. That said, for the specific case of power flow computations, in some specific applications performance gains can be had by avoiding the JuMP model abstraction and solving the problem more directly. To that end, PowerModelsDistribution includes Julia-native solvers for AC power flow in rectangular voltage coordinates. This section provides an overview of the different power flow options that are available in PowerModelsDistribution and under what circumstances they may be beneficial.
+The typical goal of PowerModelsDistribution is to build a JuMP model that is used to solve distribution power network optimization problems. The JuMP model abstraction enables PowerModelsDistribution to have state-of-the-art performance on a wide range of problem formulations. That said, for the specific case of power flow computations, in some specific applications performance gains can be had by avoiding the JuMP model abstraction and solving the problem more directly. To that end, PowerModelsDistribution includes Julia-native solvers for AC power flow in rectangular voltage coordinates. This section provides an overview of the different power flow options that are available in PowerModelsDistribution and under what circumstances they may be beneficial.
 
 ## Generic Power Flow
 
@@ -67,12 +67,12 @@ The table below reports the accuracy of the native power flow with respect to Op
 
 ### Input arguments
 
-`compute_mc_pf` receieves input arguments as follows,
+`compute_mc_pf` receives input arguments as follows,
 
-- `data_math` - network data in MATHEMAICAL format
-- `explicit_neutral` - a boolean input indication wether or not the nuetral is explicitly modelled
+- `data_math` - network data in MATHEMATICAL format
+- `explicit_neutral` - a boolean input indication wether or not the neutral is explicitly modelled
 - `v_start` - warm start if different from in-built initialization algorithm
-- `max_iter` - maximum itertions
+- `max_iter` - maximum iterations
 - `stat_tol` - statistical tolerance
 
 ### Outputs
@@ -94,8 +94,8 @@ The table below reports the accuracy of the native power flow with respect to Op
 - starting from the math dictionary means that transformer decomposition is already done, which is different from what OpenDSS does
 - we calculate the primitive admittance matrix in p.u. whereas OpenDSS algorithm works with actual units
 - no load model relaxation is performed
-- inpspired by OpenDSS, we add small ppm values to certain component primitive admittance values to avoid singularity issues
-- inpspired by OpenDSS, switch primitive admittance has specific values
+- inspired by OpenDSS, we add small ppm values to certain component primitive admittance values to avoid singularity issues
+- inspired by OpenDSS, switch primitive admittance has specific values
 
 ## Network Admittance Matrix