v0.9.4 Release Preparation

CHANGELOG.md

@@ -1,4 +1,4 @@
-## Unreleased (TBD)
+## 0.9.4 (1 July 2024)
 
 - Adds support for Python 3.11 and 3.12.
 - Adds the following capability and servicing equipment codes:
@@ -17,6 +17,8 @@
 - Update README.md to be inline with current conda and Python standards.
 - Fully adopts `functools.cache` now that older Python versions where
   `functools.lru_cache` was the available caching method.
+- Fixes a Pandas `FutureWarning` by removing a now unnecessary piece of code in
+  `wombat/core/post_processor.py:equipment_costs`
 
 ## v0.9.3 (15 February 2024)
 

docs/examples/examples_reference.md

@@ -41,7 +41,7 @@ This is the notebook used for the NAWEA WindTech 2023 Workshop. See
 ### `dinwoodie_validation.ipynb`
 
 This shows the latest results of the model validation using the modeling parameters from
-Dinwoodie, et. al, 2015 [^dinwoodie2015reference].
+Dinwoodie, et al., 2015 [^dinwoodie2015reference].
 
 ### `iea_26_validation.ipynb`
 

docs/examples/how_to.md

@@ -11,9 +11,14 @@ kernelspec:
 
 # How To Use WOMBAT
 
