Release v1.3 Prep

CHANGELOG.md

@@ -1,22 +1,7 @@
 (changelog)=
 # Changelog
 
-## Unreleased
-
-- The existing documentation has been converted from a Sphinx-based setup to a Jupyter Book v1 build
-  to create more easily modifiable documentation components and integrate better code examples
-  directly into the documentation site.
-- The `save_config` function is now compatible with the `ProjectManager.config` object, allowing
-  for direct saving without user modification.
-- Adds a contributor's guide to clearly delineate how to install and use the various developer's
-  tools.
-- Modernize and streamline the installation instructions.
-- Converts all the materials found in `examples/` to either tutorials or topical guides in the
-  documentation.
-- Adds a documentation build shell script to help automatically clean existing documentation site
-  materials, build the documentation, copy over the output example Jupyter Notebooks to `examples/`,
-  and run the pre-commit workflow for basic file handling.
-- Places the ORBIT tech report citation more prominently throughout the repository and documentation.
+## 1.3
 
 ### Bug Fixes
 
@@ -29,11 +14,28 @@
 
 - Project parameter `contingency` is fully deprecated in favor of `installation_contingency` and
   `procurement_contingency` and will raise a `KeyError` when detected by the `ProjectManager`.
-- Top-level `landfall` dictionary is no longer suppored and is fully deprecated in favor of nesting
+- Top-level `landfall` dictionary is no longer supported and is fully deprecated in favor of nesting
   it in the `export_system_design` and `export_system` dictionary, for design and installation phases.
 - The `export_system`-level `interconnection_distance` variable is deprecated and should now be
   placed in the `export_system.landfall` dictionary.
 
+### Miscellaneous Updates and Improvements
+
+- The existing documentation has been converted from a Sphinx-based setup to a Jupyter Book v1 build
+  to create more easily modifiable documentation components and integrate better code examples
+  directly into the documentation site.
+- The `save_config` function is now compatible with the `ProjectManager.config` object, allowing
+  for direct saving without user modification.
+- Adds a contributor's guide to clearly delineate how to install and use the various developer's
+  tools.
+- Modernize and streamline the installation instructions.
+- Converts all the materials found in `examples/` to either tutorials or topical guides in the
+  documentation.
+- Adds a documentation build shell script to help automatically clean existing documentation site
+  materials, build the documentation, copy over the output example Jupyter Notebooks to `examples/`,
+  and run the pre-commit workflow for basic file handling.
+- Places the ORBIT tech report citation more prominently throughout the repository and documentation.
+
 ## 1.2.6
 
 - Implements `create_layout_df` for the `CustomArraySystemDesign` model to ensure
@@ -157,7 +159,7 @@
   - Fixed the output substructure type from Monopile to Floating. (use `oss_substructure_type`)
   - Removes any pile or fixed-bottom substructure geometry.
   - See `Example 5. Example Floating Project` for more details.
-- Updated `MoredSubInstallation`:
+- Updated `MooredSubInstallation`:
   - Uses an AHTS vessel which must be added to project config file.
   - See `example/example_floating_project.yaml` (use `ahts_vessel`)
 - New `22MW_generic.yaml` turbine.
@@ -259,7 +261,7 @@
 - Refactored aggregation project level outputs in `ProjectManager`.
 - Revised Net Present Value calculation to utilize new project outputs.
 - Added `load_config` and `save_config` functions.
-- Moved `ORBIT.library` to `OBRIT.core.library`.
+- Moved `ORBIT.library` to `ORBIT.core.library`.
 - Centralized model defaults to `ORBIT.core.defaults`.
 - `ProjectManager.project_actions` renamed to `ProjectManager.actions`
 - `ProjectManager.project_logs` renamed to `ProjectManager.logs`
@@ -295,8 +297,8 @@
 ## 0.4.2
 
 - New feature: Phase dependencies in `ProjectManager`.
-- New feature: Windspeed constraints at multiple heights, including automatic
-  interpolation/extrapolation of configured windspeed profiles.
+- New feature: Wind speed constraints at multiple heights, including automatic
+  interpolation/extrapolation of configured wind speed profiles.
 - Added option to define `mobilization_days` and `mobilization_mult` in a
   `Vessel` configuration file.
 - Added option for pre-installation trenching operations to
@@ -319,7 +321,7 @@
 
 - Vessel mobilization added to all vessels in all installation modules.
   Defaults to 7 days at 50% day-rate.
-- Cable lay, bury and simulataneous lay/bury methods are not flagged as
+- Cable lay, bury and simultaneous lay/bury methods are not flagged as
   suspendable to avoid unrealistic project delays.
 - Cost of onshore transmission construction added to
   `ExportCableInstallation`.
@@ -353,7 +355,7 @@
 ## 0.3.3
 
 - Added configuration for multiple tower sections in `TurbineInstallation`.
-- Added configuration for seperate lay/burial in `ArrayCableInstallation` and
+- Added configuration for separate lay/burial in `ArrayCableInstallation` and
   `ExportCableInstallation`.
 - Overhauled test suite and associated library.
 - Bugfix in `CableCarousel`.

ORBIT/__init__.py

@@ -17,4 +17,4 @@
 from ORBIT.parametric import ParametricManager
 from ORBIT.supply_chain import SupplyChainManager
 
-__version__ = "1.2.6"
+__version__ = "1.3"

ORBIT/phases/install/cable_install/export.py

@@ -49,7 +49,7 @@ class ExportCableInstallation(InstallPhase):
                 "linear_density": "t/km",
                 "sections": [("length, km", "speed, km/h (optional)")],
                 "number": "int (optional)",
