Package Details: metis 5.2.1-2

Git Clone URL: https://aur.archlinux.org/metis.git (read-only, click to copy)
Package Base: metis
Description: Serial Graph Partitioning and Fill-reducing Matrix Ordering
Upstream URL: https://github.com/KarypisLab/METIS
Licenses: Apache
Submitter: arojas
Maintainer: carlosal1015
Last Packager: carlosal1015
Votes: 28
Popularity: 1.03
First Submitted: 2022-11-21 21:22 (UTC)
Last Updated: 2025-04-07 16:53 (UTC)

Latest Comments

1 2 Next › Last »

medaminezghal commented on 2025-04-17 20:18 (UTC)

@lahwaacz scotch does support 64bits integer (you can check by reading INSTALL.txt from source. It’s not necessary to for the amount of data to be twice the size and I don’t think it’s a big deal.

If you don’t mind, could you build metis, scotch and pastix with 64bits support and test if it will cause any problems?

I’ve done the same work in my machine to use petsc and it works well.

lahwaacz commented on 2025-04-17 19:58 (UTC)

@medaminezghal I think you underestimate the amount of work needed here. E.g. -DPASTIX_INT64=ON will not work for pastix because it also depends on scotch which has 32-bit ints at the moment.

Also note that switching the types will make pretty much all data structures take about twice the amount of memory. The performance effects are really case-by-case depending on many factors.

medaminezghal commented on 2025-04-17 19:07 (UTC) (edited on 2025-04-17 19:19 (UTC) by medaminezghal)

@lahwaacz I think it's better and faster to use 64bits support rather than 32bits.

I have checked that only few packages need to be rebuilt to use the 64bits version: petsc, kahip, pastix, spral. The others have if else case to support both.

carlosal1015 commented on 2025-04-17 18:42 (UTC)

Many thanks, therefore will keep the same configuration.

lahwaacz commented on 2025-04-17 18:40 (UTC)

@carlosal1015 metis can be built with either 32-bit types or 64-bit types, but not both at the same time. This change would affect all packages that depend on metis. Some packages have multiple dependencies like metis that force either 32-bit or 64-bit types and will not work if one but not all packages change the size of types.

carlosal1015 commented on 2025-04-17 18:09 (UTC)

Thanks @medaminezghal, if nobody objects, I'll add it in two weeks.

medaminezghal commented on 2025-04-17 17:25 (UTC) (edited on 2025-04-17 17:34 (UTC) by medaminezghal)

@carlosal1015 I have some suggestion:

1- Add 64bits support by Adding 

  # Enable 64bits
  sed -i '22,35 s/#//g' CMakeLists.txt
  sed -i 's/OFF/ON/g' CMakeLists.txt

to the prepare function and i64=1 r64=1 to the make config command.

2- Add OpenMP support (it won't affect the usage if you don't use ENABLE_OPENMP variable) by adding openmp=1 to the make config command and OpenMP as dependency.

xantares commented on 2025-04-07 16:22 (UTC)

its the same problem than gklib, the first line of cmakelists.txt should be modified:

cmake_minimum_required(VERSION 3.10)

Libellisth commented on 2025-03-31 23:29 (UTC) (edited on 2025-03-31 23:37 (UTC) by Libellisth)

I ran into a problem building with CMake 4.0

 CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.

  Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.

So I ran makepkg -o , changed the value to 3.5 in src/METIS-5.2.1/CMakeLists.txt , then continued with with makepkg -ei

lahwaacz commented on 2023-08-02 10:31 (UTC)

@SvenMeyer The problem is that it runs /home/sum/.local/bin/cmake instead of /usr/bin/cmake. You need to solve that on your own.

1 2 Next › Last »