NREL / OpenOA

This library provides a framework for assessing wind plant performance using operational assessment (OA) methodologies that consume time series data from wind plants. The goal of the project is to provide an open source implementation of common data structures, analysis methods, and utility functions relevant to wind plant OA.
https://openoa.readthedocs.io/
BSD 3-Clause "New" or "Revised" License
194 stars 63 forks source link

Is there same defenition for oa.tie & eya.tie? #235

Closed hamiddatalev closed 8 months ago

hamiddatalev commented 1 year ago

The issue is: "eya.tie" is calculated from "eya.gross energy" excluding some losses(line 125, eya_gap_analysis.py) but "oa.tie" is calculated from MC simulation at turbine level energy with no losses deducted from it. So, are these two KPIs comparable?

ejsimley commented 1 year ago

Hi @hamiddatalev, the EYA and operational TIE values are intended to be comparable. Turbine Ideal Energy is meant to represent the energy the wind plant would be able to produce if all turbines were operating normally (i.e., always available and not curtailed or derated) and there were no major environmental losses. We define this as the gross energy of the wind plant with wake losses, turbine performance losses, and blade degradation losses subtracted. This definition is exactly how it's calculated from the EYA data because we have access to the predicted gross energy and loss categories. But in the operational data the losses are inherent in the turbine-level SCADA data, which is why we don't subtract any additional losses from the measurements. Instead, we use power curve filtering to identify times when the turbines are operating normally (not derated, curtailed, or underperforming significantly), then use those times to estimate the long-term ideal energy that the plant would be able to produce.

The method and a comparison between the EYA and OA TIE values is provided in the following journal article (see Section 3.1 for a detailed description of the methods for estimating TIE from EYA and operational data): https://onlinelibrary.wiley.com/doi/10.1002/we.2768

hamiddatalev commented 1 year ago

• Is the power curve filtering running in the "filter_turbine_data" function? and if yes: o "turb_capac" (line290, turbine_long_term_gross_energy.py) is calculated from max power, and I couldn't find any outlier detection filter used in "turbine_long_term_gross_energy.py" or "porject_ENGIE.py" for SCADA data. So, how do you deal if this max power is an outlier in the energy data of each turbine? because all other filters are based on this "turb_capac".

• How does this tool work for a site with multiple turbine OEMs or multiple rated powers?

ejsimley commented 1 year ago

Yes, power curve outlier detection is performed in the filter_turbine_data function, mostly using the bin_filter function. That's a good point that the turb_capac parameter is based on the maximum power, so it is assuming the maximum power is not an outlier. I think this could be fixed by setting turb_capac equal to the "rated_power" value for each turbine from the asset table, so we'll review that choice and probably make that fix.

The method should work fine for a site with multiple turbine types because the filtering steps and the selection of the turb_capac parameter are performed separately for each turbine.

hamiddatalev commented 1 year ago

Ok, I'll appreciate it if you can let me know when a new version of the tool is released.

Another point is, Does line 89 "project_ENGIE.py" need to be commented on, as it saves a fixed number for turbine capacity for the site with multiple rated power turbines?

Thank you again for your response!

ejsimley commented 10 months ago

Hi @hamiddatalev, I apologize for the long delay in getting back to you. I hope you were able to successfully use the TIE method in OpenOA for your work despite relying on the maximum turbine power to define filter parameters instead of the known rated power. I will submit a pull request to address this next week.

Note that even though there was no outlier filtering for unrealistically high power values in turbine_long_term_gross_energy.py or project_ENGIE.py, users are free to apply appropriate filtering steps (for example using OpenOA's filtering module) as part of their own custom data preparation workflows before creating a PlantData object. Regardless, I still think it makes sense to update TurbineLongTermGrossEnergy to use the known rated power of each turbine as you suggested.

You made a good point about the single turbine_capacity parameter in project_ENGIE.py not making sense for a plant with multiple turbine types. In OpenOA V3, which was released in the fall, this parameter no longer exists for the wind plant. Instead, the rated_power variable in the asset table is used to define the rated power for each individual turbine. Note that the process for importing data to create a PlantData object was updated in V3 to simplify the process. In addition to passing pandas DataFrames or csv files for each data type to create a PlantData object, there is a metadata file where the columns in each file or DataFrame get mapped to the internal variable names used in OpenOA. Here is the metadata file for the the ENGIE project in V3 (you can also see that turbine_capacity was removed as a parameter; the only plant-level parameters are latitude, longitude, and the total plant capacity): https://github.com/NREL/OpenOA/blob/main/examples/data/plant_meta.yml

ejsimley commented 8 months ago

@hamiddatalev, we merged in the changes mention above for our V3.1 release. Specifically, TIE and other analysis methods use the turbine-specific rated powers and other properties instead of assuming a constant value for the entire wind farm. So I am going to close this issue, but please let us know if you have any more questions or comments. Thanks!