Minor Bugfix Release #96
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Support for WindIO 2.0
- The meshing algorithm was receiving member's position in the global reference frame (mem.rA and mem.rB) whereas it should use member's position wrt the FOWT reference frame (mem.rA0 and mem.rB0). Maybe in the future we will want to make this differently and solve the radiation/diffraction problem around the equilibrium position of the system - Modified the code to call pyHAMS only once for each different platform type in an array
- Renamed fowtInfo to arrayInfo because it stores information about the array and not about the fowt - Fixed a call to fowt.calcTurbineConstants that was using r6 instead of fowt.r6
Need to use the position of the reference node wrt the platform coordinate system
…to member headings
Before this commit, RAFT fowt.plots() would zoom in the FOWT if not plotting the mooring system, which is specified by plot_ms. Now, we have an optional flag axes_around_fowt that overwrites that behaviour and lets you choose whether you want to zoom in or not. It works like this: - If the flag is not provided, fowt.plot() just like before: it zooms in the FOWT if not plotting the mooring system, it does not zoom in if plotting the mooring system. - If axes_around_fowt==True: Zoom in the FOWT regardless of plotting the mooring system or not. - If axes_around_fowt==False: Zoom in the FOWT regardless of plotting the mooring system or not. In that case, the function uses the axes limits of the ax object passed to it. Users can use MoorPy's helper function `set_axes_equal` to ensure that axes have the same aspect ratio, just like done in model.plot()
We were double counting the lever arm of the aerodynamic forces. This part of the code self.rotorList[0].nodeList[0].T@self.f_aero0[:,ir])[4] already accounts for the lever arm via the transformation matrix, so applying transformForce() was applying the lever arm twice
The operation T@self.f_aero0 had to many assumptions within it to get the force wrt the rotor reference frame, so replaced it by rotor.f0. We do the same computation as previous RAFT versions, but as rotor.f0 is given wrt the rotor structural node, we need to add self.rotorList[ir].nodeList[0].r0[2] to the offset in transformForce()
Meshing update
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Purpose
Support upcoming meshing update in WEIS v2.1
Type of change
What types of change is it?
Select the appropriate type(s) that describe this PR
Testing
Explain the steps needed to test the new code to verify that it does indeed address the issue and produce the expected behavior.
Checklist
Put an
xin the boxes that apply.