#961183 metis: providing a 64-bit build

Package:
src:metis
Source:
metis
Submitter:
Drew Parsons
Date:
2023-05-28 10:12:04 UTC
Severity:
normal
#961183#5
Date:
2020-05-21 03:13:59 UTC
From:
To:
We're discussing introducing a 64 bit-build for the computational
stack. This refers to 64-bit addressing to cells in meshes, etc.

c.f. Bug#953116 (petsc)
Bug#961108 (openmpi)
https://lists.debian.org/debian-science/2020/05/msg00051.html

BLAS is already 64-bit enabled.

For the 64-bit environment to work, it needs to be carried through all
along the library stack, from BLAS to PETSc.

MUMPS is in the middle. Its docs indicate that its 64-bit support
requires METIS to be 64-bit enabled.

Probably we want 2 separate builds, 32-bit (the current libmetis-dev)
and a separate 64-bit libmetis64-dev.

Opening this bug to track the chain of 64-bit package dependencies.
#961183#10
Date:
2020-05-21 04:24:31 UTC
From:
To:
That's because mumps uses scotch rather than metis. This is because
parmetis is not available (not-free).

If the licence for parmetis became free, then we would use it with mumps
(and would be looking for a 64-bit build).

Drew
#961183#17
Date:
2021-06-05 11:32:35 UTC
From:
To:
64-bit integers are now available for several libraries.

64-bit PETSc is able to use 64-bit SuperLU-Dist, which we don't
currently have.

64-bit SuperLU-Dist requires 64-bit metis.

In principle 64-bit metis is simple to configure: set IDXTYPEWIDTH to
64 in metis.h.

The challenge that we need to address is the location of metis.h.
Currently it's located in /usr/include/metis.h (for the standard 32-bit build)

To distinguish between standard and 64-bit builds, we'd probably want to place
the 64-bit header in /usr/include/metis64/metis.h
#961183#22
Date:
2021-06-05 15:07:20 UTC
From:
To:
Well, theoretically we can do it. But we need to do some kind
of a transition for all dependencies.

Regards

Anton


Am Sa., 5. Juni 2021 um 13:36 Uhr schrieb Drew Parsons <dparsons@debian.org
#961183#27
Date:
2021-06-05 15:21:18 UTC
From:
To:
Doing it through a formal transition request is sensible. There's a
backlog of numerical library upgrades (some still in the NEW queue)
waiting for bullseye to get released. Perhaps we can run this transition
at the same time as the others, process them all as a bulk transition.

We'll set it up in experimental first, of course.

I'll prepare the list of affected packages.

Drew
#961183#32
Date:
2021-06-05 15:59:41 UTC
From:
To:
Here is the list of affected packages identified by
apt-rdepends -r libmetis-dev libmetis5

libmetis-dev
  Reverse Depends: libdeal.ii-dev (9.2.0-3+b2)
  Reverse Depends: libparmetis-dev (4.0.3-5+b1)

libmetis5
  Reverse Depends: libcholmod3 (>= 1:5.8.1+dfsg-2)
  Reverse Depends: libdeal.ii-9.2.0 (>= 9.2.0-3+b2)
  Reverse Depends: libfreefem++ (>= 3.61.1+dfsg1-6)
  Reverse Depends: libgmsh4 (>= 4.7.1+ds1-5)
  Reverse Depends: libmetis-dev (= 5.1.0.dfsg-7)
  Reverse Depends: libnglib-6.2 (>= 6.2.2006+really6.2.1905+dfsg-2.1)
  Reverse Depends: libparmetis4.0 (4.0.3-5+b1)
  Reverse Depends: libsuperlu-dist7 (>= 7.0.0+dfsg1-1exp2)
  Reverse Depends: metis (= 5.1.0.dfsg-7)
  Reverse Depends: parmetis-test (4.0.3-5+b1)
  Reverse Depends: pyfr (1.5.0-3)
  Reverse Depends: syrthes-tools (>= 4.3.5+20200129-dfsg1-1+b1)


I'm applying affects tags to this bug to let the maintainers know what
we're planning.

Drew
#961183#39
Date:
2021-06-05 16:03:35 UTC
From:
To:
Also scotch-metis will need to be updated to match.
#961183#48
Date:
2021-06-12 23:20:31 UTC
From:
To:
Hi Anton, I've prepared packaging for a 64-bit that I'm happy to push
(and upload).

Would you like me to push to salsa (experimental branch) for inspection?

Drew
#961183#53
Date:
2021-06-13 05:02:31 UTC
From:
To:
Hi Drew,

Yes, please.

Anton


Am So., 13. Juni 2021 um 01:24 Uhr schrieb Drew Parsons <dparsons@debian.org
#961183#58
Date:
2021-06-13 08:35:12 UTC
From:
To:

OK, pushed to experimental branch.

Bring the question of REALTYPEWIDTH to mind (the size of floating point
numbers). The "64-bit support" in other packages essentially concerns
integers (indexing) not floating point numbers, so I figure we don't
need to change REALTYPEWIDTH as well. Or if we do want to change
REALTYPEWIDTH, then we might want to change it in the standard build
too.

For comparison, SuperLU-Dist just uses double for values.  Hypre uses
HYPRE_Real, which can be configured to single or double or longdouble
(default double). SCOTCH is mainly working with indices (integers
defined as SCOTCH_Num) but internally uses double more often than float
when it needs floating point numbers (it does use both).  PETSc uses
PetscReal which can be configured single or double, float128 or fp16
(default double).

I figure it's simplest not to change REALTYPEWIDTH unless there's a
specific known need to make the change. We need to set IDXTYPEWIDTH to
64 to support extremely large systems with billions of degrees of
freedom, but that doesn't necessarily mean the floating point value at
each index also requires higher precision. On the other hand changing to
REALTYPEWIDTH=64 (even in standard libmetis) might better match the
default of other packages.

Apart from that question, I'm happy with the patch. As far as I'm
concerned it's ready to upload to experimental.


Drew
#961183#63
Date:
2021-06-13 08:58:38 UTC
From:
To:
Hello,

why  there is no pkgconfig files provided with metis and metis64.
this simplify the configuration of packages depending on these libraries.

Cheers

Fred
#961183#68
Date:
2021-06-15 20:45:28 UTC
From:
To:
Hi Fred, I guess the simple reason why there's no pkgconfig for Metis
is that upstream does not provide one.

We could add one ourselves easily enough.  But SCOTCH-Metis
compatibility would want to be taken into consideration.  Historically
SCOTCH-Metis never had full compatibility (#506033, #653647), but
they're about to make a new release expected to address that.