Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrate Modelica_Synchronous into MSL 4.0.0 #2862

Open
bernhard-thiele opened this issue Mar 20, 2019 · 11 comments

Comments

Projects
None yet
5 participants
@bernhard-thiele
Copy link
Collaborator

commented Mar 20, 2019

Add the Modelica_Synchronous library to the MSL 4.0.0.

Some thoughts how the integrated structure could look like:

Modelica
  .ClockedBlocks                 <- Modelica_Synchronous (M_S)
-> Pro: Self-contained library, consistent with approach taken for .ComplexBlocks
-> Con: Additional first level library which could be subsumed under the broader domain of directed data-flow blocks

Modelica.Blocks
  .Clocked                       <- M_S
-> Pro: Subpackage below an existing adequate domain, no need for additional first level Modelica.xxx library
-> Con: Basically adds a self-contained sub-library into a self-contained library which feels not coherent

Modelica.Blocks
  .Examples.Clocked              <- M_S.Examples
  .Clocks
    .Sources                     <- M_S.ClockSignals.Clocks
    .Sampler                     <- M_S.ClockSignals.Sampler
    .Interfaces                  <- M_S.ClockSignals.Interfaces
  .ClockedReal                   <- M_S.RealSignals
  .ClockedInteger                <- M_S.IntegerSignals
  .ClockedBoolean                <- M_S.BooleanSignals
  .Types                         <- M_S.Types
-> Pro: Arguably more coherent integration into the Blocks library
-> Con: Four additional subpackages below Blocks, not as self-contained in regard to maintenance responsibilities

Alternative (possibly not as good?) subpackage names instead of Modelica.ClockedBlocks
Modelica
  .Synchronous
  .ClockedSynchronous

@bernhard-thiele bernhard-thiele added this to the MSL4.0.0 milestone Mar 20, 2019

@bernhard-thiele bernhard-thiele self-assigned this Mar 20, 2019

@bernhard-thiele

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 20, 2019

@HansOlsson @MartinOtter @christoff-buerger @tbeu @tobolar Just mentioning you so that you are aware that I have created a ticket for discussing the Modelica_Synchronous integration

@beutlich beutlich pinned this issue Mar 20, 2019

@HansOlsson

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2019

I think I prefer the Modelica.Blocks.Clocked

Having it split just adds a complication (finding all of them together - and accidentally mixing with non-clocked), and I think we already have too many packages directly under Modelica.

@beutlich

This comment has been minimized.

Copy link
Member

commented Mar 25, 2019

I have no strong opinion here if we should aim for first or second alternative here. But since we have ComplexBlocks already next to Blocks (and ComplexMath next to Math), and also Modelica_DeviceDrivers has ClockecBocks next to Blocks, it might look naturals to add ClockedBlocks too. It also seems to feature least effort for migration and a potential later modularization of domains.

@christoff-buerger

This comment has been minimized.

Copy link
Member

commented Apr 3, 2019

I think I would prefer Modelica.Synchronous.

Are there specific reasons to use ClockedBlocks -- to talk about blocks? I somehow miss the context with blocks here. Of course, it is very likely that in most use-cases sampled subsystems are simple block diagrams. But for me this tastes to much Simulink like. I mean, there is no need to only use blocks within clocked partitions. You can use any Modelica model. For me this is actually a strong selling point of Modelica Synchronous (not Modelica Clocked Blocks), that you can apply it on existing continuous models. After all, clocks can have solvers for clocked discretized continuous-time partitions; this does not sound like just a block-diagram thing to me.

Or is the use of block due to synchronous elements (like sample, hold, clock) being blocks? But also that are very strange/special blocks for me, not comparable with normal blocks. The catch with clock partitioning is, that it is cross-cutting -- i.e., breaking -- the normal component hierarchy; but a data-flow according to a component hierarchy is the essential ingredient for blocks.

I hope this comment is not to confusing; I have trouble to explain my bad feeling about relating synchronous to blocks concise.

@bernhard-thiele

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 4, 2019

At the moment all drag'n'drop components from the library are blocks and use the directed data-flow connectors from Modelica.Blocks.Interfaces and/or the directed Clock connectors. From that perspective I think it is okay to classify them as blocks, but I kind of get your preference for Modelica.Synchronous.

What I don't like with the name Synchronous is that we have the "synchronous data flow principle" as a fundamental concept of Modelica (MLS 8.4), so all of Modelica is basically "synchronous". For a more unambiguous classification, one could use the name Modelica.ClockedSynchronous, but this has the disadvantage of being less short and crisp.

