Skip to content

set run_until as default behavior for mini - #281

Open
michaellans wants to merge 21 commits into
xopt-org:mainfrom
michaellans:run_until
Open

michaellans wants to merge 21 commits into
xopt-org:mainfrom
michaellans:run_until

Conversation

@michaellans

@michaellans michaellans commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

This PR features two main behavior changes, as well as performance improvements for starting and stopping:

Behavior Updates

  1. Updates run_until and termination_condition behavior to pause and open a popup when the condition is reached, giving the user a choice to end or continue.
    • Sets run_until with 100 iterations as the default play button behavior for the mini GUI
    • Clicking the main play button will skip the initial dialog, selecting "Run Until" from the run options menu will open the dialog to edit the termination condition
    • Updated run button tooltips and gui status messages to reflect termination condition status
Screenshot 2026-08-06 at 10 30 53 Screenshot 2026-09-10 at 11 47 30
  1. Adds 'Resume' as an option from the run options menu (side arrow on run button) and reimplements data loading for the mini GUI
    • 'Resume' will load the displayed data and generator parameters into a new optimization routine, and skip re-sampling initial points. If the selected vocs are incompatible with the displayed data, raises an error
    • Re-implemented the data loading feature for the mini GUI version
Screenshot 2026-09-10 at 11 56 55

GUI performance

  1. Xopt generator libraries were being imported for each new routine. Added imports for xopt.generators.sequential and xopt.generators.bayesian to routine.py so they are imported once on startup. This improves routine loading times from between 0.5 and 1 second to less than 0.02s

Previous:
Screenshot 2026-09-10 at 12 23 41
Screenshot 2026-09-10 at 12 23 05

Update:
Screenshot 2026-09-10 at 12 23 19
Screenshot 2026-09-10 at 12 23 27

  1. Blocked signals when the history_tree is updated after a routine is finished to avoid duplicate GUI updates. With faster stop/starting, I noticed that the GUI could get stuck if you stopped and then started a new routine very quickly.
  • Added a separate args_queue for subprocess startup args, so it's no longer reusing the data_and_error_queue. It seemed like this was causing the GUI to get stuck if a new routine was started too quickly, since the startup args and data/error could get mixed up in the same queue. All seems to work well with a separate args_queue for starting the routine.

@michaellans
michaellans marked this pull request as ready for review September 17, 2026 17:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant