Hi, I can't simulate complex systems at all with the step() or lsim() command. I have 5 own simulators and all of them can simulate so it is a little bit change that the control package can't manage it. Some code:
pkg load control
q=tf([ 1.46668928632582 38.5234944088261 1023.42433722006 18055.8729050165 275471.128598611 3680685.32154243 40413629.6869944 433109318.542883 3699840188.09672 32827566143.7738 225798332168.488 1689921426466.71 9494747382069.7 60613579740811.5 278626623858487 1.52747193482069e+15 5.6883783399098e+15 2.69067309068308e+16 7.92226372994905e+16 3.25360727881732e+17 7.2059792475876e+17 2.61175754638012e+18 3.8909506684981e+18 1.31637705830625e+19 9.12640045084024e+18 3.78290213329238e+19 1.41630594163597e+19 5.02932079881115e+19 1.29547036349465e+20 1.05983336007477e+19 2.43633391646665e+20 1.31208497581345e+19 1.04713601706961e+20 7.83465823853832e+18 ],[ 1 17.1698120499521 542.934121038049 7294.98595152311 126155.971925398 1377306.37948524 16829405.6386297 152789570.438515 1448656865.6342 11095921096.5808 85365123037.7488 556372911296.259 3555399791580.02 19799716986834.5 106353561602035 506292672690482 2.29624277698132e+15 9.31618125768562e+15 3.56349262092232e+16 1.22398996473335e+17 3.92373264437545e+17 1.12860046096021e+18 2.99632129507514e+18 7.09934073973815e+18 1.53176948230893e+19 2.91760427412351e+19 4.97010301791734e+19 7.33491370510952e+19 9.42777562297368e+19 1.01604047339533e+20 9.12510568398965e+19 6.44576522525933e+19 3.46367980244933e+19 1.23309424846899e+19 2.4145011614912e+18 ]);
step(q)
%lsim(q,ones(1,1001),[0:.01:10]) %another simulator, same result
am I asking too much that octave should be able to simulate a 34:th order system? I don't have matlab so I can't check if it is supposed to be like this.
Thanks for any input. 
Administrator

