WindFarmer Services Release notes
OpenAPI specifications
For a detailed description of the API interface please see the generated html documentation for each version, and the associated OpenAPI specification for each version. See API documentation, or alternatively download the specifications from the WindFarmer services user portal at https://windfarmer.dnv.com/documents.
API v2.3.0 (30 Apr 2024)
The API version 2.3.0, previously released for BETA use is now released to the production environment.
Version 1 of the WindFarmer services API is now deprecated and we propose to remove the V1 service 3 months from today on 1st August 2024.
Actions:
- Users of V2 (e.g. CFD.ML) will now need to change the API url to access the service on our production servers.
- Update your base URL from: https://windfarmer.uat.dnv.com/api/v2/ to https://windfarmer.dnv.com/api/v2/, and
- Get a your access key to our production system from https://windfarmer.dnv.com.
- Users of V1 please see upgrading from V1 to V2 for migration guidance from this deprecated version.
Version 2 brings many benefits including new models (CFD.ML, TurbOPark, Beet Blockage OnWindSpeed, CFD.ML blockage correction) and a new asynchronous AEP calculation end point designed for reliable long-running calculations to simulate very large wind farms. Please see our release note history below since V2.0 in May 2023.
Our WebAPI user examples have now all been updated to all use the production environment and version 2.
API v2.3 (BETA 18 Jan 2024)
Blockage corrections from CFD.ML for 1000 turbines
This version enables CFD.ML simulations in neutral atmospheric conditions for large offshore wind farms. It is now possible to estimate a CFD.ML blockage correction efficiency for a 1000 turbine wind farm in 10 minutes.
In version 2.3, the Same Graph Neural Network model options are available as for version 2.2: Onshore Neutral / Offshore Neutral. See CFDML Wake & Blockage Model for background documentation on CFD.ML, and also see the webinar we ran in September: Addressing offshore wake prediction biases (and links to slides from there). The validations presented were created using Version 2.2.
CFD.ML is available in private preview for existing WindFarmer customers who have agreed to give feedback on the new model. If you would like to join the preview program, please get in touch.
Summary
- A new
FromBlockageExtrapolationCurve
methodology for thecfdmlBlockageWindSpeedDependency
enables us to run an order of magnitude faster. - New
AnnualEnergyProductionAsync
API end point supports long-running calcs for larger projects. - New Coupled mode to join blockage corrections and wake models at a flow case level.
Single speed CFD.ML
Choosing the new FromBlockageExtrapolationCurve
option for the cfdmlBlockageWindSpeedDependency
makes the CFD.ML blockage calculation > 10 faster.
This methodology uses a single CFD.ML simulation at a wind speed near peak Ct, paired with an empiracally derived curve to extrapolate calculated blockage impacts to other wind speeds. The differences between the FromBlockageExtrapolationCurve
and FromMultiSpeedGNN
approaches are small at most sites. This single-speed approach is analogous to how we use single-speed RANS CFD to predict a blockage correction within a DNV EPA.
It is likely we will deprecate the FromMultiSpeedGNN
method for blockage correction in a future release.
New AnnualEnergyProductionAsync end point
To enable long-running simulations of the largest wind farms we had to make an architectural change to how our cloud-based calculations are run. To use the AnnualEnergyProductionAsync you should:
- Post your calculation, this returns a job ID back in a few seconds
- Poll repeatedly to Get the calculation status
- When the calculation status returns SUCCESS, then extract and use the results
Coupled blockage correction method
The new OnWindSpeed
BlockageCorrectionApplicationMethod
enables a coupling of wind speed and blockage models. When selected, wind speed reductions from the blockage model are applied at turbines before wake modelling. The blockage efficiency can then derived in the same way as other energy efficiencies by comparing the blockageOnAnnualYield_MWh_per_year
yield with the grossAnnualYield_MWh_per_year
yield. These results are derived if CalculateEfficiencies
is set to true
.
API v.2.2.2 (BETA 20th Sep 2023)
A minor bug fix release.
- fixed input validation to properly handle:
- the Weibull wind climates added in v2.2.1
- the wind farm size checks when CFD.ML is chosen for blockage modelling
- CFD.ML blockage model settings now properly handled
- number of direction steps in CFD.ML blockage calculation now synced with the
numberOfDirectionSectorsForWakeCalculation
setting underEnergyEfficiencySettings
.
API v2.2.1 (BETA 15th Sep 2023)
New CFD.ML turbine interaction model (Beta), specify wind climates using Weibull parameters, breaking changes in energy efficiency settings
This version includes the new CFD.ML turbine interaction model to estimate a blockage correction and the possibility to specify wind climates using Weibull parameters for cases when no on-site measurements exist. To enable the new features, and future-proof the API, breaking changes have been made to the API interface.
CFD.ML blockage correction [BETA]
Further to the earlier Beta release of CFD.ML for turbine interaction loss prediction, it may also be used to derive a single blockage correction efficiency. This Blockage Correction can correct engineering wake models to account for missing blockage effects in the same way as DNV's Blockage Effect Estimation Tool (BEET) is currently used.
Weibull wind climates
Weibull wind climates are a new alternative for specifying wind distributions at turbines. They have been introduced to support calculations when no on-site measurements are available, but you have a modelled WRG file for your site (composed of Weibull parameters). In this context you may now run a non-association method calculation, specifying one Weibull climate for each turbine. The Weibull climates can also be used as drop-in replacement for the current wind climates when using the association method.
API breaking changes
We made breaking changes to the energy efficiency settings in the AEP calculation inputs. Previously, the property turbineInteractionModelSettings contained the wake model settings for all models. To support our new and wake and blockage modelling options, and make this extensible, we now separate settings into a section to describe the wakeModel settings, with specific options for each wake model type, and a section for the blockageModel, with a corresponding section for each blockage model type. The update document in the user guide provides the necessary information on how to migrate to the new structure.
API v2.0 (BETA 31st May 2023)
This version includes the new CFD.ML turbine interaction model to estimate wakes and blockage together, available in private preview.
CFD.ML for turbine interaction loss modelling [BETA]
CFD.ML is a machine-learning based, surrogate model for DNV's state-of-the-art, high-fidelity CFD RANS model of wind farm flows. In contrast to the engineering wake & blockage models, CFD.ML aims to capture the entirety of turbine aerodynamic interactions (wake & blockage together) and is not tuned to any particular SCADA dataset. It approximates RANS CFD - a method derived from first principles. The original method is described in [38]. The application of CFD.ML as a stand-alone model in energy production assessment of wind farms has been postulated publicly during the WindEurope Technology Workshop in 2023. These topics were also discussed in DNV's recent webinar.
CFD.ML can be used as a wake & blockage model from the WindFarmer services API. For more details on the model consult our calculation reference.
API v1.0.34 (21st Feb 2023)
Energy modelling improvements for turbines with "storm control" or "high wind ride through" features The WindFarmer Services API version 1.0.34 was released on 21st February 2023. It includes power modelling improvement for projects using turbines with "storm control" or "high wind ride through" features that will change results for some projects. There is no change to the API interface.
Some wind turbines have a high wind speed shutdown policy with a "storm control" or "high wind ride through" feature. For these turbines the turbine de-rates at high wind speeds near cut-out to enable a smoother transition to a non-operational state. To improve the modelling of these graduated high wind shutdown polices, the air density correction is no longer applied to pitch-controlled turbines operating above the wind speed where they reach rated power.
This change has no impact for wind turbines where the production is constant once you reach rated power.
Across a sample of 30 projects we observed a maximum change in AEP of 0.17% due to this change for a project with a large air density correction of > 0.2 kg\m3, whereas all other projects all experienced differences of < 0.05%.
A bug with negligible impacts was also fixed in the interpolation of power curves for turbines with "storm control". This issue was introduced to the new energy calculation in version 1.2.3. The bug/fix was observed to have a maximum impact of 0.01% AEP for same project described above.
In summary, changes in numbers will only be observed for turbines with storm control. Greater impacts will be observed where the air density correction is greater. We recommend using power curves closer to the site air density to reduce uncertainties and using the multi-air density turbine type feature so that the best data is selected automatically by the energy calculation for each turbine.
API v1.0.33 (14th Dec 2022)
Performance improvements, OpenAPI documentation on website, and calculation size limits to improve reliability
The WindFarmer Services API version 1.0.33 includes improvements to the infrastructure to improve performance and reliability, and calculation size limits to make the service more robust.
AEP Calculation Inputs
To ensure reliable and performant API requests, we have implemented maximum limits on AEP calculations. The biggest drivers we have identified for API response time and response size are the number of turbines being calculated, whether efficiencies are being calculated, and number of Flow and Performance Matrices (FPMs) to be exported.
If Efficiencies are turned on, the maximum number of wind turbines in your wind farms can be 500, with an additional 800 turbines in neighbouring wind farms.
If FPMs are set to be exported, then only 3 can be set and the total number wind turbines, including neighbouring turbines, is limited to 1000.
If Efficiencies and exporting FPMs are off, then a total of 1500 turbines, both neighbour and non-neighbour can be included in the calculation.
With these settings at their limits a response can be expected within 5 minutes and will be no larger than 100MB.
Performance improvements
We have also improved the performance of the compute cluster to improve response times and system stability. This change applies to both the AEP and Blockage endpoints.
Online OpenAPI documentation
For traceability of how the API changes over time, you can now download the latest OpenAPI specification and html documentation from the WindFarmer services user portal at https://windfarmer.dnv.com, documents tab.
Bug fix in edge case near turbine low wind speed cut-in
There is a change predicted power after air density correction for the edge case where you provide turbine performance data where the low wind speed cut-in is below the lowest wind speed data points in the turbine performance table (power and thrust curves). Normally we expect users to specify performance table (power curve) data from a wind speed of zero through to above cut-out, but this is not enforced. If no data is provided for below the cut-in wind speed it is ambiguous how the model should interpolate the power curve points.
In the edge case setup described, in previous versions you could see zero power above cut-in. In the latest version if no power data is provided at cut-in, WindFarmer assumes zero power at cut-in then and interpolates linearly from this to the first non-zero power data point to define the power output at the in-between wind speeds.
We generally advise that you specify turbine performance tables such that they contain at least one zero power record below the cut-in wind speed. The WindFarmer: Analyst GUI guides DNV users to create turbine performance tables that always include a zero power - zero wind speed record to remove ambiguity.