I'm trying to do continuation analysis on a dynamical model including auxiliary variables (i.e. defined explicitly from the state variables), which I would like to track during the continuation analysis.
I successfully implemented my system in PyDSTool and I can compute the trajectory using the Dopri integrator.
However, I get a compile error when trying to compile the Auto lib in the PyCont toolbox.
The problem come from my auxiliary variables, which are used in my rhs expression but are undefined in the generated source file.
When comparing the C-source code generated for the Dopri integrator and the one for the Auto lib, "#define" corresponding to the auxvars at the beginning of the file are missing in the auto source code.
The reason is that the following lines are "missing" in the ContClass.py code.
See Dopri_ODEsystem.py (l. 565) and ContClass.py (l. 544).
Is there a reason for the Auto lib not supporting auxiliary variables in the model? Is it a missing feature or does it work but I'm defining my model the wrong way?
Best,
Florian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting. I don't know why that wasn't included in ContClass.py. There might be a problem with getting them calculated during continuation, as we had to write our own code to post-calculate all their values after Dopri/Radau finished integration of the dynamic variables. That's why the RHS cannot depend on aux vars. What happened when you added this to PyCont? It might be that we can similarly add the post-processing for the aux vars but that also means they won't be available internally to PyCont as it continues. I assume by "track" you just mean informally by you in the output of PyCont?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, by "tracking" I meant output their values in PyCont and being able to plot them as we plot state variables.
I added the "#define" to PyCont and the continuation seems to work properly ( i.e. I could compute the Limit Cycle Curve, which needs Auto Lib).
However I cannot plot the auxiliary variables using the curves' "display" function.
Should I create a PR with the code for including the auxvars "#define" code?
It is just a minor change I would say.
Interestingly, the function "auxvars" containing the definition of the auxiliary variable was already being generated. I guess this is the post-processing function you are talking about, isn't it?
Do you have an idea of where the code should be modified in order to apply this post-calculation to the aux vars? Or at least where is, in the Dopri/Radau integration, the call to the post-procesing done?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Right, they are not being calculated in the post-processing. I'm not familiar with Drew's interface to AUTO, but in Dopri it's done like this: line 91 of integrator/dop853mod.c calls AuxVarCalc, passing the main data structure for the integration. This function is in integration.c, line 6. It gets a little tricky because any "external input" values must be filled in at the appropriate times. Then, the user-defined auxvars function is finally called. The closest equivalent to the wrapper for AUTO is in PyCont/auto/module/include/automod.c, where a similar data structure is used to contain all the parameters and settings. However, you want auxvars to be defined whether or not AUTO is invoked, so maybe an easier approach (although less efficient if using AUTO) is to do the post-processing in python. A model for doing that is already present in Generator/Euler_ODEsystem.py (line 169 then at 194) which is happening per step inside the integration loop.
There would have to be a new method for calculating auxvars called after self._compute in the Continuation class' forward and backward methods. The setup and context is not quite the same as for an ODE integrator so be careful to compute the auxvars only when the code has decided what the correct set of new solution points are (self.new_sol_segment). The new method would create a new array in the same way that the Curve class has a 'sol' solution attribute that grows as continuation proceeds. You'd loop over the times and points of the new solution points and fill in the new solution pointset with auxvar values. The 'sol' pointset will have to have all the var and auxvar coordinate names set up at its inception. Currently, that happens at line 1245 of Continuation.py with self._curveToPointset(). In that method, note that by adding self.auxvars (if that's even currently defined) to totlen you also have to do one of the following:
1) pre-allocate space in the self.curve array (line 1068 uses self.dim which would have to be self.dim+len(self.auxvars) as self.dim must stay as is) so that line 1763 does not fail. This will probably have unwanted side-effects elsewhere in the core code and I don't like this approach.
2) It might be better to leave self.curve as is, and make line 1763 check the shape of self.curve and add on the # aux vars there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had a brief look at the source code and I am no longer sure it is possible to post-calculate the auxiliary variables.
I'm quite novice with Auto and PyDSTool, so correct me if I'm wrong.
In case of limit cycles (LC-C curve) only "Solution measures" values (Max, min or avg) of the state variables are known when exiting Auto. The full limit cycles are known only for some specific points (bifurcations and some regular points) along the branch.
Since these "solution measures" are not necessarily at the same position on the limit cycle, computing the aux vars from them is impossible.
Moreover, doing the postcalculation in python could have been problematic, since the function evaluating the aux vars could be defined in C only in case of a C-integrator.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, everyone. Sorry I'm late to the conversation. I agree that post-calculation is impossible due to the reasons you stated, Florian. I have to admit it's been ages since I've delved into the AUTO code (it is a beast!). My (possible incorrect) understanding is that I just didn't implement calculation of auxiliary variables in AUTO, although it certainly should be! I'll take a look as well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry this will be too much for me, since I do not have enough knowledge of Auto and PyDSTool to go that deep in the code.
In the end, I will "track" only the state variables and compute the auxiliary variables from the full limit cycle only at specific point along the continuation curve.
As I understood the full limit cycle are saved for bifurcations points and Regular Points.
Is there a way to ask PyCont to compute the full limit cycle for a given point on the continuation curve? For example by specifying where a Regular Point should be placed other than using the NumSPOut parameters?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry this will be too much for me, since I do not have enough knowledge of Auto and PyDSTool to go that deep in the code.
In the end, I will "track" only the state variables and compute the auxiliary variables from the full limit cycle only at specific point along the continuation curve.
As I understood the full limit cycle are saved for bifurcations points and Regular Points.
Is there a way to ask PyCont to compute the full limit cycle for a given point on the continuation curve? For example by specifying where a Regular Point should be placed other than using the NumSPOut parameters?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just wanted to revive this thread, since having Auto computing the auxiliary variable along the limit cycle curve would definitively be a nice feature.
However I guess this might take some time to implement. In between, it would be worth to at least fix the compile error corresponding to the aux variables (i.e. the #define lines not being set when generating the auto source file).
I already fixed it for me locally, should I open a PR for this?
Best,
Florian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, Florian. I am planning on diving into the AUTO code soon to implement tracking of codim-1 bifurcation curves for limit cycles and fix the current bug on solution measures. I can take a look at this issue while I'm in there as well.
Regarding the PR, can you do a PR with my fork? (https://github.com/mdlama/pydstool) I think Rob would want me to look over your code anyways, so this might be a more direct approach. Once merged, I'll put in a PR with the main repo.
Thanks, Florian!
Drew
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm trying to do continuation analysis on a dynamical model including auxiliary variables (i.e. defined explicitly from the state variables), which I would like to track during the continuation analysis.
I successfully implemented my system in PyDSTool and I can compute the trajectory using the Dopri integrator.
However, I get a compile error when trying to compile the Auto lib in the PyCont toolbox.
The problem come from my auxiliary variables, which are used in my rhs expression but are undefined in the generated source file.
When comparing the C-source code generated for the Dopri integrator and the one for the Auto lib, "#define" corresponding to the auxvars at the beginning of the file are missing in the auto source code.
The reason is that the following lines are "missing" in the ContClass.py code.
See Dopri_ODEsystem.py (l. 565) and ContClass.py (l. 544).
Is there a reason for the Auto lib not supporting auxiliary variables in the model? Is it a missing feature or does it work but I'm defining my model the wrong way?
Best,
Florian
Interesting. I don't know why that wasn't included in ContClass.py. There might be a problem with getting them calculated during continuation, as we had to write our own code to post-calculate all their values after Dopri/Radau finished integration of the dynamic variables. That's why the RHS cannot depend on aux vars. What happened when you added this to PyCont? It might be that we can similarly add the post-processing for the aux vars but that also means they won't be available internally to PyCont as it continues. I assume by "track" you just mean informally by you in the output of PyCont?
Yes, by "tracking" I meant output their values in PyCont and being able to plot them as we plot state variables.
I added the "#define" to PyCont and the continuation seems to work properly ( i.e. I could compute the Limit Cycle Curve, which needs Auto Lib).
However I cannot plot the auxiliary variables using the curves' "display" function.
Should I create a PR with the code for including the auxvars "#define" code?
It is just a minor change I would say.
Interestingly, the function "auxvars" containing the definition of the auxiliary variable was already being generated. I guess this is the post-processing function you are talking about, isn't it?
Do you have an idea of where the code should be modified in order to apply this post-calculation to the aux vars? Or at least where is, in the Dopri/Radau integration, the call to the post-procesing done?
Right, they are not being calculated in the post-processing. I'm not familiar with Drew's interface to AUTO, but in Dopri it's done like this: line 91 of integrator/dop853mod.c calls AuxVarCalc, passing the main data structure for the integration. This function is in integration.c, line 6. It gets a little tricky because any "external input" values must be filled in at the appropriate times. Then, the user-defined auxvars function is finally called. The closest equivalent to the wrapper for AUTO is in PyCont/auto/module/include/automod.c, where a similar data structure is used to contain all the parameters and settings. However, you want auxvars to be defined whether or not AUTO is invoked, so maybe an easier approach (although less efficient if using AUTO) is to do the post-processing in python. A model for doing that is already present in Generator/Euler_ODEsystem.py (line 169 then at 194) which is happening per step inside the integration loop.
There would have to be a new method for calculating auxvars called after self._compute in the Continuation class' forward and backward methods. The setup and context is not quite the same as for an ODE integrator so be careful to compute the auxvars only when the code has decided what the correct set of new solution points are (self.new_sol_segment). The new method would create a new array in the same way that the Curve class has a 'sol' solution attribute that grows as continuation proceeds. You'd loop over the times and points of the new solution points and fill in the new solution pointset with auxvar values. The 'sol' pointset will have to have all the var and auxvar coordinate names set up at its inception. Currently, that happens at line 1245 of Continuation.py with self._curveToPointset(). In that method, note that by adding self.auxvars (if that's even currently defined) to totlen you also have to do one of the following:
1) pre-allocate space in the self.curve array (line 1068 uses self.dim which would have to be self.dim+len(self.auxvars) as self.dim must stay as is) so that line 1763 does not fail. This will probably have unwanted side-effects elsewhere in the core code and I don't like this approach.
2) It might be better to leave self.curve as is, and make line 1763 check the shape of self.curve and add on the # aux vars there.
Thanks for the information.
I'll have a look at it and come back to you.
I had a brief look at the source code and I am no longer sure it is possible to post-calculate the auxiliary variables.
I'm quite novice with Auto and PyDSTool, so correct me if I'm wrong.
In case of limit cycles (LC-C curve) only "Solution measures" values (Max, min or avg) of the state variables are known when exiting Auto. The full limit cycles are known only for some specific points (bifurcations and some regular points) along the branch.
Since these "solution measures" are not necessarily at the same position on the limit cycle, computing the aux vars from them is impossible.
Moreover, doing the postcalculation in python could have been problematic, since the function evaluating the aux vars could be defined in C only in case of a C-integrator.
Hi, everyone. Sorry I'm late to the conversation. I agree that post-calculation is impossible due to the reasons you stated, Florian. I have to admit it's been ages since I've delved into the AUTO code (it is a beast!). My (possible incorrect) understanding is that I just didn't implement calculation of auxiliary variables in AUTO, although it certainly should be! I'll take a look as well.
Sorry this will be too much for me, since I do not have enough knowledge of Auto and PyDSTool to go that deep in the code.
In the end, I will "track" only the state variables and compute the auxiliary variables from the full limit cycle only at specific point along the continuation curve.
As I understood the full limit cycle are saved for bifurcations points and Regular Points.
Is there a way to ask PyCont to compute the full limit cycle for a given point on the continuation curve? For example by specifying where a Regular Point should be placed other than using the NumSPOut parameters?
Sorry this will be too much for me, since I do not have enough knowledge of Auto and PyDSTool to go that deep in the code.
In the end, I will "track" only the state variables and compute the auxiliary variables from the full limit cycle only at specific point along the continuation curve.
As I understood the full limit cycle are saved for bifurcations points and Regular Points.
Is there a way to ask PyCont to compute the full limit cycle for a given point on the continuation curve? For example by specifying where a Regular Point should be placed other than using the NumSPOut parameters?
Hi everyone,
I just wanted to revive this thread, since having Auto computing the auxiliary variable along the limit cycle curve would definitively be a nice feature.
However I guess this might take some time to implement. In between, it would be worth to at least fix the compile error corresponding to the aux variables (i.e. the #define lines not being set when generating the auto source file).
I already fixed it for me locally, should I open a PR for this?
Best,
Florian
Hi, Florian. I am planning on diving into the AUTO code soon to implement tracking of codim-1 bifurcation curves for limit cycles and fix the current bug on solution measures. I can take a look at this issue while I'm in there as well.
Regarding the PR, can you do a PR with my fork? (https://github.com/mdlama/pydstool) I think Rob would want me to look over your code anyways, so this might be a more direct approach. Once merged, I'll put in a PR with the main repo.
Thanks, Florian!
Drew
Hi Drew,
yes, that would be great if the auxiliary variables would be computed in Auto.
Meanwhile, the PR I just did enables the continuation to work for systems containing auxiliary variables, without saving their values along the curve.
Best,
Florian
Awesome, thanks, FLorian. I'll pull it soon.
Drew