Hi,
I strongly disagree - this is a huge advantage of relax in comparison
to the competition. If the optimisation space is simple and works
fine and quickly, then it serves no purpose. But there are a number
of distinct and important advantages that differentiates relax from
the rest:
- For some problems, optimisation can take a long, long time.
Therefore this gives feedback to the user as to what is happening, so
they don't think that relax has frozen. They can see if individual
steps are taking a long time or if many, many steps are required.
This allows the user, if they wish, to manually investigate the
optimisation space using dx.map and to really understand the problem.
The feedback this provides is invaluable for understanding the problem
and what relax is doing.
- When running in multi-processor mode, you can see how the
calculations are operating. There can be long pauses and then the
return of a set results, another long pause and then another set of
results. This is again important user feedback.
- The messages allow the user to create a multi-dimensional map of how
the optimisation has moved through the optimisation space, and then
superimpose this on the isosurfaces generated by the dx.map user
function.
- These messages can really help a user decide if a certain spin
system should not be used in an analysis.
- The messages are essential for understanding model failures. We
cannot know about such failures in advance. The user can then use the
messages to understand the problem. Many other strange things can and
do happen during optimisation, so being able to see what is happening
is extremely important.
As for faster operation with the messages turned off, this is only the
case when the calculations are very fast. For slower calculations and
the grid search, there is no significant speed up. This is also 100%
dependent on the terminal emulation program providing the prompt, or
the wxPython version of the wx.stc.StyledTextCtrl element used for the
logs in the GUI controller window, as well as how often the IO buffer
is flushed (this can be changed). If output to the terminal is turned
off, using '--log' or '>', then the speed difference goes away. The
slowest part of the analysis is the grid searches and the Monte Carlo
simulations anyway, and here none of these issues apply.
The relax philosophy is to present as much information to the user as
possible. If the user chooses to ignore it, that is their choice.
But for those who wish to understand, the can see everything. This is
in sharp contrast to other NMR software where the user feedback is
very limited. By presenting all this information, relax is operating
less as a black-box and users can learn a lot. A power user can turn
this off, but a normal user should see everything whether they
appreciate it or not.
Regards,
Edward
On 19 March 2014 13:48, Troels Emtekær Linnet <tlinnet@xxxxxxxxxxxxx> wrote:
I can say, that time for analysis drops after issuing verbosity=0
For 15 spins.
Model: 'R2eff', 'No Rex', 'DPL94', 'final'
GRID_INC = 11
MC_NUM = 10
MODSEL = 'AIC'
OPT_FUNC_TOL = 1e-15
verbosity=0
531.521u 0.120s 8:51.88 99.9% 0+0k 0+0io 0pf+0w
verbosity=1
663.138u 0.127s 11:15.87 98.1% 0+0k 0+0io 0pf+0w
You are saving 20% computational time.
2014-03-19 12:08 GMT+01:00 Troels Emtekær Linnet <tlinnet@xxxxxxxxxxxxx>:
Hi Edward.
The outcome from
grid_search(verbosity=1)
minimise(verbosity=1)
has newer proven to be of much value.
It actually clutters the log file, with lengthy information, which are
hard to debugger.
Would it be reasonable to give the auto analysis a stander of: verbosity=0
and pass that on to grid_search and minimise?
Best
Troels
_______________________________________________
relax (http://www.nmr-relax.com)
This is the relax-devel mailing list
relax-devel@xxxxxxx
To unsubscribe from this list, get a password
reminder, or change your subscription options,
visit the list information page at
https://mail.gna.org/listinfo/relax-devel
Re: Turning off verbosity of grid_search() and minimise() in auto_analysis