running those lines in Matlab 2020a: >> q=tf([ 1.46668928632582 38.5234944088261 1023.42433722006 18055.8729050165 275471.128598611 3680685.32154243 40413629.6869944 433109318.542883 3699840188.09672 32827566143.7738 225798332168.488 1689921426466.71 9494747382069.7 60613579740811.5 278626623858487 1.52747193482069e+15 5.6883783399098e+15 2.69067309068308e+16 7.92226372994905e+16 3.25360727881732e+17 7.2059792475876e+17 2.61175754638012e+18 3.8909506684981e+18 1.31637705830625e+19 9.12640045084024e+18 3.78290213329238e+19 1.41630594163597e+19 5.02932079881115e+19 1.29547036349465e+20 1.05983336007477e+19 2.43633391646665e+20 1.31208497581345e+19 1.04713601706961e+20 7.83465823853832e+18 ],[ 1 17.1698120499521 542.934121038049 7294.98595152311 126155.971925398 1377306.37948524 16829405.6386297 152789570.438515 1448656865.6342 11095921096.5808 85365123037.7488 556372911296.259 3555399791580.02 19799716986834.5 106353561602035 506292672690482 2.29624277698132e+15 9.31618125768562e+15 3.56349262092232e+16 1.22398996473335e+17 3.92373264437545e+17 1.12860046096021e+18 2.99632129507514e+18 7.09934073973815e+18 1.53176948230893e+19 2.91760427412351e+19 4.97010301791734e+19 7.33491370510952e+19 9.42777562297368e+19 1.01604047339533e+20 9.12510568398965e+19 6.44576522525933e+19 3.46367980244933e+19 1.23309424846899e+19 2.4145011614912e+18 ]); >> step(q) >> figure >> lsim(q,ones(1,1001),[0:.01:10]) produces the attached figures in MatlabControlOutput.png. All steps complete 'very quickly'. Trying to do the same in Octave 5.2.1 and Control 3.2.0, the step command takes a very long time, several times producing the following warning any time I bring focus to the plot window: warning: opengl_renderer: data values greater than float capacity. (1) Scale data, or (2) Use gnuplot same thing with the lsim command. if I try: >> graphics_toolkit('gnuplot') it runs, but the outputs are as attached in OctaveControlGnuplot.png so, there does seem to be some issue here. MatlabControlOutput.png (140K) Download Attachment OctaveControlGnuplot.png (151K) Download Attachment 
Thanks for the matlab test and pictures, I will create a bug report if I can upload your pictures without registering. I have the same behaviour in Octave.
Sent: Wednesday, June 10, 2020 at 12:37 AM
From: "Nicholas Jankowski" <[hidden email]> To: "GoSim GoSim" <[hidden email]> Cc: "Help GNU Octave" <[hidden email]>, "Doug Stewart" <[hidden email]> Subject: Re: control package, can't simulate complex systems
running those lines in Matlab 2020a:
>> q=tf([ 1.46668928632582 38.5234944088261 1023.42433722006 18055.8729050165 275471.128598611 3680685.32154243 40413629.6869944 433109318.542883 3699840188.09672 32827566143.7738 225798332168.488 1689921426466.71 9494747382069.7 60613579740811.5 278626623858487 1.52747193482069e+15 5.6883783399098e+15 2.69067309068308e+16 7.92226372994905e+16 3.25360727881732e+17 7.2059792475876e+17 2.61175754638012e+18 3.8909506684981e+18 1.31637705830625e+19 9.12640045084024e+18 3.78290213329238e+19 1.41630594163597e+19 5.02932079881115e+19 1.29547036349465e+20 1.05983336007477e+19 2.43633391646665e+20 1.31208497581345e+19 1.04713601706961e+20 7.83465823853832e+18 ],[ 1 17.1698120499521 542.934121038049 7294.98595152311 126155.971925398 1377306.37948524 16829405.6386297 152789570.438515 1448656865.6342 11095921096.5808 85365123037.7488 556372911296.259 3555399791580.02 19799716986834.5 106353561602035 506292672690482 2.29624277698132e+15 9.31618125768562e+15 3.56349262092232e+16 1.22398996473335e+17 3.92373264437545e+17 1.12860046096021e+18 2.99632129507514e+18 7.09934073973815e+18 1.53176948230893e+19 2.91760427412351e+19 4.97010301791734e+19 7.33491370510952e+19 9.42777562297368e+19 1.01604047339533e+20 9.12510568398965e+19 6.44576522525933e+19 3.46367980244933e+19 1.23309424846899e+19 2.4145011614912e+18 ]);
>> step(q) >> figure
>> lsim(q,ones(1,1001),[0:.01:10]) produces the attached figures in MatlabControlOutput.png. All steps complete 'very quickly'.
Trying to do the same in Octave 5.2.1 and Control 3.2.0, the step command takes a very long time, several times producing the following warning any time I bring focus to the plot window:
warning: opengl_renderer: data values greater than float capacity. (1) Scale data, or (2) Use gnuplot
same thing with the lsim command.
if I try:
>> graphics_toolkit('gnuplot')
it runs, but the outputs are as attached in OctaveControlGnuplot.png
so, there does seem to be some issue here.

In reply to this post by GoSim
I tried this pkg load signal [a,b,c,d] = tf2ss(q); step(ss(a,b,c,d)) representing high order systems in transfer function form is not a good idea in general. The pzmap of 'q' showed that the poles are all in the left half plane. That hinted that the coefficients are still probably good; which is why I tried converting to state space. If possible in your application, avoid transfer functions where the order is very high. Regards, 
On Wed, Jun 10, 2020 at 11:32 AM octavecontrib <[hidden email]> wrote:
This also works without te signal pkg. step(ss(q))  
In reply to this post by GoSim
On Tue, Jun 9, 2020 at 7:37 PM GoSim GoSim <[hidden email]> wrote:
step(ss(q)) 
Administrator

