KIELER Models Repository (Public)

This repository holds test models for the KIELER project. These test files are used while developing our layout algorithms, to reproduce and fix bugs, and to run automated tests to ensure the bugs remain fixed.

Repository Layout

On the top level, the repository contains the following folders:

Folder	Description
tests	Test graphs written or generated by us or others.
realworld	Models obtained by converting examples from the real world into formats we can use.
tickets	Models that reproduce problems described in tickets.
collections	Somewhere in-between tests and realworld: Larger collections of models that are usually derived from real world models and may serve as a basis for evaluations.

Both tests and tickets are further subdivided into folders specific to the models' context (e.g. 'ptolemy', 'sccharts'). In the test tree, these folders may contain further folders specific to the respective tickets if more than one file is produced for a given ticket.

File Types

The file types we use are the following:

Type	Description
.elkt	Textual ELK graph language. See the specification.
.elkg	EMF's XMI-based representation of ELK graphs.
.json	JSON files. See the specification.
.md	Readme files can be placed in folders to describe their purpose.

Collections

Next, the available collections are described. The collections may be subject to change both in terms of structural changes of the graphs itself and in terms of the graph instances that are included within a collection. Thus, when referencing a certain collection in a post or an article, it is a good idea to include the git commit id of the used state.

The following table provides an overview, and the sections below describe the properties of the graphs in further detail.

Collection	Description
rome, north	Taken from the graphdrawing.org website, these two collections are well-known within the graph drawing community. As opposed to the other collections, the graphs' nodes do not have dimensions.
ptolemy	Taken from UC Berkeley's Ptolemy II project, the graphs represent dataflow diagrams with ports.
sccharts	SCCharts are a type of control flow diagram, representing state machines with hierarchy. The provided graphs have been created by university students during practical courses.
scgs	SCGraphs occur during the compilation of SCCharts. The provided graphs originate from the previously mentioned SCCharts.

Ptolemy

Variants:

• original
• flattened: the hierarchy has been removed by moving all simple nodes to the top-most level

There are two *._map.txt files in the corresponding directory that can be used to identify the original model.

Interesting features:

• Ports
• Different node dimensions
• Hyperedges
• Node labels
• Hierarchy
• Disconnected graphs

Desired layout style:

• Left-to-right layout direction
• Orthogonally routed edges

Preserved layout options:

• portConstraints
  • portSide
  • portIndex
• nodeLabels.placement

What to do:

• Simple nodes have a dimension, the dimension of hierarchical nodes must be determined
• Nodes have labels, which have a dimension, that are to be positioned properly
• Nodes have ports that are to be positioned according to their port constraints
  • Simple nodes have fixed order port constraints
  • Hierarchical nodes have free port constraints

SCCharts

Variants:

• original
• core: the original SCCharts are transformed to only comprise of core features, which usually results in a larger number of nodes and edges

Interesting features:

• Different node dimensions
• Hierarchy
• Mixture of a regular layout algorithm and a packing algorithm. The latter has explicitly been configured to org.eclipse.elk.box
• Edge labels

Desired layout style:

• Spline edge routes
• Even node distribution

Preserved layout options:

• Layout algorithm as mentioned above

SCGraphs (SCGs)

SCGs emerge during the compilation of SCCharts.

Variants:

• original
• bb: at some point, several nodes are combined to basic blocks, which are modeled using hierarchy
• seq: sequentialized SCGs are acyclic and may become very long

Interesting features:

• Different node dimensions
• Hyperedges
• Node labels
• Hierarchy

Desired layout style:

• Top-down layout direction
• Orthogonally routed edges

Preserved

• portConstraints
  • portSide
  • portIndex
• nodeLabels.placement
• layerConstraint