Making GIBBON robust to numerical instability

[SebastianAment]

Summary:
When using GIBBON for batch acquisition, numerical instabilities can be encountered that lead a quantity (V_determinant) that is mathematically positive to be numerically negative. Taking the logarithm of this quantity then leads to NaNs in the information gain tensor, which in turn leads to optimization failures.

This commit clamps a term in the expression for V_determinant so that the resultant quantity is positive, while ensuring that gradients continue to flow through the backward pass to all relevant variables.

Differential Revision: D45584690

[facebook-github-bot]

This pull request was exported from Phabricator. Differential Revision: D45584690

[codecov]

Codecov Report

Merging #1814 (bae61a1) into main (e7077a6) will not change coverage.
The diff coverage is 100.00%.

❗ Current head bae61a1 differs from pull request most recent head 43d24c4. Consider uploading reports for the commit 43d24c4 to get more accurate results

@@            Coverage Diff            @@
##              main     #1814   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          170       170           
  Lines        14913     14915    +2     
=========================================
+ Hits         14913     14915    +2     

Impacted Files	Coverage Δ
botorch/acquisition/max_value_entropy_search.py	100.00% <100.00%> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[facebook-github-bot]

This pull request was exported from Phabricator. Differential Revision: D45584690

[SebastianAment]

@henrymoss Hi Henry, Sebastian "from GitHub" here :)

I encountered some NaNs while using GIBBON for batch optimization and traced it to V_determinant being negative. Do you think clamping variance_m to enforce V_determinant > 0 is a reasonable thing to do here?

[henrymoss]

Hello Sebastian "from GitHub". I guess the issue came after a fair few optimisation steps?

Once we are quite confident where the optimum is, then the batch gets very concentrated and we run into numerical precision issues with the ratio of the pdf/cdf in the GIBBON calculation (I think).

I think clamping makes sense, but I would keep the lower limit as small as possible. Towards the end of BO the actual size of information gain can be pretty tiny (hence all the other numerical hacks in the code), so you might wanna try 1e-12 or something?

[facebook-github-bot]

This pull request was exported from Phabricator. Differential Revision: D45584690

[SebastianAment]

Thanks for the feedback Henry! I just updated the clamp to use inv_quad_term * (1 + eps), where eps = 1e-6 for floats and eps = 1e-12 for doubles. If we go much lower than 1e-6 for floats, 1 + eps == 1 numerically, so the NaNs will appear.

numerical precision issues with the ratio of the pdf/cdf in the GIBBON calculation

As far as I can tell, V_determinant is not affected by the pdf-cdf ratio, which is already checked for NaNs, so this issue seems different.

This occurred mostly after a couple of iterations, but I've even observed it in the second batch on a 12-dimensional problem after initializing with 24 Sobol points and with a candidate set consisting of 1024 points. Maybe the dimensionality also has an effect on this.

In any case, works like a charm now!

[facebook-github-bot]

This pull request has been merged in f39bde4.