View Issue Details

IDProjectCategoryView StatusLast Update
0000159ascendpygtk guipublic2010-02-24 18:28
Reporterjohn 
Assigned Tojohn 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version 
Summary0000159: No update of GUI while solver in process, need bintoken and compiler progress indicator
DescriptionAt 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?
TagsNo tags attached.

Relationships

related to 0000138 closedjohn standardised status reporting 
parent of 0000208 resolvedjohn Solver status callback system for GUI 
related to 0000400 resolvedjohn bintoken functionality broken 

Activities

ben

2005-12-23 10:32

manager   ~0000188

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.

john

2005-12-23 11:07

administrator   ~0000193

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.

ben

2005-12-26 23:08

manager   ~0000210

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.

john

2006-01-18 19:06

administrator   ~0000244

Fix in changeset 236.

Bug 208 is a followup bug for the solver status reporting.

john

2010-02-24 18:28

administrator   ~0000576

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.

Issue History

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