Different optimizer options for multistart and profiles

[FFroehlich]

When I call getMultiStarts, fmincon uses options.localOptimizerOptions. When I call getParameterProfiles, fmincon uses options.profileReoptimizationOptions.

This makes no sense to me. I am definitely not reoptimizing any profiles. Does anybody have a use-case where it was necessary to specify a different optimizer for multistarts and profiles? I would argue that only having options.localOptimizerOptions should suffice.

[paulstapor]

I found for example that, if you use a Hessian matrix, it makes sense to do profile optimization with a trust-region algorithm, since it seem to converge faster close to the optimum, but for a multistart parameter optimization, I rather use interior-point, since it converges better. I think it makes sense that the user is able to specify different optimizer setting for both things. We shouldn't give up this flexibility... One could argue on the naming of the Options-fields, but I would really like to keep them separate...

[FFroehlich]

Okay, but still I would suppose that this is corner-caseish. I would argue that the default should be options.localOptimizerOptions == options.profileReoptimizationOptions and that this is automatically set unless options.profileReoptimizationOptions is manually specified. Also the name profileReoptimizationOptions is not obvious to me.

[paulstapor]

Yes, as mentioned, the naming may be arguable. Yet: If use do not use fmincon as local optimizer, but lsqnonlin or Meigo, then you even have to specify different options, since you can't use those two for profiling at the moment... So: it may be still be corner-caseish, yes. But I would rather let people write one more line of code, than possibly disable a functionality of Pesto...

So: one could think of the following: If Profile(Re)OptimizationOptions is not set, then options.profileReoptimizationOptions = options.localOptimizerOptions; is used in getParameterProfiles. Does that sound reasonable?