Question to qLogNParEgo Acquisition Function

[jduerholt]

Hi all,

I came across theimplementation of a qLogNParEgo acquisition function (https://github.com/pytorch/botorch/blob/main/botorch/acquisition/multi_objective/parego.py).

From my understanding, it is like a qLogNEI acqf but instead of letting the user handling the scalarization upfront (as in this tutorial: https://github.com/pytorch/botorch/blob/main/tutorials/constrained_multi_objective_bo/constrained_multi_objective_bo.ipynb), it is done within the new acqf.

The only difference, I see, with respect to the tutorial is, that in the tutorial the q candidates are generated sequentially using different scalarizations per acqf (it is done using optimize_acqf_list). In the "new" acquisition function, the batch of candidates is generated in parallel using always the same scalarization for every candidate in the batch.

What is your experience there? What performs better? Or is the idea, to use the new acquisition function within optimize_acqf_list in a sequential way with a different scalarization per candidate in a batch? In this case, the new acqf class would release the burden from the user to codeup the scalarization on his own. If this is the case, we should maybe also think about updating the tutorial notebook ;)

Best,

Johannes

[saitcakmak]

Hi @jduerholt. qLogNParEgo was primarily implemented to avoid the need to manually construct the scalarizations in Ax. Ax typically uses sequential candidate generation, so the scalarizations being the same within a batch hasn't been an issue. The q-batch support in the acquisition function is primarily being used to support pending points when multiple candidates are generated. We use qLogNParEgo when there are many objectives, in which case qLogNEHVI tends to get quite slow.

As to whether one is better than the other, I haven't benchmarked this. My guess is, in the typical small budget regime, you would get a more diverse Pareto frontier if you use different scalarizations for each point, but that's just a guess.

What performs better?

qLogNEHVI performs better in most benchmarks I've run :)

If this is the case, we should maybe also think about updating the tutorial notebook ;)

Yes, good idea. Some of the tutorials are quite old and could use an audit.

[jduerholt]

Ah ok. This makes sense! By doing so, you get in this case the same as using optimize_acqf_list. One other question: why do you generate the q batch by default in a sequential manner in ax? What is the advantage?

[saitcakmak]

We've been doing it for a long time that way, so it's hard to say for sure what the original motivation was. There are various orchestration level things that come into play with async parallelism as well, such as the possibility of fetching new data after generating some of the points.

Optimization related things that come to mind: Sequential tends to take longer to optimize (multiple easier problems to solve) but produces higher quality (measured in terms of acqf value) candidates on average. I don't know whether this is L-BFGS-B having difficulty with increased dimension, or the sequential producing more favorable initial conditions due to a lot more potential raw_samples if you consider all combinations. The peak memory usage is also lower, which we've had issues with in the past (OOM).

[jduerholt]

The point regarding higher acqf values on average is really interesting, because from my intuition I would expect the opposite! Thanks for sharing!

[saitcakmak]

Just as a last point: not everything is in favor of using sequential optimization. We've had issues with extremely slow candidate generation when using sequential as well, particularly in settings where there are a lot of constraints. If you try to generate 10 points with qLogNEI with 10 constraints, it takes quite some time with sequential but tends to be much faster with joint optimization. The constraint evaluation adds quite a bit to the runtime.

[jduerholt]

Yeah, also other points like handling interpoint constraints is not possible with sequential mode. But this discussion shows me that I should look deeper into it.