GithubHelp home page GithubHelp logo

kahypar / mt-kahypar Goto Github PK

View Code? Open in Web Editor NEW
112.0 112.0 23.0 34.93 MB

Mt-KaHyPar (Multi-Threaded Karlsruhe Hypergraph Partitioner) is a shared-memory multilevel graph and hypergraph partitioner equipped with parallel implementations of techniques used in the best sequential partitioning algorithms. Mt-KaHyPar can partition extremely large hypergraphs very fast and with high quality.

License: MIT License

CMake 3.03% HTML 0.09% C++ 94.31% C 0.55% Perl 0.23% Python 1.70% Shell 0.09%
algorithm-engineering graph-algorithms graph-partitioning graphs high-performance-computing hypergraph hypergraph-partitioning hypergraphs parallel-computing partitioning partitioning-algorithms shared-memory tbb

mt-kahypar's Introduction

KaHyPar - Karlsruhe Hypergraph Partitioning

License Fossa Zenodo
License: GPL v3 FOSSA Status DOI
Linux & macOS Build Code Coverage Code Quality Coverity Scan Issues
Build Status codecov Codacy Badge Coverity Status Average time to resolve an issue

Table of Contents

What is a Hypergraph? What is Hypergraph Partitioning?

Hypergraphs are a generalization of graphs, where each (hyper)edge (also called net) can connect more than two vertices. The k-way hypergraph partitioning problem is the generalization of the well-known graph partitioning problem: partition the vertex set into k disjoint blocks of bounded size (at most 1 + ε times the average block size), while minimizing an objective function defined on the nets.

The two most prominent objective functions are the cut-net and the connectivity (or λ − 1) metrics. Cut-net is a straightforward generalization of the edge-cut objective in graph partitioning (i.e., minimizing the sum of the weights of those nets that connect more than one block). The connectivity metric additionally takes into account the actual number λ of blocks connected by a net. By summing the (λ − 1)-values of all nets, one accurately models the total communication volume of parallel sparse matrix-vector multiplication and once more gets a metric that reverts to edge-cut for plain graphs.

alt textalt text

What is KaHyPar?

KaHyPar is a multilevel hypergraph partitioning framework for optimizing the cut- and the (λ − 1)-metric. It supports both recursive bisection and direct k-way partitioning. As a multilevel algorithm, it consist of three phases: In the coarsening phase, the hypergraph is coarsened to obtain a hierarchy of smaller hypergraphs. After applying an initial partitioning algorithm to the smallest hypergraph in the second phase, coarsening is undone and, at each level, a local search method is used to improve the partition induced by the coarser level. KaHyPar instantiates the multilevel approach in its most extreme version, removing only a single vertex in every level of the hierarchy. By using this very fine grained n-level approach combined with strong local search heuristics, it computes solutions of very high quality. Its algorithms and detailed experimental results are presented in several research publications.

Additional Features

  • Hypergraph partitioning with variable block weights

    KaHyPar has support for variable block weights. If command line option --use-individual-part-weights=true is used, the partitioner tries to partition the hypergraph such that each block Vx has a weight of at most Bx, where Bx can be specified for each block individually using the command line parameter --part-weights= B1 B2 B3 ... Bk-1. Since the framework does not yet support perfectly balanced partitioning, upper bounds need to be slightly larger than the total weight of all vertices of the hypergraph. Note that this feature is still experimental.

  • Hypergraph partitioning with fixed vertices

    Hypergraph partitioning with fixed vertices is a variation of standard hypergraph partitioning. In this problem, there is an additional constraint on the block assignment of some vertices, i.e., some vertices are preassigned to specific blocks prior to partitioning with the condition that, after partitioning the remaining “free” vertices, the fixed vertices are still in the block that they were assigned to. The command line parameter --fixed / -f can be used to specify a fix file in hMetis fix file format. For a hypergraph with V vertices, the fix file consists of V lines - one for each vertex. The ith line either contains -1 to indicate that the vertex is free to move or <part id> to indicate that this vertex should be preassigned to block <part id>. Note that part ids start from 0.

    KaHyPar currently supports three different contraction policies for partitioning with fixed vertices:

    1. free_vertex_only allows all contractions in which the contraction partner is a free vertex, i.e., it allows contractions of vertex pairs where either both vertices are free, or one vertex is fixed and the other vertex is free.
    2. fixed_vertex_allowed additionally allows contractions of two fixed vertices provided that both are preassigned to the same block. Based on preliminary experiments, this is currently the default policy.
    3. equivalent_vertices only allows contractions of vertex pairs that consist of either two free vertices or two fixed vertices preassigned to the same block.
  • Evolutionary framework (KaHyPar-E)

    KaHyPar-E enhances KaHyPar with an evolutionary framework as described in our GECCO'18 publication. Given a fairly large amount of running time, this memetic multilevel algorithm performs better than repeated executions of nonevolutionary KaHyPar configurations, hMetis, and PaToH. The command line parameter --time-limit=xxx can be used to set the maximum running time (in seconds). Parameter --partition-evolutionary=true enables evolutionary partitioning.

  • Improving existing partitions

    KaHyPar uses direct k-way V-cycles to try to improve an existing partition specified via parameter --part-file=</path/to/file>. The maximum number of V-cycles can be controlled via parameter --vcycles=.

  • Partitioning directed acyclic hypergraphs

    While the code has not been merged into the main repository yet, there exists a fork that supports acyclic hypergraph partitioning. More details can be found in the corresponding conference publication.

