Hi everyone,
I assume everyone is on holidays right now, yet any feedback on this issue would be precious:
The detailed error occurs both with forward() and backward() methods.
--->22PC['FO1'].backward()23print"LP Forward"24PC['FO1'].forward()/usr/lib/python2.7/site-packages/PyDSTool-0.90.2-py2.7.egg/PyDSTool/PyCont/Continuation.pycinbackward(self)1338self.CurveInfo=PointInfo()1339ifself.solisNone:->1340self._compute(v0=self.initdirec,direc=-1)1341self.sol=self._curveToPointset()1342/usr/lib/python2.7/site-packages/PyDSTool-0.90.2-py2.7.egg/PyDSTool/PyCont/Continuation.pycin_compute(self,x0,v0,direc)10481049ifsingular:->1050raisePyDSTool_ExistError("Problem in _compute: Failed to compute tangent vector.")1051#v0=zeros(self.dim,float)1052#v0=linalg.solve(r_[c_[J_coords,J_params],PyDSTool_ExistError:'Problemin_compute:Failedtocomputetangentvector.'
Thanks again.
Cheers,
M
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
SoIamlookingintothe`Continuation.py`rightnow.Therearesomevalueof`J_coords`andJ_params` that are `nan`s... but I cannot trace back where these latter vecs are computed exactly...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I assume this is related to an issue mentioned recently in another
forum post. The tolerances used to compute some types of data may not
have been sufficient to start computations of different kinds of
points using the previous as starting data. A naive attempt to fix
this would be to significantly strengthen the tolerances on the
computation of your original data before trying to continue the LPs.
So I am looking into the Continuation.py right now. There are some value
of J_coords and J_paramsthat arenan`s... but I cannot trace back where
these latter vecs are computed exactly...
PyDSTool_ExistError: 'Problem in _compute: Failed to compute tangent
vector.'
Thanks Rob.
Unfortunately it seems to be something more serious. I shrunk the tolerances to seek very stringent values and still, the computation fails. Note that i tried any combination of VarTol, FuncTol and TestTol from 1e-2 to 1e-10. So, ultimately I am reconstructing codim-2 curves from interpolations of several LP points obtained from a batch of equilibrium curves continued for a series of increasing values of the second bifurcation parameter. I cannot rule out however at this point that the problem in this case could raise from my equations, whose numerical behaviour may go wild in some parameter regimes...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear all,
what could be the reason (beyond singularity) and how could I avoid the error:
I computed an
EP-Cwhich contains twoLPs. and the above error comes up as soon as I selectLP1to continue from an trace aLP-C.I hope you could give me some insights.
Cheers,
M
Hi everyone,
I assume everyone is on holidays right now, yet any feedback on this issue would be precious:
The detailed error occurs both with
forward()andbackward()methods.Thanks again.
Cheers,
M
I assume this is related to an issue mentioned recently in another
forum post. The tolerances used to compute some types of data may not
have been sufficient to start computations of different kinds of
points using the previous as starting data. A naive attempt to fix
this would be to significantly strengthen the tolerances on the
computation of your original data before trying to continue the LPs.
On Thu, Aug 25, 2016 at 1:57 PM, Maurizio De Pitta'
mauriziodepitta@users.sf.net wrote:
Thanks Rob.
Unfortunately it seems to be something more serious. I shrunk the tolerances to seek very stringent values and still, the computation fails. Note that i tried any combination of
VarTol,FuncTolandTestTolfrom1e-2to1e-10. So, ultimately I am reconstructing codim-2 curves from interpolations of severalLPpoints obtained from a batch of equilibrium curves continued for a series of increasing values of the second bifurcation parameter. I cannot rule out however at this point that the problem in this case could raise from my equations, whose numerical behaviour may go wild in some parameter regimes...