Kinematics

[cmichelenstrofer]

Description

Verified that the kinematics are implemented correctly. Changed names of kinematics functions to make them more explicit. Added a test for multiple WEC/PTO DOFs.

Type of PR

• Bug fix
• Major change
• New feature
• Minor change

Checklist for PR

• Authors read the contribution guidelines
• The pull request is from an issue branch (not main) on your fork to the main branch in WecOptTool.
• The authors have given the admins edit access
• All changes adhere to the style guide including PEP8, Docstrings, and Type Hints.
• Added note in Changelog
• Modified the documentation if applicable
• Modified or added a new test
• All tests pass
• Documentation builds
• Reference or close any relevant issues

[cmichelenstrofer]

Closes #52

[cmichelenstrofer]

Tested with the WaveBot in heave and surge (uncoupled). Ran 5 different combination of WEC - PTO DOFs: s=surge, heave=h, WEC_PTO DOFs (e.g. sh_s means the WEC can surge and heave but there is a PTO only in surge):

• sh_sh
• sh_s
• sh_h
• s_s
• h_h

All cases match (WEC velocity, PTO force, PTO power) except for the WEC surge motion. Since there is no force that depends on WEC surge position (radiation & added mass surge forces depend on WEC surge velocity and acceleration), the mean surge position is arbitrary.

WEC SURGE POSITION

WEC HEAVE POSITION

PTO SURGE POWER

[cmichelenstrofer]

Closes #54

[ryancoe]

I think this looks great and OK to merge.

Only thought is that, given the extended discussion amongst our group, it would be good to explain the kinematic Jacobian in the docs and/or example(s). With the documents that you and @dtgaebe have prepared during our discussions (#52), this might not be too much work. I'll leave this up to you @cmichelenstrofer whether that should be part of this PR or another later on (if so make an Issue).

[cmichelenstrofer]

@ryancoe I'll add the documentation and merge. Note this doesn't test that the code is using the off-diagonal terms correctly or not. If we think of a good test for this we can add it later.

[cmichelenstrofer]

@ryancoe @dtgaebe I added a paragraph in the Documentation. Please review. @dtgaebe you can expand on this documentation with #60 to include how to construct this matrix.

[ryancoe]

Approved pending the suggested fixes and @dtgaebe's concurrence.

[ryancoe]

Looks good, just one minor clarification

[ryancoe]

should this be (f_p=0 -> x=0)

Again, this represents a linearization of the function :math:`f_w(f_p)` about the mean :math:`x=0` with :math:`K^T` being the Jacobian of :math:`f_w(f_p)` at :math:`x=0`.

the linearization of K is based on position only, right

[ryancoe]

@cmichelenstrofer will follow up with @dtgaebe on this

[dtgaebe]

Yes, if we want to linearize K it is based on position only and doesn't need extra treatment to relate the forces

[cmichelenstrofer]

@dtgaebe So.... I'm confused again. I am thinking about something you brought up. We define K as the best linearization for the motions and then conservation of energy requires K^T to relate the forces. But ... is K^T also the best linearization for the forces? I.e. if you linearized the force relation f_w(f_b) would you also get f_w = K^T f_b? Or is K^T some suboptimal linearization but required to conserve energy, given the linear assumption made for the motions

[dtgaebe]

@cmichelenstrofer Let's say we always use the instantaneous kinematic matrix K(x) defined as partial derivatives of dp/dx I think then the relation between the forces is not an approximation! Of course, if we linearize K(x) about (say the origin) everything else will be a linear approximation too.
The only inherent linearization comes into places if we use p =Kx = dp/dx * x and the x components are not of unit length.