LCOE optimization and BOS cost

Wind & Water Computer-Aided Engineering Software Tools
1

Dear all,
starting from the RAFT studies example, I was setting up an LCOE optimization problem, using RAFT for the simulation of a single FOWT response. The used analysis and modeling options are reported below.
Analysis options:

general:
folder_output: outputs/15_RAFT_Rect
fname_output: refturb_output

design_variables:
floating:
joints:
flag: True
z_coordinate:
- names: [main_keel, col1_keel, col2_keel, col3_keel]
lower_bound: -40.0
upper_bound: -15.0
r_coordinate:
- names: [col1_keel, col1_freeboard, col2_keel, col2_freeboard, col3_keel, col3_freeboard]
lower_bound: 40. #35.8125
upper_bound: 70. #64.6875
members:
flag: True
groups:
- names: [column1,column2,column3]
diameter:
lower_bound: 9.5 #9.375
upper_bound: 20.0 #15.625
constant: True
# thickness:
# lower_bound: 0.05
# upper_bound: 0.25
# constant: True
# - names: [Y_pontoon_lower1, Y_pontoon_lower2, Y_pontoon_lower3]
# diameter:
# lower_bound: 7.5
# upper_bound: 12.5

constraints:
control:
rotor_overspeed:
flag: False
min: 0.0
max: 0.25
Max_PtfmPitch:
flag: True
max: 5.5
Std_PtfmPitch:
flag: True
max: 2.
Max_Offset:
flag: True
max: 30.
floating:
stress:
flag: True
global_buckling:
flag: True
shell_buckling:
flag: True

merit_figure_user:
name: financese.lcoe

driver:
optimization:
flag: True # Flag to enable optimization
solver: COBYLA # Optimization solver. Other options are ‘SLSQP’ - ‘CONMIN’
tol: 1.e-2 # Optimality tolerance
max_iter: 100 # Maximum number of iterations (SLSQP)

recorder:
flag: True # Flag to activate OpenMDAO recorder
file_name: log_opt.sql # Name of OpenMDAO recorder
includes: [‘raft’,‘floating’,‘platform’]

Modeling options:

General:
verbosity: False # When set to True, the code prints to screen many infos
openfast_configuration:
use_exe: True
allow_fails: True
fail_value: 9999

WISDEM:
RotorSE:
flag: True
spar_cap_ss: Spar_Cap_SS
spar_cap_ps: Spar_Cap_PS
te_ss: TE_reinforcement_SS
te_ps: TE_reinforcement_PS
TowerSE:
flag: True
DriveSE:
flag: True
FloatingSE:
flag: True
# gamma_f: 1.35 # Safety factor for fatigue loads
# gamma_m: 1.3 # Safety factor for material properties
# gamma_n: 1.0 # Safety factor for …
# gamma_b: 1.1 # Safety factor for …
# gamma_fatigue: 1.755 # Safety factor for fatigue loads
# buckling_length: 30 # Buckling parameter
# soil_springs: True
# gravity_foundation: False
# frame3dd:
# shear: True
# geom: True
# tol: 1e-9
BOS:
flag: True

Level3: # Options for WEIS fidelity level 3 = nonlinear time domain
flag: False
simulation:
DT: 0.01
CompElast: 1
CompInflow: 1
CompAero: 2
CompServo: 1
CompHydro: 1
CompSub: 0
CompMooring: 3
CompIce: 0
OutFileFmt: 3
linearization:
Linearize: False
ElastoDyn:
FlapDOF1: True
FlapDOF2: True
EdgeDOF: True
TeetDOF: False
DrTrDOF: False
GenDOF: True
YawDOF: False
TwFADOF1 : True
TwFADOF2 : True
TwSSDOF1 : True
TwSSDOF2 : True
PtfmSgDOF: True
PtfmSwDOF: True
PtfmHvDOF: True
PtfmRDOF : True
PtfmPDOF : True
PtfmYDOF : True
HydroDyn:
WvLowCOff: 0.15708
WvHiCOff: 3.2
WaveSeed1: 123456789
AddBQuad1: [9.23e5, 0.0, 0.0, 0.0, -8.92e6, 0.0]
AddBQuad2: [0.0, 9.23e5, 0.0, 8.92e6, 0.0, 0.0]
AddBQuad3: [0.0, 0.0, 2.3e6, 0.0, 0.0, 0.0]
AddBQuad4: [0.0, 8.92e6, 0.0, 1.68e10, 0.0, 0.0]
AddBQuad5: [-8.92e6, 0.0, 0.0, 0.0, 1.68e10, 0.0]
AddBQuad6: [0.0, 0.0, 0.0, 0.0, 0.0, 4.8e10]
PotMod: 1
# WaveMod: 0

Level1:
flag: True
potential_model_override: 0
trim_ballast: 0
heave_tol: 1
save_designs: True

