User Guide

This page provides an overview of what WOMBAT is currently able to model, broken down by general category. Following this, there are separate pages for how this is done as demonstrated through example notebooks. To fully follow the particulars of each example, 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 shortlist of the core functionality that WOMBAT can provide.

Post Processing and the Simulation API

• The Simulation class and its Configuration 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 of Python exposure.

• The Metrics class provides a straightforward interface for computing a wide variety of operational summary statistics from performance to wind power plant financials.

Environmental Considerations

• 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 using the following three variables: reduced_speed_start, reduced_speed_end, and reduced_speed (km/hr). This translates to a maximum speed of reduced_speed being enforced between the starting and ending dates each year of the simulation. For more details, see the documentation pages for the environment, port, unscheduled servicing equipment, or scheduled servicing equipment.

• 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 documentation pages as above can be referenced for more details.

• Generalized maintenance start date. This enables the first occurrence for all maintenance events to be set universally, if not specifically defined. If the date is prior to the start of the simulation, it merely sets the cadence. The ability to set a maintenance starting date allows for the staggering of the weather timeseries and maintenance timing. For instance, a weather profile starting in January for the Gulf of Maine, would have annual maintenance occurring in the middle of winter, likely causing many unnecessary weather delays in accessing the site, so the cadence can now start in the late spring or summer to ensure there are ideal weather conditions. This feature is made available through the Configuration.maintenance_start field,

System and Subassembly Modeling

Each substation, turbine, and cable operate with the same core logic of maintenance and failure events. The following will break down the differences between each of these systems' modeling assumptions as well as the basic operations of the maintenance and failure models.

• Maintenance

  • frequency: based on an amount of time between events and a given starting date.

  • frequency_basis: allows the input of frequency to be configured in days, months, or years.

  • start_date: enables the first occurrence of a maintenance event to be offset from the weather profile, or even well after the start date of a simulation.

  • operation_reduction: the percentage of degradation the triggering of this event cause

• 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 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 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 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

  • Similar to substations, any failure or maintenance with an operation_reduction of 1 will turn off every connected upstream cable and turbine on the same string

• Export Cables

  • Similar to array cables, any failure or maintenance with an operation_reduction of 1 will turn off every connected upstream substation and string of cable(s) and turbine(s)

  • As noted in the substation section, export cables connecting substations act independently and not as a string of connected systems

  • The final export cable connecting a substation to the interconnection point can however shut down the entire wind farm

• Electrolyzers (new in v0.11)

  • Similar to both the turbine model, except that they are only allowed to be connected to a substation. Electrolyzer downtime does not impact the rest of the farm.

  • Requires at least 1 turbine with a power curve and 1 substation to enable H2 production. The turbine and substation may be modeled without any failures as a method to model only an electrolyzer.

  • NOTE: in a future version (likely v0.12) there will be a simplified way to model only an electrolyzer, and provide an external power profile for a more accurate assessment of the capacity factor and hydrogen production.

Repair Modeling

• Repair Management: see here for complete details

  • 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 severity level first, or a single system first, respectively.

• Servicing Equipment: see here for complete details

  • Can either be modeled on a scheduled basis, such as a year-round schedule for onsite equipment or equipment with an annual visit schedule during safe weather, or on an unscheduled basis with a threshold for number of submitted repair requests or farm operating level.

  • Mobilizations can be modeled with a fixed number of days to get to site and a flat cost for both scheduled and unscheduled servicing equipment. For scheduled equipment, the mobilization is scheduled so that the equipment arrives at the site for the start of it's first scheduled day.

  • Mooring disconnections and reconnections operate without considering shift timing to ensure that these (typically) very long processes can find an optimal weather window within the simulation. These typically only occur with tugboats.

  • A wide range of generalized capabilities can be specified for various modeling scenarios. It's important to note that outside of the "TOW" designation, there are no specific implementations of functionality.

    • CTV: crew transfer vessel/vehicle

    • OFS: offsite equipment

    • 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 for more details

Examples and Validation Work

Below are a few examples to get started, for users interested in the validation work in the code-to-code comparison presentations, the notebooks generating the most up-to-date results can be found in the main repository, where there is a separate analysis for the Dinwoodie, et al., 2015 comparison, and for the IEA Task 26, 2016 comparison.