Experimental Results

We use the performance profiles to compare KaHyPar to other partitioning algorithms in terms of solution quality. For a set of algorithms and a benchmark set containing instances, the performance ratio relates the cut computed by partitioner p for instance i to the smallest minimum cut of all algorithms, i.e.,

.

The performance profile of algorithm p is then given by the function

.

For connectivity optimization, the performance ratios are computed using the connectivity values instead of the cut values. The value of corresponds to the fraction of instances for which partitioner p computed the best solution, while is the probability that a performance ratio is within a factor of of the best possible ratio. Note that since performance profiles only allow to assess the performance of each algorithm relative to the best algorithm, the values cannot be used to rank algorithms (i.e., to determine which algorithm is the second best etc.).

In our experimental analysis, the performance profile plots are based on the best solutions (i.e., minimum connectivity/cut) each algorithm found for each instance. Furthermore, we choose parameters for all p, i, and such that a performance ratio if and only if algorithm p computed an infeasible solution for instance i, and if and only if the algorithm could not compute a solution for instance i within the given time limit. In our performance profile plots, performance ratios corresponding to infeasible solutions will be shown on the x-tick on the x-axis, while instances that could not be partitioned within the time limit are shown implicitly by a line that exits the plot below . Since the performance ratios are heavily right-skewed, the performance profile plots are divided into three segments with different ranges for parameter to reflect various areas of interest. The first segment highlights small values (), while the second segment contains results for all instances that are up to a factor of worse than the best possible ratio. The last segment contains all remaining ratios, i.e., instances for which some algorithms performed considerably worse than the best algorithm, instances for which algorithms produced infeasible solutions, and instances which could not be partitioned within the given time limit.

In the figures, we compare KaHyPar with PaToH in quality (PaToH-Q) and default mode (PaToH-D), the k-way (hMETIS-K) and the recursive bisection variant (hMETIS-R) of hMETIS 2.0 (p1), Zoltan using algebraic distance-based coarsening (Zoltan-AlgD), Mondriaan v.4.2.1 and the recently published HYPE algorithm.

Solution Quality Solution Quality

Running Time Running Time

Additional Resources

We provide additional resources for all KaHyPar-related publications:

kKaHyPar-SEA20 /
rKaHyPar-SEA20
SEA'20 Paper TR Slides Experimental Results
kKaHyPar /
rKaHyPar
- Dissertation - Slides Experimental Results
KaHyPar-MF /
KaHyPar-R-MF
SEA'18 /
JEA'19
SEA Paper /
JEA Paper
TR Slides Experimental Results:
SEA / JEA
KaHyPar-E (EvoHGP) GECCO'18 Paper TR Slides Experimental Results
KaHyPar-CA SEA'17 Paper - Slides Experimental Results
KaHyPar-K ALENEX'17 Paper - Slides Experimental Results
KaHyPar-R ALENEX'16 Paper TR Slides Experimental Results

Projects using KaHyPar

Requirements

The Karlsruhe Hypergraph Partitioning Framework requires:

  • A 64-bit operating system. Linux, Mac OS X and Windows (through the Windows Subsystem for Linux) are currently supported.
  • A modern, C++14-ready compiler such as g++ version 9 or higher or clang version 11.0.3 or higher.
  • The cmake build system.
  • The Boost.Program_options library and the boost header files. If you don't want to install boost yourself, you can add the -DKAHYPAR_USE_MINIMAL_BOOST=ON flag to the cmake command to download, extract, and build the necessary dependencies automatically.

Building KaHyPar

  1. Clone the repository including submodules:

    git clone --depth=1 --recursive [email protected]:SebastianSchlag/kahypar.git

  2. Create a build directory: mkdir build && cd build

  3. Run cmake: cmake .. -DCMAKE_BUILD_TYPE=RELEASE

  4. Run make: make

Testing and Profiling

Tests are automatically executed while project is built. Additionally a test target is provided. End-to-end integration tests can be started with: make integration_tests. Profiling can be enabled via cmake flag: -DENABLE_PROFILE=ON.

Running KaHyPar

The standalone program can be built via make KaHyPar. The binary will be located at: build/kahypar/application/.

KaHyPar has several configuration parameters. For a list of all possible parameters please run: ./KaHyPar --help. We use the hMetis format for the input hypergraph file as well as the partition output file.

The command line parameter --quiet=1 can be used to suppress all logging output. If you are using the library interfaces, adding quiet=1 to the corresponding .ini configuration file has the same effect.

Default / Most Recent Presets

We provide two default framework configurations - one for recursive bipartitioning (rKaHyPar) and one for direct k-way partitioning (kKaHyPar).

In general, we recommend using kKaHyPar as it performs better than rKaHyPar in terms of both running time and solution quality.

To start kKaHyPar optimizing the (connectivity - 1) objective run:

