Default sprectral weighting

[rgcoe]

Description

I found the toggling of warnings in the example file particularly offensive for some reason :), so I made changes to set the equal weighting of the example spectra. This relates to #108, although does not close it.

Fixes (none)

test_results.pdf

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

[H0R5E]

I think this is a good idea, as it looks a bit shonky having an example that triggers our own warning. Before I review this, though, I would like to suggest a couple of things to add value to the PR:

1. Take the opportunity to move this warning outside of the optimiser by moving lines 146-154 of DeviceModelTemplate.m into the addSpectra method of RM3Study.m (between lines 91 and 92). Then update the error message on line 158 of DeviceModelTemplate.m to just say you need to set mu throughout. Some of the tests might need updated to add mu to the input spectra.
2. Maybe update 8spectra.mat rather than add code to the loading function, just to avoid confusion down the line if someone adds a different 8spectra.mat and doesn't get that mu is being overwritten.

I'm not totally sold on the second suggestion, but I think the first one would be a useful improvement from this PR, beyond tidying up the example.

[rgcoe]

I completed 2 with cf7747c and a version of 1 with 705da40.

"version of 1:" I moved the checking for mu to WecOptLib.utils.checkSpectrum, which was already being called in RM3Study.addSpectra. I do not check the spectral weighting within DeviceModelTemplate.m, because it seems like this would be checking them twice (right?).

Additionally, I added some unit tests for this functionality to checkSpectrumTest.

test_results.pdf

[H0R5E]

I'll try and get the review of this done before our meeting tomorrow.

[H0R5E]

OK, so there is an issue that checkSpectrum doesn't return the fixed spectrum, so when you run the example with a WAFO generated spectra it bugs out:

Running study...
Reference to non-existent field 'mu'.

Error in WecOptLib.models.DeviceModelTemplate/getPower (line 155)
            mus(iSS) = S.mu;

Error in WecOptTool.run/obj (line 69)
        pow = -1 * RM3Device.getPower(study.studyDir,           ...

Error in fmincon (line 562)
      initVals.f = feval(funfcn{3},X,varargin{:});

Error in WecOptTool.run (line 93)
    [sol,fval,exitflag,output] = fmincon(@obj,                  ...

Error in example (line 62)
WecOptTool.run(study, options);

Caused by:
    Failure in initial objective function evaluation. FMINCON cannot continue. 

The name checkSpectrum has also become a bit weird in that it fixes the spectra as well as checks them. My personal preference would be to have checkWeightingsPresent as standalone function rather than rolling it into checkSpectrum and change its name to be clearer that it's going to change the input.

[H0R5E]

This is a superfluous comment. Remove or edit the docstring, if necessary.

[H0R5E]

For this to be useful S must be returned by checkSpectrum

[H0R5E]

Would need changed if S is returned

[H0R5E]

I'm not sure if checkSpectrum is the correct name for this now if it does two jobs, checking and fixing.

[rgcoe]

agreed, but I actually do prefer that its just one function call to do both

[H0R5E]

I think I am going to push you on this, but not just because it's nasty to have one function with two purposes (ick). I'm most worried that, as we change to the new structure, there is a risk that this function ends up back inside the optimisation loop without the spectra being corrected first, rendering the original purpose of stopping the warning showing up in every iteration moot.

If we have an explicit function that fixes the mu prior to use in any optimisation that the user creates, then checkSpectrum can simply generate an error if it's not set (for more than one spectrum), which is its typical behaviour, allowing it to be safely used anywhere in the code. Does that make sense?

[H0R5E]

Consider making this a standalone function, then checkSpectrum doesn't need to return S and it's purpose remains clear. I think the name could be changed as well, to something like "fixWeightings", just to show that it changes the input.

[rgcoe]

Based on #143 and #144, we can close this by simply updating the .mat files for the example spectra. Also the warnings would happened only once (outside of loop), so not a big deal anyways.

[H0R5E]

.mat files added to #161