Skip to content

Simplify _Q_opt in parmest with block scenario structure.#3789

Open
sscini wants to merge 185 commits into
Pyomo:mainfrom
sscini:Q_opt-redesign
Open

Simplify _Q_opt in parmest with block scenario structure.#3789
sscini wants to merge 185 commits into
Pyomo:mainfrom
sscini:Q_opt-redesign

Conversation

@sscini
Copy link
Copy Markdown
Contributor

@sscini sscini commented Nov 20, 2025

Fixes # .

Summary/Motivation:

_Q_opt, the main model building and solving function within parmest, is still heavily dependent on MPISPPY, and the code is becoming outdated and difficult to interpret. The goal of this PR is to redesign _Q_opt to work without this dependence, retaining all the current functionality

Changes proposed in this PR:

-_Q_opt redesign, using a block structure, with minimal changes needed to functions that utilize it.

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.

@sscini
Copy link
Copy Markdown
Contributor Author

sscini commented Nov 20, 2025

@djlaky @adowling2 Here are my initial thoughts on the redesign. Please provide feedback on code layout to this point.

@sscini
Copy link
Copy Markdown
Contributor Author

sscini commented Nov 20, 2025

Dan and I had a good conversation today about the functional things needed in the redesign, and how to go about adding components to the overall block and sub-models. Working to implement changes, closely related to what is done currently in doe's _generate_scenario_blocks.

Copy link
Copy Markdown
Member

@adowling2 adowling2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice progress

Comment thread pyomo/contrib/parmest/parmest.py Outdated
@sscini
Copy link
Copy Markdown
Contributor Author

sscini commented Nov 25, 2025

@adowling2 @djlaky Added case for bootstrap, now works with theta_est, theta_est_bootstrap, and theta_est_leaveNout if I replace _Q_opt with _Q_opt_blocks. Please review.

I am aware of the duplicated code, but when I attempted to unify them using n_scenarios = len(self.exp_list) or len(bootlist), I am getting an error for bootstrap I am still working out.

Would we want to fully transition to using theta_est for obj and theta, and cov_est for covariance and add an error/warning? Or should I make it work to calculate cov if calc_cov=True?

Thanks!

@codecov
Copy link
Copy Markdown

codecov Bot commented Nov 30, 2025

Codecov Report

❌ Patch coverage is 87.62542% with 37 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.10%. Comparing base (68cefde) to head (c966bbc).
⚠️ Report is 28 commits behind head on main.

Files with missing lines Patch % Lines
pyomo/contrib/parmest/parmest.py 86.87% 37 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3789      +/-   ##
==========================================
- Coverage   90.10%   90.10%   -0.01%     
==========================================
  Files         904      904              
  Lines      107113   107110       -3     
==========================================
- Hits        96512    96507       -5     
- Misses      10601    10603       +2     
Flag Coverage Δ
builders 29.15% <3.67%> (+0.01%) ⬆️
default 86.42% <87.62%> (?)
expensive 35.25% <51.50%> (?)
linux 87.58% <87.62%> (-2.01%) ⬇️
linux_other 87.58% <87.62%> (+<0.01%) ⬆️
oldsolvers 28.10% <3.67%> (+<0.01%) ⬆️
osx 82.94% <87.62%> (+<0.01%) ⬆️
win 86.02% <87.62%> (-0.01%) ⬇️
win_other 86.02% <87.62%> (-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.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@sscini
Copy link
Copy Markdown
Contributor Author

sscini commented Dec 9, 2025

@adowling2 @djlaky Should I tag larger team on this? Please review when available. Thanks!

Copy link
Copy Markdown
Contributor

@mrmundt mrmundt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am confused about the usage of mock in the tests.

Comment thread pyomo/contrib/parmest/tests/test_parmest.py Outdated
Comment thread pyomo/contrib/parmest/tests/test_parmest.py Outdated
Comment thread pyomo/contrib/parmest/tests/test_parmest.py Outdated
@sscini sscini requested a review from mrmundt May 11, 2026 17:30
Comment thread pyomo/contrib/parmest/tests/test_parmest.py
@sscini
Copy link
Copy Markdown
Contributor Author

sscini commented May 11, 2026

@mrmundt Please rerun the one failing check. It failed really early.

@slilonfe5
Copy link
Copy Markdown
Member

@blnicho, @mrmundt, I think all of the review comments have been addressed. We would appreciate final comments if there are any, otherwise, I think this looks pretty good.

Copy link
Copy Markdown
Contributor

@mrmundt mrmundt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have two comments about what look like residual comments / blocks, but they aren't critical to remove.


if "BootList" in outer_cb_data:
bootlist = outer_cb_data["BootList"]
# print("debug in callback: using bootlist=",str(bootlist))
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably don't need this anymore but not critical to remove

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mrmundt This appears to be in the deprecated interface. Should this be done in a future PR?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Real failure-mode gap — fixed in 4964f915. Updated the Tailwind-bump risk mitigation:

MVP: one live kitchen-sink artifact at a stable URL. A bump rebuilds and re-publishes the same URL — every release picks up the new version on next render. We explicitly accept that an old release does NOT preserve prior-version visual fidelity if the upstream bump changes utility semantics; bump policy compensates via a regression-test sweep across representative sites before promoting the new version. This is acceptable because we control all the input (inspector only emits utilities we ship rules for) and a bump is a coordinated platform op.

Post-MVP: per-site compile produces a content-hashed artifact per release; the asset is retained as long as any release references it (retention-immune). The visitor's <link> can fall back to the current stable URL if a versioned URL 404s.

No more 404-unstyled-page failure mode in either era — MVP via stable URL, post-MVP via retention + fallback.

Comment on lines +2225 to +2237
"""
try:
instance = callback(scenario_tree_model, scen_name, node_names)
except TypeError: # deprecated signature?
try:
instance = callback(scen_name, node_names)
except:
print("Failed to create instance using callback; TypeError+")
raise
except:
print("Failed to create instance using callback.")
raise
"""
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also probably not needed?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mrmundt Similar comment here. As this is in the deprecated interface, should this be done in a future PR?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @mrmundt and @slilonfe5. In previous discussions, @blnicho and I agreed to use a separate PR to remove unused code and potentially update the deprecated interface. I will try removing this, but it might lead to new test failures in deprecated. Will happily discuss in the dev meeting today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

Status: Ready for design review

Development

Successfully merging this pull request may close these issues.

8 participants