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

Structurally singular system #122

Open
tbeu opened this issue Jun 23, 2016 · 10 comments
Open

Structurally singular system #122

tbeu opened this issue Jun 23, 2016 · 10 comments
Labels

Comments

@tbeu
Copy link
Collaborator

tbeu commented Jun 23, 2016

Reusing a (serial) package for multiple senders results in a structurally singular system.

ss
In this example I just wanted to test the LCM logging feature (lcmSend1) beside the UDP broadcast (lcmSend).

I believe it should be allowed to have multiple senders or am I wrong?

@bernhard-thiele
Copy link
Collaborator

The PackageIn and PackageOut connectors have both, inputs and outputs.
Hence, there is also a backward signal flow and this is why the example above doesn't work.

@tbeu
Copy link
Collaborator Author

tbeu commented Jun 27, 2016

Is it a current limitation of the SerialPackager we need to accept or is there a workaround? I consider this limitation as rather critical.

@bernhard-thiele
Copy link
Collaborator

This is a limitation and I don't see a simple workaround. One could provide a distinguished splitter block, but one needs think how to handle the back propagation. Also, once one can split into parallel branches, somebody could be tempted to add packages in parallel branches.

Another workaround could be to have a feedthrough at a send block which allows to connect another send block in series. Not sure what is more feasible.

@tbeu
Copy link
Collaborator Author

tbeu commented Jun 27, 2016

Since package branching is not allowed anywhere, I would prefer a splitter block.

Do you know of any (tool-specific) way to prohibit branching, i.e. have max (exactely) 1 connection per connector? We could use cardinality (like in MSL Fluid) but it is deprecated.

@tbeu
Copy link
Collaborator Author

tbeu commented Jun 27, 2016

https://trac.modelica.org/Modelica/ticket/1410 proposes to use cardinality only in asserts. Thus we could simply do that.

@bernhard-thiele
Copy link
Collaborator

I have no idea how one could prohibit this and I also have no clear picture how to implement. Probably it needs a trial and error approach.

@tbeu
Copy link
Collaborator Author

tbeu commented Jun 27, 2016

Adding an assert(cardinality(..)) for each element with PackageIn and PackageOut connectors could help. What do you think?

@bernhard-thiele
Copy link
Collaborator

For me it seems that in this way one maybe could get better error messages for systems that branch out, but it still wouldn't allow you to have several sinks as you would like to have (or am I missing something)?

@tbeu
Copy link
Collaborator Author

tbeu commented Jun 27, 2016

Yes, instead of the singular sysem error msg you would get the cardinality assert.

Parallel branches are simple not possible. I beleive a user needs to define its own block if he/she wants to model multiple sinks.

@tbeu
Copy link
Collaborator Author

tbeu commented Jun 29, 2016

Too bad, adding a cardinality assert message does not help the user since the error message on structurally singularity is raised before the assert (in SimulationX).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants