View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000159 | ascend | pygtk gui | public | 2005-12-09 18:04 | 2010-02-24 18:28 |
| Reporter | john | ||||
| Assigned To | john | ||||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | |||||
| Target Version | Fixed in Version | ||||
| Summary | 0000159: No update of GUI while solver in process, need bintoken and compiler progress indicator | ||||
| Description | At present, the GUI just hangs while the solver is working and while the bintokens are being compiled. There should be a graphical indication of what is happening: 1. status bar should say "Compiling C-code version of equations..." 2. status bar should say "Solving..." If it's possible to show a status bar for the solution, that would be good. Perhaps as a fraction of the maximum number of iterations combined with the total residual or something like that? | ||||
| Tags | No tags attached. | ||||
|
|
Bear in mind that, particularly in the case of gui updates during solving, there's no free lunch. Stopping to issue status messages makes a *tremendous* slowdown in the math. We have control settings in the tickle gui to let the user tune how often they get 'feedback' while solving; a feature worth stealing. |
|
|
Reminder sent to: ben I thought here that a light-weight callback function inside the solver might be possible. At the end of each iteration, or at the end of every 'n' iterations, the callback could be made. Then, the GUI code could decide if it wanted to do a GUI update or not, perhaps after first checking that a second or two had elapsed on the wallclock. I'll have a look at the tcl stuff and see how it works on this. |
|
|
To summarize, the heart of the gui(tickle) solve implementation (Solve_Solve) is a loop calling slv_iterate and checking the status on return instead of calling on slv_solve (which is "go away until done"). slv_iterate takes as an argument the number of steps specified from user input to take before returning. If ctrl-c is detected slv_iterate will return early. |
|
|
Fix in changeset 236. Bug 208 is a followup bug for the solver status reporting. |
|
|
Some solvers do not implement the means for a 'multi-step' solution process. They provide single-step solution, but with a mechanism for status callbacks. With sensible timer/interval checking, status feedback to the GUI could be managed without excessive GUI overhead. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-12-09 18:04 | john | New Issue | |
| 2005-12-09 18:04 | john | Status | new => assigned |
| 2005-12-09 18:04 | john | Assigned To | => john |
| 2005-12-21 17:02 | john | Relationship added | related to 0000138 |
| 2005-12-23 10:32 | ben | Note Added: 0000188 | |
| 2005-12-23 11:07 | john | Note Added: 0000193 | |
| 2005-12-26 23:08 | ben | Note Added: 0000210 | |
| 2006-01-18 19:06 | john | Status | assigned => resolved |
| 2006-01-18 19:06 | john | Resolution | open => fixed |
| 2006-01-18 19:06 | john | Note Added: 0000244 | |
| 2006-02-07 13:17 | john | Target release | => 1.0 |
| 2008-02-10 13:04 | john | Status | resolved => closed |
| 2009-05-26 10:08 | john | Relationship added | parent of 0000208 |
| 2010-02-24 18:26 | john | Relationship added | related to 0000400 |
| 2010-02-24 18:28 | john | Note Added: 0000576 |
