Adding fixed_paramter to ContinuousInput

[KislayaRavi]

Motivation

In this pull request, I am targeting optimization problems where we want to hold one or more continuous parameters constant during optimization while still including them as inputs to the surrogate model. Previously, the only way to achieve this in BoFire was to set lower_bound == upper_bound, which collapses the parameter's range to a single point. This is non-intuitive for two reasons:
(1) it destroys the meaningful range of the parameter, making it impossible to express the true experimental bounds; and
(2) it conflates two distinct concepts — a parameter that is physically constrained to one value versus one that is deliberately fixed for a particular optimization run.

This PR introduces an explicit fixed_value: Optional[float] = None field on ContinuousInput. When set, the parameter is pinned to that value during acquisition function optimization (via BoTorch's fixed_features mechanism), while its bounds remain intact for surrogate training. Training data may contain any value within [lower, upper] for the parameter, allowing historical experiments — collected before the parameter was frozen — to inform the surrogate model. The existing lower == upper convention is fully preserved for backward compatibility. The method previously named fixed_value() across the input feature hierarchy has been renamed to get_fixed_value() to avoid a name collision with the new Pydantic field.

Have you read the Contributing Guidelines on pull requests?

yes

Have you updated CHANGELOG.md?

yes

Test Plan

• added a new test to test fixed parameter,
• Modified exiting tests to accommodate for the new term.

[jduerholt]

Hi @KislayaRavi,

thanks for the PR. I am a bit hesitant to change this as we rely in a lot of APIs in production on handling this, for this reason I would like to understand the problem a bit better:

• Why is it destroying the meaningful range of parameters? You can always overwrite it or? Also note that for surrogate building and the min max scaler there, we always take the widest possible bounds. For example if the lowest value of a feature in your dataset is 5 and the higherst one 10 and the bounds are fixed to lb=11 and ub=11, then the bounds for the minmax scaler would be 5 and 11. So it is already intact for surrogate building. Also have a look at the get_bounds functionality, there you see the logic if real values are provided:

  bofire/bofire/data_models/features/continuous.py

  Line 219 in 53880c9

  def get_bounds(

• Why does it matter if it is a parameter that is physically constrained vs one that is fixed for one optimization run? Is there anything that you cannot express with the current setup?

Best,

Johannes

cc: @bertiqwerty

[KislayaRavi]

I just feel that current setup is non-intuitive and it overcomplicates everything else. At this moment, it is not a make or break pull request, just a good to have feature. I have also jumped few hoops for the fixed parameters in my setup by storing the bounds separately in a variable (user provided bounds and surrogate bounds are different things) and using them later for other things instead of directly calling the bounds from the strategy/domain object generated from Bofire. But, this change might help in future when we need to send additional payload to other API instead of just sending serialised data models. It might turn the setup more intuitive and less prone to error.

I understand your issue of API in production use case. I had same headache (still having) when all the Scalers were removed and allow_zero was added. That's why we also need a way to futurize data models when we update bofire versions, which leads to one of your old pull request. Let us discuss this together in hackathon.

[jduerholt]

Sounds good to discuss on the hackathon, also have a look at this almost finished PR where a lot was implemented regarding allow_zero: #747