@MartinOtter

This comment has been minimized.

Copy link
Member

commented Apr 25, 2019

I am strongly to include it in parallel to Blocks due to practical reasons (and since Modelica.Synchronous are discrete-time blocks, whereas Modelica.Blocks are continouous-time blocks): Subpackages are structured into Examples and Interfaces and it would be very awkward if the many examples and interfaces in Modelica_Synchronous would be spread in many locations of Modelica.Blocks. Including everything (examples, several Interface packages) under Modelica.Blocks.Synchronous would suddenly introduce a new structure.

Furthermore, as Christoff pointed out, there are clocked continuous-time models used in side a sampled block and this looks strange for a Modelica.Blocks library (so it should not be in Modelica.Blocks).

Modelica has synchronous language elements to describe clocked state machines. If the package is called Modelica.Synchronous, it would be natural to include clocked state machines also here in the future (just point this out, although this is not yet relevant).

Here are my preferences (first: my preferred choice):

  1. Modelica.Clocked
  2. Modelica.Sampled
  3. Modelica.Synchronous
@HansOlsson

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 2019

Modelica.Sampled would be confusing for many as the non-clocked sample-operator also leads to sampled systems.

What I don't like with the name Synchronous is that we have the "synchronous data flow principle" as a fundamental concept of Modelica (MLS 8.4), so all of Modelica is basically "synchronous".

I know that we have stated that for a long time, and synchronous data flow was part of the original inspiration for Modelica (as described in "Hybrid Modeling in Modelica based on the Synchronous Data Flow Principle"). However, looking at https://en.wikipedia.org/wiki/Dataflow_architecture the general data flow terminology doesn't seem like a good match for the entire Modelica language; and people don't normally use this term for Modelica.

However, that doesn't imply that I like the name Modelica.Synchronous.

@MartinOtter

This comment has been minimized.

Copy link
Member

commented Apr 30, 2019

Modelica.Sampled would be confusing for many as the non-clocked sample-operator also leads to sampled systems.

What about Modelica.Clocked: Isnt't this exactly describing the core feature? Yes, there is also a block Modelica.Blocks.Sources.Clock, but I think it is fine to have a continuous-time clock and call it Clock. Clocked on the other hand means that the models/blocks inside this package are executed under control of a clock.

What I don't like with the name Synchronous is that we have the "synchronous data flow principle" as a fundamental concept of Modelica (MLS 8.4), so all of Modelica is basically "synchronous"

I think the underlying principle of Modelica is usually stated as single assignment rule: a variable is assigned exactly once.

I know that we have stated that for a long time, and synchronous data flow was part of the original inspiration for Modelica (as described in "Hybrid Modeling in Modelica based on the Synchronous Data Flow Principle"). However, looking at https://en.wikipedia.org/wiki/Dataflow_architecture the general data flow terminology doesn't seem like a good match for the entire Modelica language; and people don't normally use this term for Modelica.

I would also like to mention https://en.wikipedia.org/wiki/Synchronous_programming_language that describes synchronous programming languages. These languages use single assignment at a particular clock tick (a variable can be assigned in multiple statements, but at the same clock tick it can be assigned only once).

Therefore, I still think that Modelica.Synchronous would be o.k., but I prefer Modelica.Clocked because people who do not know synchronous languages have an intuitive feeling for "Clocked" but "Synchronous" has several meanings and it is not at once obvious what meaning is meant at this place.

@HansOlsson

This comment has been minimized.

Copy link
Contributor

commented Apr 30, 2019

What about Modelica.Clocked: Isnt't this exactly describing the core feature?

I have no problem with Modelica.Clocked.
However, I prefer Modelica.Blocks.Clocked since I think we are adding too many packages directly under Modelica, but it might be that the problem isn't Clocked but some of the other packages (e.g. ComplexMath and ComplexBlock).

I think the underlying principle of Modelica is usually stated as single assignment rule: a variable is assigned exactly once.
I would also like to mention https://en.wikipedia.org/wiki/Synchronous_programming_language that describes synchronous programming languages.

I opened a separate ticket on that modelica/ModelicaSpecification#2348

@bernhard-thiele

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 30, 2019

From the discussion so far there seems a majority preference to have it as a top level package, despite the drawback of increasing the package count below Modelica.

