As raised by #307, we should add better documentation of the distributions you can select for inputs to a problem.

This issue that surfaced from conversation with @henrymoss .

If you wanted to do parallel evaluations of your objective, you might be able to do that with Emukit, but it isn't obvious how to get started. A good tutorial would be nice to help people out.

Issue Description

The GRID entity must use the input parameter machinery.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it w

Each section of the Users Manual should have a small discussion of theory behind the method. This should be just enough to understand the inputs and outputs, without derivations (typically no more than one page, see e.g. Nataf). If the theory is complex and requires elaborate discussion, references should be provided that give adequate background to the user.

• MCS

• LHS

• STS

I have some suggestions on how to make an actual documentation for OpenCossan (yes again 😄) since now the Wiki is pretty much outdated (at least for development) and the internal Matlab documentation is horrible to use.

I will prepare an example of what I have in mind and present it at the first day of the Cossanthon.

When I call plotConfidenceIntervals(parameters), i.e. with one parameter, it fails with error Undefined function or variable 'boolWarning' in line 59. The "if" in line 48 defines boolWarning, but not in the "else" clause.
There are also multiple doc bugs.
In line 1, the second parameter is "alpha", but it is never used.
In lines 4-8, USAGE refers to plotParameterUncertainty, which is wrong.
Li

Hello,

I see references to using celery for job submission, would it be possible to see an example of the config file in documentation (under examples). ? Thanks!

• Brandon Walker

The problem module should both describe the inputs, but also the results to be produced. This standarizes access to result, independently from the solver of choice. Needed for hierarchical.

The current benchmarks are quite thorough, which can make them difficult to adapt for users that just want to use one particular feature. Addition of some simple templates that show how to use one particular feature would be helpful for users. (In previous software I have written, these examples get read and used about 100x more often than the actual documentation!)

From the Dakota docs, either step_vector or final_point can be chosen as a parameter for a vector parameter study. Currently, only final_point has been implemented.