Extend valid types for PyROS solver argument uncertain_params

[shermanjasonaf]

Summary/Motivation:

Motivated by recent user feedback, this PR adds support for the speciifcation of Var and VarData objects as (entries of) the argument uncertain_params to contrib.pyros.PyROS.solve(). Thus, the argument uncertain_params can now be a Param, ParamData, Var, or VarData instance, or an iterable sequence of such instances. All VarData objects derived from uncertain_params should be fixed by the user in advance of invoking PyROS.

Note that if uncertain_params is of type Var/VarData, or otherwise has Var or VarData entries, then there may be an appreciable computational overhead during the PyROS solver preprocessing step for models with large numbers of Constraint, Expression, and/or Objective components in which the Var/VarData objects appear.

Changes proposed in this PR:

• Allow PyROS solver to support Var and VarData objects in uncertain_params argument

TODO (after #3434 merged)

• Update version number and changelog
• Add bullet on preprocessing progress logging in logging output explanation table?

Legal Acknowledgement

By contributing to this software project, I have read the contribution guide and agree to the following terms and conditions for my contribution:

1. I agree my contributions are submitted under the BSD license.
2. I represent I am authorized to make the contributions and grant the license. If my employer has rights to intellectual property that includes these contributions, I represent that I have received permission to make contributions and grant the required license on behalf of that employer.

[codecov]

Codecov Report

Attention: Patch coverage is 98.27586% with 1 line in your changes missing coverage. Please review.

Project coverage is 88.47%. Comparing base (8a50553) to head (7dec651).
Report is 47 commits behind head on main.

Files with missing lines	Patch %	Lines
pyomo/contrib/pyros/util.py	97.72%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3439      +/-   ##
==========================================
+ Coverage   88.19%   88.47%   +0.28%     
==========================================
  Files         880      880              
  Lines      100594   100639      +45     
==========================================
+ Hits        88715    89044     +329     
+ Misses      11879    11595     -284     

Flag	Coverage Δ
linux	86.19% <98.27%> (+0.01%)	⬆️
osx	76.20% <91.37%> (+0.01%)	⬆️
other	86.71% <98.27%> (+0.01%)	⬆️
win	84.66% <98.27%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jsiirola]

One question that should probably be addressed before merging. The other two are enhancements, but not strictly necessary.

[jsiirola]

Do you need to make sure that the Var has a value here? We allow Vars with lower == upper to be uncertain Params even if they don't have a current (numeric) value, correct?

[shermanjasonaf]

I do not believe we need to ensure the Var has a value here, as:

• The nominal value of the uncertain parameter represented by the Var was already obtained (accounting for the state of the Var) in util.validate_uncertainty_specification (see line 977 @ 7dec651)
• Immediately after this loop:
  • The previously obtained nominal value is used to initialize the newly constructed Param that is to be substituted for the Var
  • The Param is substituted for the Var, and (apart from cloning the Var when the working model is cloned) the Var is not subsequently used to set up subproblem components

[jsiirola]

Great! Thanks for clarifying