Recent changes to tickets

Is there an online documentation?

George Datseris — Thu, 12 Mar 2026 09:26:14 -0000

Hi, I am trying to figure out if this software has an online documentation. The Wiki pages do not have any runnable code but point to the 2013 published book. Yet the releases page states in nearly every release that the new releases are fully documented. I am struggling to understand where this documentation exists. It cannot be in the textbook, as it was published before new releases.

Is the documentation only in the source code, which means you need to open the programming language, and press help, and then the function name? If this is the case, where is the list of all function names...?

Nowadays software documentation is typically online, in the same website that hosts the software source code (most frequently GitHub or GitLab). For users that are more of this generation like myself, I believe it would be worth it adding more comments about the documentation structure in the wiki overview page, particularly the "Documentation" subsection.

#67 sco_sym2funcs function-definition consistency error

Alexandra McKendry — Thu, 15 Jan 2026 22:11:06 -0000

Good catch - that was indeed the problem thank you. All working perfectly now. Thanks for your help!

#67 sco_sym2funcs function-definition consistency error

Jan Sieber — Thu, 15 Jan 2026 10:06:35 -0000

Dear Alex,
The debugging.zip was really helpful. When unpacking and running main, I got other errors:

Unrecognized function or variable 'F_coupled_Winfree'.

Error in sco_gen (line 46)
maxorder=fun('maxorder');

Error in coupled_Winfree_symbolic (line 31)
f = sco_gen(@F_coupled_Winfree,'');

Error in main (line 31)
funcs.field = coupled_Winfree_symbolic();

so, I had to add many paths:

addpath('./functions/symcoco/F_coupled_Winfree');
addpath('./functions/symcoco/F_VAR/');
addpath('./functions/symcoco/F_seg1/');
addpath('./functions/symcoco/F_seg2/');
addpath('./functions/symcoco/F_seg3/');
addpath('./functions/symcoco/F_seg4/');
addpath('./functions/symcoco/F_bcs_PO/');
addpath('./functions/symcoco/F_bcs_PR/');
addpath('./functions/symcoco/F_bcs_VAR/');

After adding these paths the ode45 call worked. I suspect that your error message comes because the ode45 uses a F_coupled_Winfree>F_coupled_Winfree_rhs_0 that is still hanging around from previous code generation attempts in a folder that is in the path. As the files you generate do not have conflicting names, you could use the option

'folder','./functions/symcoco'

for all your generated functions. Then all the generated files would be in this one folder, and you would not need to add so many paths. Could you try checking your paths?

#67 sco_sym2funcs function-definition consistency error

Alexandra McKendry — Thu, 15 Jan 2026 03:28:39 -0000

Thank you (and Jan) very much for your help, and for your quick response!

Your suggested solution works well. I have amended the functions to call sco_sym2funcs with the option 'multifile' set to 'true', and no longer encounter any errors in the symbolic code generation.

However, if I try to use the function

f = sco_gen(@F_coupled_Winfree,'')

with ode45, for example,

[t,x]=ode45(@(t,x)f(x,p0), [0 20*pi], [1;0; 1; 0]);

I now encounter the following error message:

Error using F_coupled_Winfree>F_coupled_Winfree_rhs_0
Too many input arguments.

Error in F_coupled_Winfree (line 32)
[varargout{:}]=f(varargin{2:end});

Error in sco_gen>fuwrap (line 141)
[out{:}]=fun(ext,order,uc{:},duc{:});

Error in sco_gen>dfdir_wrap (line 104)
    y=fuwrap(fun,0,u0);

Error in sco_gen>dfdirprep (line 97)
y=dfdir_wrap(fun,fmt,u0,udev,dims);

Error in sco_gen>@(varargin)dfdirprep(fun,fmt,varargin{:}) (line 59)
    fout=@(varargin)dfdirprep(fun,fmt,varargin{:});

Error in main (line 92)
[t,x]=ode45(@(t,x)f(x,p0), [0 20*pi], [1;0; 1; 0]);

Error in odearguments (line 92)
f0 = ode(t0,y0,args{:});   % ODE15I sets args{1} to yp0.

Error in ode45 (line 107)
  odearguments(odeIsFuncHandle,odeTreatAsMFile, solver_name, ode, tspan, y0, options, varargin);

Error in main (line 92)
[t,x]=ode45(@(t,x)f(x,p0), [0 20*pi], [1;0; 1; 0]);

I have attached the updated code, with the example call to ode45 in line 92 of the script 'main.m'.

Thanks again for your help.

Alex

#67 sco_sym2funcs function-definition consistency error

Harry Dankowicz — Thu, 15 Jan 2026 01:27:31 -0000

Dear Alex,

I forwarded your query to Jan Sieber (University of Exeter) who is the developer of symcoco. He shared the following (edited for clarity):

The outcome appears to depend on the version of Matlab used and does not occur with the version used by Jan.

The problem that you have encountered is mentioned in doc-src/symcoco-doc.pdf in the section that discusses inputs to sco_sym2funcs.

