non_box_cons violation after gridization in BADS

[rschween]

First of all thanks for providing this great tool and now the python version of it! 💯

I just encountered a situation where gridization (bads.py l. 646 in 846cfd0) causes an otherwise valid starting point to violate non_box_cons test (bads.py l. 914 in 846cfd0).
So I wanted to feed back that this was quite difficult to spot and that I think it would help to adapt the error message in l. 918 to something more along the lines of "Initial starting point X0 does no longer satisfy non-bound constraint after being fit into the mesh grid."
Beyond this, I wanted to ask whether this is a reflection of me fundamentally misspecifiying non_box_cons / starting parameters or if not, suggest whether gridization could be adjusted to take this into account?
I'm currently using
lb = np.log([0.015, 0.001, 0.001, 1.0, 1.0, 1.0, 0.001, 1.0])
ub = np.log([15.0, 100.0, 100.0, 150, 150, 150, 150, 150])
plb = np.log([0.44999999999999996, 0.01, 0.002, 1.5, 1.5, 1.5, 0.002, 1.5])
pub = np.log([4.5, 1.0, 1.0, 100, 100, 100, 100, 100])
x0 = np.log([1.5, 0.1, 0.1, 6. , 2. , 2. , 1. , 6. ]) ,
so after log, x0 equals array([[ 0.40546511, -2.30258509, -2.30258509, 1.79175947, 0.69314718, 0.69314718, 0. , 1.79175947]])

the resulting self.u is array([[ 0.04589844, 0. , 0.25878906, -0.33984375, -0.86328125, -0.86328125, 0.1484375 , -0.33984375]]) , so quite different from x0 (and outside plausible bounds).

My non_box_cons' main body is:

    x_2d = np.atleast_2d(x) # M test points * D dimensions
    
    result = np.logical_or( np.logical_or(x_2d[:,3] < x_2d[:,4], x_2d[:,7] < x_2d[:,3]), x_2d[:,6] < x_2d[:,2])

Therefore, x0 clears non_box_cons, but self.u doesn't, specifically due to the 3rd condition x_2d[:,6] < x_2d[:,2]
I replicated this behavior with both, v0.8.2 and v1.0.0
Thanks again!

[lacerbi]

Thanks for the detailed error report. Indeed this is a valid point and we should look into it. Gridization can indeed move points around and that might be enough to cause issues.

However, looking at u is further confounded by the fact that u is an internal (possibly nonlinear) transformation of x, so a direct comparison of x and u is not necessarily meaningful. You should first transform u back into x-space to make any analysis.

The non_box_cons check should clearly be done in x-space, not in u-space (we'll double-check that); u is part of the inner workings of the algorithm and not something the user should care about, ideally.

In short, the issue is likely with gridization: that's a real effect. If you have a less-than constraint (as opposed to equal-or-less-than) it is true that two points that satisfy the original constraint (in x-space) might fail after gridization (back in x-space after gridization).