

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

I don't have matlab so I can't check if it is supposed to be like this.
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.


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.
I don't have matlab so I can't check if it is supposed to be like this.
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.


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: 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,
This also works without te signal pkg. step(ss(q))  DAS


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.
I don't have matlab so I can't check if it is supposed to be like this.
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.
try step(ss(q))
 DAS

Administrator

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?
>
>
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
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


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, 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.


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


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.
I don't have matlab so I can't check if it is supposed to be like this.
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.
try
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.
"

