IEC TS 62600 updates

[akeeste]

Resolves #381

TODO:

• 62600-100 Ed. 2 en 2024 (WEC Power Performance)
• "capture length" to "capture width"
  • changed across all MHKiT including: textual references in doc strings and notebooks, function names, variable names (L --> CW, LM --> CWM)
  • Created function aliases for capture_length and capture_length_matrix that point to capture_width and capture_width_matrix respectively.
  • Optional: could add deprecation warnings to the function aliases
• 62600-101 Ed. 2 en 2024 (Wave resource)
• Generally, "IEC/TS" is updated to "IEC TS"
  • Looking at IEC references again, this seems to be somewhat inconsistent. In the standard itself they always use "IEC TS X-Y" but the formatting probably isn't that important. I'm inclined to leave my update instead of reverting it
• Update standard deviation degree of freedom
• Confirm that we define bins edges/centers in the same was as the 62600 for e.g. power matrices
  • Bins are not specifically defined in IEC TS 62600, so there's no way to confirm we use them the same. Though I think our representation is fairly standard (bin name = bin center, bin edges are halfway between centers, etc). I also added warnings on height/period bin sizing which is called out, so we are adhering as closely as possible.

[ssolson]

@akeeste thanks for updating the functions to match the latest TS.

The changes are consistently applied and the only question I had was around if in the future we would want to deprecate capture length. You captured this option in your PR summary. Interested in capturing your thoughts here before merging this PR.

[akeeste]

@ssolson I'm on the fence. It's not a lot of effort to maintain these two so I'm in no rush to deprecate them, but I know this stuff adds up over time. Perhaps we should add a FutureWarning now to encourage users to move to the new function over time

[ssolson]

I think we should aim to support only the terminology defined in the standard.

I agree that we should add a future deprecation warning.

[akeeste]

Sounds good. I'll add two FutureWarnings quick

[akeeste]

@ssolson is there a reason we ignore all FutureWarnings in mhkit/__init__.py?

[akeeste]

@ssolson I added FutureWarnings. Per https://docs.python.org/3/library/warnings.html, this seems like the most accurate category to use. However we ignore all of these warning types in mhkit/init.py which prevents users from seeing it

[ssolson]

@akeeste apologies I missed the notification on this and I should have checked in sooner.

I believe ignoring the future warning was added to address mhkit dependencies warnings which could not be updated at one time (e.g. the update needed to remove the future warning was not available). Seeing the warning added confusion to the user's mhkit environment setup we did not want them to worry about.

Now that the future warning exists in this module I suggest we merge this PR and in a separate issue/ PR we handle cleaning up this logic to address only specific future warnings that we specifically want to ignore (replacing the blunt ignore all logic currently implemented).

[akeeste]

@ssolson that sounds good. This is ready to merge from my end. The FutureWarnings currently added will work once we address ignoring them over all