logo

Help

Frequently Asked Questions

The graphs from our database can be downloaded in one of the following formats:

The adjacency matrix of a graph is a symmetric square matrix with zero diagonal, where rows and columns correspond to vertices. An entry denotes whether the vertex that corresponds to the row is connected by an edge to the vertex that corresponds to the column. (1 = connected, 0 = not). In this format we print one line for each row, with 0-1 entries separated by spaces. The resulting file is a text file consisting of ASCII characters only.

In this format we represent the graph by a line for each vertex. The line starts with the sequence number of that vertex (we count starting from 1), followed by a colon, and then a list of all sequence numbers of the vertices that are connected by an edge to the reference vertex. Sequence numbers are expressed in decimal notation and are separated by blanks. The resulting file is a text file consisting of ASCII characters only.

The graph6 format is for storing undirected graphs in a compact manner, using only printable ASCII characters. Files in this format have text type and contain one line per graph. The formal definition of this format can be found on Brendan McKay's website .

Graphs encoded in 'graph6' format can be converted to human-readable adjacency lists using the program showg . A precompiled Linux binary of showg can be downloaded here and a Mac OS X binary here. The graphs in 'graph6' format can be converted as follows:

./showg < Graphs.g6

Of course, if your primary intention is to obtain the graphs in a human readable format, then it is more convenient to use either the adjacency matrix or the adjacency list format directly.

The Graphviz DOT language is a plain-text format known for its simplicity and versatility in describing graphs and diagrams. It uses a straightforward syntax where nodes are defined by their labels enclosed in square brackets, and edges are indicated using '- -'. Attributes, enclosed in square brackets, allow you to customize the appearance and behavior of nodes, edges, and the overall graph structure. The DOT language is widely used with the Graphviz suite of tools for graph visualization.

This format lists the adjacency list of a graph followed by its invariant values. We use the following format to display these invariant values: "<invariant name>: <invariant value>". The resulting file is a text file consisting of ASCII characters only.

Multicode is a binary code for storing undirected graphs. The first entry is the number of vertices. Vertices are numbered 1,...,n. To each vertex x there is a list of neighbours with higher numbers than x, followed by a zero. The last list is always empty (no neighbours of n with a higher number than n), so the last "list" is not followed by a zero. After the last byte the next graph follows. The length of a multicode is number of vertices + number of edges.

Graphs encoded in 'multicode' format can be converted to human-readable adjacency lists using the program multiread. A precompiled Linux binary of multiread can be downloaded here and a Mac OS X binary here. The C source file can be found here. The graphs in 'multicode' format can be converted as follows:

./multiread < Graphs.mc

Of course, if your primary intention is to obtain the graphs in a human readable format, then it is more convenient to use either the adjacency matrix or the adjacency list format directly.


The following format is supported for importing or exporting drawings:

In this format, the first line should contain only the number of vertices of the graph. Next, each line describes the position of a vertex and its neighbourhood. Vertices are given in increasing index starting from zero. The values are separated by spaces. The line starts with two floating point numbers separated by a space. These are the coordinates of the vertex in the plane with the first one being the x-coordinate and the second one being the y-coordinate. This is followed by a list of all sequence numbers of the vertices that are connected by an edge to the reference vertex. Sequence numbers are expressed in decimal notation and are separated by spaces. The resulting file is a text file consisting of ASCII characters only.

In case of importing a new drawing to the database, the given drawing will be transformed to occupy a square between coordinates -1.5 to 1.5. The aspect ratio will be preserved. If the graph contains more than one vertex, make sure the area spanned by the drawing is large enough (i.e., that the vertices are not all at the same place).


In addition, for our list of planar graphs, we use so-called planar code.

Planar code is for storing planar graphs. It is a binary code that is easy and fast to compute and to decode. Every entry of the code is an unsigned char. The first entry is the number of vertices. After that there is a list of the vertices adjacent to vertex number 1 in clockwise orientation. This list is ended with a 0. Then you have the vertices adjacent to number 2 ended with a 0, etc. In case that the numbers are too large for unsigned char (i.e. > 255), the first unsigned char written is 0 (!!!). After that the code is as above - only with unsigned short instead of unsigned char. The unsigned shorts are written in little-endian order (low order byte first). A 0 character is written before EVERY code.

In addition to the encodings of graphs, a planar code file by default begins with the 15 characters >>planar_code<< without end-of-line characters.

Graphs encoded in this format can be read and visualized by software such as CaGe . They can also be converted to human-readable adjacency lists using the program planarread. A precompiled Linux binary of planarread can be downloaded here and a Mac OS X binary here. The C source file can be found here. The graphs in planar_code can be converted as follows:

./planarread < Planar_graphs.pl

Following invariants are currently supported.

Most graph theorists will agree that among the vast number of graphs that exist, there are only a few thousand that can be considered really interesting. We would like to find a workable definition of 'interesting' and provide a searchable database of graphs that conform to this definition. Therefore, the searchable database does not contain all graphs of a given order, but only the ones which are considered 'interesting' by at least one of the users. If you notice that a graph which you find interesting is missing, please add it to the database. In order to avoid abuse, only registered users can add new graphs.

On the other hand, the graph meta-directory contains complete lists of all graphs of a given order for various graph classes (up to the orders for which it was still feasible to store them), though these lists are static and cannot be searched.

Registered users are able to:
  • Upload new graphs
  • Create new graph drawings
  • Comment on graphs

Please cite House of Graphs as:

About

In 2010, researchers at Ghent University started developing an online database for graphs, called House of Graphs (HoG). It was the goal of HoG to establish a workable definition for the term 'interesting' and to develop a searchable database, consisting of graphs that adhere to this definition. This database was made available to the general public as a web application. Researchers can browse the database using different search options to find graphs that meet their specified requirements. Users of the web application can look at these graphs, study the values of the invariants or they can download the graphs in different formats for further personal use. Lastly, users can also upload graphs themselves. This way, the database of interesting graphs keeps growing to become as complete as possible.


Because the development of HoG started in 2010, the underlying frameworks and technologies of the House of Graphs became outdated over the years. However, the content of the database and the need to use these graphs for research is still relevant and will be relevant for the foreseeable future. This is why in 2022, the House of Graphs was rebuilt completely, using modern frameworks to build a maintainable and expandable web application that is future-proof. On top of this, new functionalities were added to improve the application and the user experience.

Tutorial

A video tutorial of the most important functionalities can be found here. The functionalities of the website are also described in this paper.

Links

Some links to useful graph theory websites are listed here.

Contact

If you have any questions or suggestions for the House of Graphs, please contact us at info[at]houseofgraphs.org.

This project was originally developed by:

  • Gunnar Brinkmann (Ghent University)
  • Kris Coolsaet (Ghent University)
  • Jan Goedgebeur (KU Leuven)
  • Hadrien Mélot (University of Mons)

And is currently being maintained by Gauvain Devillez and Jan Goedgebeur.

Acknowledgements

We would like to thank Sven D'hondt who did his master's thesis on the House of Graphs and was largely responsible for the complete rebuild of the House of Graphs website in 2022 as well as Gauvain Devillez who added several new features to the website from 2023 onwards. Next to that, would like to thank Gunnar Brinkmann, Brendan McKay and Jarne Renders who kindly provided programs to compute one or more graph invariants. Finally, we also thank the many users who uploaded new interesting graphs, added useful comments about graphs or contributed in any other way.

Copyright © 2010-2024 Ghent University & KU Leuven

Our website uses functional cookies to enhance your user experience. By using this site, you agree to our use of cookies. Learn more

Close