Scotch's INTSIZE64 is a bit of a misnomer, as it simply tells scotch to use the 'long' type rather than 'int'. IIRC, Ludovic's rational was that this would be 32 bits or 64 bit integers depending on the platform.

I think this is a reasonable default, but, like you point out, it does mean we need to keep thing consistent across packages. For metis this might mean a build phase that patches metis.h's IDXTYPEWIDTH macro appropriately for the target system. That should be a separate patch.

Thanks for working on it,

On August 16, 2017 12:52:26 PM CDT, Paul Garlick <> wrote:
Hello Guix,

Thank you Marius and Eric for your reviews and comments.

I have been working through the changes and updating the patch.  However, in the process of rebasing I have noticed a change in Guix that impacts on the OpenFOAM definition.  Specifically, a recent commit (26599d6) has changed the definition of the scotch package so that it now uses 64bit integers.  In a nutshell, this causes a build failure in OpenFOAM.

In OpenFOAM, there is a variable to specify the size of the integer values (32bit or 64bit).  This single variable is used by both metis and scotch, meaning that they both have to use 32bit integers or both use 64bit integers.  At present, Guix offers a 64bit scotch and a 32bit metis.

A straightforward solution would be to add the extra packages, a 32bit scotch and/or a 64bit metis.  For scotch, that would be the same definition, except for the 'INTSIZE64' line.  For metis, that would involve an edit of 'metis.h', setting IDXTYPEWIDTH and REALTYPEWIDTH to 64.

Would you prefer this to be the subject of a separate patch, or included in the OpenFOAM patch?  There is also a question about how to name the packages; scotch and scotch32, for example, or scotch and scotch-64int etc.

Best regards,


On Mon, 2017-08-14 at 21:49 -0500, Eric Bavier wrote:
Hello Paul,

Thank you for the patch!

Sent from my Android device with K-9 Mail. Please excuse my brevity.