fit verbosity
Karl Ratzsch
is there a way to decrease the verbosity of the fit command? I´ve
got a script that produces a fit.log > 2MB for each run, an i expect
it is slowed down a lot by letting all that run over the terminal.
The individual fits do usually converge in less that 20 steps, but
there are many, many data sets, unfortunately. Most of them are
redundant, of course, but it´s hard to know before evaluating them.
I expect it won´t be possible without patching!?
Another thing: Is there a way to catch a fit error (and restarting
the fit with new values afterwards automatically)?
Any suggesions would be welcome!
Regards,
Karl Ratzsch
sfeam
> Hello,
>
> is there a way to decrease the verbosity of the fit command?
Maybe "set fit log '/dev/null'" ?
> I´ve
> got a script that produces a fit.log > 2MB for each run, an i expect
> it is slowed down a lot by letting all that run over the terminal.
> The individual fits do usually converge in less that 20 steps, but
> there are many, many data sets, unfortunately. Most of them are
> redundant, of course, but it´s hard to know before evaluating them.
>
> I expect it won´t be possible without patching!?
>
> Another thing: Is there a way to catch a fit error (and restarting
> the fit with new values afterwards automatically)?
Not sure. Your could try
if ((GPVAL_ERRNO != 0) \
&& (GPVAL_ERRMSG eq "some error I'm trying to catch...")) \
do something
> Any suggesions would be welcome!
Please add your thoughts/comments to Tracker item 2355210
https://sourceforge.net/tracker/?func=detail&aid=2355210&group_id=2055&atid=102055
> Regards,
> Karl Ratzsch
Karl Ratzsch
> Karl Ratzsch wrote:
>
>> Hello,
>>
>> is there a way to decrease the verbosity of the fit command?
>
> Maybe "set fit log '/dev/null'" ?
Well, no. That just makes the logfile disappear. It still goes to the
shell. I´d like to keep the logfile, but get rid of the shell output. I
guess it should be possible to redirect stderr to /dev/null while
fitting, but not for the subjects of lord redmont ;-/.
That sf-tracker item proposed sending fit output to stdout instead of
sterr, but stdout is the plot terminal in gnuplot, as i get it from the
help, so that can´t work.
>> Another thing: Is there a way to catch a fit error (and restarting
>> the fit with new values afterwards automatically)?
>
> Not sure. Your could try
> if ((GPVAL_ERRNO != 0) \
> && (GPVAL_ERRMSG eq "some error I'm trying to catch...")) \
> do something
Well, yes. But the script stops before any error variable can be
evaluated, falling back to the (gp-)shell. I wanted to keep it running,
letting it take care of the error by itself.
Karl
Hans-Bernhard Bröker
> is there a way to decrease the verbosity of the fit command?
None short of building your own gnuplot from modified sources.
> I´ve got a script that produces a fit.log > 2MB for each run, an i
> expect it is slowed down a lot by letting all that run over the
> terminal.
So redirect it to a file. /dev/null if you really don't want to see it,
an actual file otherwise.
> Most of them are redundant, of course, but it´s hard to know before
> evaluating them.
That seems a strange statement to make. How can datasets "of course" be
redundant? And if they are: why the heck are you trying to fit curves
to them?
> Another thing: Is there a way to catch a fit error (and restarting
> the fit with new values afterwards automatically)?
I don't think so. You may be better of fitting only one file per
gnuplot invocation, so a single broken fit at least doesn't affect those
of the other data files.
Karl Ratzsch
> Karl Ratzsch wrote:
>
>> is there a way to decrease the verbosity of the fit command?
>
> None short of building your own gnuplot from modified sources.
>
>> I´ve got a script that produces a fit.log > 2MB for each run, an i
>> expect it is slowed down a lot by letting all that run over the
>> terminal.
>
> So redirect it to a file. /dev/null if you really don't want to see it,
> an actual file otherwise.
gnuplot scriptname >> /dev/null
? Ok, but doesn´t work for windows. Maybe I should install cygwin.
I´ve been running gnuplot interactively all the time, but probably
that´s not the right way for my job.
>
>> Most of them are redundant, of course, but it´s hard to know before
>> evaluating them.
>
> That seems a strange statement to make. How can datasets "of course" be
> redundant? And if they are: why the heck are you trying to fit curves
> to them?
I do measurements every 10 or 15 seconds, over hours. I could do
with a lot less, but i need them that dense a some point to catch
what i´m trying to see.
>
>> Another thing: Is there a way to catch a fit error (and restarting
>> the fit with new values afterwards automatically)?
>
> I don't think so. You may be better of fitting only one file per
> gnuplot invocation, so a single broken fit at least doesn't affect those
> of the other data files.
Yea, restarting is sort of pointless, as I´ve got so many datasets.
If one doesn´t fit, there is obviously something wrong with it, and
i should skip it. Gnuplot scripts stop at each error, and i wanted
it to go and and let it handle the error for itself, by restoring
the old parameter set, incrementing the meas. counter, and restarting.
But i see the error handling should probably be done outside gnuplot.
sfeam
> Gnuplot scripts stop at each error, and i wanted
> it to go and and let it handle the error for itself, by restoring
> the old parameter set, incrementing the meas. counter, and restarting.
I'm not following you here.
Why can't the gnuplot script catch and handle the error?
# callable script
# save current params
reset error
Asave = A
# do the fit
fit ... via A
# Catch error and restore parameters
if (GPVAL_ERRNO > 0) A = Asave
Hans-Bernhard Bröker
> Hans-Bernhard Bröker schrieb:
>> So redirect it to a file. /dev/null if you really don't want to see it,
>> an actual file otherwise.
> But how? You mean running the script like this?
>
> gnuplot scriptname >> /dev/null
Not quite. Rather like this:
gnuplot scriptname 2>/dev/null
(since fit messages go to stderr).
> ? Ok, but doesn´t work for windows.
As of version 4.4, it will. That comes with a console version that
allows full redirection.
