Validate constraints in optimize_acqf

[Balandat]

In some cases we may allow not using box constraints (e.g. when optimizing Alebo). Also, in general it would be good to the optimziation raise an error if the constraint set is empty.

Will require some unit tests.

[codecov[bot]]

Codecov Report

Merging #1231 (b499da9) into main (0afcf35) will decrease coverage by 0.00%. The diff coverage is 100.00%.

@@             Coverage Diff             @@
##              main    #1231      +/-   ##
===========================================
- Coverage   100.00%   99.99%   -0.01%     
===========================================
  Files          122      122              
  Lines        10553    10607      +54     
===========================================
+ Hits         10553    10606      +53     
- Misses           0        1       +1     

Impacted Files	Coverage Δ
botorch/optim/optimize.py	100.00% <100.00%> (ø)
botorch/acquisition/fixed_feature.py	98.18% <0.00%> (-1.82%)	:arrow_down:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 0afcf35...b499da9. Read the comment docs.

[Balandat]

Not sure why the MacOS tests are failing, but that's unrelated to this PR.

[facebook-github-bot]

@Balandat has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[Balandat]

One question here is whether we're ok with solving an LP on each call of optimize_acqf as this isn't super lightweight. But I guess it's rather minimal compare to full fledged acquisition function optimization. We could also add a validate_constraints option that defaults to True but that we set to False in situations like running sequential greedy optimization where we know constraints don't change between calls.

[facebook-github-bot]

@Balandat has updated the pull request. You must reimport the pull request before landing.

[facebook-github-bot]

@Balandat has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[Balandat]

Coverage gap is unrelated and fixed in #1234

[esantorella]

Is there still a need for this? Conceptually the _validate_constraints function still makes sense.

[Balandat]

Yeah I think we still want to do this, just correctly :) I think we should be able to use a slightly different reformulation of the problem to avoid the non-convexity issue.