WDRT: Integrating the WEC Design Response Toolbox

[ssolson]

The WEC Design Response Toolbox (WDRT) is an OpenSource python code hosted on GitHub (code, docs). Some internal discussion has concluded that integrating the WDRT's capabilities into MHKiT could be beneficial as the WDRT provides WEC specific analysis for:

1. Environmental Characterization
2. Extreme Response
3. Fatigue Analysis

Looking at the WDRT code the three topic areas above are broken down into 5 primary modules in the WDRT:

1. Environmental Characterization
2. Short extremes
3. Long extremes
4. Fatigue
5. Most-likely extreme response (MLER)

where module "a" maps to capability "1"; modules "b" & "c" map to capability "2"; and modules "d". and "e". map to capability "3".

Integration from the WDRT is proposed to take place in the order of the capabilities listed above e.g. starting with Environmental Characterization followed by Extreme Response. This order has been proposed due to the dependencies of the other capabilities (e.g. some Fatigue analysis will depend on Environmental Characterization). Further, the proposed order starts with the less object-oriented code which will speed the transition to the function-based MHKiT.

The proposed workflow will start with a particular capability e.g. Environmental characterization. For this capability, we will

1. Write unit/integration tests on the WDRT master branch (e.g. perform development on WDRT prior to integration) to ensure when transferred the code is working correctly. I have spoken to Ryan about this.
2. Create a working Pull Request (PR) where developers can collaborate on the code structure and implementation of the transferred code. The PR will discuss feature-specific (e.g. Environmental Characterization) discussion where this issue will relate to WDRT integration on the whole.

I have functions mapped from each module to a proposed location in MHKiT but will save that discussion for the PR.

Please let me know what you guys think!

[kmruehl]

@ssolson This strategy/priority list sounds good to me. Here's my biggest question.

How do you want to structure WDRT integration into MHKiT? Is that something you'll decide as you begin the migration? Also worth considering, will the structure of the WDRT integration into MHKiT affect the functional vs object oriented nature of the implementation?

It seems like a) b) and c) belong in waves.resource submodule as they are wave resource specific, but d) and e) should probably go in the new loads module since (I believe) they apply to MHK generally. Thoughts?

[kmruehl]

@ssolson should I add aubreyeckert and adallman to this discussion about the role of https://github.com/SNL-WaterPower/SNL-ESSC (the MATLAB precursor to WDRT)

[ssolson]

Yes I would be interested to know if anything was not captured in WDRT. Eventually, we may want to capture the plotting from ESSC for MHKiT-MATLAB.

[kmruehl]

@ssolson added them both to this thread (not to the org)

[kmruehl]

As an FYI, adding SNL-ESSC developers to this thread: @aubreyeckert @adallman As an FYI, adding WDRT developers to this thread: @yuyihsiang and @nathanmtom

[ssolson]

Updates to WDRT Integration/Unit Tests: WEC-Sim/WDRT#27

[hivanov-nrel]

@ssolson @rpauly18 do you foresee any clashes/duplicate efforts of this tool and the loads module? Is there a plan for some sort of overall integration?

[ssolson]

Good question I believe you are referring to the fatigue module in WDRT (Are you concerned about any of the other modules? I would characterize the others as resource assessment). I am not familiar with your current plan for the loads module so it is hard for me to say. The fatigue module in WDRT is essentially a rainflow calculation to get the equivalent load (Docs, source). Could you tell me the relationship between the damage equivalent load in MHKiT and the one in the source code of WDRT. Skimming the functionality it appears to be duplicate and we would not merge if so.

[hivanov-nrel]

I briefly looked at the code and docs. It seems like they are doing a simplified version of fatigue analysis to get to a damage equivalent load. However, the equation they are using differs from the new IEC loads standard.

I think the other functions look quite useful. They are more specific towards MEC devices. What is the time frame for integration of this tool? Perhaps I could work around some of the functions and/or supplement them.

[ssolson]

My plan of attack/ first step for bringing you into the conversion would be to modify the WDRT fatigue module example results/plot to use the MHKiT loads module. However, as NREL lead lets have @rpauly18 weigh in on how to best apply your skillset.

My status on the conversion is that #53 is 95% complete and incorporates the request NDBC function from WDRT. I am currently working on the environmental_sampling example. I have functionalized and re-written the principal_component_analysis and get_contours into functions in a local branch of MHKiT so that I currently can return an expected contour (e.g. 100 year contour) using MHKiT. This function still requires minor clean up, tests, and documentation. From my experience, this part often takes as long as writing the code so I would put this effort at 50%.

As far as timeline it really depends on how things shake out and what we prioritize. E.g. #56 will impact how PCA and get_contours function. I hope this provides a good overview of the project status and communicates that the timeline is highly fluid given the low level of funding e.g. limited time on this project to spend each week.

[rpauly18]

@ssolson and @hivanov-nrel I think it is a good idea for the two of you to work together on the fatigue functionality in WDRT with respect to merging it into MHKiT. We do not want to duplicate efforts and Chris will likely have insights into to best to improve the existing functionality.

[ssolson]

Revisiting the completion of the environmental contours in Q3 of 2021