./KaHyPar -h <path-to-hgr> -k <# blocks> -e <imbalance (e.g. 0.03)> -o km1 -m direct -p ../../../config/km1_kKaHyPar_sea20.ini

To start kKaHyPar optimizing the cut net objective run:

./KaHyPar -h <path-to-hgr> -k <# blocks> -e <imbalance (e.g. 0.03)> -o cut -m direct -p ../../../config/cut_kKaHyPar_sea20.ini

To start rKaHyPar optimizing the (connectivity - 1) objective run:

./KaHyPar -h <path-to-hgr> -k <# blocks> -e <imbalance (e.g. 0.03)> -o km1 -m recursive -p ../../../config/km1_rKaHyPar_sea20.ini

To start rKaHyPar optimizing the cut net objective run:

./KaHyPar -h <path-to-hgr> -k <# blocks> -e <imbalance (e.g. 0.03)> -o cut -m recursive -p ../../../config/cut_rKaHyPar_sea20.ini

To start the memetic algorithm kKaHyPar-E optimizing the (connectivity - 1) objective run:

./KaHyPar -h <path-to-hgr> -k <# blocks> -e <imbalance (e.g. 0.03)> -o km1 -m direct -p ../../../config/km1_kKaHyPar-E_sea20.ini

Old Presets

Additionally, we provide different presets that correspond to the configurations used in the publications at ALENEX'16, ALENEX'17, SEA'17, SEA'18, GECCO'18, as well as in our JEA journal paper and in the dissertation of Sebastian Schlag. These configurations are located in the config/old_reference_configs folder. In order to use these configurations, you have to checkout KaHyPar release 1.1.0, since some old code as been removed in the most current release.

To start KaHyPar-MF (using flow-based refinement) optimizing the (connectivity - 1) objective using direct k-way mode run:

./KaHyPar -h <path-to-hgr> -k <# blocks> -e <imbalance (e.g. 0.03)> -o km1 -m direct -p ../../../config/old_reference_configs/km1_kahypar_mf_jea19.ini

To start KaHyPar-MF (using flow-based refinement) optimizing the cut-net objective using direct k-way mode run:

./KaHyPar -h <path-to-hgr> -k <# blocks> -e <imbalance (e.g. 0.03)> -o cut -m direct -p ../../../config/old_reference_configs/cut_kahypar_mf_jea19.ini

To start EvoHGP/KaHyPar-E optimizing the (connectivity - 1) objective using direct k-way mode run

 ./KaHyPar -h <path-to-hgr> -k <# blocks> -e <imbalance (e.g. 0.03)> -o km1 -m direct -p ../../../config/old_reference_configs/km1_direct_kway_gecco18.ini

Note that the configuration km1_direct_kway_gecco18.ini is based on KaHyPar-CA. However, KaHyPar-E also works with flow-based local improvements. In our JEA publication the km1_kahypar_e_mf_jea19.ini configuration was used.

To start KaHyPar-CA (using community-aware coarsening) optimizing the (connectivity - 1) objective using direct k-way mode run:

./KaHyPar -h <path-to-hgr> -k <# blocks> -e <imbalance (e.g. 0.03)> -o km1 -m direct -p ../../../config/old_reference_configs/km1_direct_kway_sea17.ini

To start KaHyPar in direct k-way mode (KaHyPar-K) optimizing the (connectivity - 1) objective run:

./KaHyPar -h <path-to-hgr> -k <# blocks> -e <imbalance (e.g. 0.03)> -o km1 -m direct -p ../../../config/old_reference_configs/km1_direct_kway_alenex17.ini

To start KaHyPar in recursive bisection mode (KaHyPar-R) optimizing the cut-net objective run:

./KaHyPar -h <path-to-hgr> -k <# blocks> -e <imbalance (e.g. 0.03)> -o cut -m recursive -p ../../../config/old_reference_configs/cut_rb_alenex16.ini

All preset parameters can be overwritten by using the corresponding command line options.

Input Validation

When creating a hypergraph KaHyPar validates that the input is actually a correct hypergraph, otherwise printing an error and aborting. This applies to hgr input files, the C interface and the Python interface. The runtime cost of the validation should be negligible in almost all cases. However, the input validation can also be disabled using the cmake flag -DKAHYPAR_INPUT_VALIDATION=OFF.

Additionally, warnings are printed for non-fatal issues (e.g. hyperedges with duplicate pins). To treat non-fatal issues as hard errors instead, use the cmake flag -DKAHYPAR_INPUT_VALIDATION_PROMOTE_WARNINGS_TO_ERRORS=ON.

Using the Library Interfaces

The C-Style Interface

We provide a simple C-style interface to use KaHyPar as a library. Note that this interface is not thread-safe yet. However there are some existing workarounds. The library can be built and installed via

make install.library

and can be used like this:

#include <memory>
#include <vector>
#include <iostream>

#include <libkahypar.h>

