JuliaDynamics / Attractors.jl

Find attractors of dynamical systems, their basins, and continue them across parameters. Study global stability (a.k.a. non-local, or resilience). Also tipping points functionality.
MIT License
27 stars 5 forks source link

(2.0) Parameter-by-parameter continuation using featurizing #126

Open KalelR opened 1 month ago

KalelR commented 1 month ago

Hey, this is a new PR, following up on #69. Sorry I took so long, made all of this a bit unnecessarily complicated. I came back to this now as I need this continuation for two projects I'm working on. On the previous PR, we were discussing whether it was better to match the attractors found for different parameters using the clouds of features or the attractors themselves. There were good points for using the features, one of them being that there would be no need for reconstructing the attractors. This is true for matching, but, importantly, not for seeding. We need the attractors to sample ics from them to use them as seeds for the attractor-finding algorithm in the subsequent parameter. Thus, since we need the attractors anyway for seeding (which is the heart of the continuation!), then we might as well use them for matching! If the user then wants to match via features, they can just extract the features in their matching function.

In summary, this PR thus implements continuation for AttractorsViaFeaturizing very similarly to how it is implemented for AttractorsViaRecurrences. The only big difference is that the ics sent to continuation must be pre-generated and stored in a StateSpaceSet, contrary to the sampler function that the AttractorsViaRecurrences version needs. This is because basins_fractions requires the ics in this way to be able to extract the attractors after grouping the features. Again, the attractors are needed for seeding, so this is necessary. After attractors are found, initial conditions are sampled from them and sent together with the pre-generated ics for basins_fractions on the next parameter. The ics are all put together for extracting features and grouping them.

Let me know what you think!

I compared this algorithm with the recurrences one for the magnetic pendulum example in the documentations. Here is a comparison image with the recurrences on the left and the featurizing on the right for 1000 ics per parameter. I think the curves for featurizing are smoother because the pre-generated ics are fixed. For recurrences, new ics are generated for all parameters, which probably causes the bigger fluctuations.

Datseris commented 1 month ago

thanks, i will review this after Tuesday.

Datseris commented 1 month ago

Can you point me to where in the source code you "find the attractor" or "extract the attractor"?

KalelR commented 1 month ago

Can you point me to where in the source code you "find the attractor" or "extract the attractor"?

The attractors are extracted as usual in extract_attractors, defined in https://github.com/KalelR/Attractors.jl/blob/28f662a29972c3b826bbaaa63b2cc44efce4e97f/src/mapping/grouping/attractor_mapping_featurizing.jl#L180.

awage commented 1 week ago

Hello, I'm free from academic duties! I will review the code tomorrow.

awage commented 1 week ago

Hi Kalel! I am not sure to get the point of sampling the attractors point. The thing that puzzles me is that you add these extra ics to the pool of predefined initial conditions. How this influences the mapper? Is it to ensure that you have at least one initial condition from each attractor? Because the mapper does its job with or without these extra initial conditions.

The matching is done the usual way. So what is the advantage over the previous matching continuation?

The code is fine. It's just that I don't see the benefits right now over the previous method.

Datseris commented 1 week ago

How this influences the mapper? Is it to ensure that you have at least one initial condition from each attractor? Because the mapper does its job with or without these extra initial conditions.

It is the same as the seeding part of our original Recurrences continuation, the one we described in our 2023 paper.

The featurizing mapper did not so far seed initial conditions from found attractors when moving to the next parameter. With this PR it does. This makes it more likely that if an attractor continues to exist, it will be found during the continuation.

awage commented 1 week ago

Ok, I see more clearly the context. The code is good to go!

@KalelR @Datseris: I have an idea to factorize a bit the code. But it is a breaking change. A new type called AttractorsFindAndMatch can generalize the interface. Then we dispatch on the type of mapper depending if its recurences or featurizing. There some code in common that can be refactored. What do you think?

Datseris commented 1 week ago

@awage have you seen #130 ...? I do exactly that. In fact, the whole code is already implemented and pushed in the branch matcher_interface. I will open a PR now.

awage commented 1 week ago

@awage have you seen #130 ...? I do exactly that. In fact, the whole code is already implemented and pushed in the branch matcher_interface. I will open a PR now.

Wow! I l'll catch up.

Datseris commented 1 week ago

See #132