[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-patch-tracker] [patch #8778] Control pkg: improvement of lti/ss/
[Octave-patch-tracker] [patch #8778] Control pkg: improvement of lti/ss/freqresp numerics, possibly also a way to better ss2tf
Thu, 22 Oct 2015 17:08:24 +0000
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.2.0
Summary: Control pkg: improvement of lti/ss/freqresp
numerics, possibly also a way to better ss2tf
Project: GNU Octave
Submitted by: None
Submitted on: Thu 22 Oct 2015 05:08:23 PM UTC
Priority: 5 - Normal
Assigned to: None
Originator Email: Marek Peca <address@hidden>
Discussion Lock: Any
during my work on atomic clock ensembling, which uses a lot of Control
toolbox, I have encountered grave numerical errors during plotting of
state-space (@lti/@ss) Bode plots, traced to __freqresp__.m.
In MATLAB it gave good plots out of the same data. I haven't looked into
MATLAB and not into a SLICOT and tried a fix using high-level algebraic
functions. Original __freqresp__ uses a textbook formula for on-the-fly
transformation of ss LTI system into an operator transfer function, i.e. c*
(e*s - a)^-1 *b, where e is identity for regular systems, and something for
Here, the matrix inverse yielded a lot of rcond warnings. Although I can
agree, that my system is "ugly", and there might be lot of nearly cancelling
modes, it turned out to be possible to fix freqresp by calling
eigendecomposition first, and then to just fiddle with inversions on diagonal.
Besides the more stable behaviour, it shall be much faster, where there are
(typically) lots of frequency points to evaluate.
I am attaching my test data, together with new freqresp and test script
What I have not done:
1. support for stiff systems: I can not imagine the function for case of
non-identity e; however, stiff systems are rare enough, so in worst case a
revert to old formula could be used;
2. it seems to me silly to call C*diag(..)*D, but I am unsure about internal
optimizations, JIT etc., so I do not know, whether to use this, for cycles, or
something else to get fastest result.
Besides the ss/freqresp function, it may be interesting to consider
improvement of ss2tf, ss2zpk conversions. It seems, that these functions are
outsourced to some SLICOT code (in what I do not dare to even look). Freqresp
using these converted systems are even much worse, than the original.
It seems to me, that the conversion into tf & zpk respectively could be better
made by the same eigendecomposition, which I have used for freqresp. But I am
not so experienced LTI guru to imagine all possible scenarios, I mean, whether
the SLICOT ones could be better in some situation (but I doubt it could).
Any advanced appreciated.
Date: Thu 22 Oct 2015 05:08:23 PM UTC Name: lti_ss_freqresp_improve.png
Size: 88kB By: None
Date: Thu 22 Oct 2015 05:08:23 PM UTC Name: lti_ss_xfer_improve.tar.gz Size:
12kB By: None
Reply to this item at:
Message sent via/by Savannah
|[Prev in Thread]
||[Next in Thread]|
- [Octave-patch-tracker] [patch #8778] Control pkg: improvement of lti/ss/freqresp numerics, possibly also a way to better ss2tf,