Systems Identification

[ahwillia]

Hey this looks like a great package!

I'm curious if you are planning to support subspace identification and similar functionality here, or would that live in a different repo? I could contribute it if there is interest. Sorry if this is outside your scope.

[baggepinnen]

Hey!

There are plans to eventually provide a system identification package alongside this package. See #68 for a discussion on a separation of the types of ControlSystems.jl into a separate package, which both ControlSystems.jl and SystemIdentification.jl can depend on.

Your contribution would be greatly appreciated. Maybe @mfalt have some idea regarding when the restructuring might take place?

[mfalt]

System Identification would be a nice feature to have in this package/ecosystem. There is currently no time-plan for when we would restructure and split the package, so if you are willing to provide tools for system identification we could definitely integrate that into the current code, and then I could try to separate it when we restructure and split the code.

[neveritt]

Hey!

We had a summer student working on implementing some basic System Identification methods. He basically implemented the Prediction Error Method for polynomial types (ARX, ARMAX, OE, BJ) and subspace identification (n4sid). I'm currently checking his code and restructuring it a bit. It will be available here once I'm done.

[jleny]

Hi all, I see now that there is the JuliaSystems organization with a bunch of packages including SysId and no mention of ControlSystems.jl as far as I can see. Plus a just announced workshop at ACC 2017 on Julia involving @neveritt and no mention of ControlSystems.jl either Surely there must be a way to avoid competition & duplication of packages and efforts at this stage. Any thought on this?

[mfalt]

Hi. Yes, we had a lot of talks with them when they stared up, both in online an in person with the goal of avoiding competition and duplication. They had though out a different type system, which had some nice advantages compared to the current setup in ControlSystems.jl. This promped the discussion on the restructuring on the types in this package, as a way of finding common ground to work on, see for example this page. I think one of the main differences were whether or not a SISO system should be implemented as a different type from a MIMO system (their approach), or whether a SISO could just be considered a special case of MIMO (our thinking). Some of this discussion is found here. We had a hard time agreeing on this, and tried to set up some inter-university collaboration on this, and consulted some well respected developers, such as the guy who wrote Debug.jl and the founder of the Modelica language. However, one day one of the developers on the other project gave up on working together and said:

I do not want to collaborate anymore, nor use Julia. sure,, implement your own way, and that's perfectly fine for me. i will do from now on as an exercise/gymnastics for my programming skills, as I told you just for the fun of it

We though this was quite sad ,since we recognize that the current ControlSystems.jl could use a rewrite to a better typesystem, and the collaboration could have made both projects much better. They have since gone on and developed some of the basic functionality. They seem to have adopted most of the things we agreed on in the discussions, and as far as I can see, have gone back on some of the things they didn't seem to agree on before. For example they have a common implementation of SISO/MIMO as a matrix of RationalFunctions, where the rational functions don't have individual sample times encoded in them. They however still have a type parameter for indicating if the system is SISO or MIMO, something that seems better than their original idea that they didn't want to abandon, but still seems like it could be inconvenient. I haven't looked though most of their code yet, but it will be interesting to see what it looks like when they are done. The ControlSystems.jl package still needs a rewrite, but we have not committed much time to it recently, in part because it feels like the double work is so unnecessary. I am assuming that they will develop more features before ACC, so by then I guess we will see how well their approach works, hopefully they either reach a point where we can see that their type system is easy to work with, or to the point where they agree that it is not the way to go, eitherway, maybe there will be another chance for collaboration later.

They had not mentioned the talk at ACC to us by the way, even though both me and @baggepinnen will attend the conference. I should also mention that it has been a while since this discussion was going on, so I hope that I am not mistaken in any of the details. Lastly I want to point out that @neveritt is not to blame for the lack of agreement, he remained cooperative.

[jleny]

Ok, thanks for the explanations. I understand that different groups might have different constraints and views regarding how to implement things. However, regarding the ACC workshop, I think it is legitimate for you to reach out to them and make sure they at least mention/cite ControlSystems.jl, since your package predates theirs and is reasonably functional already (plus they might have drawn inspiration from it). The natural thing should have been to invite you as speakers in fact. Unfortunately I will not be able to attend ACC this year.

[aytekinar]

Dear @jleny,

I have just found out that I was mentioned in the public conversations below. I find it quite disturbing that I am mentioned with citations that are taken out of context from private conversations, and in a way that does not reflect the efforts and dedication that I have put into the development of open source software for Julia.

Still, please let me clarify the points that you raise.

ACC Workshop

As for the ACC workshop, its purpose is to promote the Julia language to the broader control community. It will be a tutorial, aiming at bringing participants with knowledge of other technical environments from basic Julia to productivity with the full range of (relevant) toolboxes that are now emerging. It is not intended to promote or demote any particular package. I am not an organizer, but I have understood that the organizers have invited several of the developers that @mfalt is mentioning. Let us hope that it will be a well-attended workshop and that the Julia language will get the attention that it deserves from the control community!

JuliaControl vs. JuliaSystems

This part will be a bit long. I just want to share my and @neveritt's view.

JuliaSystems, as you have already found out, aims at having a modular ecosystem similar to, say, those in JuliaML, JuliaStats, or JuliaDiffEq, which evolves around some reusable building block package. We (me, @neveritt and @crro) have tried to learn from these successful organizations when it comes to structuring Julia packages, and we have decided to separate IdentificationToolbox, ControlToolbox and (hopefully in some near future) MPCToolbox. We had 6 M.Sc. students working on LinearMPC, NonlinearMPC and Invariant Sets over the course of 8-10 weeks. All these mentioned packages will be using SystemsBase (with its RationalTF, StateSpace, and left and right MFD objects; all defined for discrete and continuous-time SISO/MIMO representations).

In fact, we had also developed a rather complete toolbox for control systems together with an M.Sc. student before; but we froze the development of that package once we found out about ControlSystems. Our intention was to collaborate on the restructuring of ControlsSystems so that we could build our ecosystem on top of it. However, the discussions were perpetually getting stuck on the SISO/MIMO topic. Instead of continuing the discussions, we implemented the functionality we needed in other packages. For example, both I and @neveritt actively contributed to Polynomials and I have written and released RationalFunctions, which is a general-purpose package that could be used as a building block for RationalTF objects. In the meantime, @neveritt has written and released PolynomialMatrices, which will be serving as the building block for MFD objects. Of course, these are all open source software, and the functionality defined in Polynomials, RationalFunctions, PolynomialMatrices, and SystemsBase could be used in ControlSystems if needed.

There have also been attempts from other groups to join forces (cf. here, here, and the comments therein). As you can see, these attempts have not been (at least, as of now) successful, either. High inertia and diverging views on the future direction of a package are inherent in open source world. For example, JuliaML was born as a "playground" from a more mature package JuliaStats; related discussions are here and here, and these competitions might even end up with better, higher quality solutions in the end.

Finally, as @mfalt mentions, we are actively trying to set up a multi-university cooperation with their university and others to coordinate our support to the open initiatives in Julia. We are hopeful that this project will soon be granted.

Best,