int main(int argc, char* argv[]) {

  kahypar_context_t* context = kahypar_context_new();
  kahypar_configure_context_from_file(context, "/path/to/config.ini");
  
  kahypar_set_seed(context, 42);

  const kahypar_hypernode_id_t num_vertices = 7;
  const kahypar_hyperedge_id_t num_hyperedges = 4;

  std::unique_ptr<kahypar_hyperedge_weight_t[]> hyperedge_weights = std::make_unique<kahypar_hyperedge_weight_t[]>(4);

  // force the cut to contain hyperedge 0 and 2
  hyperedge_weights[0] = 1;  hyperedge_weights[1] = 1000;
  hyperedge_weights[2] = 1;  hyperedge_weights[3] = 1000;

  std::unique_ptr<size_t[]> hyperedge_indices = std::make_unique<size_t[]>(5);

  hyperedge_indices[0] = 0; hyperedge_indices[1] = 2;
  hyperedge_indices[2] = 6; hyperedge_indices[3] = 9;
  hyperedge_indices[4] = 12;

  std::unique_ptr<kahypar_hyperedge_id_t[]> hyperedges = std::make_unique<kahypar_hyperedge_id_t[]>(12);

  // hypergraph from hMetis manual page 14
  hyperedges[0] = 0;  hyperedges[1] = 2;
  hyperedges[2] = 0;  hyperedges[3] = 1;
  hyperedges[4] = 3;  hyperedges[5] = 4;
  hyperedges[6] = 3;  hyperedges[7] = 4;
  hyperedges[8] = 6;  hyperedges[9] = 2;
  hyperedges[10] = 5; hyperedges[11] = 6;

  const double imbalance = 0.03;
  const kahypar_partition_id_t k = 2;

  kahypar_hyperedge_weight_t objective = 0;

  std::vector<kahypar_partition_id_t> partition(num_vertices, -1);

  kahypar_partition(num_vertices, num_hyperedges,
       	            imbalance, k,
               	    /*vertex_weights */ nullptr, hyperedge_weights.get(),
               	    hyperedge_indices.get(), hyperedges.get(),
       	            &objective, context, partition.data());

  for(int i = 0; i != num_vertices; ++i) {
    std::cout << i << ":" << partition[i] << std::endl;
  }

  kahypar_context_free(context);
}

To compile the program using g++ run:

g++ -std=c++14 -DNDEBUG -O3 -I/usr/local/include -L/usr/local/lib program.cc -o program -lkahypar

Note: If boost is not found during linking, you might need to add -L/path/to/boost/lib -I/path/to/boost/include -lboost_program_options to the command.

To remove the library from your system use the provided uninstall target:

make uninstall-kahypar

The Python Interface

To compile the Python interface, do the following:

  1. Create a build directory: mkdir build && cd build
  2. If you have boost installed on your system, run cmake: cmake .. -DCMAKE_BUILD_TYPE=RELEASE -DKAHYPAR_PYTHON_INTERFACE=1. If you don't have boost installed, run: cmake .. -DCMAKE_BUILD_TYPE=RELEASE -DKAHYPAR_PYTHON_INTERFACE=1 -DKAHYPAR_USE_MINIMAL_BOOST=ON instead. This will download, extract, and build the necessary dependencies automatically.
  3. Go to libary folder: cd python
  4. Compile the libarary: make
  5. Copy the libary to your site-packages directory: cp kahypar.so <path-to-site-packages>

After that you can use the KaHyPar libary like this:

import os
import kahypar as kahypar

num_nodes = 7
num_nets = 4

hyperedge_indices = [0,2,6,9,12]
hyperedges = [0,2,0,1,3,4,3,4,6,2,5,6]

node_weights = [1,2,3,4,5,6,7]
edge_weights = [11,22,33,44]

k=2

hypergraph = kahypar.Hypergraph(num_nodes, num_nets, hyperedge_indices, hyperedges, k, edge_weights, node_weights)

context = kahypar.Context()
context.loadINIconfiguration("<path/to/config>/km1_kKaHyPar_sea20.ini")

context.setK(k)
context.setEpsilon(0.03)

kahypar.partition(hypergraph, context)

For more information about the python library functionality, please see: module.cpp

We also provide a precompiled version as a PyPI version , which can be installed via:

python3 -m pip install --index-url https://pypi.org/simple/ --no-deps kahypar

The Julia Interface

Thanks to Jordan Jalving (@jalving) KaHyPar now also offers a Julia interface, which can currently be found here: kahypar/KaHyPar.jl.

The corresponding dependency can be installed via:

using Pkg
Pkg.add(PackageSpec(url="https://github.com/jalving/KaHyPar.jl.git"))
Pkg.test("KaHyPar")

After that, you can use KaHyPar to partition your hypergraphs like this:

using KaHyPar
using SparseArrays

I = [1,3,1,2,4,5,4,5,7,3,6,7]
J = [1,1,2,2,2,2,3,3,3,4,4,4]
V = Int.(ones(length(I)))

A = sparse(I,J,V)

h = KaHyPar.hypergraph(A)

KaHyPar.partition(h,2,configuration = :edge_cut)

KaHyPar.partition(h,2,configuration = :connectivity)

KaHyPar.partition(h,2,configuration = joinpath(@__DIR__,"../src/config/km1_kKaHyPar_sea20.ini"))

The Java Interface

Romain Wallon has created a Java interface for KaHyPar. Please refer to the readme for a detailed description on how to build and use the interface.

Bug Reports

We encourage you to report any problems with KaHyPar via the github issue tracking system of the project.

