When running cyclops, users will likely want to return multiple (N) sensor suite options to suit a range of budgets. By default, N=3 levels including:
"Black cheque" version i.e. best data without regard for cost.
"Value" version i.e. cheapest option which meets some minimal acceptable level of data quality and robustness to sensor failure.
One or more middle option(s) which find points with a good trade off between budget and data quality.
Likely this will involve adjusting the weight coefficient of the budgetary term(s) in the loss function, thus this issue requires/links to #16.
Another important aspect of this feature will be implementing a sensible way to control the extreme options. The simple approach would be to add bounds to the budgets, but this may prompt the result too much. Alternatives may be possible to allow sensible returns for an unbounded budget.
If unbounded, the high budget option will just return an experiment with as many sensors as will physically fit in the space. One option would be to set some high but finite upper bound for maximum budget. Another would be to prevent the addition of additional sensors to the suite once they give sufficiently diminishing returns against the data quality performance metric.
Similarly, if unbounded the low budget option will just return a suite with zero sensors. Again, one option would be to set some minimal budget, but an alternative would be to define some minimal acceptable data quality and robustness to failure the suite must achieve to be considered a valid setup.
"Nice to have" features linked to this issue would be automatic generation of reports from a run, which could be easily added to a technical report of a study.
When running cyclops, users will likely want to return multiple (N) sensor suite options to suit a range of budgets. By default, N=3 levels including:
Likely this will involve adjusting the weight coefficient of the budgetary term(s) in the loss function, thus this issue requires/links to #16.
Another important aspect of this feature will be implementing a sensible way to control the extreme options. The simple approach would be to add bounds to the budgets, but this may prompt the result too much. Alternatives may be possible to allow sensible returns for an unbounded budget.
"Nice to have" features linked to this issue would be automatic generation of reports from a run, which could be easily added to a technical report of a study.