adding spherical constraint, cable block, and cable ex #675
Conversation
|
@dforbush2 This PR is showing a lot of updates that are actually trying to change files back to a point in v4.2 (wecSim.m, simulationClass.m, responseClass.m line 56-59). Can you update your branch to avoid these extra changes? In the meantime I'll review the cable implementation. |
There was a problem hiding this comment.
@dforbush2 I'm still going through some of the class and block details, but my main thought so far is on the end constraints. What is the reasoning for putting the end constraints (spherical or fixed) in the cable block? I suggest we make users define 2 extra constraints or ptos outside of the cableClass. The cable can be used in Simulink with the following connections:
Body -- Constraint/PTO -- Cable -- Constraint/PTO -- body
This will make the cableClass more like a body-pto combination, instead of body-ptox3, and will clean up the class properties. This would eliminate the need for separate 1DOF and 3DOF cables and allow users to create whatever end constraints they want. The top/bottom joint motion can be calculated with our motion sensor block. There will be a lot less class properties that users need to define.
sphere_out.stl -- since this is required in the cable's drag bodies and users can't change it, move to the source folder. However if users won't input an .stl file, we can turn the 'Body Properties' (mesh input) into a Simscape Inertia with a generic sphere shape. Then no .stl file is necessary.
WECSim_Lib.slx:
- Add the cable on top of the v4.3 changes. Right now this can't run from Simulink. I can help set-up the callbacks for the cable once the implementation is finalized.
- move
calcCableTens()to a .m file per #654 #661 - set
cable1_outdecimation toround(simu.dtOut/simu.dt,0)per other to workspace blocks
RM3_cable.slx -- Link the 3dof Cable to the library. Maybe make this an application? We can likely move the RM3_runFromSimulink to an application case too.
source/objects/cableClass.m
Outdated
| 'color', [1 0 0.5], ... % | ||
| 'opacity', 1) % Structure defining visualization properties in either SimScape or Paraview. ``color`` (`3x1 float vector`) is defined as the body visualization color, Default = [``1 1 0``]. ``opacity`` (`integer`) is defined as the body opacity, Default = ``1``. | ||
| bodyparaview = 1; % (`integer`) Flag for visualisation in Paraview either 0 (no) or 1 (yes). Default = ``1`` since only called in paraview. | ||
| bodyInertia = [ 1 1 1]; % (`1 x 3 float vector`) body inertia kg-m^2, default [1 1 1] |
There was a problem hiding this comment.
--> momOfInertia see mass comment
There was a problem hiding this comment.
Ok. I prefer keeping it somewhat clear, whether here or in the documentation, that this is the inertia/mass of the low-order lumped capacitance nodes rather than the cable itself, since the MOI of a flexible cable is complicated. That was my justification for not calling these cable.mass and cable.inertia, but this may not have been a better solution.
There was a problem hiding this comment.
Okay I see your reasoning. I guess if I was a user implementing a cable in WEC-Sim for the first time, I wouldn't know about the dummy bodies being used behind the scenes. I would probably approach this with a total mass or mass/length of the cable, but might be confused if the input file requires the mass or inertia of half the cable.
|
@dforbush2 There are a few library updates that we'll need before I can review this again. I can't run the example right now because its not linked to the library. When I replaced the example with the library cable, I get the error:: It looks like the motion sensors are tied to the wrong library. Can you go through the library and check for these issues? (and save in 2019b). We should also look at getting a section in the advanced features documentation and a CI test for the cable. Whether that is here or in the Applications repo will depend on where the example ends up. |
|
@dforbush2 @kmruehl a few more comments below. I didn't have time to write out all my thoughts before I'm off work next week, but I didn't want to hold up your development. I think it would be easier to discuss this live when I'm back rather then trading comments over github.
|
|
@dforbush2 @kmruehl Just looked back on this in preparation for v4.4 release--
I can do the run from Simulink capability, but need to completely hammer out the implementation before doing that (see items in previous comment). I think there's some renaming we can do to clarify things and that we can probably reduce the number of user-defined options. IMO the number of options makes the implementation a bit overwhelming. |
This PR consists of 3 new additions:
Significant modifications are to:
Added files:
The 3 DOF cable uses a modification of the spherical constraint: the included block is distinct from the /constraint/spherical constraint.
To facilitate testing, I have also added ./examples/cable which runs a quick example, but this is intended to be deleted upon PR approval and re-uploaded to the applications repo.