I tried to continue an initial orbit, but cannot get the attached script to work. I get the following message:
STEP DAMPING NORMS COMPUTATION TIMES
IT SIT GAMMA ||d|| ||f|| ||U|| F(x) DF(x) SOLVE
0 5.90e-002 5.55e+001 0.0 0.0 0.0
1 1 1.00e+000 2.28e-001 3.47e-004 5.54e+001 0.0 0.0 0.0
2 1 1.00e+000 1.17e-003 1.33e-008 5.54e+001 0.0 0.0 0.0
3 1 1.00e+000 8.38e-008 1.12e-014 5.54e+001 0.0 0.0 0.0
warning: AtlasBase: initial point is outside computational domain
active boundary or terminal constraints were: MXCL
STEP TIME ||U|| LABEL TYPE F
0 00:00:00 5.5430e+001 1 EX 5.3044e-004
Also if I widen the range for F to [-0.1 0.3] I still get the warning that the initial point is outside the computational domain.
Am I doing something wong?
Thank you
Egbert
This warning occurs, because the estimated error of the initial orbit discretisation is larger than the tolerance, hence, outside the computational domain. At the moment, one needs to set a sufficiently large value for NTST manually.
We plan to change this behavior in the future; see also [#12] and [#13].
Related
Tickets:
#12Tickets: #13
Thanks a lot for your fast reply. Indeed that worked (esp if I lowered the tolerance).. You could consider to change this error message as (at least for me) it was not clear that the program had problems with discretising the orbit. I thought it went outside of the user-defined range of the continuation parameter (which I interpreted as the domain)
Best wishes
Egbert
I was thinking about that for a while now, because this warning message is bugging me as well. Unfortunately things are not that simple. I would like to have a message that includes a hint what one can do about it. However, this would need to be defined in a toolbox, whereas the current message is generated in the core, which does not have sufficient information. A good solution should solve this and other cases and I simply don't have one yet. I don't want to overcomplicate toolboxes.
I will collect this with other related tickets: [#20], [#23]. For now, I will add a description of certain messages and what to do to a user short reference I plan to write soon. For the future, please collect further messages that are not easy to understand, either as a comment below or a new ticket.
Related
Tickets: #20
Tickets: #23
Thanks I understand the tradeoff of being generic and specific. Maybe the toolboxes can optionally use try/catch/rethrow to improve the error messages? I will collect other things that I find hard to understand.
Thank you, Egbert, for your continued interest in COCO and your willingness to alert us to potential improvements in the user interface. These are very helpful.
For your information, I just thought I would share some deeper details about COCO, which are also described in Recipes for Continuation. As you may know, users can define new monitor functions, independent of those that are already made available through different toolbox instances. Each monitor function is associated with a continuation parameter. Although continuation parameters come in different flavors, they can all be used to define a computational domain. A user does so by associating special points with discrete values of the continuation parameters. Such special points are detected by COCO and actions are taken depending on the type of point. Special points that are defined as boundary points define the computational domain. If continuation starts on the inside of the domain, all is well. Under certain circumstances, continuation can also start on the boundary of the domain, as long as a continuation direction points into the domain. If continuation starts on the outside of the domain, then the algorithm terminates.
For user-defined boundary points, there is currently no support for a particular course of action in the case that continuation starts outside the computational domain.
The MCXL special point is defined by the 'coll' toolbox (see page 29 of the tutorial document). It triggers when the tolerance is exceeded. The estimated error is a function of the number of discretization intervals, NTST, (which is currently assigned an initial value, either by default or by the user, and then updated adaptively provided that adaptation is enabled, see page 30 of the tutorial document).
In a future release, the 'coll' toolbox may automatically compute an appropriate initial value for NTST, as well as for the range over which NTST may vary during continuation. The 'coll' toolbox may also, as has been suggested in this thread, include an explicit, toolbox-specific instruction to the user when an MXCL special point is detected.
It is not currently possible for the 'coll' toolbox to distinguish between an MXCL point that is detected during continuation, and one that is detected after convergence onto an initial solution point. This poses a challenge in terms of the way feedback to the user should be presented.
It may also be true that including more explicit reference documents, as well as examples in which errors or warnings were thrown (as was done in Recipes for Continuation), would be helpful.
Note, you might also need to enable adaptation explicitly:
This is also on our list of considerations; [#12].
Related
Tickets:
#12Last edit: Frank Schilder 2016-03-28