-
Notifications
You must be signed in to change notification settings - Fork 8
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
flapping device #170
Conversation
examples/Flapper/designDevice.m
Outdated
zlim([-Inf, 0]) | ||
ylim([-10, 10]) | ||
xlim([-10, 10]) | ||
|
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
examples/Flapper/designDevice.m
Outdated
% 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',... |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
examples/Flapper/designDevice.m
Outdated
xlim([-10, 10]) | ||
|
||
% hydro = WecOptTool.solver("NEMOH", folder, meshes, w); | ||
hydro = nan; |
There was a problem hiding this comment.
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
....
There was a problem hiding this comment.
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).
An example of a command line call to set parameters is also shown.
Add installation of the executable path, and checking Add MATLAB mesh file generation in Gmsh class. Needs to add file read.
So, I have Gmsh set up in a similar way to Aximesh now, and it produces similarly formatted meshes, as so: 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. |
You can look at the mesh normals in |
Fix panel orientation for traditional model
Allows specific setting of degrees of freedom, rotation point, centre of gravity and water depth
* Uses half mesh. * Fixes issues with Mesh.cal writing. * Allows wave direction to be set (to 90 in this case).
examples/Flapper/simulateDevice.m
Outdated
end | ||
|
||
% Mass | ||
mass = hydro.Vo * hydro.rho; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
examples/Flapper/simulateDevice.m
Outdated
myPerf.Fpto = -1 * myPerf.Zpto .* myPerf.u; | ||
|
||
% power | ||
myPerf.pow = 0.5 * myPerf.Fpto .* conj(myPerf.u); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
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. |
@ryancoe, do you think the issue could be where the excitation force is applied? 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. |
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:
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:
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. |
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: |
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. |
Can you find the capture width agains the limit for a pitching device (Falnes Sec. 6.4.2)? |
# Conflicts: # .travis.yml
Also skip Gmsh tests if not installed
Moved branches and reopened in #207 |
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).Fixes #156
Checklist:
[ ] Ifexamples/RM3/optimization.m
has been modified, the content / linenumbers in
docs/user/optimization.rst
are still valid or have been fixed