On Wed, Jun 10, 2020 at 12:40 PM Doug Stewart <[hidden email]> wrote:
well that seemed to do the trick. step(ss(q)) plots quickly in Octave, and it matches the output produced in Matlab by step(q) and step(ss(q)) so, thoughts on why octave needs it converted into statespace representation to avoid choking on it but Matlab doesn't? 
On 20200610 11:26, Nicholas Jankowski wrote:
> On Wed, Jun 10, 2020 at 12:40 PM Doug Stewart <[hidden email] > <mailto:[hidden email]>> wrote: > > try > step(ss(q)) > > > well that seemed to do the trick. step(ss(q)) plots quickly in Octave, > and it matches the output produced in Matlab by step(q) and step(ss(q)) > > so, thoughts on why octave needs it converted into statespace > representation to avoid choking on it but Matlab doesn't? > > q = tf(...) error: '__lti_input_idx__' undefined near line 211, column 211 error: called from tf at line 211 column 31 octave:70> ver  GNU Octave Version: 6.0.1 (hg id: ae94e3fad6d4) GNU Octave License: GNU General Public License Operating System: Linux 5.3.051generic #44~18.04.2Ubuntu SMP Thu Apr 23 14:27:18 UTC 2020 x86_64  Package Name  Version  Installation directory ++ control * 3.2.0  /home/tomdean/octave/control3.2.0 datasmoothing  1.3.0  /home/tomdean/octave/datasmoothing1.3.0 financial  0.5.3  /home/tomdean/octave/financial0.5.3 geometry  4.0.0  /home/tomdean/octave/geometry4.0.0 imageacquisition  0.2.2  /home/tomdean/octave/imageacquisition0.2.2 instrumentcontrol  0.5.0  /home/tomdean/octave/instrumentcontrol0.5.0 io  2.6.1  /home/tomdean/octave/io2.6.1 linearalgebra  2.2.3  /home/tomdean/octave/linearalgebra2.2.3 mapping  1.4.0  /home/tomdean/octave/mapping1.4.0 matgeom  1.2.2  /home/tomdean/octave/matgeom1.2.2 ocs  0.1.5  /home/tomdean/octave/ocs0.1.5 odebvp  1.0.6  /home/tomdean/octave/odebvp1.0.6 odepkg  0.9.1  /home/tomdean/octave/odepkg0.9.1 optim  1.6.0  /home/tomdean/octave/optim1.6.0 signal  1.4.1  /home/tomdean/octave/signal1.4.1 sockets  1.2.0  /home/tomdean/octave/sockets1.2.0 specfun  1.1.0  /home/tomdean/octave/specfun1.1.0 statistics  1.4.2  /home/tomdean/octave/statistics1.4.2 struct  1.0.16  /home/tomdean/octave/struct1.0.16 symbolic  2.9.0  /home/tomdean/octave/symbolic2.9.0 
On Wed, 20200610 at 11:37 0700, Thomas D. Dean wrote:
> On 20200610 11:26, Nicholas Jankowski wrote: > > On Wed, Jun 10, 2020 at 12:40 PM Doug Stewart <[hidden email] > > > > <mailto:[hidden email]>> wrote: > > > > try > > step(ss(q)) > > > > > > well that seemed to do the trick. step(ss(q)) plots quickly in > > Octave, > > and it matches the output produced in Matlab by step(q) and > > step(ss(q)) > > > > so, thoughts on why octave needs it converted into statespace > > representation to avoid choking on it but Matlab doesn't? > > > > > I get an error with this. > > q = tf(...) > > error: '__lti_input_idx__' undefined near line 211, column 211 > error: called from > tf at line 211 column 31 > This typically looks as if the control package was not installed with the currently running octave version. Torsten 
In reply to this post by nrjank
On Wed, 20200610 at 14:26 0400, Nicholas Jankowski wrote:
> On Wed, Jun 10, 2020 at 12:40 PM Doug Stewart <[hidden email]> > wrote: > > try > > step(ss(q)) > > > > > > well that seemed to do the trick. step(ss(q)) plots quickly in > Octave, and it matches the output produced in Matlab by step(q) and > step(ss(q)) > > so, thoughts on why octave needs it converted into statespace > representation to avoid choking on it but Matlab doesn't? I think the problem is that the discretization (which is done for the simulation) is not sufficiently accurate for a transfer function: # discretization of the state space model # => stable eigenvalues sys_ss_ct = ss (q); sys_dt2 = c2d (sys_ss_ct, 0.01); eig (sys_dt2.a) # discretization of the transfer function # unstable eigenvalues (lambda > 1) sys_tf_dt = c2d (q, 0.01); sys_dt1 = ss (sys_tf_dt); eig (sys_dt1.a) Torsten 
Administrator