Licensing

KaHyPar is free software provided under the GNU General Public License (GPLv3). For more information see the COPYING file. We distribute this framework freely to foster the use and development of hypergraph partitioning tools. If you use KaHyPar in an academic setting please cite the appropriate papers. If you are interested in a commercial license, please contact me.

// Overall KaHyPar framework
@phdthesis{DBLP:phd/dnb/Schlag20,
  author    = {Sebastian Schlag},
  title     = {High-Quality Hypergraph Partitioning},
  school    = {Karlsruhe Institute of Technology, Germany},
  year      = {2020}
}

@article{10.1145/3529090, 
  author = {Schlag, Sebastian and 
            Heuer, Tobias and 
            Gottesb\"{u}ren, Lars and 
            Akhremtsev, Yaroslav and 
            Schulz, Christian and 
            Sanders, Peter}, 
  title = {High-Quality Hypergraph Partitioning}, 
  url = {https://doi.org/10.1145/3529090}, 
  doi = {10.1145/3529090}, 
  journal = {ACM J. Exp. Algorithmics},
  year = {2022}, 
  month = {mar}
}

// KaHyPar-R
@inproceedings{shhmss2016alenex,
 author    = {Sebastian Schlag and
              Vitali Henne and
              Tobias Heuer and
              Henning Meyerhenke and
              Peter Sanders and
              Christian Schulz},
 title     = {k-way Hypergraph Partitioning via \emph{n}-Level Recursive
              Bisection},
 booktitle = {18th Workshop on Algorithm Engineering and Experiments, (ALENEX 2016)},
 pages     = {53--67},
 year      = {2016},
}

// KaHyPar-K
@inproceedings{ahss2017alenex,
 author    = {Yaroslav Akhremtsev and
              Tobias Heuer and
              Peter Sanders and
              Sebastian Schlag},
 title     = {Engineering a direct \emph{k}-way Hypergraph Partitioning Algorithm},
 booktitle = {19th Workshop on Algorithm Engineering and Experiments, (ALENEX 2017)},
 pages     = {28--42},
 year      = {2017},
}

// KaHyPar-CA
@inproceedings{hs2017sea,
 author    = {Tobias Heuer and
              Sebastian Schlag},
 title     = {Improving Coarsening Schemes for Hypergraph Partitioning by Exploiting Community Structure},
 booktitle = {16th International Symposium on Experimental Algorithms, (SEA 2017)},
 pages     = {21:1--21:19},
 year      = {2017},
}

// KaHyPar-MF
@inproceedings{heuer_et_al:LIPIcs:2018:8936,
 author ={Tobias Heuer and Peter Sanders and Sebastian Schlag},
 title ={{Network Flow-Based Refinement for Multilevel Hypergraph Partitioning}},
 booktitle ={17th International Symposium on Experimental Algorithms  (SEA 2018)},
 pages ={1:1--1:19},
 year ={2018}
}


@article{KaHyPar-MF-JEA,
  author = {Heuer, T. and Sanders, P. and Schlag, S.},
  title = {Network Flow-Based Refinement for Multilevel Hypergraph Partitioning},
  journal = {ACM Journal of Experimental Algorithmics (JEA)}},
  volume = {24},
  number = {1},
  month = {09},
  year = {2019},
  pages = {2.3:1--2.3:36},
  publisher = {ACM}
}