ROSCO:
flag: True
SD_Mode: 0
PS_Mode: 1
ps_percent: 0.85
F_LPFType: 2
F_NotchType: 2
Fl_Mode: 2
tuning_yaml: …/…/examples/01_aeroelasticse/OpenFAST_models/IEA-15-240-RWT/IEA-15-240-RWT-UMaineSemi/IEA15MW-UMaineSemi.yaml
zeta_pc: [1]
omega_pc: [0.2]
U_pc: [12]
zeta_vs: 0.85 # Torque controller desired damping ratio [-]
omega_vs: 0.12
twr_freq: 3.2
ptfm_freq: 0.2
Kp_float: -10

DLC_driver:
metocean_conditions:
wind_speed: [4., 6., 8., 10., 12., 14., 16., 18., 20., 22., 24.]
wave_height_NSS: [0.83, 0.88, 0.94, 1.03, 1.16, 1.34, 1.57, 1.86, 2.22, 2.62, 3.07]
wave_period_NSS: [6.9, 6.96, 7.02, 7.12, 7.25, 7.43, 7.66, 7.94, 8.27, 8.63, 9.01]
wave_height_SSS: [6.3, 8, 8, 8.1, 8.5, 8.5, 9.8, 9.8, 9.8, 9.8, 9.9]
wave_period_SSS: [11.5, 12.7, 12.7, 12.8, 13.1, 13.1, 14.1, 14.1, 14.1, 14.1, 14.1]
wave_height1: 6.98
wave_period1: 11.7
wave_height50: 10.68
wave_period50: 14.2
DLCs:
- DLC: “1.1”
n_seeds: 1
- DLC: “1.3”
n_seeds: 6
# - DLC: “1.4”
# - DLC: “1.5”
# - DLC: “1.6”
# n_seeds: 1
- DLC: “6.1”
n_seeds: 1
# - DLC: “6.3”
# n_seeds: 6

The optimization ends successfully, but I have found a very large final value of the BOS cost per kW from the output file (~14500 $/kW). This results in a very large LCOE value (around 300 $/MWh) as well and in a low sensitivity of the LCOE on the platform sizing, which is the final objective of the optimization. I was wondering where to look for possible error in the settings and if there is a way to set different values of the cost parameters (maybe in the Orbit module).
Thanks in advance.

Best regards,

2

I would encourage you to dive into the output files to understand a bit more where the design wound up, if it looks like the constraints are satisfied, and what might be driving the high costs. It is difficult for me to make these assessments myself at a quick glance (I have not run your files).

I will say that your convergence tolerance looks high, so it is likely that the optimizer isn’t really converged to an answer worth scrutinizing further. I would recommend values more like tol: 1e-6 and max_iter: 300 for the COBYLA solver. Furthermore, if you have installed the nlopt package with WEIS (you likely have), then the solver: LN_COBYLA setting might be a bit more robust and effective.

3

Dear @Garrett.Barter ,
thanks for your advices, I’ve followed them. I’m trying to study a single turbine optimization case. I’ve seen that some input values related to the BOS settings, which seem to be very high for a single turbine. In particular, the site_auction_price and site_assessment_cost are very large. The default value are respectively 100e6 $ and 50e6 $. I’ve tried to reduce the site_auction_price as a preliminary approximation, but it seems that the code only reads the default value reported in the documentation (default value = 100e6 $). The same thing occurs with site_assessment_cost (default value = 50e6 $). I’ve tried to change the input values in BOS section.

BOS_yaml
BOS_yaml342×275 16.6 KB

I’ve set a true BOS flag in modelling option. Other parameters are sensitive to variations (such as distance to site, distance to landfall and distance interconnection) of the values defined into the yaml file. Could you suggest me where to look for a possible error?

Best regards,

4

Hi Vincenzo,

Good catch on your part. This is a bug in the WISDEM-ORBIT interface. I will try to push an update to WISDEM soon.

5

This will be fixed in this PR, after which we will do a minor release of WISDEM to fix the ORBIT interface.

6

Dear @Garrett.Barter ,

Thanks for the update, I’m currently using the last versions of WISDEM and WEIS. I am trying to run an optimization on LCOE using WISEDM/WEIS. Currently, I would like to define an analysis at single turbine level (not for a whole farm). I would like to account for BOS costs, using Orbit, but I cannot find a way to control some cost parameters used in the design and install phases when Orbit is run through the WISDEM interface.
Could you, please, give me some advice on how to manage Orbit parameters within the Wisdem framework? I have seen that there is a set of library files with a list of default input parameters. Are the Orbit settings within Wisdem customizable?

For example, we noticed a very high cost for the offshore substation design and installation, which results in very high levels of the LCOE for a single turbine (for increasing farm size the LCOE ).

Thanks in advance,
best regards

7

@Vincenzo.Auriemma - Thanks for checking in on this. We have definitely debated about how many ORBIT inputs to elevate to WISDEM inputs as it could be overwhelming to some users and helpful to others.

First, ORBIT did do a significant release recently and we have incorporated this into the latest WISDEM v3.17+ versions. In this update came some changes to the yaml-inputs which are captured in the examples. Here is an example of the latest options for a monopile. You may also want to adjust the number of turbines that are assumed in the plant here.

From your question, it sounds like you may have other inputs that you would like you adjust. You can follow the logic of the WISDEM-ORBIT interface in this file. If you want to change some vessel parameters or settings, that is where you will need to look.

Let us know if you have suggestions on better ways to empower users here.