Replace StateGraph by StateGraph2?

[MartinOtter]

@HansOlsson what is your opinion:

It would be useful to move the by far outdated Modelica.StateGraph to ObsoleteModelica4 and include Modelica_StateGraph2 instead into Modelica. I just checked and it seems to be not much work to adapt Modelica_StateGraph2 so that it can be included in MSL:

• Changing Modelica_StateGraph2 to Modelica.StateGraph2
• Moving statements with the Modelica extensions uniqueRoot and uniqueRootIndices into comments (or removing them completely). These extensions are only used to provide meaningful error messages, e.g. to guarantee that every loop has at least one delayed transition.
• Change license to BSD3
• Slighly adapt the documentation (rename in the User's Guide: "Used Modelica Extensions" to "Useful Modelica Extensions")

[AHaumer]

I'm strongly in favour although you are rather late looking at the Feature freeze. Makes sense and seems to be no big project.
@beutlich @dietmarw what's your opinion?

[HansOlsson]

Even if not very big we have to consider that feature freeze was planned for last week.

[dietmarw]

So yes this is simply too late to add at this stage. But also the library itself is not yet standard compliant. Something that I would actually consider a very big obstacle. And the proper sequence should be to make a new library first standard compliant (and there exists an open issue on this HansOlsson/Modelica_StateGraph2#1 ) to even be considered to be added.
An additional issue is what to do with applications that rely on Modelica.StateGraph and can not be converted to Modelica_StateGraph2. So then we would need to consider if we should add another StateGraph library side by side which would add confusion.
An then there is the whole issue that StateGraph2 should probably be rewritten in order to make use of the since MLS 3.3 available "State Machines" features. It is strange that we add state machine features to the language but at the same time add a new library that does not use them and has a rather "outdated" implementation. So there is much discussion ground to be covered to even consider including this or maybe better a completely new implementation of state machine in the MSL that would be a properly implemented successor to StateGraph that makes use of 3.3 features.

So for endusers keeping Modelica.StateGraph means their models will continue to run with 4.0.0. Endusers already utilising Modelica_StateGraph2 can continue to do so. Given that Modelica_StateGraph2 will see some maintenance "love" and also made to work with tools other than just Dymola.

[beutlich]

I'd even claim it is too late to mark StateGraph as obsolete for v4.0.0. This would be required to properly discontinue StateGraph for a new major release.

By the way, there have been a few improvements on StateGraph for v4.0.0, which will increase usability.

[MartinOtter]

I understand it is too late. Just in case:

• My sketch included of course to make it Modelica compliant (before including it in MSL; second item in my list, by removing checks that give error diagnostics) and then the library should work with every Modelica tool.
• As I wrote in the beginning, StateGraph could be moved to ObsoleteModelica4. This means that existing models would still work (via conversion script).
• The State Machine feature of the Modelica Language is only for clocked systems. StateGraph2 is for continuous-time systems, so these are orthogonal features.

[AHaumer]

* The State Machine feature of the Modelica Language  is only for clocked systems. StateGraph2 is for continuous-time systems, so these are orthogonal features.

So why close this issue? It's still a good idea. Keep it open and shift the milestone.

BTW, we need new milestones, at least "Next Minor Version", "Next Major Version".

[beutlich]

BTW, we need new milestones, at least "Next Minor Version", "Next Major Version".

Done: Created new milestones MSL4.1.0 (the next minor version according to semver.org) and MSL5.0.0 (the next major).