Jekyll2020-07-07T12:05:51+00:00https://dilsonguim.github.io/website/feed.xmlDilson Almeida GuimarãesA place to share projects and ideas.Google Summer of Code 2020 - Week 42020-07-07T12:00:00+00:002020-07-07T12:00:00+00:00https://dilsonguim.github.io/website/kde/gsoc/2020/07/07/gsoc-week4<p>According to my GSoC proposal, I should be done with the general purpose graph layout capabilities for <a href="https://kde.org/applications/education/org.kde.rocs">Rocs</a> and free to start working on layout algorithms specifically designed to draw trees.
This is not the case for a series of reasons, including my decision to write my own implementation of a general purpose force-based graph layout algorithm and failure to anticipate the need for non-functional tests to evaluate the quality of the layouts. I still need to document the functionalities of the plugin and improve the code documentation as well. Besides that, although it is not present in my original purpose, I really want to include the layout algorithm presented in [1], because I have high expectations about the quality of the layouts it can produce.</p>
<p>Even though I am not done with this first part, I decided to start working on the layout algorithms for trees. Now that I am more used to the code base and to the precesses used by KDE, I expect to be more productive and finish everything on time.</p>
<p>The main motivation for implementing layout algorithms specifically designed for trees is the possibility of exploiting the properties of trees to come up with better layouts.
Yesterday, I started studying more about layout algorithms for trees. Most of them are based on a subset of the following ideas:</p>
<ul>
<li>Select a root node for the tree. This node can be provided by the user or selected automatically.</li>
<li>Partition the nodes by their depth in the rooted tree and draw all nodes with the same depth at the same layer (usually a line or a circle).</li>
<li>Draw the sub-trees in a recursive way and compose the resulting drawings to get the complete layout.</li>
</ul>
<p>All of these ideas are related to the structure of trees.
In order to improve my intuition about them, I wrote an experimental implementation based on the first two ideas above.
The application of this implementation to a tree with 15 nodes generated the following result:</p>
<p><img src="/website/assets/images/2020-07-07-tree.png" alt="Tree layout." /></p>
<p>By taking advantage of the properties of trees, even simple solutions such as my one-day experimental implementation can guarantee some desirable layout properties that the general purpose force-based layout algorithm can not. For instance, it guarantees that there are no intersections between edges or between nodes. The force-based layout algorithm I implemented can generate layouts with pairs of edges that intersect even when applied to trees.</p>
<p>[1] R. Davidson and D. Harel. Drawing graphs nicely using simulated annealing.ACM Transactions on Graphics, 15(4):301–331, 1996.</p>According to my GSoC proposal, I should be done with the general purpose graph layout capabilities for Rocs and free to start working on layout algorithms specifically designed to draw trees. This is not the case for a series of reasons, including my decision to write my own implementation of a general purpose force-based graph layout algorithm and failure to anticipate the need for non-functional tests to evaluate the quality of the layouts. I still need to document the functionalities of the plugin and improve the code documentation as well. Besides that, although it is not present in my original purpose, I really want to include the layout algorithm presented in [1], because I have high expectations about the quality of the layouts it can produce.Google Summer of Code 2020 - Week 32020-06-29T23:00:00+00:002020-06-29T23:00:00+00:00https://dilsonguim.github.io/website/kde/gsoc/2020/06/29/gsoc-week3<p>This week, I spent most of my time testing the <a href="https://kde.org/applications/education/org.kde.rocs">Rocs</a> graph-layout-plugin.
I needed to test the method that applies the force-based layout algorithm to a graph, whose signature is the following.</p>
<div class="language-c++ highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="k">static</span> <span class="kt">void</span> <span class="nf">applyForceBasedLayout</span><span class="p">(</span><span class="n">GraphDocumentPtr</span> <span class="n">document</span><span class="p">,</span> <span class="k">const</span> <span class="n">qreal</span> <span class="n">nodeRadius</span><span class="p">,</span>
<span class="k">const</span> <span class="n">qreal</span> <span class="n">margin</span><span class="p">,</span> <span class="k">const</span> <span class="n">qreal</span> <span class="n">areaFactor</span><span class="p">,</span>
<span class="k">const</span> <span class="n">qreal</span> <span class="n">repellingForce</span><span class="p">,</span> <span class="k">const</span> <span class="n">qreal</span> <span class="n">attractionForce</span><span class="p">,</span>
<span class="k">const</span> <span class="kt">bool</span> <span class="n">randomizeInitialPositions</span><span class="p">,</span> <span class="k">const</span> <span class="n">quint32</span> <span class="n">seed</span><span class="p">);</span>
</code></pre></div></div>
<p>Unfortunately, there is not much that is guaranteed by this method. Basically, given a graph and some parameters, it tries
to find positions for each node in such a way that, if we draw the graph using these positions, it will look nice.
What does it mean for the drawing of a graph to look nice? How can we test it?
This is a subjective concept, and there is no clear way to test it. But there is still something that can be done: non-functional tests.</p>
<p>Before going to the non-functional part, I decided to deal with the easy and familiar functional tests.
I was not precise in my description of the method deliberately. Actually, there is at least one guarantee that it should provide:
if we draw each node as a circle of radius nodeRadius with centers at the positions calculated by the method, these circles should respect
a left-margin and a top-margin of length margin. This was a nice opportunity for me to try the <a href="https://doc.qt.io/qt-5/qtest-overview.html">QtTest framework</a>.
I wrote a data-driven Unit Test and everything went well.</p>
<p>Back to the non-functional part, I decided to write a quality benchmark. The idea is to measure some aesthetic criteria of the layouts generated for
various classes of graphs. The metrics already implemented are: number of edge crosses, number of edges that cross some other edges, number of node intersections
and number of nodes that intersect some other node. Although there is no formal definition of a nice layout, keeping the values of these metrics low
seems to be desirable. Currently, I already implemented generators for paths, circles, trees and complete graphs. For each one of these classes of graph,
I generate a number of graphs, apply the layout algorithm a certain number of times to each of them, and calculate summary statistics for each one of the considered aesthetic metrics.</p>
<p>For now, there is only one layout algorithm which can applied to any graph. The idea of the quality benchmark is to compare it to other layouts algorithms I will
implement. But it does not mean that the quality benchmark is currently useless. Actually, the results I got were quite revealing.
The good part is that there were no intersection between nodes. But the results about edge crossing are not so good. Despite my efforts in tuning the parameters, the algorithm can fail to eliminate all edge crosses even for very simple graphs such as paths and circles. Fortunately, choosing parameter values specifically for a graph can sometimes help, and the user can do that in the graph-layout-plugin user interface.</p>This week, I spent most of my time testing the Rocs graph-layout-plugin. I needed to test the method that applies the force-based layout algorithm to a graph, whose signature is the following.Google Summer of Code 2020 - Week 22020-06-18T12:00:00+00:002020-06-18T12:00:00+00:00https://dilsonguim.github.io/website/kde/gsoc/2020/06/18/gsoc-week2<p>Last week, I did not manage to work as much as I should, because I was not feeling very well.
Now that I am feeling better, I am trying to work more to compensate. This is the post that
should have been written last week.</p>
<p>This week, I implemented the first version of the graph-layout-plugin for <a href="https://kde.org/applications/education/org.kde.rocs">Rocs</a>.
For now, it supports only a force based graph layout algorithm, which is an adaption of the Fruchtermani-Reingold algorithm.
The graph-layout-plugin can be found at Graph Document - Tools - Graph Layout. The user interface is the following.</p>
<p><img src="/website/assets/images/2020-06-17-screenshot-graph-layout-plugin.png" alt="Screenshot of the graph-layout-plugin" /></p>
<p>The user can control the magnitude of the forces acting on the nodes using these slide bars. I decided to use slide bars because
I do not think the user would benefit from having the exact value of each parameter.</p>
<p>I used the graph-layout-plugin to generate the following layouts. All of them are for connected graphs because
I still need to handle the disconnected ones.</p>
<p><img src="/website/assets/images/2020-06-17-k5.png" alt="Complete graph." />
<img src="/website/assets/images/2020-06-17-tree.png" alt="Tree." />
<img src="/website/assets/images/2020-06-17-circle.png" alt="Circle graph." />
<img src="/website/assets/images/2020-06-17-planar.png" alt="Planar graph." />
<img src="/website/assets/images/2020-06-18-random.png" alt="Random graph." /></p>
<p>I experimented a little in order to find default parameters that work well. In particular, the layout algorithm used
requires a rectangle in which all centers of the nodes should be placed and the forces applied depend on the area of this
rectangle. In order to make things simpler, I decided to go with squares.</p>
<p>How big should a square for a given graph be? Sincerely, I do not now. I came up with an heuristic, though. My heuristic
finds a square big enough for one to be able to place a certain number of circles at positions chosen at random with
uniform probability, with high probability of not having intersections between circles. Currently, I am
using one circle for each vertex and for each edge. If a random algorithm can succeed at placing this many
circles without getting intersection, there should be enough space in the square so the graph layout algorithm
can move nodes around easily.</p>Last week, I did not manage to work as much as I should, because I was not feeling very well. Now that I am feeling better, I am trying to work more to compensate. This is the post that should have been written last week.Google Summer of Code 2020 - Week 12020-06-06T21:35:00+00:002020-06-06T21:35:00+00:00https://dilsonguim.github.io/website/kde/gsoc/2020/06/06/gsoc-week1<p>This week, I started working on the <a href="https://kde.org/applications/education/org.kde.rocs">Rocs</a> graph layout capabilities.
The Fruchtermani-Reingold [1] algorithm seems to be the most common option for drawing graphs automatically when no extra
information about the graph is known. In fact, the Boost library implementation of this algorithm is currently being used
by Rocs. However, the Fruchtermani-Reingold algorithm has some parameters that can change its results deeply.
In order to better understand the algorithm and how different parameterizations lead to different results, I wrote my
own C++ implementation directly in the Rocs’ libgraphtheory. This allowed me to generate debug information during the
execution of the algorithm.</p>
<p>Unfortunately, tuning the parameters directly into the implementation is time consuming.
Automatic parameter tuning solutions can not be applied in a trivial way,
because the quality of the result obtained for a given parameterization is quite subjective.
Therefore, I decided to make my manual tuning and evaluation process more efficient by creating a user interface that will allow me
to choose parameter values and apply the algorithm to the current graph. Because I am new to Qt and the way to do this is to implement a
Rocs’ plugin, it is not done yet. Creating such interface was already in my plans, but I expected to do it later.</p>
<p>I also studied more about graph layout algorithms. In particular, the Davidson-Harel algorithm [2] seems to be an interesting option for Rocs.
It consists of two building blocks. The first is a cost function that assigns a value to each graph based on aesthetic criteria, such as the
number of pairs of edges that intersect and how well the vertices are spread.
The second is a Simulated Annealing optimization algorithm implementation aimed to minimize the mentioned cost function. Although the
algorithm is slower than Fruchtermani-Reingold, the results seems to be quite nice. The application of this algorithm may be reserved
to small graphs in order to avoid very long computation times. The exact upper bound on the size of the graph is still to be determined experimentally.
However, I believe this is going to be fast enough for graphs with a few tens of vertices, which are important use cases in education and in some research areas.</p>
<p>For a survey about graph layout algorithms, see [3]. Although some recent results were published
after [3], the most classical algorithms are well covered.</p>
<p>[1] Fruchtermani and E. Reingold. Graph drawing by force-directed placement. Softw. – Pract. Exp., 21(11):1129–1164, 1991</p>
<p>[2] R. Davidson and D. Harel. Drawing graphs nicely using simulated annealing.ACM Transactions on Graphics, 15(4):301–331, 1996.</p>
<p>[3] <a href="https://arxiv.org/abs/1201.3011">Stephen. (2012). Spring Embedders and Force Directed Graph Drawing Algorithms</a>.</p>This week, I started working on the Rocs graph layout capabilities. The Fruchtermani-Reingold [1] algorithm seems to be the most common option for drawing graphs automatically when no extra information about the graph is known. In fact, the Boost library implementation of this algorithm is currently being used by Rocs. However, the Fruchtermani-Reingold algorithm has some parameters that can change its results deeply. In order to better understand the algorithm and how different parameterizations lead to different results, I wrote my own C++ implementation directly in the Rocs’ libgraphtheory. This allowed me to generate debug information during the execution of the algorithm.Google Summer of Code 2020 - Rocs2020-05-30T12:00:00+00:002020-05-30T12:00:00+00:00https://dilsonguim.github.io/website/kde/gsoc/2020/05/30/gsoc<p>Google Summer of Code (GSoC) 2020 coding phase starts next week and I am going to participate as a student,
working on the graph layout capabilities of the Graph Theory IDE <a href="https://kde.org/applications/education/org.kde.rocs">Rocs</a>.
Rocs is a KDE software which provides various features for working with graphs and simulating graph algorithms in a visual way,
which can be useful for students and researchers.</p>
<p>I created this blog mainly to share my experience during this project.
For the next 3 months, I am going write about graph layout (or graph drawing) algorithms, Rocs, developing software for KDE and
Google Summer of Code. This is my first experience blogging. Maybe I will enjoy it and start writing about other topics as well.</p>
<p>During the last weeks, I have been preparing to start working on Rocs as a GSoC student.
I am new to open source development and, consequently, to KDE.
Therefore, I spent some time learning about KDE and how it operates.
The <a href="https://community.kde.org/Policies">KDE Community Wiki Polices page</a> was really useful.
There, I found guidelines related to software development in KDE, including coding style and commit polices.</p>
<p>Many KDE applications, including Rocs, are developed using <a href="https://www.qt.io/">Qt</a>, which I was not very familiar with.
Although I would like to have studied more, I got the basics of Qt. I hope this will reduce substantially the amount of time I will spend
reading the documentation during this project.</p>
<p>Finally, besides the community and software development subjects, I also studied graph layout algorithms. More specifically,
I studied graph layout algorithms based on physical analogies, which are the ones I am going to work with during the first
phase of the project. I am planning to write about some of these algorithms next week.</p>
<p>I am really excited about this project and about becoming part of the amazing KDE Community.
I hope everything goes well during the next months of GSoC coding phase.</p>Google Summer of Code (GSoC) 2020 coding phase starts next week and I am going to participate as a student, working on the graph layout capabilities of the Graph Theory IDE Rocs. Rocs is a KDE software which provides various features for working with graphs and simulating graph algorithms in a visual way, which can be useful for students and researchers.