How to expose the default acquisition function being used by AxClient()

[AndrewFalkowski]

I am wondering how to find the acquisition function being used in AxClient() with the Service API when it isn't specified manually? I'm sure its buried among the attributes somewhere, but I wasn't able to find it among the options in AxClient()._generation_strategy. Thanks in advance!

[sgbaird]

On a related note, it might be nice to expose the specific model as a default INFO message. As-is, it outputs something like "Sobol + Botorch" which doesn't clarify e.g., use of (noisy) GPEI for single-objective optimization. Likewise for NEHVI in the multi-objective case.

[mgarrard]

Hi @AndrewFalkowski - i'll put up a PR to expose the acquisition function as a property on GS, and once i find the keying sequence will paste it here for you as a workaround.

@sgbaird thanks for the request - we are actually trying to work on reducing our logs so that folks don't get overwhelmed and then read none of the log information. Could you describe a time when this would have been helpful -- trying to see if there is a workaround that isn't a log but instead something else we could expose instead :)

[sgbaird]

Hi @mgarrard, thanks for the prompt response! The use case may be somewhat niche. When using https://honegumi.readthedocs.io/, we want users to be able to know what is being used by default under the hood. In particular, we're changing the model row so that it says "Default" instead of GPEI, since, depending on the other rows selected the "default" model might be qNEHVI, etc. This came about while @AndrewFalkowski was creating some tutorial content and trying to describe what defaults were being chosen. Likewise, since we often are required to report details about the models we're using for publications, it's important to be able to access it.

In this instance, I'm not sure it would matter as much whether it's accessible via an attribute vs. contained in the logs so long as someone could find it relatively quickly. For example, the logs could be updated with short instructions for which attribute(s) to look at or link to docs or an issue.

The solution you described for @AndrewFalkowski is enough for us though.