Modelica.Sampled fits, but as Hans mentioned, it might be more confusing than the other options.

Modelica.Clocked is short, intuitive, less ambiguous for the the uninitiated and I like it, too.

I have no strong feelings against Modelica.Synchronous either. It is in line with the related MLS chapter name and has the advantage that it is the direct mapping of the current library name into the MSL namespace, so that at least people who know Modelica_Synchronous will immediately recognize what Modelica.Synchronous is about.

If we would open up the package for state machines at a later time, I think both names would do.

@christoff-buerger

This comment has been minimized.

Copy link
Member

commented May 7, 2019

I like both, Modelica.Clocked and Modelica.Synchronous.

I slightly prefer Modelica.Synchronous simply for the reason that we speak of synchronous language features since their introduction in the specification quite some time ago. Thus, the papers documenting the foundations and how to use clocks etc use the term synchronous; and the specification speaks of Synchronous Language Elements in Chapter 16, not clocked. But maybe it would be better (in the long run) to consistently change it all to clocked? If not, I prefer Modelica.Synchronous.

Note: A short scan of the specification shows, that synchronous is much less used than clocked in Chapter 16 Synchronous Language Elements and, as mentioned, overlaps with Section 8.4 Synchronous Data-flow Principle and Single Assignment Rule.

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue May 22, 2019

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue May 22, 2019

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue May 22, 2019

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue May 22, 2019

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue May 22, 2019

Modelica.Clocked: Fix undesired "Modelica_Synchronous" occurrences (m…
…odelica#2862)

Manual search and replace fixes of remaining undesired occurrences of "Modelica_Synchronous".

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue May 22, 2019

Modelica.Clocked: Manually fix "Modelica_Synchronous" occurrences (mo…
…delica#2862)

Manually fix text occurences related to the switch from "Modelica_Synchronous" to Modelica.Clocked.

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue May 22, 2019

Modelica.Clocked: Remove WorkInProgress.mo (modelica#2862)
The models in WorkInProgress.mo are experimental and nobody
worked at them for a long time. Should be moved out of the
main repository (may preserve the package in a feature branch in my fork of the
main repo).

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue May 22, 2019

Move Modelica_Synchronous to Modelica.Clocked (modelica#2862)
Goal: Integrate the Modelica_Synchronous library into the MSL 4.0.0 under
the name Modelica.Clocked.

Reference to the code which is the starting point of this integration
task: modelica/Modelica_Synchronous@0416c85

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue May 22, 2019

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue May 22, 2019

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue May 22, 2019

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue May 22, 2019

Modelica.Clocked: Manual text/code fixes (modelica#2862)
Manually fix remaining text occurences related to the switch from "Modelica_Synchronous" to Modelica.Clocked.

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue May 22, 2019

Modelica.Clocked: Remove WorkInProgress.mo (modelica#2862)
The models in WorkInProgress.mo are experimental and nobody
worked at them for a long time. Should be moved out of the
main repository (may preserve the package in a feature branch
in my fork of the main repo).

@beutlich beutlich added the L: Clocked label May 22, 2019

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue May 23, 2019

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue May 23, 2019

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 11, 2019

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 11, 2019

Replaced xxx_dot by xxx_der (modelica#2862)
Using the suffix _der to denote a derivative is more idiomatic Modelica code

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 11, 2019

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 12, 2019

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 12, 2019

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 12, 2019

Removed quantity attributes (modelica#2862)
Removed as requested in review, related to discussion in modelica#2494.

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 13, 2019

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 13, 2019

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 13, 2019

beutlich added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 13, 2019

beutlich added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 13, 2019

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 18, 2019

beutlich added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 18, 2019

beutlich added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 18, 2019

beutlich added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 18, 2019

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 24, 2019

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 24, 2019

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 24, 2019

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 24, 2019

Reformulate assert for better tool compatibility (modelica#2862)
Replaced assert(not trigger_interval==0, "...") by assert(trigger_interval > 0 or trigger_interval < 0, "...")

bernhard-thiele added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 26, 2019

@beutlich beutlich unpinned this issue Jun 27, 2019

beutlich added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 29, 2019

beutlich added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 29, 2019

beutlich added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 29, 2019

beutlich added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 29, 2019

beutlich added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 29, 2019

beutlich added a commit to bernhard-thiele/ModelicaStandardLibrary that referenced this issue Jun 29, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.