SubDyn documentation: Member Cosine Matrices #2374
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I believe this pull request is ready to be merged.
Feature or improvement description
The current documentation is quite confusing about how the user should define the member cosine matrices in SubDyn.
The documentation shows the calculation of direction cosine matrix as: (https://openfast.readthedocs.io/en/dev/source/user/subdyn/theory.html#local-to-global-transformation):
In this case, the vectors x, y, and z correspond to the columns of the direction cosine matrix.
However, when the user provides the direction cosine matrix as input (https://openfast.readthedocs.io/en/dev/source/user/subdyn/input_files.html#member-cosine-matrices-cosm-i-j) for example to define the directions for a spring element (https://openfast.readthedocs.io/en/dev/source/user/subdyn/theory.html#spring-elements), it has to provide the vectors x, y, and z as the rows of the direction cosine matrix (not the columns as shown in the above [Dc]).
Internally, SubDyn computes the transpose of the matrix provided by the user. Making the direction cosine matrix consistent with the definition of [Dc]. This may be very confusing for a user if it doesn't look in detail in the source code.
The same issue would be faced in the future when defining rectangular members in SubDyn.
I illustrate this with an example taking advantage of the USFLOWT project. The image below shows the top view of the substructure.
The member cosine matrix for the vectors that I show in the above picture, would correspond to:
where the direction 1 (x_e) is defined by (COSM11, COSM12, COSM12); the direction 2 (y_e) is defined by (COSM21, COSM22, COSM23); and the direction 3 (z_e) is defined by (COSM31, COSM32, COSM33).
Impacted areas of the software
Only documentation.