octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #61061] [octave forge] (control) margin() and


From: Torsten Lilge
Subject: [Octave-bug-tracker] [bug #61061] [octave forge] (control) margin() and step() giving wrong results
Date: Thu, 19 Aug 2021 15:21:32 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36

Follow-up Comment #2, bug #61061 (project octave):

Thanks for the report. I can confirm the issue. After some debugging it turns
out that the call to __sl_td04ad__, a wrapper to the SLICOT Fortran function
TD04AD returns empty A, B and C matrices and D = 0. Passing a much lower
tolerance to __sl_td04ad__ leads to a non emtpy state space representation but
not to a reasonable step response.

When running 

bode (ax_eps, ax_0 logspace(5,35,1000))

one can see that this is a very special system which is approximated by ax_0
for lower frequencies. I guess that the poles at 10^31 rad/s are somehow
messing up the frequency range calculation in margin() and the state space
representation in step(). A solution might be to just ignore stable poles that
are more than 20 decades faster than the dominant poles.

Btw: The phase in bode() is only correct (no offset) when removing the zero
coefficients for s^1 and s^0 in numerator and denominator.
 

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61061>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]