As analysis takes quite some time, it'll be helpful if there is a progress bar or progressing % showing. example: progress 1% progress 2% progress 3% . . . . . . progress 15% . . etc.
this feature will really help large problem. is it possible to integrate this feature into sfepy??? Thanks
Hi,
this is not possible in general, as we rely on external linear solvers (e.g. umfpack), that do not support this feature. A progress bar might be feasible for assembling, but that is in my experience only a minor part of the solving process - most of the time is spent in the linear solver.
r.
On 08/18/11 19:16, Md. Golam Rashed wrote:
As analysis takes quite some time, it'll be helpful if there is a progress bar or progressing % showing. example: progress 1% progress 2% progress 3% . . . . . . progress 15% . . etc.
this feature will really help large problem. is it possible to integrate this feature into sfepy??? Thanks
ok, i got it. it'd be very much helpful to have one. however, i'm seeking theory behind sfepy. can you help me in this regard? thanks.
On 08/19/11 18:39, Md. Golam Rashed wrote:
ok, i got it. it'd be very much helpful to have one. however, i'm seeking theory behind sfepy. can you help me in this regard? thanks.
Well, the theory is well described in any finite element textbook, and even on-line (e.g. the site Vladimir mentioned) - it's one of standard methods to solve PDEs (partial differential equations). SfePy implements the basic version without mesh adaptivity, and uses, for the moment, the most classical, Lagrangian, basis for polynomial approximation on elements.
If you are really interested in the actual implementation, currently the best way is to look at the source code in sfepy/fem, starting with sfepy/fem/problemDef.py where the ProblemDefinition class is defined. But before that, go through the tutorial (check especially "Sneak peek: what is going on under the hood" and "Interactive Example: Linear Elasticity" sections).
There is no real "user" documentation of sfepy.fem yet. It would be nice to have, but I do not have currently power to do it. But I can try to answer any particular question, so if you have any, ask... :)
r.
bugging you again, for a really fine mesh and a complex problem, it takes large amount of time by sfepy. and as you've mentioned earlier, a progress bar is not suitable for the external solver of sfepy. but i wonder what if an approximated solving time can be estimated from assembly. From the size of the matrix and the processing power of CPU, can a solving time estimation be made (+/- 10% error)???
On 12/24/2011 02:21 PM, Md. Golam Rashed wrote:
bugging you again, for a really fine mesh and a complex problem, it takes large amount of time by sfepy. and as you've mentioned earlier, a progress bar is not suitable for the external solver of sfepy. but i wonder what if an approximated solving time can be estimated from assembly. From the size of the matrix and the processing power of CPU, can a solving time estimation be made (+/- 10% error)???
Well, it really cannot be estimated reliably - the solution time depends heavily on the condition number of the matrix, and it is possible (as far as I recall), for a given matrix size and number of nonzeros, to generate a matrix with arbitrarily high condition number -> solution time from almost zero to infinity. So one could estimate time for a particular problem, e.g. Poisson, or elasticity, but there is no general way. Maybe sfepy could just print "solving..." so that you know you have to wait?
r.
well that would be nice, if all else is not possible. can you make the "solving..." statement a dynamic one? A 3 second loop, with each second "solving"+ 1 dot will be added, after 3 second loop will be restarted. again... It'll show us that the program is running and not hanged or stuck. thanks!
On 12/26/2011 02:39 PM, Md. Golam Rashed wrote:
well that would be nice, if all else is not possible. can you make the "solving..." statement a dynamic one? A 3 second loop, with each second "solving"+ 1 dot will be added, after 3 second loop will be restarted. again... It'll show us that the program is running and not hanged or stuck. thanks!
Well, the problem is that sfepy cannot print anything when the solver runs - it's still the same process. To do something dynamic like you want would mean use threading. I would rather avoid such complication.
To conclude: it's easy to print "solving..." before the solver starts (e.g. if the matrix size is big enough(?)), but nothing more.
Cheers, r.
well, the last thing we want is to make sfepy completed. so just include the print "solving..." statement.
correction: well, the last thing we want is to make sfepy complicated. so just include the print "solving..." statement.
On 12/28/11 18:02, Md. Golam Rashed wrote:
correction: well, the last thing we want is to make sfepy complicated.
Understood :)
so just include the print "solving..." statement.
I have added 'verbose' option to Solver class, i.e. base class of all solvers. Currently, only Newton solver uses it: add "'verbose' : True" to the nls.newton solver options, and it will print 'solving linear system...'.
r.
participants (2)
-
Md. Golam Rashed -
Robert Cimrman