The symbolic code generation in the version used by you creates functions that sometimes include "end" and sometimes don't, depending on the complexity of the function created by the code and the creation of a subfunction to handle this complexity.

The only safe way (that should be version independent) is to call sco_symfuncs with the options 'multifile', true, and optionally (eg) 'folder','private' to put each created function into its own file, if desired into in a subfolder. The demo bistable in the symcoco contributed folder shows how this is done.

Please give this a try first and let us know if the problem persists, in which case we may recommend switching Matlab version, if possible.

Kind regards,

Harry

sco_sym2funcs function-definition consistency error

Alexandra McKendry — Wed, 14 Jan 2026 22:22:31 -0000

Hello,

I have been using the 'sco_sym2funcs' function to generate CoCo-compatible symbolic function encodings for my project and have run into the following error message when attempting to generate the function 'F_VAR.m' in line 67 of the attached code 'coupled/main.m':

Error: File: F_VAR.m Line: 1642 Column: 1
The function "ft_1" was closed with an 'end', but at least one other function definition was not. To avoid
confusion when using nested functions, it is illegal to use both conventions in the same file.

Error in sco_gen (line 46)
maxorder=fun('maxorder');

Error in sco_sym2funcs (line 151)
    outstruc.fout=sco_gen(str2func(funcname));

Error in VAR_symbolic (line 76)
  F_coco = sco_sym2funcs(F_seg, {u_vec, p_vec}, {'x', 'p'}, 'filename', filename_out);

Error in main (line 67)
funcs.VAR = VAR_symbolic(xdim, pdim, @coupled_Winfree_symbolic_field);

I have used sco_sym2funcs on several other symbolic vector fields other than the 'coupled/functions/fields/coupled_Winfree_symbolic_field.m' used in the attached code without encountering any errors. For example, I have also attached a function 'single/functions/fields/Winfree_symbolic_field.m' from which the function 'F_VAR.m' is generated without any issues in line 67 of the attached code 'single/main.m'.

It therefore seems to be an issue originating from the symbolic function generated by the 'coupled_Winfree_symbolic_field.m' function.

The error message does not occur consistently; I have managed to run the script 'coupled/main.m' and successfully generate 'F_VAR' once, and a colleague has also been able to do so without encountering any errors.

I am using the latest release of COCO (January 28, 2025) and MATLAB R2022b.

Any advice would be greatly appreciated. If there is any other information you need, please just let me know.

Thanks,

Alex

#57 Detection and continuation of extrema of user-defined monitor functions

Joseph Paez Chavez — Tue, 02 Sep 2025 15:38:44 -0000

Dear Harry, many thanks for the soon reply, the code have been now adapted according to your advice.

Kind regards and thanks,
Joseph

#57 Detection and continuation of extrema of user-defined monitor functions

Harry Dankowicz — Tue, 02 Sep 2025 13:02:26 -0000

Thank you, Joseph, for the question.

The most recent release of COCO provides new general-purpose support for generic branch switching (that was originally motivated by and is compatible also with analysis of symmetry-breaking bifurcations in dynamical systems with symmetries). As a result, constructors of the form ===BP2TYPE have all been deprecated in favor of the corresponding ===TYPE2TYPE constructor and the assignment of 'switch' to the 'branch' property of the 'cont' settings.

You can find examples of this in the tutorial documentation and demos. For example, in EP_Tutorial.pdf on pages 10, 14, 26, and as described on page 33; in COLL-Tutorial.pdf on page 33 and as described on page 43; in PO-Tutorial.pdf on pages 14 and 38, and as described on page 51; in CORE-Tutorial.pdf on pages 8, 13, and 20; and in GettingStartedwithCOCO.pdf on pages 5, 7, 26.

This change eliminates the need for separate constructors for generic branch switching.

I hope that helps.

/Harry

#57 Detection and continuation of extrema of user-defined monitor functions

Joseph Paez Chavez — Tue, 02 Sep 2025 12:42:21 -0000

Dear Harry, with the kind help of one of your former PhD students we were able to use the adjt_isol2hspo constructor to tackle the problem described in this post. However, during the continuation runs we get the following warning:

Warning: Use of ADJT_BP2COLL is deprecated. Reset 'branch' property

In adjt_BP2coll (line 45)
In adjt_BP2bvp (line 58)
In adjt_BP2hspo (line 53)

And similarly for ADJT_BP2HSPO, ODE_BP2COLL and ODE_BP2BVP. Does the warning mean that the code may not run in future COCO releases? I would like to know if there is any way to avoid such warnings.

Kind regards and thanks,
Joseph

#66 Stop Continuation at Special Point

Harry Dankowicz — Mon, 11 Aug 2025 13:08:21 -0000

I am thinking of an example where the family of solutions lies on a circle with two fold points at either extreme. The default atlas algorithm then keeps going around and around, since it has no memory of the parts of the atlas that have been covered previously.

An alternative is the atlas-kd algorithm, which does retain such a memory (it is similar to the advancing front algorithm in Recipes for Continuation). To switch atlas algorithm, use coco_set(prob, 'cont', 'atlas', 'kd').

Best,

Harry