Drivetrain code implementation: potential inconsistencies / area of development

[ibrahim-hanif]

Description

This issue concerns the implementation of von Mises stress utilisation constraint TubevonMisesStressUtilization.py within ...WISDEM?wisdem\commonse\utilization_constraints.py, that I reckon may have a implementation mistake.
Would be grateful if you could cross check this again. Thank you 😄

Current behavior (line 179)

# von mises stress
    a = ((axial_stress + hoop_stress) / 2.0) ** 2
    b = ((axial_stress - hoop_stress) / 2.0) ** 2
    c = shear_stress**2
    von_mises = np.sqrt(a + 3.0 * (b + c))

Expected behavior

# von mises stress
    a = ((axial_stress + hoop_stress) ** 2)  / 2.0
    b = ((axial_stress - hoop_stress) ** 2)  / 2.0
    c = shear_stress**2
    von_mises = np.sqrt( (a+b) + 3c ) 

von Mises stress can be written as:

source: Eq. 5-14, Shigley's Mechanical Engineering Design 11e in SI Units, Richard Budynas, Keith Nisbett

[gbarter]

I agree that on face value it doesn't seem like the current code matches the textbook definitions, but if you expand out the algebra, I promise they are equivalent. I haven't looked at this in a while, but just confirmed by hand that it works out.

[ibrahim-hanif]

Description

Planetary gear stage volume within DrivetrainSE
After cross checking

• the code for planetary volume of a gear stage implemented within V_planetary function of file wisdem/drivetrainse/gearbox.py,
• according to the reference Guo (2015), Analytical Formulation for Sizing and Estimating the Dimensions and Weight of Wind Turbine Hub and Drivetrain Components (link), eq. 2.45
  there seems some inconsistencies

Current

def V_planetary(U, B, K):
    sunU = 0.5 * U - 1.0
    V = (
        1.0 / U            # error?
        + 1.0 / U / B      # extra?
        + 1.0 / B / sunU
        + sunU
        + sunU**2
        + K * (U - 1.0) ** 2 / B
        + K * (U - 1.0) ** 2 / B / sunU
    )
    return V

Expected

def V_planetary(U, B, K):
    sunU = 0.5 * U - 1.0
    V = (
        1.0 / B 
        + 1.0 / B / sunU
        + sunU
        + sunU**2
        + K * (U - 1.0) ** 2 / B
        + K * (U - 1.0) ** 2 / B / sunU
    )
    return V

However, the volume (/mass) detailed in the wisdem website for the gearbox module matches the code originally implemented.

We would be grateful if you could cross check this yourself, and feel free to let me know if I understood it correctly or there is a mistake 😄
Thank you very much

[gbarter]

Thank you for the keen review of code and paper. We acknowledge that the code documentation and the original source paper are not in full agreement, and may never have been. Additionally, no matter which version / equation is treated as "truth", the resulting mass values do not match current industry capabilities for torque/mass performance ("torque density"). For that reason, we have instead made the default WISDEM sizing approach to be based purely on a user-input of torque density, such as is done here, which is a single scaling factor that avoids the prior implementation of the source paper. We would very much like to eventually have a bottom-up, physics-based design optimization of the gearbox, as with all drivetrain components. As of now, we lack the funding and the in-house expertise to revisit the older code or implement a new approach. We would very much be open to suggestions and community contributions in this area.

[ibrahim-hanif]

Hi @gbarter,

I am trying to set up a geared drivetrain optimization within WISDEM for the IEA 15MW,
taking the working example of the 5MW geared drivetrain.

Model properties (to reproduce)

there are some differences/edits compared to the 5MW, at this early first run setup, such as:

