Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

flapping device #170

Closed
wants to merge 38 commits into from
Closed

flapping device #170

wants to merge 38 commits into from

Conversation

ryancoe
Copy link
Member

@ryancoe ryancoe commented Sep 8, 2020

Description

A bottom fixed flapping device (e.g., Oyster). I am leveraging gmsh for this, which is something that I've been wanting to do for some time (see #118).

image

Fixes #156

Checklist:

  • All new files contain the GPL header
  • [ ] If examples/RM3/optimization.m has been modified, the content / line
    numbers in docs/user/optimization.rst are still valid or have been fixed

@ryancoe ryancoe added enhancement New feature or request examples Tutorials and examples labels Sep 8, 2020
zlim([-Inf, 0])
ylim([-10, 10])
xlim([-10, 10])

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At this point, we need to create a file that NEMOH can use. It looks like one of the MATLAB tools that comes with NEMOH (https://github.com/LHEEA/Nemoh/blob/master/matlab%20routines/Mesh.m) may be able to do this for us.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is already done by the NEMOH class. What we need is a gmsh equivalent of the AxiMesh class.

% call gmsh to create the mesh and save as STL
geofn_2 = 'Flapper.stl';
meshscalefator = 1;
syscall_gmsh = sprintf('gmsh %s -clscale %f -1 -2 -o %s',...
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just remembered that (I think) NEMOH needs quads (four sided panels); just need to add the proper flags to the gmsh call: nschloe/pygmsh#331

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I now believe NEMOH can work with either, but are specified in the mesh file as a four node panel with one repeated node.

xlim([-10, 10])

% hydro = WecOptTool.solver("NEMOH", folder, meshes, w);
hydro = nan;
Copy link
Member Author

@ryancoe ryancoe Sep 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When writing the Nemoh.cal file for this flapping device, we will need to specify the degrees of freedom to look at pitch (not heave as with the WaveBot and RM3), see explanation here: https://lheea.ec-nantes.fr/valorisation/logiciels-et-brevets/nemoh-running.

...
1                       ! Number of degrees of freedom
2 0. 1. 0. 0. 0. -7.5   ! Pitch about CG: 2 for rotation, followed by direction vector (axis and center of rotation)
1                       ! Number of resulting generalised forces
2 0. 1. 0. 0. 0. -7.5   ! Moment force in y direction about CdG
....

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a note here that we have been calculating all 6 degrees of freedom in all NEMOH simulations so far (since the repository was set up).

@H0R5E
Copy link
Member

H0R5E commented Sep 25, 2020

So, I have Gmsh set up in a similar way to Aximesh now, and it produces similarly formatted meshes, as so:

flapper

Next job is to modify the NEMOH solver routine to allow different degrees of freedom to be simulated.

EDIT: Before that I need to add something to show the normals, to check that the node numbering is in the correct order.

@ryancoe
Copy link
Member Author

ryancoe commented Oct 1, 2020

You can look at the mesh normals in gmsh... this may be helpful -- you may be able to do a system call to do this.

@ryancoe
Copy link
Member Author

ryancoe commented Oct 1, 2020

Looks like the normals on one face are point in

image

end

% Mass
mass = hydro.Vo * hydro.rho;
Copy link
Member Author

@ryancoe ryancoe Oct 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to be the rotational inertia (I = r_cog^2 * m), where r_cog is the distance from the center of mass to the center of rotation

Additionally, we should allow m != Vo * rho - @ssolson has done this for #3

EDIT: I originally messed up the eq. for moment of inertia, corrected now

myPerf.Fpto = -1 * myPerf.Zpto .* myPerf.u;

% power
myPerf.pow = 0.5 * myPerf.Fpto .* conj(myPerf.u);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can check this against the theoretical limit... will point to a paper or Section of Falnes

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry for the lag on this one... maximum absorbed power for a pitching device in a single frequency ("regular") wave is Pmax = J lambda / pi, where J is the wave power flux (units power/length), and lambda is the wave length.

Additionally, you can use Pmax = abs(Fe).^2 ./ (8*real(Zi)), where Fe is the excitation vector (units moment) and Zi is the impedance.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ryancoe is Pmax invariant with the width of the flap?

@H0R5E
Copy link
Member

H0R5E commented Nov 4, 2020

So, the problem with NEMOH not calculating with depth < 10 was that the mesh generation was not being updated alongside the NEMOH config (the bottom centre of the flap is placed at (0, 0, -depth). Therefore, the flap was being placed below the seabed and NEMOH must not like that.

@H0R5E
Copy link
Member

H0R5E commented Nov 4, 2020

@ryancoe, do you think the issue could be where the excitation force is applied? Where is NEMOH applying the forces, at the centre of mass? But then don't we have to do something about considering where the PTO acts?

EDIT: Actually, I am requesting the moment at the base of device. Perhaps this is the issue, wouldn't it be infinitely big at the point of rotation itself?

EDIT2: Tomorrow I will try requesting the forces not at the point of rotation and see what happens.

@H0R5E
Copy link
Member

H0R5E commented Nov 5, 2020

OK, I think that was a bit of a red herring, I am basically following the procedure here for setting up the case, where the calculation and rotation points are coincident.

From that page, I am struggling to interpret what "moment force along y axis" means. Is "moment force" the torque and does "along y axis" mean it is calculated at the origin? Do we need to scale it, perhaps?

EDIT: Yes, I think there is a good chance this is what is happening. I varied the depth of water for the same sized flap and got these results:

           AvgPow     |MaxPow|     PowTHD_dBc    MaxPos    MaxVel       MaxPTO  
           ______    __________    __________    ______    _______    __________

     -9    -26184    7.4173e+05       NaN        1.1274    0.67645    2.1156e+06
    -10    -30928    1.6164e+06       NaN        2.0519    1.2312     2.5756e+06
    -11    -35854    5.1083e+06       NaN        4.4137    2.6482     3.8308e+06

So, perhaps we should scale it to the z-value of the centre of mass?

EDIT 2: After scaling the torque to be applied at the centre of mass, I get the following results:

           AvgPow     |MaxPow|     PowTHD_dBc    MaxPos    MaxVel       MaxPTO  
           ______    __________    __________    ______    _______    __________

     -9    -2020.3     57232         NaN        0.31317    0.1879     5.8766e+05
    -10    -1933     1.0102e+05      NaN        0.51298    0.30779    6.4389e+05
    -11    -1852     2.6386e+05      NaN        1.0031     0.60186    8.7065e+05

It makes sense to me that the average power increases as the depth reduces, as linear waves are more powerful near the surface. I'm sort of surprised that all the other metrics reduce. These values seem more in the ballpark, at least.

@ryancoe
Copy link
Member Author

ryancoe commented Nov 24, 2020

We should confirm that they way we are setting up the problem and interpreting the results from NEMOH are consistent with what's been done here:

@H0R5E
Copy link
Member

H0R5E commented Nov 26, 2020

So, it looks like the measurements were taken at the origin for the WAMIT run for OSWC. So I guess that confirms that NEMOH is also outputting results measured at the origin (you can't set the equivalent WAMIT XFIELD value), although for some reason they were also measuring the values 0.5m off the body surface (in x) in WAMIT. They don't make any effort to translate these values into any power measurement, it's just a like for like comparison.

@H0R5E
Copy link
Member

H0R5E commented Nov 26, 2020

OK. so the power per wave front of a linear wave is:

So, for and we get . For a 10m width of device, that would be 3830W, so we're seeing a conversion ratio of 52% which doesn't seem too bad to me, given the device is 4m+ below the sea surface.

@H0R5E H0R5E marked this pull request as ready for review November 26, 2020 16:55
@ryancoe
Copy link
Member Author

ryancoe commented Nov 27, 2020

Can you find the capture width agains the limit for a pitching device (Falnes Sec. 6.4.2)?

@H0R5E
Copy link
Member

H0R5E commented Nov 30, 2020

There is equation 6.108, but I'm not sure what is. In the following paragraph it suggests that the absorption would be between 50 and 100% (salters duck is 80% apparently), but I guess that doesn't account for depth variation.

@H0R5E H0R5E mentioned this pull request Dec 1, 2020
3 tasks
@H0R5E H0R5E mentioned this pull request Jan 12, 2021
1 task
@H0R5E
Copy link
Member

H0R5E commented Jan 12, 2021

Moved branches and reopened in #207

@H0R5E H0R5E closed this Jan 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request examples Tutorials and examples
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Flapping device
2 participants