+[![Binder](https://mybinder.org/badge_logo.svg)](https://mybinder.org/v2/gh/WISDEM/WOMBAT/main?filepath=examples)
+
 This tutorial will walk through the setup, running, and results stages of a WOMBAT
 simulation while providing background information about how each component is related.
 
+A Jupyter notebook of this tutorial can be run from `examples/how_to.ipynb` locally, or
+through [binder](https://mybinder.org/v2/gh/WISDEM/WOMBAT/main?filepath=examples).
+
 ## Imports
 
 The following code block demonstrates a typical setup for working with WOMBAT and

docs/examples/index.md

@@ -9,26 +9,27 @@ it is recommended to see how each model's configuration files are composed.
 For thorough explanations of the design and implementation ethos of the model, please
 see our NREL Technical Report: https://www.osti.gov/biblio/1894867, which was published
 alongside v0.5.1, so some functionality has been updated.
+
 ## Feature Overview
 
 For a complete and detailed description of the functionality provided in WOMBAT, it is
 recommended to read the API documentation. However, that is quite a task, so below is
-a short listing of the core functionality that WOMBAT can provide.
+a shortlist of the core functionality that WOMBAT can provide.
 
 ### Post Processing and the Simulation API
 
 - The [`Simulation` class](simulation-api) and its
   [`Configuration`](simulation-api:config) allow users unfamiliar with
   Python to run the simulation library with minimal code. This was the primary design
   choice for the model: to create a configuration-based model to enable users with nearly
-  any level Python exposure.
-- The [`Metrics`](simulation-api:metrics) class provides a
-  straightfoward interface for computing a wide variety of operational summary statistics
-  from performance to wind power plant financials.
+  any level of Python exposure.
+- The [`Metrics`](simulation-api:metrics) class provides a straightforward interface for
+  computing a wide variety of operational summary statistics from performance to wind
+  power plant financials.
 
 ### Environmental Considerations
 
-- Windspeed (m/s) and wave height (m) for the duration of a simulation (user-provided,
+- Wind speed (m/s) and wave height (m) for the duration of a simulation (user-provided,
   hourly profile)
 - Reduced speed periods for animal migrations. This is primarily an offshore-focused
   feature, but can be defined at the simulation, port, or servicing equipment level
@@ -37,13 +38,13 @@ a short listing of the core functionality that WOMBAT can provide.
   enforced between the starting and ending dates each year of the simulation. For more
   details, see the documentation pages for the
   [environment](core:environment), [port](core:port),
-  [unshcheduled servicing equipment](types:service-equipment:unscheduled), or
+  [unscheduled servicing equipment](types:service-equipment:unscheduled), or
   [scheduled servicing equipment](types:service-equipment:scheduled).
-- Prohibited operation periods. This dictates periods of time where a site or port may
+- Prohibited operation periods. This dictates periods of time when a site or port may
   be inaccessible, or when a piece of servicing equipment should not be allowed to be
   mobilized/dispatched. Similar to the speed reduction periods, `non_operational_start`
   and `non_operational_end` dictate an annual date range for when servicing equipment
-  can't be active, or a port or the whole site is inaccessible. The same documenation
+  can't be active, or a port or the whole site is inaccessible. The same documentation
   pages as above can be referenced for more details.
 
 ### System and Subassembly Modeling
@@ -58,22 +59,23 @@ modeling assumptions as well as the basic operations of the maintenance and fail
   - `operation_reduction`: the percentage of degradation the triggering of this event
     cause
 - Failure
-  - Randomly samples from a Weibull distribution to determine the next failure
+  - Randomly samples from a Weibull distribution to determine the time to the next
+    failure
   - `operation_reduction`: the percentage of degradation the triggering of this event
-    cause
-  - `replacement`: if `True`, then all preceeding failures and maintenance tasks are
+    will cause
+  - `replacement`: if `True`, then all preceding failures and maintenance tasks are
     cancelled and the time until the next event is reset because a replacement is
     required, otherwise, each successive failure is added to the repair queue
 - Commonalities between Substations, Turbines, and Cables
   - Maintenance and Failures compose the actual "model"
   - `operating_level` provides the real degradation of a model, including if it is turned
     off for servicing
-  - `operating_level_wo_servicing` provides the operting level as if there were no
-    ongoing operations to know the potential operating operating
+  - `operating_level_wo_servicing` provides the operating level as if there were no
+    ongoing operations
 - Substations
   - Any failure or maintenance with an `operation_reduction` of 1 will turn off every
     upstream connected (and modeled) cable and turbine
-  - For subations that are connected by an export cable this, the upstream connections
+  - For substations that are connected by an export cable this, the upstream connections
     made from the export cable will not be considered upstream connections and therefore
     shutdown when a downstream substation has a failure
 - Array cables
@@ -94,7 +96,7 @@ modeling assumptions as well as the basic operations of the maintenance and fail
   - Generally, repairs and maintenance tasks operate on a first-in, first-out basis with
     higher severity level `Maintenance.level` and `Failure.level` being addressed first.
   - Servicing equipment, however, can specify if they operate on a "severity" or "turbine"
-    basis that prioritizes focusing on either the highest serverity level first, or
+    basis that prioritizes focusing on either the highest severity level first, or
     a single system first, respectively.
 - Servicing Equipment: see [here](core:service-equipment) for complete details
   - Can either be modeled on a scheduled basis, such as a year-round schedule for onsite
@@ -106,21 +108,37 @@ modeling assumptions as well as the basic operations of the maintenance and fail
     the mobilization is scheduled so that the equipment arrives at the site for the
     start of it's first scheduled day.
   - A wide range of generalized capabilities can be specified for various modeling
-    scenarios.
-    - RMT: remote (no actual equipment BUT no special implementation)
-    - DRN: drone
+    scenarios. It's important to note that outside of the "TOW" designation, there are
+    no specific implementations of functionality.
     - CTV: crew transfer vessel/vehicle
     - SCN: small crane (i.e., field support vessel)
+    - MCN: medium crane
     - LCN: large crane (i.e., heavy lift vessel)
     - CAB: cabling vessel/vehicle
+    - RMT: remote reset (no actual equipment BUT no special implementation)
+    - DRN: drone
     - DSV: diving support vessel
+    - VSG: vessel support group
+    - TOW: tugboat and support vessel (triggers the tow-to-port model)
+    - AHV: anchor handling vessel (special case that can be modeled from the port or
+      main simulation configuration)
   - Operating limits can be applied for both transiting and repair logic to ensure site
     safety is considered in the model.
 - Ports
   - Currently only used for tow-to-port repairs or tugboat based repairs, which adds the
     following additional capabilities:
     - TOW: tugboat or towing equipment
     - AHV: anchor handling vessel (tugboat that doesn't trigger tow-to-port)
+  - There are a few limitations to the tow-to-port model as follows:
+    - Port usage fees are only modeled by the single monthly access fee `equipment_rate`.
+    - Tugboats are not formally mobilized, so cost and vessel wait times are not
+      applied when a tow-to-port simulation is kicked off.
+    - Tugboats are called out on the first request from the requesting system,
+      regardless of the user encoding.
+    - All subsequent repair and maintenance requests following a "TOW" request will not
+      be addressed until the system is at the port. This can create a significant
+      backlog of repairs if there are not enough tugboats, crews, or active turbine
+      slots encoded at the port.
   - See the [API docs](core:port) for more details
 
 ## Examples and Validation Work
@@ -131,5 +149,5 @@ Below are a few examples to get started, for users interested in the validation
 the [code-to-code comparison presentations](presentations:code-comparison),
 the notebooks generating [the most up-to-date results can be found in the main repository](https://github.com/WISDEM/WOMBAT/examples/), where there is a separate analysis
 for the
-[Dinwoodie, et. al, 2015 comparison](https://github.com/WISDEM/WOMBAT/blob/main/examples/dinwoodie_validation.ipynb),
+[Dinwoodie, et al., 2015 comparison](https://github.com/WISDEM/WOMBAT/blob/main/examples/dinwoodie_validation.ipynb),
 and for the [IEA Task 26, 2016 comparison](https://github.com/WISDEM/blob/main/WOMBAT/examples/iea_26_validation.ipynb).

docs/examples/metrics_demonstration.md

@@ -13,13 +13,19 @@ kernelspec:
 (metrics-demo)=
 # Demonstration of the Available Metrics
 
+[![Binder](https://mybinder.org/badge_logo.svg)](https://mybinder.org/v2/gh/WISDEM/WOMBAT/main?filepath=examples)
+
 For a complete list of metrics and their documentation, please see the API Metrics
 [documentation](simulation-api:metrics).
 
 This demonstration will rely on the results produced in the "How To" notebook and serves
 as an extension of the API documentation to show what the results will look like
 depending on what inputs are provided.
 
+A Jupyter notebook of this tutorial can be run from
+`examples/metrics_demonstration.ipynb` locally, or through
+[binder](https://mybinder.org/v2/gh/WISDEM/WOMBAT/main?filepath=examples).
+
 ```{code-cell} ipython3
 :tags: ["output_scroll"]
 from pprint import pprint
@@ -483,18 +489,6 @@ emissions_factors = {
         "idle at site": 0.5,
         "idle at port": 0.25,
     },
-    "Crew Transfer Vessel 2": {
-        "transit": 4,
-        "maneuvering": 3,
-        "idle at site": 0.5,
-        "idle at port": 0.25,
-    },
-    "Crew Transfer Vessel 3": {
-        "transit": 4,
-        "maneuvering": 3,
-        "idle at site": 0.5,
-        "idle at port": 0.25,
-    },
     "Field Support Vessel": {
         "transit": 6,
         "maneuvering": 4,
@@ -507,8 +501,24 @@ emissions_factors = {
         "idle at site": 1,
         "idle at port": 0.5,
     },
+    "Diving Support Vessel": {
+        "transit": 4,
+        "maneuvering": 7,
+        "idle at site": 0.2,
+        "idle at port": 0.2,
+    },
+    "Anchor Handling Vessel": {
+        "transit": 4,
+        "maneuvering": 3,
+        "idle at site": 1,
+        "idle at port": 0.25,
+    },
 }
 
+# Add in CTVs 2 through 7
+for i in range(2, 8):
+    emissions_factors[f"Crew Transfer Vessel {i}"] = emissions_factors[f"Crew Transfer Vessel 1"]
+
 style(metrics.emissions(emissions_factors=emissions_factors, maneuvering_factor=0.075, port_engine_on_factor=0.20))
 ```
 

docs/examples/strategy_demonstration.md

@@ -12,8 +12,14 @@ kernelspec:
 
 # Servicing Strategies
 
+[![Binder](https://mybinder.org/badge_logo.svg)](https://mybinder.org/v2/gh/WISDEM/WOMBAT/main?filepath=examples)
+
 In this example, we'll demonstrate the essential differences in scheduled servicing, unscheduled servicing, and tow-to-port repair strategies. Each of the examples demonstrated below will be based on the 2015 Dinwoodie, et al. paper, though the variations will be for demonstration purposes only.
 
+A Jupyter notebook of this tutorial can be run from
+`examples/strategy_demonstration.ipynb`locally, or through
+[binder](https://mybinder.org/v2/gh/WISDEM/WOMBAT/main?filepath=examples).
+
 ## WOMBAT Setup and Variables
 
 The vessels that will be changed in this demonstration are the field support vessel (FSV) with capability: "SCN", the heavy lift vessel (HLV) with capability: "LCN", and the tugboats, which have capability: "TOW".

docs/presentations.md

@@ -41,7 +41,7 @@ of the model.
 This document serves as a demonstration of the capabilities of this work in reference to
 two major works to document simulated O&M results from various industry and research
 software systems. Here we compare our software to the published results from
-Dinwoodie, et. al, 2015 [^dinwoodie2015reference] and IEA, 2016 [^smart2016iea].
+Dinwoodie, et al., 2015 [^dinwoodie2015reference] and IEA, 2016 [^smart2016iea].
 <br/>
 {download}`presentation PDF <../presentation_material/code_comparison.pdf>`