-                "cable_type": "str(optional, defualt: 'HVAC')",
+                "cable_type": "str(optional, default: 'HVAC')",
                 "landfall": {
                     "trench_length": "km (optional)",
                     "interconnection_distance": "km (optional); default: 3km",

README.md

@@ -21,11 +21,11 @@ Offshore Renewables Balance of system and Installation Tool
 - [Rob Hammond](https://www.linkedin.com/in/rob-hammond-33583756/)
 - [Nick Riccobono](https://www.linkedin.com/in/nicholas-riccobono-674a3b43/)
 
-### Curent Maintainers
+### Current Maintainers
 
 - Rob Hammond
 
-## Documentationa
+## Documentation
 
 Please visit the documentation site at https://nlrwindsystems.github.io/ORBIT/
 
@@ -92,7 +92,7 @@ pip install jupyterlab
 
 ### Source Installation
 
-For users looking to modify ORBIT or build their own models to incorporte, installing
+For users looking to modify ORBIT or build their own models to incorporate, installing
 from the source code is required.
 
 1. Open a terminal/Anaconda Prompt session and navigate to your desired folder location
@@ -129,7 +129,7 @@ from the source code is required.
 
 ### Development Setup
 
-For more advanced users, such as those interested in building the documentation localling, running
+For more advanced users, such as those interested in building the documentation locally, running
 tests, or even contributing code back to the library, please use the following instructions.
 
 1. Open a terminal/Anaconda Prompt session and navigate to your desired folder location
@@ -160,7 +160,7 @@ tests, or even contributing code back to the library, please use the following i
    pip install -3 .
    ```
 
-   For developers install the developer dependences in addition:
+   For developers install the developer dependencies in addition:
 
    ```bash
    pip install -e .[dev,docs]

docs/getting_started/overview.md

@@ -10,7 +10,7 @@ cost in a highly customizable framework, allowing the user to override any
 default values if they wish.
 
 The primary structure of ORBIT relies on the [Project Manager](#project-manager-methods)
-to intrepret the user specified configuration. Refer to the
+to interpret the user specified configuration. Refer to the
 [library/project/config](https://github.com/NLRWindSystems/ORBIT/tree/main/library/project/config).
 The `ProjectManager` calls `DesignPhase` to include all the wind farm components that
 comprise the balance of system, then it calls `InstallationPhase` to schedule all the installation

docs/methods/ProjectManager.md

@@ -19,7 +19,7 @@ and save the outputs.
 
 ## Run
 
-This method checks to see if a design or install phase is instatiated prior to running them. Depending on
+This method checks to see if a design or install phase is instantiated prior to running them. Depending on
 which design phases are specified, each phase is run in no particular order and the results are added to
 `design_results` dictionary. Conversely, the install phases can be run sequentially or as overlapped
 processes (see example: {doc}`Overlapping install <../examples>`). It is worth noting, that ORBIT

docs/methods/design/ElectricalDesign.md

@@ -19,12 +19,12 @@ For more detail on the helper classes used to support this design please see
 
 The number of export cables required for HVAC is calculated by dividing the windfarm's
 capacity by the configured export cable's power rating and adding any user
-defined redundnacy as seen below.
+defined redundancy as seen below.
 
 $num\_cables = \lceil\frac{plant\_capacity}{cable\_power}\rceil + num\_redundant$
 
 For HVDC cables (both monopole and bipole), the number of cables is twice the number as
-calculated abpve because HVDC systems require a pair of cables per implementation.
+calculated above because HVDC systems require a pair of cables per implementation.
 The equation for this calculation is shown below.
 
 $num\_cables = 2 * \lceil\frac{plant\_capacity}{cable\_power}\rceil + num\_redundant$
@@ -46,15 +46,15 @@ crossing. The default number of cable crossings is 0 and cost per cable
 crossing is \$500,000. This cost includes materials, installation, etc. Crossing
 cost is calculated as product of number of crossings and unit cost.
 
-## Number of Required Power Transformer, Tranformer Rating, and Cost
+## Number of Required Power Transformer, Transformer Rating, and Cost
 
 The number of main power transformers (MPT) required is assumed to be equal to the number
 of required export cables. The transformer rating is calculated by dividing the
 windfarm's capacity by the number of MPTs. MPTs are only required if the
 export cables are HVAC. The default cost of the MPT is \$2.87m per HVAC cable. Therefore, the total MPT cost is
 proportional to the number of cables. Note: Previous versions may have used curve-fits to
 calculate total MPT cost based on the windfarm's capacity. The MPT unit cost (\$/cable) can
-be ovewritten by the user by setting (`mpt_unit_cost`) to the desired cost. If the export cables
+be overwritten by the user by setting (`mpt_unit_cost`) to the desired cost. If the export cables
 are HVDC, then the cost of power transformers will be \$0.
 
 ## Number of Shunt Reactors, Reactive Power Compensation, and Cost
@@ -63,7 +63,7 @@ The shunt reactor cost is dependent on the amount of reactive power compensation
 required based on the distance of the substation to shore. This model assumes
 one shunt reactor for each HVAC export cable. An HVDC export systems do not require
 reactive power compensation. The default cost rate of the shunt reactors is \$10k per HVAC cable. The total cost is proportional
-to the number of cables multipled by a cable-specific compensation factor. The default cost rate
+to the number of cables multiplied by a cable-specific compensation factor. The default cost rate
 can be overwritten by the user by setting (`shunt_unit_cost`) to the desired cost. The shunt
 reactor cost is \$0 for HVDC systems.
 
@@ -78,7 +78,7 @@ cables.
 ## Number of Circuit Breakers and Cost
 
 The number of circuit breakers required is assumed to be equal to the number of required
-export cables. Breakers are only necssary if HVDC export cables are chosen. The default cost is
+export cables. Breakers are only necessary if HVDC export cables are chosen. The default cost is
 \$10.6m per HVDC cable. The default cost can be overwritten by the user by setting (`dc_breaker_cost`)
 to the desired cost. Breaker cost is \$0 for HVAC cables.
 
@@ -89,7 +89,7 @@ is assumed to be equal to the number of HVDC export cables.
 
 ## Ancillary System Cost
 
-Costs are included such as a backup generator, workspace cost, and miscellous to
+Costs are included such as a backup generator, workspace cost, and miscellaneous to
 capture any additional features outside the main components. The user can define each
 variable by setting (`backup_gen_cost`), (`workspace_cost`), and (`other_ancillary_cost`).
 

docs/methods/design/ExportSystemDesign.md

@@ -13,9 +13,9 @@ see the [Cabling Helper Classes documentation](#cable-helpers-methods), specific
 
 ## Number of Required Cables
 
-The number of export cables required is calculated by dividing the windfarm's
+The number of export cables required is calculated by dividing the wind farm's
 capacity by the configured export cable's power rating and adding any user
-defined redundnacy as seen below.
+defined redundancy as seen below.
 
 $num\_cables = \lceil\frac{plant\_capacity}{cable\_power}\rceil + num\_redundant$
 

docs/methods/design/ScourProtectionDesign.md

@@ -48,7 +48,7 @@ where $t$ represents the depth of the scour protection material. This
 value defaults to 1m in the code, which represents an appropriate initial
 assumption and not a complete design. For sites that exhibit greater seafloor
 currents, the scour protection layer may be as thick as 2m, whereas calmer
-sites may only need 0.3-0.5m of material. In the abscense of a geotechnical
+sites may only need 0.3-0.5m of material. In the absence of a geotechnical
 study, this value is difficult to calculate and is instead presented to user as
 a configurable input so the cost impacts of different thicknesses can be
 investigated.

docs/methods/install/ArrayCableInstall.md

@@ -48,7 +48,7 @@ For example,
 }
 ```
 
-The installation of each section above will be modeled seperately. In the above
+The installation of each section above will be modeled separately. In the above
 example, only one cable was used, though there could be additional defined
 cables (with their own `cable_sections` key).
 
@@ -62,7 +62,7 @@ result of running the `ArraySystemDesign` module.
 ## Configuration
 
 ORBIT considers two installation strategies: a simultaneous lay/bury operation
-using modern cable installation vessels and a seperated operation where one
+using modern cable installation vessels and a separated operation where one
 vessel lays the cable and another follows behind to bury it. A detailed
 description of the applicability of each strategy is covered in the
 [ORBIT technical report](https://www.nlr.gov/docs/fy20osti/77081.pdf).

docs/methods/install/ExportCableInstall.md

@@ -73,7 +73,7 @@ array system installation:
 
 :::{note}
 The cable lengths for an export system are typically much longer than the
-array system and thhere is the possibility that a cable splice will be
+array system and there is the possibility that a cable splice will be
 needed. The time for splicing a cable can be configured by the user using
 the `cable_splice_time` key, which defaults to 48h.
 :::

docs/methods/install/MonopileInstall.md

@@ -130,13 +130,13 @@ For grouted connections, the WTIV performs these tasks:
 
 ### Single WTIV Installation
 
-![Single WTIV monopile installation process diagrame](../../images/process_diagrams/monopile_single_wtiv.png)
+![Single WTIV monopile installation process diagram](../../images/process_diagrams/monopile_single_wtiv.png)
 
 (monopile-install-feeders-process)=
 ### WTIV with Feeder Barges Installation
 
-![WTIV with feeders monopile installation process diagrame](../../images/process_diagrams/monopile_wtiv_with_feeders.png)
+![WTIV with feeders monopile installation process diagram](../../images/process_diagrams/monopile_wtiv_with_feeders.png)
 
 ### Component Installation
 
-![Monopile component installation process diagrame](../../images/process_diagrams/monopile_install.png)
+![Monopile component installation process diagram](../../images/process_diagrams/monopile_install.png)

docs/methods/install/MooredSubInstallation.md

@@ -7,10 +7,10 @@ For details of the code implementation, please see the
 ## Overview
 
 The `MooredSubInstallation` module simulates the manufacture and installation
-of moored substuctures for a floating offshore wind project. The installation
+of moored substructures for a floating offshore wind project. The installation
 procedures include the time required to manufacture a substructure at quayside,
 assemble a turbine on the substructure, ballast the completed assembly, tow
-the completed assembly to site and hook up the pre-installed moooring lines.
+the completed assembly to site and hook up the pre-installed mooring lines.
 
 ## Configuration
 
@@ -29,7 +29,7 @@ config = {
     "towing_groups": {
         "towing_vessel": 1,  # Vessels used to tow the substructure to site.
         "ahts_vessels": 3,  # Number of anchor handling/station keeping vessels
-        "num_groups": 1  # Number of independent groups. Optional, defualt: 1.
+        "num_groups": 1  # Number of independent groups. Optional, default: 1.
     },
 
     "port": {

docs/methods/install/ScourProtectionInstall.md

@@ -23,7 +23,7 @@ installation method, involving "Side Stone Installation Vessels" that dump
 loads of rocks next to the substructure without much ability to ensure that
 their payload is distributed evenly. A future version of ORBIT may expand this
 module to include more modern installation approaches using a "Fall Pipe
-Vessel" that allow for an even distrubution of scour protection material.
+Vessel" that allow for an even distribution of scour protection material.
 
 ### Example
 

docs/methods/install/TurbineInstall.md

@@ -64,7 +64,7 @@ The default times for fastening each component to deck are listed below.
 Currently, all vessels are only able to load multiples of complete sets of
 components (tower, nacelle and three blades).
 
-### Site Preperation
+### Site Preparation
 
 Once the WTIV and a set of components are at site (either on the WTIV or a
 feeder barge), the WTIV positions itself onsite and jacks up. The following
@@ -77,7 +77,7 @@ table outlines the inputs and default times for these tasks.
 
 ### Turbine Installation
 
-After site preperation is complete, the WTIV begins installation by releasing a
+After site preparation is complete, the WTIV begins installation by releasing a
 turbine from its fastening (either on its own deck or neighboring feeder
 barge). The tower is then lifted into place using the WTIV crane and attached
 to the substructure. The nacelle is then released from its fastenings, lifted
@@ -103,12 +103,12 @@ following table.
 
 ### Single WTIV Installation
 
-![Single WTIV turbine installation proceess diagrame](../../images/process_diagrams/turbine_single_wtiv.png)
+![Single WTIV turbine installation process diagram](../../images/process_diagrams/turbine_single_wtiv.png)
 
 ### WTIV with Feeder Barges Installation
 
-![WTIV with feeder barges turbine installation proceess diagrame](../../images/process_diagrams/turbine_wtiv_with_feeders.png)
+![WTIV with feeder barges turbine installation process diagram](../../images/process_diagrams/turbine_wtiv_with_feeders.png)
 
 ### Component Installation
 
-![Component installation proceess diagrame](../../images/process_diagrams/turbine_install.png)
+![Component installation process diagram](../../images/process_diagrams/turbine_install.png)

docs/topical_guides/cable_installation.md

@@ -108,7 +108,7 @@ df_combined.iloc[3:12]
 Now, we demonstrate the separate process by combining the separate laying and burying steps taken
 for the first cable. Note that we have to concatenate two separate sections of the actions log
 to highlight this process. For each process the vessel has to "Position Onsite", then go on
-with the separate logic. For the burying process, this is much simpler than the intial laying
+with the separate logic. For the burying process, this is much simpler than the initial laying
 and cable connection.
 
 ```{code-cell} ipython3

docs/topical_guides/cost_curves.md

@@ -369,7 +369,7 @@ class CostFunction():
         in ``ParametricManager``. Additionally, the independent variables are extracted
         into ``x` and ``y`` (for two-variable parameterizations) and ``z`` is extracted
         as the dependent variable. Whether the cost function is 3D or 2D is determined
-        by the length of theparameters variable.
+        by the length of the parameters variable.
 
         Parameters
         ----------