Associations.jl icon indicating copy to clipboard operation
Associations.jl copied to clipboard

Move predefined systems out?

Open Datseris opened this issue 2 years ago • 7 comments

Datseris avatar Sep 21 '23 16:09 Datseris

Evolving dynamical systems is a heavy dependency. Yet, CausalityTools.jl is a pakcage that exclusively deals with input data. It doesn't necessarily need to have a dependency on the whole OrdinaryDiffEq pipeline. Perhaps it makes sense to create a CoupledPredefinedSystems.jl package. Or even better, to add all these predefined systems to the existing PredefinedDynamicalSystems.jl package, that already exists?

Additionally, I am not sure whether the existence of SystemDefinition, DiscreteDefinition, and ContinuousDefinition. system is useful. What do all these extra types achieve? Why not just use the existing API from DynamicalSystems.jl and just initialize a DynamicalSystem?

Datseris avatar Sep 21 '23 16:09 Datseris

Additionally, I am not sure whether the existence of SystemDefinition, DiscreteDefinition, and ContinuousDefinition. system is useful.

With the API from DynamicalSystemsBase.jl, these definitions aren't needed.

Perhaps it makes sense to create a CoupledPredefinedSystems.jl package add all these predefined systems to the existing PredefinedDynamicalSystems.jl package

I think adding them to PredefinedDynamicalSystems.jl is the best option. We can put them under a "coupled dynamical systems" in the docs. These systems can be selectively documented here for convenience (but only in the docs, which tells the user to do using PredefinedDynamicalSystems if they want to use them).

kahaaga avatar Sep 21 '23 17:09 kahaaga

Additionally, I am not sure whether the existence of SystemDefinition, DiscreteDefinition, and ContinuousDefinition. system is useful.

Ah, I totally forgot: I've been using the wrapper types, e.g. Anischenko as dictionary keys for storing results, so that there is a 1-to-1 mapping between [system + initial condition + parameters] and the results, without having to do extra work.

I've also been frequently defining e.g rand(sys::Anischenko, p::Constraints) → Anischenko in my scripts to generate systems with randomized parameters and initial conditions (in combination with the UncertainData.jl package). I think I need to think a bit deeper on the future integration with the uncertain data package before deciding to toss these types out.

kahaaga avatar Sep 21 '23 18:09 kahaaga

This doesn't sound like it belongs in the CausalityTools.jl package. It sounds like it belongs in your scientific scripts. Or you could make an unregistered package and add it to your projects. I just don't think any of this is highly relevant for the main functionality CausalityTools.jl offers.

Datseris avatar Sep 21 '23 19:09 Datseris

This doesn't sound like it belongs in the CausalityTools.jl package. It sounds like it belongs in your scientific scripts. Or you could make an unregistered package and add it to your projects. I just don't think any of this is highly relevant for the main functionality CausalityTools.jl offers.

Yep, agreed.

A PR to PredefinedDynamicalSystems.jl is probably the best option here

kahaaga avatar Sep 21 '23 19:09 kahaaga

A PR to the predefined systems package would not introduce types such as Anischenko. However, you don't really need them. The dynamic rule functions can be used as types.

rand(::typeof(anischenko_rule), ...)

would work. I am not sure if I would do something like this, seems kinda weird, but it would give the same functionality you have now.

Datseris avatar Sep 21 '23 20:09 Datseris

I am not sure if I would do something like this, seems kinda weird, but it would give the same functionality you have now.

Yeah, I think the best course of action is just to abandon this approach and use functions. I vote for ecosystem consistency here.

kahaaga avatar Sep 21 '23 20:09 kahaaga

Example systems have now been completely removed from the package in a breaking release, so I'm closing this.

kahaaga avatar Jul 27 '24 06:07 kahaaga