Methods to help in finding good parameters for the recurrences method

[KalelR]

In lots of cases, AttractorsViaRecurrences works great with the default parameters. But this isn't true all the time, especially for more complicated systems. Then, we need to fine-tune at least a bit the meta-parameters of the code - do we change the grid length? the grid range? the other parameters? It would be great if there was some method to help in identifying which meta-parameters can be improved for more accuracy or speed, or at least to know which meta-parameters aren't good.

A simple example of this is for cases in which attractors aren't found, and the method returns `-1'. Currently, this can mean that:

1. The trajectory spent more than mx_chk_lost steps out of the grid or
2. The trajectory didn't converge to an attractor after mx_chk_safety steps or
3. The norm of the integrator becomes larger than horizon_limit

Lifting the degeneracy from these by changing the codes for these from -1 to -2 and -3 or something would already help. Also, before returning -X we could throw a warning. Similarly, would a debugging mode be good? This could throwinfoor 'warning messages when each attractor is found saying why it was found.

[Datseris]

Yes for debugging mode. Unfortunately changing the -1 is really hard because downstream code assumes the special value is -1 when e.g. find the keys if attractors... We need to change it to not check it key is -1 but if key is negative in stead

[KalelR]

Yes for debugging mode

What's the best way to do this? Add a lot of if conditions + warning messages in the normal function, or creating a separate "debugging" function that's a copy of the other with the messages directly?

We need to change it to not check it key is -1 but if key is negative in stead

Yup. Is there a lot of code relying on this? If so, an alternative is maybe just throwing a warning message for each of the 3 cases.

[Datseris]

throwing a wraning would only work if debugging is turned on. Actually wait. Throwing warnings isn't a good idea because if you do a simulation with many initial conditions you get your console swarmed with warnings. SO only if debugging is on then warnings should be thrown...

For debugging, I think the proper way to do it is using Julia's logging system: https://docs.julialang.org/en/v1/stdlib/Logging/

[Datseris]

Documenter.jl turns debugging on if you set an environment variable: https://github.com/JuliaDynamics/doctheme/blob/master/build_docs_with_style.jl#L5

[Datseris]

https://docs.julialang.org/en/v1/stdlib/Logging/#Environment-variables is the solytion

[Datseris]

yeah i really want the debugging mode or "print more info mode" as well. In the past the recurrences mapper printed by default a message when it found an attarctor, but it was annoying to always handle keywords to stop this. A module-wide option for printing info is the best way forwards, via the logging infastructure.

[KalelR]

Yeah so do I, would be really useful. Logging sounds like a great idea. If no one does it before, I'll try it out when I have a bit more time.

Also to mention: this would also be super useful for AttractorsViaFeaturizing, in printing the optimal radius and maybe some of the extracted features and so on.

[awage]

Good idea. Sometimes I check out the code for dev just to add special warning when I cannot find what I need. I will think also about the -1 requirement. It is used in the continuation method and maybe in other parts. But I don't think there is much code downstream. I would leave -1 for divergence. Sometimes +- Inf is considered as a basin (for example in the Hénon map). -2 and -3 as error code for attractors outside the grid and convergence error.