WaveBot - Githubissues

ryancoe commented 4 years ago

Description

Add in waveBot class for ongoing paper study. I've used a new programmatic structure here based on our recent discussions @H0R5E and @ssolson where I have a class devoted to the WaveBot. I fully expected to hit a roadblock on this and realize the idea I had was misguided, but I honestly found this to be very straightforward (so far).

This takes over some of the discussion in #125.

Fixes #70 Fixes #123

Checklist:

[ ] Added the results of running the test suite (in pdf form)
[ ] All new files contain the GPL header
[ ] If example.m has been modified, the content / line numbers in docs\user\example.rst are still valid or have been fixed
[ ] add unit tests

Other To-Do's

[ ] handle asymmetric constraints fully (in SimResults)

ryancoe commented 4 years ago

@H0R5E @ssolson - I don't think this is necessarily ready to merge, but I've appreciate your feedback.

ssolson commented 4 years ago

Thoughts on the example_waveBot results: I like the table. I think F-count is the total number of objective function calls? What is Feasibility and why is it 0? Is the 1st order optimality compared to the MC runs? If so I doubt the user will always have an MC to compare against. Not sure what Norm of the step is.

What is "Current Point" (e.g. consider renaming)? Why is it a bar graph? I think this is updated each objective function iteration e.g. each F-count. If so could you do an F-count vs Result and a scatter plot? I like seeing the Function value as a function of iteration. I like seeing the optimization function vs the MC but again do not thing this will always be an option for the user. Of course, I see this is an ad-hoc plot and not built into the results

ryancoe commented 4 years ago

@ssolson - On your comments about the example_waveBot results - most of this is built into MATLAB (the command line output, plot functions, etc.). Any questions you have about the meanings are probably best found on the MATLAB documentation. For tweaks, we can of course come up with some revised versions (I agree with you about plotting the history of the solution).

H0R5E commented 4 years ago

Also in a discussion with Mat today on D3D it came up that we should probably tag a version before we start implementing any major changes especially as a reference point before the MEC presentation.

Yeah, if we are going to present the v0.1 concept then I think it would be a good idea to do another release before we remove the existing WecOptTool UI. My expectation is that whatever the outcome of this is, it will overwrite WecOptTool to become the public API.

ryancoe commented 4 years ago

My suggestion is to try and adapt the structure of DeviceModelTemplate to look more like the waveBot class and then port the waveBot code into a concrete DeviceModelTemplate class next to the existing RM3 model (and fix that model as required for the modifications).

Yes, I think this is the idea... for me, making the one-off WaveBot class was helpful for me to work through the structure and steps. At the same time, I really do like the workflow for performing a study demonstrated in waveBot_caseA.

A lot of the process for me was simply understanding what had already been done for v0.1 a bit more completely. For instance, I think that the following methods in WaveBot class (not exhaustive) can be common between devices (i.e., part of a super class DeviceModelTemplate):

Some of the components of the init method https://github.com/SNL-WaterPower/WecOptTool/blob/2317e2bc3569d8f97c98ea01b22f3f020c98cda7/toolbox/%2BWecOptLib/%2Bmodels/%40waveBot/waveBot.m#L50
The post-processing section of runHydro https://github.com/SNL-WaterPower/WecOptTool/blob/2317e2bc3569d8f97c98ea01b22f3f020c98cda7/toolbox/%2BWecOptLib/%2Bmodels/%40waveBot/waveBot.m#L80
The CC and P cases from simPerformance. Also some parts of the PS steps (execution of solver). https://github.com/SNL-WaterPower/WecOptTool/blob/2317e2bc3569d8f97c98ea01b22f3f020c98cda7/toolbox/%2BWecOptLib/%2Bmodels/%40waveBot/waveBot.m#L197
All of the protected methods https://github.com/SNL-WaterPower/WecOptTool/blob/2317e2bc3569d8f97c98ea01b22f3f020c98cda7/toolbox/%2BWecOptLib/%2Bmodels/%40waveBot/waveBot.m#L318

As I'm sure you're noting, I have really been reinventing the wheel with this WaveBot class, as the reusable components I've identified here closely follow what's been done with DeviceModelTemplate. I think that the structure would look something like this (ignoring the simResults, etc. for expediency):

What does this mean for someone wanting to make a new device:

