Complex Conjugate Control with Curtailed Outputs

[H0R5E]

This proposal comes in two parts:

1. As the CC controller is a special case of the PS controller (i.e. with infinite constraints), we should change the CC controller to simply call the PS controller.

2. With this change it should be possible to simulate the effect of curtailment due to constraints (at least for the displacement constraint). There is code already in the repo to check the constraints:

   % Calculates relative displacement
   posT = (motion.Phip' / motion.Dphi) * [x1hat;x2hat];
   relPosT = posT(1:end/2)- posT(end/2+1:end);

   If we were to clip the power at all points where relPosT exceeds the displacement limit then we could simulate the power subject to the constraints but without optimising for them.

Another option is to totally drop the CC controller and add a flag like "no_optimise" to PS which will essentially do the same as the above.

[rgcoe]

As mentioned in #121, the CC runs analytically, and therefore much faster than the PS. Note that a key verification of the PS was to check that it asymptotically approaches CC as the constraints are relaxed. This was performed in #13. As in #121, I don't think getting rid of CC or using PS to simulate unconstrained cases is a good idea. In my opinion, we should improve documentation and perhaps the argument structure to ensure the user understands these different functionalities.

[H0R5E]

The question I think that needs to be answered is that if we were to set out to design a new WEC, using this tool, why would we choose to use the analytical controllers? Yes, they are faster, but part of the whole premise of this tool is that they do not give the right answer.

I guess the clearest use case is as a test environment to check other parts of the system. A more theoretical use case is that the faster controller could be used to "start" the geometry optimisation, after which the PS controller would continue from where the fast controller finishes. And this would have to be faster than doing just using the PS controller alone. This also hangs on the assumption that the fast controller "is heading in the right direction" in terms of the geometry optimisation.

In general, I am leaning towards removing the named controllers and, say, adding a "test" mode, where the analytical controller is run, and the user is informed that the results are not useful.

[rgcoe]

The question I think that needs to be answered is that if we were to set out to design a new WEC, using this tool, why would we choose to use the analytical controllers? Yes, they are faster, but part of the whole premise of this tool is that they do not give the right answer.

I think that one use-case we should be careful not to remove is for a more basic/theoretical/academic study.

In general, I am leaning towards removing the named controllers and, say, adding a "test" mode, where the analytical controller is run, and the user is informed that the results are not useful.

I could see something like this being OK... not sure I love the term "test." What about having the PS controller be the default, but making it so you can run the other controllers via optional arguments (not sure if the run call is exactly the right place, but something like this).

run(study) % runs PS
run(study,'SetController','P') % runs resistive damping and throws a warning

[H0R5E]

Yeah, I think that is a workable solution. I'll have a think about how best to present this in the interface.

[rgcoe]

See #139