You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I am from Kiel University and I working on automatic layout that takes the order of the input model into account. Currently, I am working on the new 0.8.0 release of ELK, which KlighD (and therefore Lingua Franca) uses to do automatic layout.
This release will come with some interesting features that I want to elaborate on.
First of all a little introduction to model order in Lingua Franca, as I understand it:
We do not care about the edge order that much, as long as it does not produce crossings.
Output ports are on the EAST side of a node, input ports are always WEST
The order of reactors, timers, and actions compared to other elements is not that interesting
Reactions should be ordered since they are also numbered and a numbering that does not correspond to the placement may look odd
The startup node should be at the beginning and the startup node should be at the end.
Currently, I am aware of some problems that are a direct or indirect result of the current configuration.
The first thing that we want to change back again (which I originally added) is that separate connected components should also be layouted separately.
This was used to enforce an ordering of components. For example, if we do not layout components separately we can order the inner graph of Customer correctly.
However, since there are no separate connected components we are also experiencing some Obviously Not Optimal (ONO) layouts.
The reaction 1 is forced in the same vertical layer as the much larger reactor MachineController. As a result Cutter is longer than it needs to be. This can be solved by handling this as two separate graphs like this:
However, for the SleepingBarber this causes problems:
Since the subgraph inside Customer consists of four separate graphs their ordering is not respected. This can be solved by activating hierarchy-aware layout (which has a breaking bug in the 0.7.1 ELK release) which we will discuss later.
Concerning the implementation, the order is currently set by giving each node pseudo positions that it might have from a previous layout run and then using the so-called semi-interactive layout, which requires "effort" to create the order.
The reason why this is necessary is that layout algorithms usually see a graph as a set of nodes and edges. However, in reality, it is often a list and has an order. I want to use this order to do the same (or better) layouts with less effort.
In the following, I will introduce new features that will be added in ELK 0.8.0 that allow to use the model order to create better layouts.
If one of the model order approaches is set, all edges and nodes get a model order that corresponds to the original order in the list of nodes and edges.
It will be possible to exclude nodes, i.e. the reactors, timers, and actions to get no order. This means we do not care were they end up.
All nodes with a model order will respect this order inside a vertical layer
Hierarchy aware layout will work
Separate components can be sorted by the minimal model order of their nodes
This leaves us with some options to consider:
Options 1, hierarchy-aware layout + model order:
This is a good option. Hierarchy aware layout solves some problems if the edge order in a child graph is different than the one in the parent graph. The following layout is created since the reaction 3 specifies its outputs as d, s, m instead of m, s, d, as it is done everywhere else. While layouting ChronoLogic we are not aware what happens outside of this node and while layouting Chrono, we cannot change
the port order on ChronoLogic anymore.
Hierarchy-aware layout can solve this by making global decisions for subgraphs:
However, it forces all nodes on the same layer grid. Separate connected components are not layouted as such (See also Cutter example shown earlier).
This can of course also be corrected by always declaring m, s, d in that order.
Option 2: Component ordering + model order:
This would solve the Chrono problem by assuming that the developer does not do something such as one writing d, s, m and in all other occurrences write m, s, d. The main advantage compared to the hierarchy-aware approach is that separate components are layouted separately.
It would for example create the following layout while the hierarchy aware solution would create the later:
The downside I see here is that reaction 5 in the CustomerFactory could be placed better. The mirroring of the upper component in CustomerFactory (with the startup node and reaction 1, 2, and 3) is here better (since the startup node is at the top) but that seems to be an anomaly that I don't want to consider here. Also, I am unsure why the algorithm decides to create a crossing in the Customer node.
I currently think that Option 1 is the better solution. However, I put a bit of thought into the component ordering (which btw also works for different layout directions and connections to NORTH or SOUTH ports) for Option 2 and it also has its advantages.
What is your opinion on this topic? Have you encountered odd layouts (I am always happy to find and solve/discuss them)?
Since most of you do not work on automatic layout feel also free to ask questions about that (since I did not explain everything in detail and tried to explain the problem independent of the implementation and actual layout options that need to be set).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi, I am from Kiel University and I working on automatic layout that takes the order of the input model into account. Currently, I am working on the new 0.8.0 release of ELK, which KlighD (and therefore Lingua Franca) uses to do automatic layout.
This release will come with some interesting features that I want to elaborate on.
First of all a little introduction to model order in Lingua Franca, as I understand it:
Currently, I am aware of some problems that are a direct or indirect result of the current configuration.
The first thing that we want to change back again (which I originally added) is that separate connected components should also be layouted separately.
This was used to enforce an ordering of components. For example, if we do not layout components separately we can order the inner graph of
Customer
correctly.However, since there are no separate connected components we are also experiencing some Obviously Not Optimal (ONO) layouts.
The reaction 1 is forced in the same vertical layer as the much larger reactor
MachineController
. As a resultCutter
is longer than it needs to be. This can be solved by handling this as two separate graphs like this:However, for the SleepingBarber this causes problems:
Since the subgraph inside Customer consists of four separate graphs their ordering is not respected. This can be solved by activating hierarchy-aware layout (which has a breaking bug in the 0.7.1 ELK release) which we will discuss later.
Concerning the implementation, the order is currently set by giving each node pseudo positions that it might have from a previous layout run and then using the so-called semi-interactive layout, which requires "effort" to create the order.
The reason why this is necessary is that layout algorithms usually see a graph as a set of nodes and edges. However, in reality, it is often a list and has an order. I want to use this order to do the same (or better) layouts with less effort.
In the following, I will introduce new features that will be added in ELK 0.8.0 that allow to use the model order to create better layouts.
If one of the model order approaches is set, all edges and nodes get a model order that corresponds to the original order in the list of nodes and edges.
This leaves us with some options to consider:
Options 1, hierarchy-aware layout + model order:
This is a good option. Hierarchy aware layout solves some problems if the edge order in a child graph is different than the one in the parent graph. The following layout is created since the reaction 3 specifies its outputs as d, s, m instead of m, s, d, as it is done everywhere else. While layouting ChronoLogic we are not aware what happens outside of this node and while layouting Chrono, we cannot change
the port order on ChronoLogic anymore.
Hierarchy-aware layout can solve this by making global decisions for subgraphs:
However, it forces all nodes on the same layer grid. Separate connected components are not layouted as such (See also Cutter example shown earlier).
This can of course also be corrected by always declaring m, s, d in that order.
Option 2: Component ordering + model order:
This would solve the Chrono problem by assuming that the developer does not do something such as one writing d, s, m and in all other occurrences write m, s, d. The main advantage compared to the hierarchy-aware approach is that separate components are layouted separately.
It would for example create the following layout while the hierarchy aware solution would create the later:
The downside I see here is that reaction 5 in the CustomerFactory could be placed better. The mirroring of the upper component in CustomerFactory (with the startup node and reaction 1, 2, and 3) is here better (since the startup node is at the top) but that seems to be an anomaly that I don't want to consider here. Also, I am unsure why the algorithm decides to create a crossing in the Customer node.
I currently think that Option 1 is the better solution. However, I put a bit of thought into the component ordering (which btw also works for different layout directions and connections to NORTH or SOUTH ports) for Option 2 and it also has its advantages.
What is your opinion on this topic? Have you encountered odd layouts (I am always happy to find and solve/discuss them)?
Since most of you do not work on automatic layout feel also free to ask questions about that (since I did not explain everything in detail and tried to explain the problem independent of the implementation and actual layout options that need to be set).
Beta Was this translation helpful? Give feedback.
All reactions