// KaHyPar-E (EvoHGP)
@inproceedings{Andre:2018:MMH:3205455.3205475,
 author = {Robin Andre and Sebastian Schlag and Christian Schulz},
 title = {Memetic Multilevel Hypergraph Partitioning},
 booktitle = {Proceedings of the Genetic and Evolutionary Computation Conference},
 series = {GECCO '18},
 year = {2018},
 pages = {347--354},
 numpages = {8}
}

// KaHyPar-SEA20 (KaHyPar-HFC)
@InProceedings{gottesbren_et_al:LIPIcs:2020:12085,
author = {Lars Gottesb{\"u}ren and Michael Hamann and Sebastian Schlag and Dorothea Wagner},
title =	{{Advanced Flow-Based Multilevel Hypergraph Partitioning}},
booktitle = {18th International Symposium on Experimental Algorithms (SEA)},
pages =	{11:1--11:15},
series = {Leibniz International Proceedings in Informatics (LIPIcs)},
year =	{2020}
}

Contributing

If you are interested in contributing to the KaHyPar framework feel free to contact me or create an issue on the issue tracking system.

mt-kahypar's People

Contributors

danielseemaier avatar hydai avatar kittobi1992 avatar larsgottesbueren avatar n-maas avatar noahares avatar patricksteil avatar picsel2 avatar uulm-janbaudisch avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

mt-kahypar's Issues

Localized Label Propagation

Currently label propagation is executed not on each level of the n-level hierarchy. Whether LP is executed or not on the current level is determined by an execution policy. An other approach is to execute label propagation on each level by performing a strongly localized version of LP only on the uncontracted hypernodes. Since, this would not scale in case we only uncontract only one pair of hypernodes, this should be an feature of the batch uncontraction mode.

print node partitioning information

Hi, I am wondering if mt-kahypar can print out information of each node belongs to which partition into a file?
If yes, where should I add codes or use which execution command parameters. Actually I try to use --verbose=true --enable-progress-bar=true --partition-output-folder=. All of them did not give me an output result file.

IHypergraphSparsifier is missing a public virtual destructor

Hello!

We are writing a student project that uses the C interface and noticed that our application randomly freezes at global destruction. Throwing AddressSanitizer at the problem we got this report:

==11666==ERROR: AddressSanitizer: new-delete-type-mismatch on 0x619000006980 in thread T1:
  object passed to delete has wrong type:
  size of the allocated type:   1032 bytes;
  size of the deallocated type: 16 bytes.
    #0 0x7fa7770bc0a8 in operator delete(void*, unsigned long) (/lib64/libasan.so.8+0xbc0a8)
    #1 0x7fa7769f5f71 in tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::process_bypass_loop(tbb::internal::context_guard_helper<false>&, tbb::task*, long) ../../src/tbb/custom_scheduler.h:495
    #2 0x7fa7769f63b1 in tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all(tbb::task&, tbb::task*) ../../src/tbb/custom_scheduler.h:636
    #3 0x7fa7769efbf6 in tbb::internal::arena::process(tbb::internal::generic_scheduler&) ../../src/tbb/arena.cpp:196
    #4 0x7fa7769ee31f in tbb::internal::market::process(rml::job&) ../../src/tbb/market.cpp:667
    #5 0x7fa7769ea26d in tbb::internal::rml::private_worker::run() ../../src/tbb/private_server.cpp:266
    #6 0x7fa7769ea4c8 in tbb::internal::rml::private_worker::thread_routine(void*) ../../src/tbb/private_server.cpp:219
    #7 0x7fa776a8e14c in start_thread (/lib64/libc.so.6+0x8b14c)
    #8 0x7fa776b0f9ff in clone3 (/lib64/libc.so.6+0x10c9ff)

0x619000006980 is located 0 bytes inside of 1032-byte region [0x619000006980,0x619000006d88)
allocated by thread T0 here:
    #0 0x7fa7770bb1a8 in operator new(unsigned long) (/lib64/libasan.so.8+0xbb1a8)
    #1 0x7fa7765e0ca0 in mt_kahypar::register_HypergraphUndefinedSparsifier::{lambda(mt_kahypar::Context const&)#1}::_FUN(mt_kahypar::Context const) (/home/sebastian/.local/opt/spack/opt/spack/linux-fedora37-haswell/gcc-12.2.1/mt-kahypar-master-bzm4vfxnyju3gqam4v3dqokbksb3ufav/lib64/libmtkahyparhgp.so+0x1e0ca0)

Thread T1 created by T0 here:
    #0 0x7fa77704b3e6 in __interceptor_pthread_create (/lib64/libasan.so.8+0x4b3e6)
    #1 0x7fa7769ea155 in rml::internal::thread_monitor::launch(void* (*)(void*), void*, unsigned long) ../../src/tbb/../rml/server/thread_monitor.h:218
    #2 0x7fa7769ea155 in tbb::internal::rml::private_worker::wake_or_launch() ../../src/tbb/private_server.cpp:297
    #3 0x7fa7769ea155 in tbb::internal::rml::private_server::wake_some(int) ../../src/tbb/private_server.cpp:395
    #4 0x60c000001e3f  (<unknown module>)

SUMMARY: AddressSanitizer: new-delete-type-mismatch (/lib64/libasan.so.8+0xbc0a8) in operator delete(void*, unsigned long)
==11666==HINT: if you don't care about these errors you may set ASAN_OPTIONS=new_delete_type_mismatch=0
==11666==ABORTING

I think that this stems from mt_kahypar::IHypergraphSparsifier not having a public virtual destructor.

hmod.precompute_attributes removes or does not remove singletons based off of the OS (inconsistent behaviour)

Depending on which OS is being used the following will print different results:

import hypernetx as hnx
import hypernetx.algorithms.hypergraph_modularity as hmod
formulaDict,stringTree = readFile("./CDL-FMINCE/toybox.dimacs") # code by me
H=formulaToHypergraph(formulaDict)
HDual = H.dual()
H=hmod.precompute_attributes(H)
HDual = hmod.precompute_attributes(HDual)

#this should diverge based off of OS

print(len(list(H.nodes())))
print(len(list(HDual.nodes())))

On the linux systems the results are 544 and 590, while on Windows I get 175 and 221.

I was using ANTLR4 with python integration to parse a dimacs (SAT) file and interpret it as a hypergraph. The resulting graph has 544 nodes and 590 edges before the attributes are computed.

Compared Systems

Ubuntu system:

  • Ubuntu 20.04.6 LTS
  • wsl 2
  • Python 3.8.10
  • pip installation manager

Debian

  • SMP Debian 5.10.127-1
  • Python 3.9.2
  • pip installation manager

Windows

  • Windows 10 Home
  • Python 3.11.3
  • Anaconda virtual environment (+VSCode)

Test execution

When a test fails, its binary gets deleted, so I cannot run it, in for example a debugger.
Additionally we can't use --gtest_filter= to run some tests by themselves.

Best effort partitions?

Hey,
I am trying to use this as part of a larger application that is somewhat time constraint.
The partitioning is usually fast enough but sometimes stalls for hours. Is there a
way to set a timeout and just use the best partition found so far?
This can even happen on different runs when the input graph is the same,
is that normal behavior or am I doing anything wrong?
Thanks!

TBB Internal NUMA Support

As of recently, TBB provides NUMA support in its task arenas -- i.e. one arena per socket, pinning threads that joined the arena to the corresponding socket and such nice things.
We should consider using their integrated support instead of Tobi's custom code for two reasons: 1) less code for us to maintain, 2) might be faster.
Open question: can we still mock hardware topology? This is desirable for testing purposes.

Edit: Apparently TBB uses hwloc to parse hardware topology info. Hence, mocking topology sounds quite possible.

Upper bound of cut between two blocks

Hi,
Is there a data structure that records the total cuts between two blocks?
I want to avoid a very large cut between the two blocks after the partition. So I want to get the total cut value between each two blocks dynamically, and modify the gain function according to this cut.

In other words, I hope to optimize the cut objective while keeping the total cut between blocks within the upper bound. Is there any way to deal with this situation?

thanks!

Heavy Assertions

Instead of enabling certain assertions for phases via CMake, we could use a single HEAVY_ASSERTION macro that looks up a variable similar to the way the KaHyPar logger does.
What do you think @kittobi1992 ?

glibc++.so.6 version

image
Hi,

When I build and compile, I run mt-kahypar executable, I got this runtime error. I have no root access, how could I change its system link to my user path which I prepare a 30 higher version library.

Refactor Hypergraph

Since we are now able to perform n-Level as well as multilevel hypergraph partitioning, we should have one dynamic hypergraph and one static hypergraph.

Union by Weight broken for multilevel coarsening

As discussed today: Using union by weight to identify representatives in multilevel coarsening only works as expected for the first level. As soon as the weights change, things might break.

How to build this if my TBB is installed in my user customized path?

I build TBB from source and install it under my user home directory, let's say /home/xxx/tbb/include and /home/xxx/tbb/lib64. And I also add this two path into my ~/.bashrc file append after variable PATH and LD_LIBRARY_PATH. Then I source this file also.

But when I build mt-kahypar with cmake .., it still shows cannot find TBB package. How should I solve it?

Btw, my gcc version is 12.0

Finalize README

Missing sections:

  1. What is Mt-KaHyPar: Description of Mt-KaHyPar with experimental results
  2. System Requirements
  3. Describe Library Interface

Force coarsening to reach contraction limit

Aborting coarsening before reaching the contraction limit can have a significant impact on the performance and scalability of the initial partitioning. There are 3 main reasons why contraction limit is not reach during coarsening:

1.) Maximum allowed hypernode weight prevents valid contractions
Currently, the maximum allowed contraction limit is set to total weight of the hypergraph divided by the contraction limit. The rational behind this is, that if the contraction limit is reached than each node should have the same weight. However, in case of social instances a majority of the hypernodes are matched to their high degree center nodes. The current maximum allowed node weight is in that case to restrictive and needs to be relaxed. One idea could be to incorporate the sum of the weight of the neighborhood of the node with the highest degree, which somehow guarantees that each hypernode can be matched with its corresponding center node. This should be inline with the maximum allowed block weight.

2.) Zero-degree vertices introduce size-one communities (see wb-edu.mtx.hgr)
We should remove all zero-degree vertices before partitioning and add them afterwards with a bin-packing heuristic to the partition. Moreover, after single-pin hyperedges are removed, we should perform an additional check for zero-degree vertices.

3.) Many small communities (see DAC2012 instances)
In case, we have many small isolated communities, it can be hard for coarsening to reach contraction limit. One idea could be to merge small communities into a big one and if during coarsening no further contraction is possible (because all vertices have degree zero), than we should randomly contract the hypernodes.

make mtkahypar fatal error "utils/debug.hpp: no such file or directory"

Dear developers,

Under Ubuntu 23.04 and GCC 13.2 I am getting the following fatal error after running make mtkahypar:


In file included from /home/X/Documents/mt-kahypar/external_tools/growt/data-structures/table_config.hpp:6,

                 from /home/X/Documents/mt-kahypar/mt-kahypar/partition/mapping/target_graph.h:40,

                 from /home/X/Documents/mt-kahypar/lib/libmtkahypar.cpp:39:

`/home/X/Documents/mt-kahypar/external_tools/growt/data-structures/element_types/complex_slot.hpp:8:10: fatal error: utils/debug.hpp: No such file or directory

    8 | #include "utils/debug.hpp"
      |          ^~~~~~~~~~~~~~~~~


Any hint of what could have been happening?

Thank you in advance.

Visualization for Memory Consumption

Would be nice, if we would have some visual representation of the memory consumption of our hypergraphs. The SDSL has there some nice concept by serializing the data structure in a tree structure enhanced with size information and writing out some visual representation in form of a pie chart using java script library "D3".

Tests are not running in Travis CI

Problem Description:
Travis sets up a VM with 2 cores on an Cloud Infrastructure. The Cloud Infrastructure Provider deploy that VM on a machine with a restricted cpuset. Our application does not consider that cpuset and tries to pin threads on cpus that are disabled.

Steps to reproduce:
sudo cset shield -c 1-3 # Restricts cpuset to cpu 1 - 3

make concurrent_hypergraph_test
Running main() from /home/heuer/mt-kahypar/external_tools/googletest/googletest/src/gtest_main.cc
[==========] Running 25 tests from 1 test suite.
[----------] Global test environment set-up.
[----------] 25 tests from AConcurrentHypergraph
[ERROR] Failed to set thread affinity

sudo cset shield --reset # reset cpuset restriction

Make EPS and MAX_ITERATION in PLM configurable

We should make epsilon and max iteration in PLM configurable in context.h

See line 114 in plm.h:
for (int currentRound = 0; nodesMovedThisRound >= 0.01 * G.numNodes() && currentRound < 16; currentRound++)

Eliminate singletons

We use singletons way too much and they're not particularly "parallel-friendly". In many cases they can simply be replaced by a member. This makes it easier to use certain things in parallel, e.g., Randomize, which currently sometimes requires requesting a processor ID.

Problems with TBB 2021 Versions

The releases of TBB from 2021 no longer contain some headers we use:

For now the Ubuntu Repos all provide the 2020 Versions of TBB, but rolling release distros already use the 2021 version, which Ubuntu will eventually use, too.

Building from release tarball fails

Mt-KaHyPar can not be built from the release tarball because the directories of git submodules are not populated:

3 errors found in build log:
     13    -- Detecting C compile features
     14    -- Detecting C compile features - done
     15    -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
     16    -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
     17    -- Found Threads: TRUE
     18    -- Found Threads:
  >> 19    CMake Error at CMakeLists.txt:17 (add_subdirectory):
     20      The source directory
     21    
     22        /tmp/sebastian/spack-stage/spack-stage-mt-kahypar-1.0.0-edfz2bj2yxmuclvzq2lufvyy3eskovxd/spack-src/external_tools/googletest
     23    
     24      does not contain a CMakeLists.txt file.
     25    

     ...

     38    -- Default linker
     39    -- Performing Test KAHYPAR_HAS_CRC32
     40    -- Performing Test KAHYPAR_HAS_CRC32 - Success
     41    -- CMAKE_CXX_FLAGS:  -W -Wall -Wextra  -Wunused  -Wuninitialized -Wfatal-errors -Wcast-qual -Woverloaded-virtual -Wredundant-decls -Winit-self -pedantic -DPARANOID  -Wno-unused-function -pthread -
           std=c++17 -ltbb -ltbbmalloc_proxy -msse4.2 -mcrc32
     42    -- CMAKE_CXX_FLAGS_RELEASE: -O3 -DNDEBUG -O3 -mtune=native -march=native
     43    -- CMAKE_CXX_FLAGS_DEBUG: -g -g3 -fsanitize=undefined -fno-omit-frame-pointer -fsanitize=address
  >> 44    CMake Error at python/CMakeLists.txt:9 (add_subdirectory):
     45      The source directory
     46    
     47        /tmp/sebastian/spack-stage/spack-stage-mt-kahypar-1.0.0-edfz2bj2yxmuclvzq2lufvyy3eskovxd/spack-src/python/pybind11
     48    
     49      does not contain a CMakeLists.txt file.
     50    
     51    
  >> 52    CMake Error at python/CMakeLists.txt:11 (pybind11_add_module):
     53      Unknown CMake command "pybind11_add_module".
     54    
     55    
     56    -- Configuring incomplete, errors occurred!
     57    See also "/tmp/sebastian/spack-stage/spack-stage-mt-kahypar-1.0.0-edfz2bj2yxmuclvzq2lufvyy3eskovxd/spack-build-edfz2bj/CMakeFiles/CMakeOutput.log".

Maintenance of border vertices is buggy

Example:
State before move:
he = 1 pin_count_in_from_part = 2 pin_count_in_to_part = 2 edge_size = 4
u = 3 from = 1 to = 0
v = 4 from = 1 to = 0
he = 1 pin_count_in_from_part_after = 0 pin_count_in_to_part_after = 3 edge_size = 4
he = 1 pin_count_in_from_part_after = 1 pin_count_in_to_part_after = 4 edge_size = 4

In this example, vertices 3 and 4 move from block 1 to block 0 in parallel. Hyperedge 1 has 4 pins. After moving both vertices to block 0 he 1 is a non-cut hyperedge. However, a hyperedge becomes a non-cut hyperedge if
1.) pin_count_in_from_part_after == 0
2.) pin_count_in_to_part_after == edge_size
In the example above this condition is not triggered.

Implement better Work Stealing for Initial Partitioning

When doing recursion during initial partitioning we split the TBB Numa Arena with half the number of threads of the original arena and pass them into the recursion. However, this introduces somehow bad load balancing, in case one recursion terminates earlier than the other, because threads are not able to join the other recursion (number of threads are limited).

Compile a static executable program

Hi,
I am trying to compile a static executable program that can run in different Linux environments,
However, I found it difficult to compile static programs because of the TBB library.
Is there a method for compiling static programs? Or is there any suggestion to run the program in different environments.

thanks!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.