1. opt["WISDEM"]["DriveSE"]["use_gb_torque_density"] = True
   --- my PhD research at NTNU Made4Wind project is actually a detailed upgrade to the DrivetrainSE module (which is lacking currently issue #593 this would be the first step towards it hopefully; would be grateful for your help in these regards)
2. this simulation is done without hub optimization, so commented are: "hub_diameter" as a design variable and "constr_hub_diameter" as a constraint
3. WT high level input values adjusted for the 15MW (like rotor dia, D_top, _rpm)
4. copied from the 15MW direct drive model are: Blade properties and hub design options & loading from rotor (ULS) "F_ & M_ aero_hub"

Results

After a long process, the optimization failed to converge (20 max iterations)

Iteration limit reached    (Exit mode 9)
            Current function value: 1.106578994156817
            Iterations: 20
            Function evaluations: 88
            Gradient evaluations: 20
Optimization FAILED.
Iteration limit reached
-----------------------------------
nacelle_mass: [1106578.99415682]

Feedback

I would be grateful for

1. your suggestions to improve the convergence (change model properties/decrease scope of wisdem-drivetrain optimization/monitor optimization iterations etc) and
2. would greatly appreciate any feedback or suggestions on how to proceed with this research on a detailed drivetrain implementation within WISDEM -- (with potential usage in WEIS later on)
   --- we could have further/detailed discussions on it via email 😄

Thank you for your time and look forward to hearing from you soon 😄

[gbarter]

Apologies for the slow reply. My first response is perhaps the obvious one that you need to increase the max number of iterations in your optimization setup (in the analysis options file). Also, if you are looking to do a gearbox optimization in conjunction with drivetrain layout and sizing, then use_gb_torque_density is not what you want as that just uses an empiral multiplier on the torque to determine gearbox mass. Beyond that, it is unclear what additional tips you need?

[ptrbortolotti]

no activity, we'll close this. please reopen an issue if needed

[ibrahim-hanif]

Hi @gbarter and @ptrbortolotti , thank you for your help and assistance till now 😄

Project: detailed drivetrain design optimization and system engineering

To reiterate (from my comment before), my PhD research at NTNU is part of the Made4Wind project which involves a detailed upgrade to the DrivetrainSE module, further design optimization of drivetrain and the wind turbine system.

Thankfully, we have made several changes/upgrades/improvements within wisdem (mostly in drivetrainSE), are working on a paper for torque2026 (and others) and hope to advance the research state-of-the-art for drivetrain-wind turbine system engineering. With this, we would request your kind assistance and feedback, as certainly good research requires great collaboration.

Information we request from you

As our reference case scenario is the IEA 15MW, both the monopile and semi-sub VolturnUS turbine designs, I would like to request some inputs to compare our results with the reference cases:

1. Hub loads used in the design of the iea 15mw turbine/drivetrain: the methods described in "Sec. 6 load assessment" of the monopile document are also what we have chosen to calculate the relevant DLC-based worst-case ultimate loading for our chosen wind site. To input these (user-defined) loads to wisdem, the process is simple when using the specific modules (like DrivetrainSE and input to F_aero_hub), but when using run_wisdem these loads are calculated by RotorSE which employes ("peak of the three-sigma gust for the extreme turbulence model" wisdem docs), a method much different than the DLC based. Moreover, disabling rotorse in modelling_options gives an error (below) due to the hard-coded connections from it to different modules (drivese, rotorse etc).

RuntimeError: 
Collected errors for problem 'M4W_15MW_driver3':
   'wt' <class WT_RNTA>: Attempted to connect from 'rotorse.wt_class.V_extreme50' to 'drivese.spinner_gust_ws', but 'rotorse.wt_class.V_extreme50' doesn't exist. Perhaps you meant to connect to one of the following outputs: [].
   'wt' <class WT_RNTA>: Attempted to connect from 'blade.high_level_blade_props.rotor_diameter' to 'drivese.rotor_diameter', but 'blade.high_level_blade_props.rotor_diameter' doesn't exist. Perhaps you meant to connect to one of the following outputs: [].
 ...
   'wt' <class WT_RNTA>: Attempted to connect from 'rotorse.mass_all_blades' to 'drivese.blades_mass', but 'rotorse.mass_all_blades' doesn't exist. Perhaps you meant to connect to one of the following outputs: [].
   'wt' <class WT_RNTA>: Attempted to connect from 'rotorse.I_all_blades' to 'drivese.blades_I', but 'rotorse.I_all_blades' doesn't exist. Perhaps you meant to connect to one of the following outputs: [].

How then can the user input their own hub loads (when using run_wisdem) for design optimization of the drivetrain/turbine system etc.? And could you please provide these loads (F_aero_hub etc) which are mentioned in the iea 15mw (monopile) report?

2. The iea 15mw direct drive drivetrain geometry: also to have a comparison on our design with the iea report, would it be possible to share the iea drivetrain geometry information (eg. the geometry.yaml file) which matches the report exactly? The windIO repository's file (named IEA-15-240-RWT.yaml) is not the same as the report, as the resulting drivetrain component mass distribution is different than the one in the (monopile) report (eg. "Table 5-1. Lumped Masses and Moments of Inertia for the Nacelle Assembly").

Thank you for your assistance. We hope we can reach out to you again if the need arises, and are excited to see where the research goes 🏎️

[gbarter]

Hello @ibrahim-hanif,

1. Please see the standalone drivetrain and monopile design examples in the WISDEM documentation for a guide on how to input your own load values. This is also captured in the WISDEM files in the IEA 15MW repository with this script.

2. You can use the Github revision history to checkout the IEA Wind 15-MW at any point in its lifetime, even back to the original v1.0 release. Some caveats though: Those old files (yaml, WISDEM, OpenFAST) will not run in current versions of the tools. You would also need to rewind WISDEM, OpenFAST, etc. Additionally, those original files are known to have errors. As in, errors in the analysis or the yaml-syntax means the turbine described did not meet the performance goals or original design intent. The current files are a much better representation of the intended 15-MW reference turbine design, so I would not recommend the path of using the original yaml files.

As you wrap up sections of your research, we would welcome improvements to WISDEM's drivetrain modeling and design tools.

[ibrahim-hanif]

Hi @gbarter ,
thank you for the quick reply, and pointing out the Loading field in modelling_options file,
as in your script's modeling_options_monopile_only.yaml file.

1. from what I understand, for a tower(+monopile/floater) analysis, these loads (withing Loading) are the RNA mass properties and total reaction force at bedplate base in tower top c.s., which is an output from DrivetrainSE (base_F, base_M), hence a rather decoupled approach. I wonder, I would like to have drivese, towerse eg. turned on (so without any Loading fields) and so the hub loads (pre user calculated eg. using the extreme DLC method as in iea 15mw report) are user-defined and applied on the drivetrain -> tower -> support structure etc. How would one do that?

2. I understand. Perhaps I can just check the original yaml geometry files for the iea 15mw drivetrain to get the component size values and can input them into the present version yaml files to just do an analysis for further comparison on design improvements etc.

Something in addition, from the script directory I see yaml modelling files for floating turbine mdao (modeling_options_floating*.yaml) which made me wonder if FloatingSE is still relevant and reliable or not (docs says not)... I have not yet started using WEIS for transient mdao, but plan to advance there in the next step after completing some drivetrain-tower-monopile mdao.