I have recently started on a journey to create a package ChaosTools.jl
that has common useful tools used in the study of nonlinear dynamics and chaos, like e.g. lyapunov exponents, attractor dimension estimation and other things.
I quickly realized that there wasn’t any API around that had a clear and intuitive way to create and explore Dynamical Systems, which gave me the idea to create a unifying package (DynamicalSystems.jl
) to provide this API. This would allow other people from other fields to use it as a base and create other kind of packages for the exploration of other dynamical systems. (Notice, both my repos are currently on a very basic state)
However, so far I have been developing by myself, and I am not sure about how to divide functionality, what functionality I should attribute to where and so on and so forth. For example, The DynamicalSystems.jl has a type ContinuousDynamicalSystem
which contains the system state, the equations of motion as well as the Jacobian function (and matrix). I chose to include the latter because the Jacobian is the second most used quantity in any kind of calculation involving a continuous dynamical system (standard example: lyapunov exponents).
Another example is that any calculation of lyapunov exponents will be in ChaosTools. Such a calculation requires for example the tangent dynamics of the vector field. Where should this tangent dynamics information be? At DynamicalSystems
or ChaosTools
?
With this post I would like to:
- invite people to collaborate on the projects and participate on the decisions on what should be the core types and/or what should they contain.
- Discuss with other developers about their opinions on how such a feat should be done. Should everything become a single package? Should the functionality be divided into 2 (or more)? I am personally leaning towards the idea of having this
DynamicalSystems
as some “core” and using the module Reexport
in the other one.
I really appreciate any feedback!
5 Likes
I think this question answers itself when users start asking “is it possible to use X without installing Y? But sometimes I only want Z”.
But this all sounds super useful and interesting! If you ever need help with DiffEqs for this, please feel free to file an issue.
1 Like
I also wonder whether it would be worth it to create a DynamicalSystemsJulia
GitHub organization
If there are multiple related packages, this can make it easier to handle commit access and shared private repos. Also, people get really happy when they join the club. It also makes it easier to have shared docs, examples, benchmarks, etc. since you can easily add repos for these, and make a nice website to make it cleaner. I would caution against putting these extra things in the main repos because they will grow the size of the repos over time, so it’s usually best to isolate them (especially if you’re putting any animations up!). Having an org is good for handling this kind of complexity.
3 Likes
The thing is that with Dynamical systems you can get really a huge variety of things that are all connected under the “dynamical system” term: E.g. neural networks, billiards and ODEs are all there.
For example the package DynamicalBilliards.jl
and the one I am talking about in this post ChaosTools.jl
could both become part of this organization. But are they connected enough to make it worth it? Who knows…
I still think it is a good idea though! But before I do it I want to find at least one more person developing a package for some kind of dynamical system!
I think it’s a great idea to think about a way to enhance support for dynamical systems in Julia; I’m interested in contributing (and in fact suggested DynamicalSystems.jl the other day, on Gitter I believe).
Usually I would suggest starting with a single monolithic package, and splitting it up once it becomes too unwieldy (big / messy) and it is clearer which functionality belongs together.
2 Likes
Hey David, thanks for the input. It is great that you are also thinking of contributing!
What is your opinion about a Github organization like DynamicalSystemsJulia
?
(Almost) all of the Julia orgs start with “Julia”, so it could be “JuliaDynSys” or “JuliaDynamicalSystems”, or maybe better just “JuliaDynamics”.
It would be great to have generic code to calculate Lyapunov exponents and such things!
I agree with @dpsanders, and I claim that packages should typically not be split out while they are under significant development. Splitting a package into subpackages is a design decision that is very difficult to go back from and at an early state of the package, the author is likely not clear what things will be tightly coupled and what things can do well in a package of its own. Having it in a monolithic repo facilitates things because all tests are in the same place, there is no need to worry about tagging and constantly updating METADATA tags because one update made 5 sub-package need updates etc.
An example of a case that worked well for me was when I was developing https://github.com/KristofferC/OhMyREPL.jl, both https://github.com/KristofferC/Tokenize.jl and https://github.com/KristofferC/Crayons.jl was in that repo. As development slowed down it was apparent that these two modules would work well as separate packages. They had use on their own, and wasn’t that tightly coupled to other things in the package, so they got split out.
4 Likes
Hey thanks a lot, that is really insightful! Unfortunately I have already made a split into two packages, but I don’t intend to do any more splitting for now on, unless I am really forced do for some weird reason. I should have thought about it more I guess!
Thankfully for me that split kind of makes sense even from this preliminary developing stage so I have this as a “saving grace” for my quick decision!
Just combine them back into the single package DynamicalSystems.jl
.
for JuliaDynamics
organization
I’m interesting in contributing a few things, mostly related to stochastic dynamical systems. Some linearization local variance estimates, Lyapenov exponents for SDEs, Fredlin-Wentzel approximations, methods for distinguishing chaos from stochasticity in data. These tools are probably more niche topics than the deterministic stuff though.
1 Like
Would it make sense for RigidBodyDynamics.jl to become part of this organization? What are the advantages of joining such an organization over keeping it in my own GitHub account? Should it instead be part of some future robotics organization?
Today I have been thinking a lot about this JuliaDynamics
organization thing. I have also been reading the “how-tos” on github about organizations.
First things first: You can always transfer a repo from one organization to another, which means that if you have your package there and there is a robots organization coming up (which is very likely to happen) you can simply transfer it.
Secondly, whether the your package fits on an organization called JuliaDynamics
: well, both names end in Dynamics
so…
Lastly, I have also been thinking what coherence could packages that belong to JuliDynamics could have between them and I concluded that they could not have any! Simply because dynamical systems are vastly different in their representation and implementation: Rigid body, billiards, Spiking neural networks could also be considered a dynamical system.
But then I thought that the absence of coherence doesn’t matter at all: I think it is definitely a good idea to have a uniting umbrella under which packages that study Dynamics of systems may live. So I am going to start this organization after I have setup my own package DynamicalSystems.jl
(I am going to make an announce post so I don’t start the organization by myself, since I would really hate being the only “owner”).
EDIT: PS: Wow, this RigidBodyDynamics is huuuuge! Really good job!
1 Like
This seems like something that could interest @lbenet - I took his awesome course on chaos and dynamical systems in computational physics last semester and there are great notebooks to pull classroom material from, albeit in Spanish.
2 Likes
I work with non-linear systems. Can you please tell us about what the content/functions in your package would be? You are doing a great job here. Please make that package as helpful in calculations as possible. And can you please guide about how to use which function for what application?
Like, if I want to find out the Observability or Controlability of a system which function to use? If I want to find out the Lyapunov result of the system then what function to use.
I am sorry, may be I am asking really silly questions. But I am new to julia and I am coming from Matlab background. So everything here is new for me. Please guide.
Hi ashim,
Well the package will be as general as possible and have as many stuff in there as possible. Of course there will be proper documentation, but only later when I will have finished the core package.
The lyapunov exponent calculation for discrete systems is already possible: https://github.com/Datseris/DynamicalSystems.jl
Continuous systems will be functional probably next week or earlier. I have not worked with Observability in my (very tiny) scientific career so far, therefore I myself will not be adding it. You are welcome to write code and submit it to the package, as I hope that this package DynamicalBilliards.jl
will be a collaborative effort of many people.
By the way, for anybody following, I have already merged everything back into DynamicalSystems.jl
and everything will operate from there. ChaosTools.jl
will be deleted very soon.
2 Likes
I will look your package. I resarch area is nonlinear control theory. I developing nonlinear controllers, which is easy to use for engineers. I working on some new controllers. The original nonlinear controller developed my mentor called Robust Fixed Point Transformation.