On Wed, Jun 10, 2020 at 3:14 PM Torsten Lilge <[hidden email]> wrote: On Wed, 20200610 at 14:26 0400, Nicholas Jankowski wrote: curious about output differences, I've attached diaries for both octave and matlab running the eig commands above. they're different. not sure how much so and if that explains Octave failing to process the tf. 
On Wed, 20200610 at 15:50 0400, Nicholas Jankowski wrote:
> On Wed, Jun 10, 2020 at 3:14 PM Torsten Lilge <[hidden email]> > wrote: > > On Wed, 20200610 at 14:26 0400, Nicholas Jankowski wrote: > > > On Wed, Jun 10, 2020 at 12:40 PM Doug Stewart < > > [hidden email]> > > > wrote: > > > > try > > > > step(ss(q)) > > > > > > > > > > > > > > well that seemed to do the trick. step(ss(q)) plots quickly in > > > Octave, and it matches the output produced in Matlab by step(q) > > and > > > step(ss(q)) > > > > > > so, thoughts on why octave needs it converted into statespace > > > representation to avoid choking on it but Matlab doesn't? > > > > I think the problem is that the discretization (which is done for > > the > > simulation) is not sufficiently accurate for a transfer function: > > > > # discretization of the state space model > > # => stable eigenvalues > > sys_ss_ct = ss (q); > > sys_dt2 = c2d (sys_ss_ct, 0.01); > > eig (sys_dt2.a) > > > > # discretization of the transfer function > > # unstable eigenvalues (lambda > 1) > > sys_tf_dt = c2d (q, 0.01); > > sys_dt1 = ss (sys_tf_dt); > > eig (sys_dt1.a) > > > > > > > > curious about output differences, I've attached diaries for both > octave and matlab running the eig commands above. they're different. > not sure how much so and if that explains Octave failing to process > the tf. > Interesting. Does this mean that Matlab also has problems in discretizing a transfer function of such order (or am I doing something wrong when discretizing and then converting into state space)? Thus, a solution might just be to first convert into state space and then do the discretization. 
On Wed, 20200610 at 21:57 +0200, Torsten Lilge wrote:
> On Wed, 20200610 at 15:50 0400, Nicholas Jankowski wrote: > > On Wed, Jun 10, 2020 at 3:14 PM Torsten Lilge < > > [hidden email]> > > wrote: > > > On Wed, 20200610 at 14:26 0400, Nicholas Jankowski wrote: > > > > On Wed, Jun 10, 2020 at 12:40 PM Doug Stewart < > > > [hidden email]> > > > > wrote: > > > > > try > > > > > step(ss(q)) > > > > > > > > > > > > > > > > > > well that seemed to do the trick. step(ss(q)) plots quickly in > > > > Octave, and it matches the output produced in Matlab by step(q) > > > and > > > > step(ss(q)) > > > > > > > > so, thoughts on why octave needs it converted into statespace > > > > representation to avoid choking on it but Matlab doesn't? > > > > > > I think the problem is that the discretization (which is done for > > > the > > > simulation) is not sufficiently accurate for a transfer function: > > > > > > # discretization of the state space model > > > # => stable eigenvalues > > > sys_ss_ct = ss (q); > > > sys_dt2 = c2d (sys_ss_ct, 0.01); > > > eig (sys_dt2.a) > > > > > > # discretization of the transfer function > > > # unstable eigenvalues (lambda > 1) > > > sys_tf_dt = c2d (q, 0.01); > > > sys_dt1 = ss (sys_tf_dt); > > > eig (sys_dt1.a) > > > > > > > > > > > > > curious about output differences, I've attached diaries for both > > octave and matlab running the eig commands above. they're different. > > not sure how much so and if that explains Octave failing to process > > the tf. > > > > Interesting. Does this mean that Matlab also has problems in > discretizing a transfer function of such order (or am I doing > something > wrong when discretizing and then converting into state space)? Thus, a > solution might just be to first convert into state space and then do > the > discretization. Btw: In the meantime, there is a bug report ( https://savannah.gnu.org/bugs/index.php?58538) about this issue. Torsten 
In reply to this post by Doug Stewart4
Sent: Wednesday, June 10, 2020 at 6:40 PM
From: "Doug Stewart" <[hidden email]> To: "GoSim GoSim" <[hidden email]> Cc: "Nicholas Jankowski" <[hidden email]>, "Help GNU Octave" <[hidden email]> Subject: Re: control package, can't simulate complex systems On Tue, Jun 9, 2020 at 7:37 PM GoSim GoSim <[hidden email]> wrote:
step(ss(q))
DAS
I just wanted to thank the person who wrote to try what is written below, i can't see your email because i'm not on the list, i only saw it on nabble.
was annoying me that i didn't thank someone who helped me. Thank you, thank you.
"
pkg load signal
[a,b,c,d] = tf2ss(q);
step(ss(a,b,c,d)) representing high order systems in transfer function form is not a good idea in general.
The pzmap of 'q' showed that the poles are all in the left half plane. That hinted that the coefficients are still probably good; which is why I tried converting to state space.
If possible in your application, avoid transfer functions where the order is very high.

Free forum by Nabble  Edit this page 