if the user's device looks kinematically just like an existing device, you'd need to copy-paste (or just edit in place) and change the code for creating the geometry. I suppose this means that the classes RM3 and WaveBot could eventually become archetypes (twoBodyPa and oneBodyPa, respectively).
if the user's device does not fit kinematically into one of the existing devices, they'd have to create a class with the proper interfaces (eventually, we aim to have some semi-automated process for this based on the discussion in #66, but this may be a way off still)

H0R5E commented 4 years ago

OK, so I have a very short time to write this down, and perhaps it warrants another chat, but my main thought is that, if we are using objects to define real concepts, an actual device doesn't come into existence until it has a size defined. This is causing the temporal coupling, because WecDevice morphs into something else once you call runHydro. In reality, we start with a device blueprint and then we make a device from it by defining a size. So, I think we need two classes, one for the blueprint and one for the created device like so:

WecOptTool

I've added some of the encapsulation ideas we talked about in here as well, but, basically, the user would be expected to build the blueprint and then the rest would be done by the toolbox. What do you think?

ryancoe commented 4 years ago

@H0R5E - I think you may be on to something... so programmatically it would be something like this?

myBp = WecOptLib.models.RM3(<controlType>,<geomType>, ...);
myWec = myBp.makeDevice(<size or geometry params>);
simResults = myWec.simPerformance(S);

H0R5E commented 4 years ago

Almost, I think it would make sense to define what type of geometry and control would be called in different places, like so:

myBp = WecOptLib.models.RM3();
myWec = myBp.makeDevice(<geomType>, <size or geometry params>);
simResults = myWec.simPerformance(S, <controlType>);

This would give you more flexibility for reuse of your objects and would probably make it easier to define the encapsulated functions, so for makeMesh, it might have a standard definition, like

mesh = makeMesh(<geomType>, <size or geometry params>)

H0R5E commented 4 years ago

Alternatively you could define a control type when you make the device, which could be changed later:

myBp = WecOptLib.models.RM3();
myWec = myBp.makeDevice(<geomType>, <size or geometry params>,  <controlType>);
simResults = myWec.simPerformance(S);
myWec.setControl(<anotherControlType>)
simResults2 = myWec.simPerformance(S);

ryancoe commented 4 years ago

I think it's time to go ahead and try one of these approaches. It won't be too hard to switch if we find something we don't like.

H0R5E commented 4 years ago

I think it's time to go ahead and try one of these approaches. It won't be too hard to switch if we find something we don't like.

I'm happy to put something together, but it will take me a couple of days, if that's OK?

ryancoe commented 4 years ago

@gbacelli - I fixed my initial issue with the power spectrum (Parseval...) with ffeb742342817737c9d97e1e07a0ca46cdf6177f, but I'm now noticing that the limits, e.g., on force, don't seem to be working symmetrically... Here's a minimum working example below. As you can see, the positive force is limited to 50N as desired, but not the negative...

clc
clear
close all

geomMode = 'scalar';
lambda = 1;
w = 2*pi*linspace(0.05, 2, 50)';
a = WecOptLib.models.WaveBot('PS',geomMode,w);
a.runHydro(lambda);
a.delta_Fmax = 50;
a.delta_Zmax = 1e10;

% regular wave
Hm0 = 0.125;
Tp = 1/0.625;
gamma = 3.3;
S = jonswap(a(1).w,[Hm0, Tp, gamma],0);
[~,idx] = min(abs(S.w - 2*pi/Tp));
Sn = S;
Sn.S = Sn.S * 0;
Sn.S(idx) = S.S(idx);
S = Sn;
clear Sn

%%

rng(3)
r = a.simPerformance(S);  

summary(r)

r.plotFreq()
r.plotTime(0:0.01:10)

Here's the line where that inequality matrix is created: https://github.com/SNL-WaterPower/WecOptTool/blob/b20bfb660ca32dfe936774565ac05f1eeda10cfe/toolbox/%2BWecOptLib/%2Bmodels/%40WaveBot/WaveBot.m#L433

H0R5E commented 4 years ago

Isn't this superseded by #159? Is there any point in @ssolson going over this?

ssolson commented 4 years ago

Isn't this superseded by #159? Is there any point in @ssolson going over this?

Mat the issue existed there as well. Ryan set me straight on the correct repository to look at yesterday though and I am not reviewing this.

I think we should close this PR though

ryancoe commented 4 years ago

now under #161

SNL-WaterPower / WecOptTool-MATLAB

WaveBot #140

Description

Checklist:

Other To-Do's