I made a new checkout and yes, everything is working now as in Matlab. Thanks!

The number of columns is equal to the number of equations being solved. You called init with a single column so only one equation was expected rather than the 11 in the expression [0:10].
Try this which has 3 equations and 5 timesteps.
odeplot ([0, 10], [1 2 3], 'init');
odeplot ([1;2;3;4;5], rand (3,5), []);
That still might fail in Octave unless you are at least up to 22683:340e37fd3c20.
I fixed the typo in the documentation on the stable branch (http://hg.savannah.gnu.org/hgweb/octave/rev/ce0f54b63923).

>So they are clear that when there are multiple times, y is a matrix with numel(t) rows and >with the number of columns equal to the number of equations being solved.
Are you sure? Matlab throws an error when using your description:
>> odeplot([0 10]',1,'init');
>> odeplot([0:10]',0:10,[]);
Error using odeplot (line 63)
Error updating the ODEPLOT window. Solution data may have been corrupted. Index exceeds matrix dimensions.
Another thing that is simple to cure: there is a typo in the docs that I noticed and had fixed: odeplot ([], [], "end") > odeplot ([], [], "done")
Seb.

plot() isn't recommended, even in Matlab, for usercreated OutputFcns. See https://www.mathworks.com/matlabcentral/newsreader/view_thread/296870.
The documentation for odeset (http://www.mathworks.com/help/matlab/ref/odeset.html) and the OutputFcn property says that
The solver calls status = myOutputFcn(t,y,[]) after each integration step for which output is requested. t contains points where output was generated during the step, and y is the numerical solution at the points in t. If t is a vector, then the ith column of y corresponds to the ith element of t.
So they are clear that when there are multiple times, y is a matrix with numel(t) rows and with the number of columns equal to the number of equations being solved.
It's easy enough to use all the points given as input rather than the first. I made that change on the development branch here (http://hg.savannah.gnu.org/hgweb/octave/rev/7c45d565d1b7). Interestingly, this gets us bugforbug compatible with Matlab as there is the funny line running back to the origin. I also changed the marker to 'o' from '.' since that is what I see in the pictures you posted. It is 31% slower to use that marker, but those are the breaks.

Sorry, my explanation was insufficient and two things got mixed up:
1. the current octave implementation of odeplot is not fully Matlab compatible. It only plots the last entry of the vectors given and Octave cares whether you supply row or column vectors. However, it's working in most cases but probably not if we implement "refine" in odeXY.
I have executed the following lines with Matlab, Octave with and without patch (see figures attached):
odeplot([0 10],[0;0],'init');
odeplot([0:10],[(0:10);(0:10).^2],[]);
odeplot([0:10],2*[(0:10);(0:10).^2],[]);
2. I made a new version that is slower but this is no surprise: it always plots the whole data (as Matlab does). Matlab seems to store the data persistently in odeplot and to concatenate the vectors in each call of odeplot. This can be seen in the attached figure "matlab.png". There is a straight line from (10,100) to (0,0). My implementation avoids this by using "hold on" and "hold off", so I am more memory efficient but not Matlabbugcompatible.
(file #38819, file #38820, file #38821)

Using plot is slow. I've attached the script I used for benchmarking as tst_odeplot.m.
Benchmark results:
Current fcn: 1.5 seconds
New fcn : 2.1 seconds
I don't see a reason to switch as most machines have gobs of memory. Even a system with 100 coupled ODEs evaluated at 1000 points consumes just 800 kB of memory.
However, if there is a visual difference we could adjust that. Octave is currently using the dot marker '.' and connecting them with a solid line ''. Could you run tst_odeplot.m in Matlab and then print out the resulting figure as a png file and attach it to this bug report?
(file #38818)

I don't say we need to fix this urgently before 4.2.0.

Jacopo and I have realized that odeplot is not fully Matlab compatible. Currently, it only adds a single point to the plot per call. I attach a new file that exploits "hold on" and hold off" such that there is no need to store data persistently (as Matlab seems to do it, too).
Sebastian
